Currently we have things called XPtr which are not what you get from ptr().
Old world:
handle->raw() returns RawObject* (tagged)
raw_obj->ptr() returns RawObject* (untagged)
After 6fe15f6df9:
handle->raw() returns ObjectPtr
obj_ptr->ptr() returns ObjectLayout*
New world:
handle->ptr() returns ObjectPtr
obj_ptr->untag() returns UntaggedObject*
TEST=ci
Change-Id: I6c7f34014cf20737607caaf84979838300d12df2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149367
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Attempts to run class finalizaton on background thread revealed the problem where during optimization(which could run on mutator thread too) we might need to finalize previously unseen class, load annotatons for it, load and set some constant fields. This could result in updating Fields guarded_cid, requires check during installation of newly produced optimized code. Because mutator thread is currently exempt from cloning and validating fields guards, that could result in invalid optimized code installation.
This CL ensures that fields are always cloned in optimizing compiler even when it runs on mutator thread.
Ability to run multiple optimizing compilers is also needed for dartbug.com/36097.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=existing test suite with ltw isolate groups enabled, https://dart-review.googlesource.com/c/sdk/+/176300 mocked up test(still to be improved).
Change-Id: I608f4abff30b468cb9d0ab270221a0ba72c32470
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175341
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This disables field unboxing in JIT with enabled lightweight isolates because currently unboxed generated code won't behave correctly if another isolate updates field unboxed state: for that guarded_cid updates would require stopping all isolates, getting to a safepoint.
Use of field guards(guarded_cid, is_nullable) in optimized compiler is concurrent-safe because each optimized compiler operates on its own clones of fields, which are checked for consistency with latest(mutator) state just before optimized code is installed.
Use of field guards in optimized generated code is safe because vm is brought to a safepoint and optimized code is deoptimized as soon as field guards are invalidated.
Use of field guards in generated unoptimized code outside of unboxed fields(transition to boxed from previously unboxed field is not safe which is why field unboxing is disabled) and use of field guards in unoptimized compiler is safe because transitions through guarded_cid and is_nullable makes less and less optimistic assumptions about the field state.
Issue https://github.com/dart-lang/sdk/issues/36097.
TEST=existing test suite
Change-Id: I00d37a49df483814c846b17c9c49e0dc6ce701e1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/172860
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
There might be a race between background compiler and mutator where
mutator changes guarded state of the field after Slot was created from
it.
A situation is possible where we have a clone of a field with its
guarded state set to unknown, however Slot::Get for this field returns
a Slot created from the previous clone of the same field with a known
guarded state. In this case we must add *old* clone from which the Slot
was created to guarded fields and not the new clone, because new clone
has no guarded state to begin with and thus
ParsedFunction::AddToGuardedFields(...) would simply ignore it.
Such slots with inconsistent guarded state that are not in the current
list of guarded fields arise due to unsuccessful inlining attempts.
If we built and discard the graph, then guarded fields associated with
that graph are also discarded. However the slot itself stays behind in
the compilation global cache.
TEST=vm/cc/SlotFromGuardedField
Bug: b/121271056
Change-Id: Ib6ee5ec4922c033c3a71bdc46da74ead47b1edd0
Reviewed-on: https://dart-review.googlesource.com/c/88575
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Alexander Aprelev