Investigate a "send-and-exit" functionality in the VM for sending isolate messages

[mkustermann]

We would like to have a atomic send-and-exit functionality, which can send an object to a port and exit the isolate at the same time.

Until we have a shared heap, this can be implemented via merging of heap pages from the sender into the receiver. See e.g. cl/112900 for the basic functionality.

Once the heap is shared, this will be a NOP.

Missing items:

• Ensure no Dart code is invoked after the verification pass was exectued
• Possibly make validation procedure check for safepoints (to avoid very long safepointing latencies)
• Have extensive Dart tests

[lrhn]

We have a kill operation on isolates, so you can always kill yourself by Isolate.current.kill(priority: Isolate.immediate). That sets a precedent for killing isolates in the middle of computation. (So does Process.exit, and killing the process when the main isolate terminates).

Any "exit immediately" functionality is potentially dangerous, there might be finally blocks that are not executed. That could mean system resources that are not released properly. If we kill the entire process, then the operating system should handle things, but for individual isolates, we may have to do something ourselves.

Do we make any records of isolate resources to be cleaned up at isolate exit? If we merge heaps, the we might have to defer this clean-up until the merged isolate ends.

[aam]

Do we make any records of isolate resources to be cleaned up at isolate exit? If we merge heaps, the we might have to defer this clean-up until the merged isolate ends.

Yes, Dart_WeakPersistentHandle for example. They will migrate to new isolate and will be cleaned up when this new owner, receiving isolate dies.

One problematic area @rmacnak-google pointed out is that embedders might rely on the fact that finalizers for those handles are executed on same thread that they were originally created on, same one used for the original "send-and-exit" isolate(OpenGL/graphics thread-sensitive resources of some sort, for example). They won't be happy if finalizers are called on potentially different thread associated with receiver's isolate.

[mkustermann]

@lrhn The VM can always end stop an isolate without running finalizers due to various reasons. If we don't cleanup resources in such cases (which might be the case, e.g. for sockets), then it's an existing bug already.

If invoking the finalizers for weak persistent handles on different thread is an issue, then this is not a send-and-exit specific issue, but exists already: A garbage collection can happen on any thread (e.g. BG compiler thread doing a scavenge). The persistent handle finalizers are being invoked on the same thread that does GC, therefore we already have this "problem" (if it is one), right?

[aam]

sendAndExit was added to dart:_internal https://github.com/dart-lang/sdk/blob/master/sdk/lib/_internal/vm/lib/internal_patch.dart#L171 and is being tested and benchmarked:

 runtime/tests/vm/dart_2/sendandexit_test.dart
 runtime/tests/vm/dart_2/isolates/ring_gc_sendAndExit_test.dart

Is there anything that prevents us from moving this function to dart:isolate?

[mkustermann]

Is there anything that prevents us from moving this function to dart:isolate?

Yes: The send-and-exit functionality only makes sense with --enable-isolate-groups, so we have to make that the default first, which requires us to finish the JIT support. Afterwards we'll have to look into what things we'd like to be able to send with send-and-exit, possibly more than we currently allow, and discuss this also with library team.

[mkustermann]

@aam Before closing this issue, we should - as discussed in the isolate sync today - ensure the verification pass in the send-and-exit has frequent safepoint checks in it - otherwise we might end up blocking other threads that want to safepoint for very long time (x00 ms).

Also: Disallow execution of dart code after send-and-exit: After c65556c landed, no more embedder API calls can execute dart code, but if there's dart<->C<->dart<->send-and-exit we might still end up executing dart code if the C code swallows unwind errors. Maybe we can do something about this.

[mkustermann]

Have filed a different issue now for the safepoint-checkins with a reproduction: #49050