Isolate.exit()s synchronous message validation happens in NoSafepointScope which harms responsiveness

[mkustermann]

The message validation code for Isolate.exit() runs synchronously in NoSafepointScope, see runtime/lib/isolate.cc:

static ObjectPtr ValidateMessageObject(Zone* zone,
                                       Isolate* isolate,
                                       const Object& obj) {
  ...
  {
    NoSafepointScope no_safepoint;
    ...
    while (!working_set.is_empty() && !error_found) {
      ...
    }
}

This is not a problem if no other threads want to safepoint, but if e.g. a UI isolate allocates widgets and will want to GC, it may have to wait for a long time (depending on how large the Isolate.exit()ed message is).

See a reproduction in isolate_exit_pause_time_issue.dart, which results in:

.Min(RunTimeRaw): 0.001 ms.
.Avg(RunTimeRaw): 388.26340250000004 ms.
.Percentile50(RunTimeRaw): 53.022 ms.
.Percentile90(RunTimeRaw): 1335.022 ms.
.Percentile95(RunTimeRaw): 1535.022 ms.
.Percentile99(RunTimeRaw): 1695.022 ms.
.Max(RunTimeRaw): 1734.022 ms.

/cc @aam Could you look into this?

[mkustermann]

/cc @mit-mit

[aam]

/cc @aam Could you look into this?

Sure, thank you for putting the benchmark together. 10M objects in the exit message is quite a bit though! :-)

[mkustermann]

Sure, thank you for putting the benchmark together. 10M objects in the exit message is quite a bit though! :-)

Some users do run compute() where the function parses 100 MB files. See d-markey/squadron#7 (comment):

Once I got the overall parse time for a 100MB VCD file down below the 30 seconds mark, performance was less of a consideration if it was happening in the background. In my case, the UI would freeze in debug mode and be more responsive in release mode (I can't remember for sure now, but I think that was native... can't remember web'.

[mkustermann]

Thanks for looking into it, @aam !