RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

sangheon.kim@oracle.com
Hi all,

Could I have some reviews for this change that adds G1 pre-barrier?

JvmtiTagHashmapEntry has a bare oop member and this is a weak reference. So any place that allows this oop to 'escape' needs the G1 pre-barrier.
JvmtiEnv::GetObjectsWithTags() provides such an escape path.

For G1, in order to maintain the SATB invariants, reading the referent of a weak reference must ensure the referent is marked alive.

So this proposal includes adding the pre-barrier at TagObjectCollector::do_entry(JvmtiTagHashmapEntry* entry) which I see the only place interacts(except 'peek' operations) with the bare oop member.

As writing stable test could take some more time, Stefan Karlsson and I did some tests to provoke this problem.
( Stefan Karlsson kindly provided the test, http://cr.openjdk.java.net/~stefank/8173013/reproducer/ )
With this proposed patch, the problem goes away.

CR: https://bugs.openjdk.java.net/browse/JDK-8173013
Webrev: http://cr.openjdk.java.net/~sangheki/8173013/webrev.0
Testing: JPRT, some closed tests which use JVMTI and JDI.

Thanks,
Sangheon

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

David Holmes
Hi Sangheon,

On 3/02/2017 5:11 AM, sangheon wrote:

> Hi all,
>
> Could I have some reviews for this change that adds G1 pre-barrier?
>
> JvmtiTagHashmapEntry has a bare oop member and this is a weak reference.
> So any place that allows this oop to 'escape' needs the G1 pre-barrier.
> JvmtiEnv::GetObjectsWithTags() provides such an escape path.
>
> For G1, in order to maintain the SATB invariants, reading the referent
> of a weak reference must ensure the referent is marked alive.
>
> So this proposal includes adding the pre-barrier at
> TagObjectCollector::do_entry(JvmtiTagHashmapEntry* entry) which I see
> the only place interacts(except 'peek' operations) with the bare oop member.

Pardon my GC ignorance but it seems odd to me that this barrier is
inserted immediately before we create a local JNIHandle. Won't the
JNIHandle ensure the object is seen as live?

Thanks,
David

> As writing stable test could take some more time, Stefan Karlsson and I
> did some tests to provoke this problem.
> ( Stefan Karlsson kindly provided the test,
> http://cr.openjdk.java.net/~stefank/8173013/reproducer/
> <http://cr.openjdk.java.net/%7Estefank/8173013/reproducer/> )
> With this proposed patch, the problem goes away.
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8173013
> Webrev: http://cr.openjdk.java.net/~sangheki/8173013/webrev.0
> Testing: JPRT, some closed tests which use JVMTI and JDI.
>
> Thanks,
> Sangheon
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

sangheon.kim@oracle.com
Hi David,

Thank you for looking at this!

On 02/02/2017 05:20 PM, David Holmes wrote:

> Hi Sangheon,
>
> On 3/02/2017 5:11 AM, sangheon wrote:
>> Hi all,
>>
>> Could I have some reviews for this change that adds G1 pre-barrier?
>>
>> JvmtiTagHashmapEntry has a bare oop member and this is a weak reference.
>> So any place that allows this oop to 'escape' needs the G1 pre-barrier.
>> JvmtiEnv::GetObjectsWithTags() provides such an escape path.
>>
>> For G1, in order to maintain the SATB invariants, reading the referent
>> of a weak reference must ensure the referent is marked alive.
>>
>> So this proposal includes adding the pre-barrier at
>> TagObjectCollector::do_entry(JvmtiTagHashmapEntry* entry) which I see
>> the only place interacts(except 'peek' operations) with the bare oop
>> member.
>
> Pardon my GC ignorance but it seems odd to me that this barrier is
> inserted immediately before we create a local JNIHandle. Won't the
> JNIHandle ensure the object is seen as live?
Unfortunately it isn't.

If we are using G1 and accessing the value of the referent field in a
reference object then we need to register a non-null referent with the
SATB barrier.

In this code path, for example:

(1) Object x is tagged.
(2) x becomes unreachable, with the only remaining reference being the
weak reference in the tag hashmap.
(3) Concurrent GC starts and has completed marking, but has not yet
entered the remark pause where reference processing occurs.
(4) GetObjectsWithTags is used to obtain x. As reference processing has
not yet run, x is still present in the tag hashmap. x remains unmarked,
because there is no read(SATB) barrier on that access.
(5) GC remark pause runs reference processing, determines x is dead, so
clears the tag entry, and reuses the space previously occupied by x.
(6) The GetObjectsWithTags result now refers to a dead and reclaimed x.  
A crash may follow.
(From Kim Barrett's note)

FYI, there are similar treatments already for this case.
Plz, search for "G1SATBCardTableModRefBS::enqueue", especially
Unsafe_GetObject().

I added this comment at the patch.
Webrev: http://cr.openjdk.java.net/~sangheki/8173013/webrev.1

Thanks,
Sangheon


>
> Thanks,
> David
>
>> As writing stable test could take some more time, Stefan Karlsson and I
>> did some tests to provoke this problem.
>> ( Stefan Karlsson kindly provided the test,
>> http://cr.openjdk.java.net/~stefank/8173013/reproducer/
>> <http://cr.openjdk.java.net/%7Estefank/8173013/reproducer/> )
>> With this proposed patch, the problem goes away.
>>
>> CR: https://bugs.openjdk.java.net/browse/JDK-8173013
>> Webrev: http://cr.openjdk.java.net/~sangheki/8173013/webrev.0
>> Testing: JPRT, some closed tests which use JVMTI and JDI.
>>
>> Thanks,
>> Sangheon
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

Thomas Schatzl
Hi Sangheon,

On Thu, 2017-02-02 at 20:00 -0800, sangheon wrote:

> Hi David,
>
> Thank you for looking at this!
>
> On 02/02/2017 05:20 PM, David Holmes wrote:
> >
> > Hi Sangheon,
> >
> > On 3/02/2017 5:11 AM, sangheon wrote:
> > >
> > > Hi all,
> > >
> > > Could I have some reviews for this change that adds G1 pre-
> > > barrier?
> > >
> > > JvmtiTagHashmapEntry has a bare oop member and this is a weak
> > > reference.
> > > So any place that allows this oop to 'escape' needs the G1 pre-
> > > barrier.
> > > JvmtiEnv::GetObjectsWithTags() provides such an escape path.
> > >
> > > For G1, in order to maintain the SATB invariants, reading the
> > > referent
> > > of a weak reference must ensure the referent is marked alive.
> > >
> > > So this proposal includes adding the pre-barrier at
> > > TagObjectCollector::do_entry(JvmtiTagHashmapEntry* entry) which I
> > > see
> > > the only place interacts(except 'peek' operations) with the bare
> > > oop 
> > > member.
> > Pardon my GC ignorance but it seems odd to me that this barrier is 
> > inserted immediately before we create a local JNIHandle. Won't the 
> > JNIHandle ensure the object is seen as live?
> Unfortunately it isn't.
>
> If we are using G1 and accessing the value of the referent field in a
> reference object then we need to register a non-null referent with
> the SATB barrier.
>
> In this code path, for example:
>
> (1) Object x is tagged.
> (2) x becomes unreachable, with the only remaining reference being
> the weak reference in the tag hashmap.
> (3) Concurrent GC starts and has completed marking, but has not yet 
> entered the remark pause where reference processing occurs.
> (4) GetObjectsWithTags is used to obtain x. As reference processing
> has not yet run, x is still present in the tag hashmap. x remains
> unmarked, because there is no read(SATB) barrier on that access.
> (5) GC remark pause runs reference processing, determines x is dead,
> so clears the tag entry, and reuses the space previously occupied by
> x.
> (6) The GetObjectsWithTags result now refers to a dead and reclaimed
> x. 
> A crash may follow.
> (From Kim Barrett's note)
>
> FYI, there are similar treatments already for this case.
> Plz, search for "G1SATBCardTableModRefBS::enqueue", especially 
> Unsafe_GetObject().
>
> I added this comment at the patch.
> Webrev: http://cr.openjdk.java.net/~sangheki/8173013/webrev.1

1539         // We could be accessing the referent field in a reference
1540         // object. If G1 is enabled then we need to register non-
null
1541         // referent with the SATB barrier.

I do not think this comment is complete, or at least I do not see why
the object in question needs to be a "referent field in a reference".
Maybe you meant that the tag map entry acts similar to the referent of
a j.l.ref.WeakReference, so we need to handle it the same as when a
thread accesses a weak reference in normal java code (i.e. the read
barrier).

As the problem description above indicates, this can occur with any
reference to an object where the tag map has the only (implicitly weak)
reference to as far as I can see.

I.e. maybe something like:

"The reference in this tag map could be the only (implicitly weak)
reference to that object. If we hand it out we need to keep it live wrt
SATB marking similar to other j.l.ref.Reference referents."

Probably others can provide a better description.

Otherwise it seems good.

esses 

Thanks,
  Thomas
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

sangheon.kim@oracle.com
Hi Thomas,

On 02/03/2017 05:51 AM, Thomas Schatzl wrote:

> Hi Sangheon,
>
> On Thu, 2017-02-02 at 20:00 -0800, sangheon wrote:
>> Hi David,
>>
>> Thank you for looking at this!
>>
>> On 02/02/2017 05:20 PM, David Holmes wrote:
>>> Hi Sangheon,
>>>
>>> On 3/02/2017 5:11 AM, sangheon wrote:
>>>> Hi all,
>>>>
>>>> Could I have some reviews for this change that adds G1 pre-
>>>> barrier?
>>>>
>>>> JvmtiTagHashmapEntry has a bare oop member and this is a weak
>>>> reference.
>>>> So any place that allows this oop to 'escape' needs the G1 pre-
>>>> barrier.
>>>> JvmtiEnv::GetObjectsWithTags() provides such an escape path.
>>>>
>>>> For G1, in order to maintain the SATB invariants, reading the
>>>> referent
>>>> of a weak reference must ensure the referent is marked alive.
>>>>
>>>> So this proposal includes adding the pre-barrier at
>>>> TagObjectCollector::do_entry(JvmtiTagHashmapEntry* entry) which I
>>>> see
>>>> the only place interacts(except 'peek' operations) with the bare
>>>> oop
>>>> member.
>>> Pardon my GC ignorance but it seems odd to me that this barrier is
>>> inserted immediately before we create a local JNIHandle. Won't the
>>> JNIHandle ensure the object is seen as live?
>> Unfortunately it isn't.
>>
>> If we are using G1 and accessing the value of the referent field in a
>> reference object then we need to register a non-null referent with
>> the SATB barrier.
>>
>> In this code path, for example:
>>
>> (1) Object x is tagged.
>> (2) x becomes unreachable, with the only remaining reference being
>> the weak reference in the tag hashmap.
>> (3) Concurrent GC starts and has completed marking, but has not yet
>> entered the remark pause where reference processing occurs.
>> (4) GetObjectsWithTags is used to obtain x. As reference processing
>> has not yet run, x is still present in the tag hashmap. x remains
>> unmarked, because there is no read(SATB) barrier on that access.
>> (5) GC remark pause runs reference processing, determines x is dead,
>> so clears the tag entry, and reuses the space previously occupied by
>> x.
>> (6) The GetObjectsWithTags result now refers to a dead and reclaimed
>> x.
>> A crash may follow.
>> (From Kim Barrett's note)
>>
>> FYI, there are similar treatments already for this case.
>> Plz, search for "G1SATBCardTableModRefBS::enqueue", especially
>> Unsafe_GetObject().
>>
>> I added this comment at the patch.
>> Webrev: http://cr.openjdk.java.net/~sangheki/8173013/webrev.1
> 1539         // We could be accessing the referent field in a reference
> 1540         // object. If G1 is enabled then we need to register non-
> null
> 1541         // referent with the SATB barrier.
>
> I do not think this comment is complete, or at least I do not see why
> the object in question needs to be a "referent field in a reference".
> Maybe you meant that the tag map entry acts similar to the referent of
> a j.l.ref.WeakReference, so we need to handle it the same as when a
> thread accesses a weak reference in normal java code (i.e. the read
> barrier).
Thank you for correctly understanding what I wanted to say.

>
> As the problem description above indicates, this can occur with any
> reference to an object where the tag map has the only (implicitly weak)
> reference to as far as I can see.
>
> I.e. maybe something like:
>
> "The reference in this tag map could be the only (implicitly weak)
> reference to that object. If we hand it out we need to keep it live wrt
> SATB marking similar to other j.l.ref.Reference referents."
I like this comment.
If other reviewers don't have better suggestion, I will upload the
revised patch with this.

Thanks,
Sangheon


>
> Probably others can provide a better description.
>
> Otherwise it seems good.
>
> esses
>
> Thanks,
>    Thomas

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

Kim Barrett
> On Feb 3, 2017, at 1:41 PM, sangheon <[hidden email]> wrote:
>> "The reference in this tag map could be the only (implicitly weak)
>> reference to that object. If we hand it out we need to keep it live wrt
>> SATB marking similar to other j.l.ref.Reference referents."
> I like this comment.
> If other reviewers don't have better suggestion, I will upload the revised patch with this.

Looks good with something like Thomas's improved comment.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

sangheon.kim@oracle.com
Hi Kim,

On 02/03/2017 01:05 PM, Kim Barrett wrote:
>> On Feb 3, 2017, at 1:41 PM, sangheon <[hidden email]> wrote:
>>> "The reference in this tag map could be the only (implicitly weak)
>>> reference to that object. If we hand it out we need to keep it live wrt
>>> SATB marking similar to other j.l.ref.Reference referents."
>> I like this comment.
>> If other reviewers don't have better suggestion, I will upload the revised patch with this.
> Looks good with something like Thomas's improved comment.
>
Thanks for the review and all the discussion for this CR.
And Thomas' comment is the candidate for now.

Sangheon

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

David Holmes
In reply to this post by sangheon.kim@oracle.com
Hi Sangheon,

On 3/02/2017 2:00 PM, sangheon wrote:

> Hi David,
>
> Thank you for looking at this!
>
> On 02/02/2017 05:20 PM, David Holmes wrote:
>> Hi Sangheon,
>>
>> On 3/02/2017 5:11 AM, sangheon wrote:
>>> Hi all,
>>>
>>> Could I have some reviews for this change that adds G1 pre-barrier?
>>>
>>> JvmtiTagHashmapEntry has a bare oop member and this is a weak reference.
>>> So any place that allows this oop to 'escape' needs the G1 pre-barrier.
>>> JvmtiEnv::GetObjectsWithTags() provides such an escape path.
>>>
>>> For G1, in order to maintain the SATB invariants, reading the referent
>>> of a weak reference must ensure the referent is marked alive.
>>>
>>> So this proposal includes adding the pre-barrier at
>>> TagObjectCollector::do_entry(JvmtiTagHashmapEntry* entry) which I see
>>> the only place interacts(except 'peek' operations) with the bare oop
>>> member.
>>
>> Pardon my GC ignorance but it seems odd to me that this barrier is
>> inserted immediately before we create a local JNIHandle. Won't the
>> JNIHandle ensure the object is seen as live?
> Unfortunately it isn't.
>
> If we are using G1 and accessing the value of the referent field in a
> reference object then we need to register a non-null referent with the
> SATB barrier.
>
> In this code path, for example:
>
> (1) Object x is tagged.
> (2) x becomes unreachable, with the only remaining reference being the
> weak reference in the tag hashmap.
> (3) Concurrent GC starts and has completed marking, but has not yet
> entered the remark pause where reference processing occurs.
> (4) GetObjectsWithTags is used to obtain x. As reference processing has
> not yet run, x is still present in the tag hashmap. x remains unmarked,
> because there is no read(SATB) barrier on that access.
> (5) GC remark pause runs reference processing, determines x is dead, so
> clears the tag entry, and reuses the space previously occupied by x.
> (6) The GetObjectsWithTags result now refers to a dead and reclaimed x.
> A crash may follow.
> (From Kim Barrett's note)
>
> FYI, there are similar treatments already for this case.
> Plz, search for "G1SATBCardTableModRefBS::enqueue", especially
> Unsafe_GetObject().

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). Does the SATB occur at a
global safepoint?

David

> I added this comment at the patch.
> Webrev: http://cr.openjdk.java.net/~sangheki/8173013/webrev.1
>
> Thanks,
> Sangheon
>
>
>>
>> Thanks,
>> David
>>
>>> As writing stable test could take some more time, Stefan Karlsson and I
>>> did some tests to provoke this problem.
>>> ( Stefan Karlsson kindly provided the test,
>>> http://cr.openjdk.java.net/~stefank/8173013/reproducer/
>>> <http://cr.openjdk.java.net/%7Estefank/8173013/reproducer/> )
>>> With this proposed patch, the problem goes away.
>>>
>>> CR: https://bugs.openjdk.java.net/browse/JDK-8173013
>>> Webrev: http://cr.openjdk.java.net/~sangheki/8173013/webrev.0
>>> Testing: JPRT, some closed tests which use JVMTI and JDI.
>>>
>>> Thanks,
>>> Sangheon
>>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

sangheon.kim@oracle.com
In reply to this post by sangheon.kim@oracle.com
Hi Kim and Thomas,

Here's webrev.2 with Thomas' comment version.
http://cr.openjdk.java.net/~sangheki/8173013/webrev.2

--------------------
1538 #if INCLUDE_ALL_GCS
1539         if (UseG1GC) {
1540           // The reference in this tag map could be the only (implicitly weak)
1541           // reference to that object. If we hand it out, we need to keep it live wrt
1542           // SATB marking similar to other j.l.ref.Reference referents.
1543           G1SATBCardTableModRefBS::enqueue(o);
1544         }
1545 #endif
--------------------

Thanks,
Sangheon


On 02/03/2017 01:10 PM, sangheon wrote:
Hi Kim,

On 02/03/2017 01:05 PM, Kim Barrett wrote:
On Feb 3, 2017, at 1:41 PM, sangheon [hidden email] wrote:
"The reference in this tag map could be the only (implicitly weak)
reference to that object. If we hand it out we need to keep it live wrt
SATB marking similar to other j.l.ref.Reference referents."
I like this comment.
If other reviewers don't have better suggestion, I will upload the revised patch with this.
Looks good with something like Thomas's improved comment.

Thanks for the review and all the discussion for this CR.
And Thomas' comment is the candidate for now.

Sangheon


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

Kim Barrett
> On Feb 6, 2017, at 1:10 AM, sangheon <[hidden email]> wrote:
>
> Hi Kim and Thomas,
>
> Here's webrev.2 with Thomas' comment version.
> http://cr.openjdk.java.net/~sangheki/8173013/webrev.2
>
> --------------------
> 1538 #if INCLUDE_ALL_GCS
> 1539         if (UseG1GC) {
> 1540           // The reference in this tag map could be the only (implicitly weak)
> 1541           // reference to that object. If we hand it out, we need to keep it live wrt
> 1542           // SATB marking similar to other j.l.ref.Reference referents.
> 1543           G1SATBCardTableModRefBS::enqueue(o);
> 1544         }
> 1545 #endif
> ——————————

Looks good.

>
> Thanks,
> Sangheon
>
>
> On 02/03/2017 01:10 PM, sangheon wrote:
>> Hi Kim,
>>
>> On 02/03/2017 01:05 PM, Kim Barrett wrote:
>>>> On Feb 3, 2017, at 1:41 PM, sangheon <[hidden email]> wrote:
>>>>> "The reference in this tag map could be the only (implicitly weak)
>>>>> reference to that object. If we hand it out we need to keep it live wrt
>>>>> SATB marking similar to other j.l.ref.Reference referents."
>>>> I like this comment.
>>>> If other reviewers don't have better suggestion, I will upload the revised patch with this.
>>> Looks good with something like Thomas's improved comment.
>>>
>> Thanks for the review and all the discussion for this CR.
>> And Thomas' comment is the candidate for now.
>>
>> Sangheon


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

Thomas Schatzl
Hi,

On Mon, 2017-02-06 at 01:17 -0500, Kim Barrett wrote:

> >
> > On Feb 6, 2017, at 1:10 AM, sangheon <[hidden email]>
> > wrote:
> >
> > Hi Kim and Thomas,
> >
> > Here's webrev.2 with Thomas' comment version.
> > http://cr.openjdk.java.net/~sangheki/8173013/webrev.2
> >
> > --------------------
> > 1538 #if INCLUDE_ALL_GCS
> > 1539         if (UseG1GC) {
> > 1540           // The reference in this tag map could be the only
> > (implicitly weak)
> > 1541           // reference to that object. If we hand it out, we
> > need to keep it live wrt
> > 1542           // SATB marking similar to other j.l.ref.Reference
> > referents.
> > 1543           G1SATBCardTableModRefBS::enqueue(o);
> > 1544         }
> > 1545 #endif
> > ——————————
> Looks good.

  looks good. Ship it.

Thomas
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

Kim Barrett
In reply to this post by David Holmes
> On Feb 5, 2017, at 10:19 PM, David Holmes <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

David Holmes
Hi Kim,

On 7/02/2017 8:46 AM, Kim Barrett wrote:

>> On Feb 5, 2017, at 10:19 PM, David Holmes <[hidden email]> 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.

Ok. Understood.

>> 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.

Thanks,
David
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

Kim Barrett
> On Feb 6, 2017, at 10:44 PM, David Holmes <[hidden email]> wrote:
>>> 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.

To be more precise, the barriers in question are executed by the
mutator concurrently with the marking phase of the collector.  Once
marking is (mostly) complete, G1 safepoints and performs various
tasks, including reference processing.  The barrier must be atomic
wrto that safepoint (which is accomplished by not allowing any
safepoints during the barrier execution).  So yes, the sequence of
extract and enqueue are atomic wrto the relevant part of the GC.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

sangheon.kim@oracle.com
Hi David,

If you don't have any other questions/comments, can I proceed to push?

Kim, thank you very much for the all explanations.

Thanks,
Sangheon


On 02/07/2017 11:00 PM, Kim Barrett wrote:
On Feb 6, 2017, at 10:44 PM, David Holmes [hidden email] wrote:
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.
To be more precise, the barriers in question are executed by the
mutator concurrently with the marking phase of the collector.  Once
marking is (mostly) complete, G1 safepoints and performs various
tasks, including reference processing.  The barrier must be atomic
wrto that safepoint (which is accomplished by not allowing any
safepoints during the barrier execution).  So yes, the sequence of
extract and enqueue are atomic wrto the relevant part of the GC.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

David Holmes
On 10/02/2017 4:54 AM, sangheon wrote:
> Hi David,
>
> If you don't have any other questions/comments, can I proceed to push?

Sorry - yes, of course.

> Kim, thank you very much for the all explanations.

Yes much appreciated!

Thanks,
David

> Thanks,
> Sangheon
>
>
> On 02/07/2017 11:00 PM, Kim Barrett wrote:
>>> On Feb 6, 2017, at 10:44 PM, David Holmes <[hidden email]> wrote:
>>>>> 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.
>> To be more precise, the barriers in question are executed by the
>> mutator concurrently with the marking phase of the collector.  Once
>> marking is (mostly) complete, G1 safepoints and performs various
>> tasks, including reference processing.  The barrier must be atomic
>> wrto that safepoint (which is accomplished by not allowing any
>> safepoints during the barrier execution).  So yes, the sequence of
>> extract and enqueue are atomic wrto the relevant part of the GC.
>>
>>
>
Loading...