This change is almost trivial. The closure is stored on the callback's
RawReceivePort, not in the VM. So we can basically just remove the CFE
check and it pretty much works. The only problem is that we can't set
function.FfiCallbackTarget anymore, so most of the CL is dealing with
that.
A few places were deciding whether an FFI trampoline was a call or a
callback based on whether function.FfiCallbackTarget() was null. But
now the target will be null for async callbacks. So instead I've added
a new value to the FfiCallbackKind enum (and renamed it), and changed
those checks.
Sync callback closures will be a separate CL, because they're more
complicated.
Bug: https://github.com/dart-lang/sdk/issues/52689
Change-Id: I8e5dfb557362e679f66195b735c3c382e6792840
TEST=async_void_function_callbacks_test.dart
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316160
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Force-optimized functions cannot deoptimize & reoptimize. Compiling them
always produces the same code.
If two mutators trigger lazy compilation of the same force-optimized
function we can let the first one win and let all others skip the
installation of code (detected in the installation phase where all
other mutators are stopped at safepoint).
This will avoid having multiple [Code] objects for the same
force-optimized function in normal circumstances.
Issue https://github.com/dart-lang/sdk/issues/52512
TEST=ci
Change-Id: I922728795943f006406feeca2e7a9f899859e800
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305920
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
The ffi-callback related information on the [Thread] object is metadata
corresponding to ffi-callback-trampoline [Function] objects. There is
nothing thread or isolate specific about it.
Moving it away from [Thread] is needed because an [Isolate] can
have different [Thread] objects across its lifetime (see [0]): When
the stack of an isolate is empty, we reserve now the right to
re-cycle the [Thread]. If the isolate later runs again, it may
get a new [Thread] object.
This CL moves this information from [Thread] to the [ObjectStore]. In
addition we make the compiler be responsible for populating this
metadata - instead of doing this per-call site of
`Pointer.fromFunction()`. It will be preserved across snapshot writing
& snapshot reading (for AppJIT as well as AppAOT).
Similarly the JIT trampolines that are on Isolate aren't isolate
specific and can go to [IsolateGroup]. This simplifies doing the above
as the compiler can allocate those as well.
The effect is that [Thread] object gets smaller, GC doesn't have to
visit the 2 slots per-thread. It comes at expense of 2 more loads
when invoking the callback.
[0] https://dart-review.googlesource.com/c/sdk/+/297920
TEST=Regression test is vm/ffi{,_2}/invoke_callback_after_suspension_test
Change-Id: Ifde46a9f6e79819b5c0e359c3d3998d1d93b9b1e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/303700
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Liam Appelbe <liama@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Some cleanups factored out of a larger CL (which refactors enter/exit of threads):
* remove unused `#include "vm/thread_registry.h"`
* remove unused/unnecessary fields from [Thread] object
* rename IsMutator() -> IsDartMutator()
* make tests using setjmp() drain the sticky error
=> to ensure there's no sticky error on isolate shutdown
TEST=ci
Change-Id: I53935e8bd0628ab3768627d6d5e01c3f0e3a57ad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296582
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
During safepoint we can distinguish between
* owner of the safepoint operation (which is running code)
* everyone else (which are all blocked
Currently `Thread::IsAtSafepoint()` will return true for both. Since the
thread owning the safepoint operation is running, it's not actually
guaranteed that it's at "safe" point (e.g. to GC or to deopt) - it
really depends on what it's doing.
=> This CL will change it so that only actually parked threads will
have `Thread::IsAtSafepoint()`.
In order to do that we change varrious usages of `IsAtSafepoint()` to be
more precise:
* `Thread::OwnsSafepoint()`: True if this thread owns the
active safepoint. The thread is running.
* `Thread::OwnsGCSafepoint()`: True if the active safepoint is a GC
(or Deopt) safepoint and this thread owns it. The thread is running.
* `Thread::OwnsDeoptSafepoint()`: True if the active safepoint is a
Deopt safepoint and this thread owns it. The thread is running.
* `Thread::CanAcquireSafepointLocks()`: True if the thread is allowed
to acquire safepoint locks.
* `Thread::IsAtSafepoint()`: true if this thread is parked at a
safepoint
TEST=ci
Change-Id: I1a5a6727e84843ae79e0a344c438da19b7d6d916
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295781
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Our compiler shouldn't depend on current isolate, since it can
run on any isolate within an IG.
Doing this change, reveals two existing dependencies on current
isolate from compiler
- resolving native symbols in unoptimized compilations
- issuing of debug events for breakpoints
For the former we'll re-enter the currently active isolate that
triggered unoptimized compilation.
=> We may want to change that embedder API to not be based on
handles and instead give embedder a simple `const char*`.
For the ladder we'll enter the isolate corresponding to the
breakpoint debug event to be issued. We are at place where
all mutators are stopped, so that does seem okish.
=> Future could remove this by making Object Id Ring per-IG
Issue https://github.com/dart-lang/sdk/issues/48523
TEST=service_2/break_on_function_many_child_isolates_test/dds
Change-Id: Id246db5972ae505e82f637ce04bb2302bed76257
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/278901
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
We have many tests that explicitly use --optimization-counter-threshold=
flag. We also have a CI builder that uses this flag for all tests.
This is an issue for cases where `kernel-isolate` is not AppJIT'ed,
which is the case for simulators and ia32. Especially in debug builds
this causes a very-very slow time-to main due to JIT'ing the CFE code in
`kernel-isolate` and running flow graph checker etc (in debug mode).
This causes various tests to sporadically hit the timeout limit, become
flaky and require gardening attention.
As workarounds: the actual threshold was modified in tests, status files
were updated to mark tests as Pass,Slow etc.
=> This Cl will make `kernel-isolate` no longer be affected by the
`--optimization-counter-threshold`
=> This should make the cycle times faster on those modes and avoid
flaky timeouts that gardeners constantly have to pay attention to.
TEST=ci
Change-Id: Ia58e807b22f69f924315a43c6764427afe398ee6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/266683
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Certain optimizations are disabled when compiling huge functions.
Also, compiling large functions may cause out of memory in compiler.
This change adds a warning in order to make it easier for users to
find out about huge functions in their programs and diagnose OOM
during compilation.
TEST=ci
Issue: https://github.com/flutter/flutter/issues/94461
Change-Id: Ibc7fb69df21fa96b8159d24c1b71ef8d690b23df
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/230160
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Implements a backend targeting RV32GC and RV64GC, based on Linux standardizing around GC. The assembler is written to make it easy to disable usage of C, but because the sizes of some instruction sequences are compile-time constants, an additional build configuration would need to be defined to make use of it.
The assembler and disassembler cover every RV32/64GC instruction. The simulator covers all instructions except accessing CSRs and the floating point state accessible through such, include accrued exceptions and dynamic rounding mode.
Quirks:
- RISC-V is a compare-and-branch architecture, but some existing "architecture-independent" parts of the Dart compiler assume a condition code architecture. To avoid rewriting these parts, we use a peephole in the assembler to map to compare-and-branch. See Assembler::BranchIf. Luckily nothing depended on taking multiple branches on the same condition code set.
- There are no hardware overflow checks, so we must use Hacker's Delight style software checks. Often these are very cheap: if the sign of one operand is known, a single branch is needed.
- The ranges of RISC-V branches and jumps are such that we use 3 levels of generation for forward branches, instead of the 2 levels of near and far branches used on ARM[64]. Nearly all code is handled by the first two levels with 20-bits of range, with enormous regex matchers triggering the third level that uses aupic+jalr to get 32-bits of range.
- For PC-relative calls in AOT, we always generate auipc+jalr pairs with 32-bits of range, so we never generate trampolines.
- Only a subset of registers are available in some compressed instructions, so we assign the most popular uses to these registers. In particular, THR, TMP[2], CODE and PP. This has the effect of assigning CODE and PP to volatile registers in the C calling convention, whereas they are assigned preserved registers on the other architectures. As on ARM64, PP is untagged; this is so short indices can be accessed with a compressed instruction.
- There are no push or pop instructions, so combining pushes and pops is preferred so we can update SP once.
- The C calling convention has a strongly aligned stack, but unlike on ARM64 we don't need to use an alternate stack pointer. The author ensured language was added to the RISC-V psABI making the OS responsible for realigning the stack pointer for signal handlers, allowing Dart to leave the stack pointer misaligned from the C calling convention's point of view until a foreign call.
- We don't bother with the link register tracking done on ARM[64]. Instead we make use of an alternate link register to avoid inline spilling in the write barrier.
Unimplemented:
- non-trivial FFI cases
- Compressed pointers - No intention to implement.
- Unboxed SIMD - We might make use of the V extension registers when the V extension is ratified.
- BigInt intrinsics
TEST=existing tests for IL level, new tests for assembler/disassembler/simulator
Bug: https://github.com/dart-lang/sdk/issues/38587
Bug: https://github.com/dart-lang/sdk/issues/48164
Change-Id: I991d1df4be5bf55efec5371b767b332d37dfa3e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217289
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
This changes Profiler::DumpStackTrace to include information available
in the CompilerState attached to the thread into the crash report.
This includes the name of the function being compiled, compilation mode,
current phase, flow graph, instruction being compiled.
TEST=manually by causing compiler to crash
Change-Id: I310629f032a86781e30f0a5e218d21df7d27528e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/220001
Auto-Submit: Slava Egorov <vegorov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
This reverts commit f8df8ca78e.
Reason for revert: breaks google3 (b/205519688)
Original change's description:
> [vm/concurrency] Remove --(no-)enable-isolate-groups flag in Dart VM
>
> The --enable-isolate-groups flag has been turned on by-default for
> months now. In this CL we're going to remove the opt-out of this (which
> was possible by explicitly passing --no-enable-isolate-groups to the VM)
>
> TEST=Existing CI. Removes flag and simplifies runtime.
>
> Change-Id: I8706b9e30df437548a81846e75e67a658d6d49d4
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219480
> Reviewed-by: Alexander Aprelev <aam@google.com>
> Commit-Queue: Martin Kustermann <kustermann@google.com>
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: Iabe6ccda6c184bb183b54a056d5011e657265d1d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219700
Reviewed-by: Emmanuel Pellereau <emmanuelp@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Emmanuel Pellereau <emmanuelp@google.com>
The --enable-isolate-groups flag has been turned on by-default for
months now. In this CL we're going to remove the opt-out of this (which
was possible by explicitly passing --no-enable-isolate-groups to the VM)
TEST=Existing CI. Removes flag and simplifies runtime.
Change-Id: I8706b9e30df437548a81846e75e67a658d6d49d4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219480
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Instead of the background compiler task waiting forever for functions to show up in its queue, it performs a single compilation and schedules a new task if the queue is not empty.
This means an inactive isolate no longer consumes a thread. It also creates interrupt points and better fits with an embedder-provided task runner abstraction.
TEST=ci
Change-Id: I13960c776590b884fdee278d2f292bb0fa725fad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214242
Reviewed-by: Liam Appelbe <liama@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
This reverts commit b5922e6db4.
Reason for revert: vm/cc/AllocateZone fails on Mac
Original change's description:
> [vm] Streamline Zones.
>
> - Don't put a HANDLESCOPE right after a StackZone, as there's no state worth restoring
> - Remove remaining zone bookkeeping dead since e3a9d70591.
> - Remove unnecessary resetting of handle blocks before zone deletion.
> - Shrink initial chunk size to make Zone's overall size fit in a faster malloc size class.
>
> TEST=ci
> Change-Id: I920e12f5af93aa71fb876435764c60df485215f9
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212261
> Reviewed-by: Siva Annamalai <asiva@google.com>
> Commit-Queue: Ryan Macnak <rmacnak@google.com>
TBR=rmacnak@google.com,asiva@google.com
Change-Id: Id23dcebb781791616e48e54d2dcd7e58159178bc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215943
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
- Don't put a HANDLESCOPE right after a StackZone, as there's no state worth restoring
- Remove remaining zone bookkeeping dead since e3a9d70591.
- Remove unnecessary resetting of handle blocks before zone deletion.
- Shrink initial chunk size to make Zone's overall size fit in a faster malloc size class.
TEST=ci
Change-Id: I920e12f5af93aa71fb876435764c60df485215f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212261
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
When doing optimizing compilations on the mutator thread (e.g. due to
--deterministic or --no-background-compilation) we can have situations
in which one thread is starting or in the middle of optimizing a
function while another has just deoptimized it, reaching the
deoptimization counter threshold.
We just remove this assertion which doesn't hold anymore with
--enable-isolate-groups enabled.
Fixes https://github.com/dart-lang/sdk/issues/46622
TEST=Fixes flaky assertion hit in vm/dart_2/isolates/regress_46539_test
Change-Id: I9812e3c6500113b7d948f96dc4cfcee607f56d39
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207023
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This extends the existing safepoint operation mechanism by allowing to
perform two different operations:
* "gc safepoint operations": All mutators are stopped at places where
it's safe to GC. It therefore requires stackmaps to be available for
all optimized mutator frames.
* "deopt safepoint operations": All mutators are stopped at places
where it's safe to GC, but also safe to lazy-deopt mutator frames.
It therefore requires deopt-id/deopt-info to be available for all
optimized mutator frames.
Mutators can be asked to block for any of those two safepoint operations.
If a mutator is at a place where its safe to GC it will respond to "gc
safepoint operations" requests, if a mutator is additionally at a place
where it's also safe to lazy-deopt it will respond to "deopt safepoint
operation" requests.
Depending on how the runtime was entered (which is tracked via the
[Thread::runtime_call_deopt_ability_] value) - the mutator might
participate in both or only in gc safepoint operations.
During the start of a "deopt safepoint operation", the safepoint handler
will request all threads to stop at a "deopt safepoint". Some threads
might first want to initiate their own "gc safepoint operation"
(e.g. due to allocation failure) before they reach a "deopt safepoint".
We do allow this by letting the safepoint handler own a "deopt safepoint
operation" but still participate in other thread's "gc safepoint
operation" requests until all mutators are checked into places where
it's safe to lazy-deopt at which point the "deopt safepoint operation"
also owns a "gc safepoint operation".
In order to facilitate this, the Thread's safepoint_state will be
extended to consist of the following bits:
* AtSafepoint
* SafepointRequested
* AtDeoptSafepoint
* DeoptSafepointRequested
* BlockedForSafepoint
Issue https://github.com/dart-lang/sdk/issues/45213
TEST=vm/cc/SafepointOperation_*
Change-Id: Icdc2827718f6780818f99b829a5e806d6bb5b130
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/196927
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Also creates LoadFromOffset/StoreToOffset variants across all
architectures (was missing in some) that take the register to
load to/store from, the memory address, and the size to load/store.
Fixes LoadFromOffset on X64 to use MOVSXD when the size is kFourBytes.
Creates slots for the data field of TypedDataBase/Pointer objects
and replaces the StoreUntagged instruction with uses of
StoreInstanceField instead to create uses of the new version of
the instruction.
BUG=https://github.com/dart-lang/sdk/issues/42793
TEST=Tests that involve FFI pointers or TypedData constructors.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-simarm64c-try,vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64c-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-linux-debug-ia32-try,vm-kernel-linux-debug-x64-try,vm-kernel-linux-product-x64-try,vm-kernel-linux-release-simarm64-try,vm-kernel-linux-release-simarm-try,vm-kernel-linux-release-x64-try,vm-kernel-linux-debug-x64c-try
Change-Id: I2c96e83bb086aa93c56b834e809e7141a32cfc35
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/196924
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Keep list of all per-isolate BreakpointLocations on isolate_group so all of them
can be traversed by isolate group when function is compiled and
GroupDebugger::NotifyCompilation() is invoked.
This also fixes data race around line_number lazy-initialization.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=existing ci test suite
Change-Id: I821b49a56cdc28da8d0c0c97e7d850995285c48a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193380
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
An allocation can - in the slow path - go to runtime which can cause a
pre-allocated OutOfMemory exception to be thrown. It therefore requires
correct deopt information.
Issue https://github.com/dart-lang/sdk/issues/45213
TEST=Existing test suite. A follow-up CL will add actual deoptimization tests for those instructions.
Change-Id: Iaf44904b82ec021919352483f58e9e8fed473955
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/192685
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Many years ago those bailouts were seemingly added due to deferred
loading in [0]. Though it seems like those bailouts might've become
obsolete.
All places that clear the IC array on the function should run inside
a [NoBackgroundCompiler] scope, therefore ensuring no optimizing
compilations are done at that time. Those places also clear code,
therefore forcing re-compilation of unoptimized code (which will
re-create the ICData).
[0] https://codereview.chromium.org/1672873003/#ps60001
TEST=Removing dead code.
Change-Id: Iec4f22be500f6e874fa5286b51396bd6d978dd6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/187902
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
The background compiler no longer has bailouts due to something that
cannot be done on BG compiler and has to be done on mutator (was
originally introduced in [0])
All optimizing compilations can happen on the BG thread. Class
finalization and other things no longer cause a bailout on BG
compiler.
If e.g. invalidated field guards cause a compilation to be discarded, it
can be retried on BG compiler.
[0] https://dart-review.googlesource.com/c/sdk/+/54886
Closes https://github.com/dart-lang/sdk/issues/45136
TEST=Fixes flaky hits of an assertion.
Change-Id: I50313dbedf96b8dec205acdb8c1ed5731d00433b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/187901
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
In presence of multiple mutators in one isolate group, same function might be unoptimized-compiled by more than one mutator. Avoid reinstallation of newly compiled unoptimized code if that happens. Unoptimized compilation itself is not that expensive, so we don't prevent multiple mutators to do actual compilation of the same function.
Fixes https://github.com/dart-lang/sdk/issues/44992.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=standalone_2\io\http_basic_test.dart on windows
Change-Id: I0fbd62e8f8299a5d8289a6689da157a691715b81
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/185460
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
With --enable-isolate-groups we will start sharing JITed code. The JITed
code - which will be executed by all isolates - should therefore not
depend on a particular isolate's state, flags or any other
isolate-specific information.
To avoid accidental bugs where the compiler starts using
isolate-specific information, we ensure the compiler runs without a
current isolate.
This CL doesn't add NoActiveIsolateScope because on unoptimized compiles
of natives, the compiler calls out to embedder for eager native
resolution of native functions. This API forces embedder to callback
into VM atm.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Adds more checking.
Change-Id: I6c86674c010b74c15855652415706dbaa8749d33
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/183692
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
The logic for background compiler can be simplified due to:
* we only have one bg compiler
* it always optimizes
* it is allocated at isolate startup and freed on isolate shutdown
* an existing check in the compiler for whether the BG compiler is
disabled is racy and therefore not helpful
* when a mutator communicates with BG compiler it will use
SafepointMutexLocker instead of MutexLocker
This CL also ecapsulates disabling the BG compiler via a
NoBackgroundCompilerScope object. It allows nested disabling and guards
against races.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Refactoring of existing code.
Change-Id: I36ed6592c9a8b91e94181698b7de662b4ee984e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/183400
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Alexander Markov