Status: Accepted
Owner: ----
CC: [email protected], [email protected], [email protected],
[email protected], [email protected]
Labels: Type-Bug Priority-Medium
New issue 3881 by [email protected]: GC marking invariant fails when
OutOfLineConstantPool is enabled
https://code.google.com/p/v8/issues/detail?id=3881
The bad scenario (there is a cctest illustrating this at
https://codereview.chromium.org/681633002/):
1. Create an optimized function f with an IC, the address of the IC is in
the constant pool.
2. Incremental marking marks the function's code object, the IC and the
constant pool.
3. The IC transitions to a new state. This will make f's code grey (and
queued for marking), the constant pool remains black, the new IC is white.
(Having a black object pointing to white does not seem to be quite ok
already.)
4. The function f is lazy deopted - the important consequence is that the
relocation info is nuked. That means that when f's code is marked again, it
will not mark the IC in the constant pool.
As a result, after marking is finished, we have an unmarked IC that is
pointed to by the marked constant pool.
I have uploaded a cctest that illustrates this. It lives at
https://codereview.chromium.org/681633002/. First enable OOL constant pools
("#define V8_OOL_CONSTANT_POOL 1" in globals.h) and run with
make arm.debug && out/arm.debug/cctest ConstantPoolICUpdateDeopt
--------
I am thinking that a slightly hacky fix would be to somehow invalidate the
code entries in the constant pool when deoptimizing (in
Deoptimizer::PatchCodeForDeoptimization or in Code::InvalidateRelocation),
perhaps by overwriting them with some known fixed code entry that is
guaranteed to be black. This would fix this particular scenario, but I
still not entirely comfortable with black object pointing to a white one.
---------
Would it be possible to hook into the point where the IC transitioning to a
new state turns the code grey, and turn the constant pool grey as well? I
had a look through the code and couldn't find the point at which this
happens, does anyone have any pointers?
----------
It might be possible to hook into the IC transitioning, but there are a few
call indirections in the way.
As for the code doing all this, the ICs do the patching in
IC::SetTargetAtAddress (src/ic/ic-inl.h), which calls to
IncrementalMarking::RecordCodeTargetPatch. Following bunch of calls, it
eventually gets to IncrementalMarking::RecordWriteIntoCodeSlow
(src/heap/incremental-marking.cc), where the code's mark is changed from
black to grey.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
