RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier
david.holmes at oracle.com
Tue Feb 7 03:44:26 UTC 2017
On 7/02/2017 8:46 AM, Kim Barrett wrote:
>> On Feb 5, 2017, at 10:19 PM, David Holmes <david.holmes at oracle.com> wrote:
>> Thanks for explaining. I must say that I find this treatment rather ad-hoc as we seem to be discovering by trial-and-error where these places occur. I would have hoped this was all encapsulated within the weakreference code itself (in this case).
> The GC team is taking a hard look at weak reference handling, as part
> of preparing for some improvements we are considering. That's turned
> up some holes that probably should have been dealt with as part of
> productizing G1, but seem to have gone unnoticed until recently.
> For now we're patching over these holes. I expect some cleanup tasks
> for JDK 10; we're not happy with this littering of otherwise generic
> runtime code with G1-specific stuff. OTOH, I have to say that some of
> the abstraction violations I'm finding around jobject, Handle, and
> oop* in non-GC code are not helpful.
>> Does the SATB occur at a global safepoint?
> SATB is the approach G1 uses for a part of concurrent collection. It
> defines the invariants that must be maintained by the mutator so that
> the collector can find all the live objects. The barriers in question
> are executed by the mutator concurrently with the collector, in order
> to inform the collector of reachability graph modifications.
Is that a "no"? :) I don't understand how the barriers operate in
relation to concurrent actions by the GC. To take the current case, what
prevents the GC from deciding that the referent is garbage and can
deleted, before the enqueue is called? I assumed a safepoint had to be
involved somewhere so that the sequence of actions: extract, enqueue,
store, was atomic with respect to the GC.
More information about the hotspot-gc-dev