From stefan.johansson at oracle.com  Tue Apr  3 07:16:55 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 3 Apr 2018 09:16:55 +0200
Subject: RFR (S): 8200426: Make G1 code use _g1h members
In-Reply-To: <1522406957.2390.1.camel@oracle.com>
References: <1522333146.2451.5.camel@oracle.com>
 <7ea7c816-66ca-c6f5-84c3-2d7772674fce@oracle.com>
 <1522348195.2273.1.camel@oracle.com>
 <53ee6863-3988-2c73-e649-bd39b533c8f2@oracle.com>
 <1522406957.2390.1.camel@oracle.com>
Message-ID: <9d55baab-43a2-93ec-da85-425734744b7a@oracle.com>

Still good!

Stefan

On 2018-03-30 12:49, Thomas Schatzl wrote:
> Hi,
>
> On Thu, 2018-03-29 at 21:40 -0700, sangheon.kim wrote:
>> Hi Thomas,
>>
>> On 03/29/2018 11:29 AM, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Thu, 2018-03-29 at 10:10 -0700, sangheon.kim wrote:
>>>> Hi Thomas,
>>>>
>>>> Thank you for addressing this cleanup!
>>>>
>>>> On 03/29/2018 07:19 AM, Thomas Schatzl wrote:
>>>>> Hi all,
>>>>>
>>>>>      can I have reviews for this change that tries to make the
>>>>> use of locally cached members of G1CollectedHeap* uniform by
>>>>> actually using it and renaming the members uniformly to "g1h".
>>>>>
>>>>> This change has been suggested in a recent review.
>>>>>
>>>>> There has not actually been a lot to change.
>>>>>
>>>>> CR:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8200426
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~tschatzl/8200426/webrev
>>>> Looks good.
>>>> And I found more.
>>>>
>>> I should improve my grep-fu...
>> Sometimes good IDE works better. :-)
>>
>>> Anyway, I think I fixed all of this and some more locations at
>>>
>>> http://cr.openjdk.java.net/~tschatzl/8200426/webrev.0_to_1 (diff)
>>> http://cr.openjdk.java.net/~tschatzl/8200426/webrev.1 (full)
>> Looks good, but below is not fixed.
>> I don't need a new webrev for this.
>>
>> src/hotspot/share/gc/g1/g1OopClosures.hpp:
>>     191:   G1CollectedHeap* _g1;
>>     196:     _g1(g1h),
>>
>> src/hotspot/share/gc/g1/g1OopClosures.inline.hpp:
>>     146:   HeapRegionRemSet* to_rem_set =
>> _g1->heap_region_containing(obj)->rem_set();
>>
>    I updated the webrev in place.
>
> Thanks for your review.
>
> Thanks,
>    Thomas



From stefan.karlsson at oracle.com  Tue Apr  3 08:18:04 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 3 Apr 2018 10:18:04 +0200
Subject: space.inline.hpp build failure
In-Reply-To: <8d453d26-4f9b-d872-4175-fa6b3f2e1dbe@oracle.com>
References: <CAF9Mjxnm3MdC+moxQYtOuT5m3TF0nX_EaVrzpozCWYV9WKFLYA@mail.gmail.com>
 <8d453d26-4f9b-d872-4175-fa6b3f2e1dbe@oracle.com>
Message-ID: <b3e8ff35-2027-0758-89de-b59b68ef25ba@oracle.com>

Looks good to me.

StefanK

On 2018-03-31 04:53, David Holmes wrote:
> Moving discussion to hotspot-gc-dev
> 
> David
> 
> On 30/03/2018 4:36 PM, Peter Johnson wrote:
>> When cross compiling either 9 or 10 to ARM with gcc 5.5.0, I get the
>> following linker error:
>> /tmp/cc7TKVtK.ltrans2.ltrans.o: In function
>> `OffsetTableContigSpace::block_start_const(void const*) const':
>> <artificial>:(.text+0x26e4): undefined reference to
>> `BlockOffsetTable::block_start(void const*) const'
>> /tmp/cc7TKVtK.ltrans13.ltrans.o: In function
>> `OffsetTableContigSpace::verify() const':
>> <artificial>:(.text+0x2ca6): undefined reference to
>> `BlockOffsetTable::block_start(void const*) const'
>> collect2: error: ld returned 1 exit status
>>
>> This appears to be due to a missing include in space.inline.hpp.  
>> Applying
>> the following patch fixes the build for me.
>>
>> Thanks,
>> Peter
>>
>> diff -r 5ab7a67bc155 src/share/vm/gc/shared/space.inline.hpp
>> --- a/src/share/vm/gc/shared/space.inline.hpp?? Fri Sep 08 18:24:18 2017
>> +0000
>> +++ b/src/share/vm/gc/shared/space.inline.hpp?? Thu Mar 29 23:25:25 2018
>> -0700
>> @@ -26,6 +26,7 @@
>> ? #define SHARE_VM_GC_SHARED_SPACE_INLINE_HPP
>>
>> ? #include "gc/serial/markSweep.inline.hpp"
>> +#include "gc/shared/blockOffsetTable.inline.hpp"
>> ? #include "gc/shared/collectedHeap.hpp"
>> ? #include "gc/shared/generation.hpp"
>> ? #include "gc/shared/space.hpp"
>>


From thomas.schatzl at oracle.com  Tue Apr  3 08:59:42 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 03 Apr 2018 10:59:42 +0200
Subject: RFR (S): 8200426: Make G1 code use _g1h members
In-Reply-To: <9d55baab-43a2-93ec-da85-425734744b7a@oracle.com>
References: <1522333146.2451.5.camel@oracle.com>
 <7ea7c816-66ca-c6f5-84c3-2d7772674fce@oracle.com>
 <1522348195.2273.1.camel@oracle.com>
 <53ee6863-3988-2c73-e649-bd39b533c8f2@oracle.com>
 <1522406957.2390.1.camel@oracle.com>
 <9d55baab-43a2-93ec-da85-425734744b7a@oracle.com>
Message-ID: <1522745982.2400.0.camel@oracle.com>

Hi Stefan,

On Tue, 2018-04-03 at 09:16 +0200, Stefan Johansson wrote:
> Still good!
> 
> Stefan

  thanks for your review.

Thomas



From leo.korinth at oracle.com  Tue Apr  3 09:43:19 2018
From: leo.korinth at oracle.com (Leo Korinth)
Date: Tue, 3 Apr 2018 11:43:19 +0200
Subject: RFR: 8200371: In g1, rename ConcurrentMarkThread to
 G1ConcurrentMarkThread
In-Reply-To: <6c4c74d7-a9ec-3b5e-58e6-6b97a0d18e72@oracle.com>
References: <427cf9a1-118c-6b2d-f035-a7794f0c65e9@oracle.com>
 <6c4c74d7-a9ec-3b5e-58e6-6b97a0d18e72@oracle.com>
Message-ID: <c563a0b0-8e50-1d0d-87b2-5f1ecc857df9@oracle.com>

Thanks for your reviews Sangheon and Thomas. I will continue with your 
suggestions in a new cr.

Thanks,
Leo

On 30/03/18 18:44, sangheon.kim wrote:
> Hi Leo,
> 
> On 03/29/2018 08:09 AM, Leo Korinth wrote:
>> Hi,
>>
>> I am renaming ConcurrentMarkThread to G1ConcurrentMarkThread.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8200371
>>
>> Webrev:
>> http://cr.openjdk.java.net/~lkorinth/8200371/00/index.html
>>
>> Testing:
>> - building with and without precompiled headers
>> - hs-tier1, hs-tier2
> Looks good.
> 
> And I agree to Thomas about changing _cmThread in G1CollectedHeap.
> 
> Thanks,
> Sangheon
> 
> 
>>
>> Thanks,
>> Leo
> 


From stefan.johansson at oracle.com  Tue Apr  3 10:58:04 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 3 Apr 2018 12:58:04 +0200
Subject: RFR (S/M): 8178105: Switch mark bitmaps during Remark
In-Reply-To: <1522334136.2451.15.camel@oracle.com>
References: <1522334136.2451.15.camel@oracle.com>
Message-ID: <c4a8f532-db1b-09f8-5b9d-aa76f2f6ae4d@oracle.com>

Hi Thomas,

On 2018-03-29 16:35, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for this small change that makes G1 switch the
> mark bitmaps already during the Remark pause as opposed waiting until
> Cleanup?
>
> This is the last step before G1 can reclaim regions at Remark, which
> means that empty regions can be cleaned up more more quickly than
> before (JDK-8154528, coming soon :)).
>
> The main changes apart from actually switching the bitmaps consist of
> updating the liveness information, i.e. how many bytes are live in a
> region, now already available at Remark since JDK-8197850, also at the
> same time.
>
> Previously G1 used the Rebuild Remsets phase to calculate that at the
> same time.
>
> I could not find significant differences in timing.
>
> This change depends on the recent g1ConcurrentMark refactorings,
> particularly JDK-8200234.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8178105
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8178105/
Looks good, but a few comments:

src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
1031???? for (uint i = region_idx; i < (region_idx + 
num_regions_in_humongous); i++) {
1032?????? HeapRegion* const r = _g1h->region_at(i);
1033?????? size_t const words_to_add = MIN2(HeapRegion::GrainWords, 
marked_words);
1034?????? r->add_to_marked_bytes(words_to_add * HeapWordSize);
1035?????? marked_words -= words_to_add;
1036???? }
Could be nice to assert that marked_words is zero after the iteration, 
i.e. that everything got distributed and maybe also that marked_words is 
greater than 0 during the iteration.

1047?????? log_trace(gc)("Added " SIZE_FORMAT " words to region %u 
(%s)", marked_words, region_idx, hr->get_type_str());
I think the logging should use at least one more tag, maybe "region" or 
"marking", but you probably know what makes most sense in this area. I 
also think it would be nice if we got this same log-line for all 
regions. Now we get this for "normal" regions, but we get 
"Distributing..." for humongous start regions and "Not Added..." for 
humongous continuous. So I would suggest adding the same log-line to the 
distribute-function after line 1034.

1045???? if (!hr->is_humongous()) {
Since the comment talks about humongous regions I would prefer not 
negating the statement and have something like:
if (hr->is_humongous()) {
 ? if (hr->is_starts_humongous()) {
 ? ? distribute_marked_bytes(hr, marked_words);
 ? } else {
 ? ? assert(marked_words == 0, "continuous humongous are not accounted 
separately");
 ? }
} else {
 ? hr->add_to_marked_bytes(marked_words * HeapWordSize);
 ? log_trace(gc)("Added " SIZE_FORMAT " words to region %u (%s)", 
marked_words, region_idx, hr->get_type_str());
}

1058 }
Newline before public :)

1686?? if (mark_completed) {
1687???? is_alive = &is_alive_prev;
1688?? } else {
1689???? is_alive = &is_alive_next;
1690?? }
1691?? _gc_tracer_cm->report_object_count_after_gc(is_alive);

I would prefer moving the call into the if and only setup the closure 
when needed:
if (mark_completed) {
 ? G1ObjectCountIsAliveClosure is_alive(_g1h);
 ? _gc_tracer_cm->report_object_count_after_gc(&is_alive);
} else {
 ? G1CMIsAliveClosure is_alive(_g1h);
 ? _gc_tracer_cm->report_object_count_after_gc(&is_alive);
}
----

Thanks,
Stefan


> Testing:
> hs-tier 1-5
>
> Thanks,
>    Thomas
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180403/4dc316e5/attachment.htm>

From shade at redhat.com  Tue Apr  3 12:21:36 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 3 Apr 2018 14:21:36 +0200
Subject: RFR: JDK-8199735: Mark word updates need to use Access API
In-Reply-To: <4cdc8f4d-3f27-5c20-a606-251077ed9a82@redhat.com>
References: <7bd73e32-a26b-2504-f069-b74807ae5e53@redhat.com>
 <859ac657-78c9-c7ab-0ec0-eddda331001b@redhat.com>
 <b8cb91fc-d332-baf6-c6ab-93d1ae39c6b1@redhat.com>
 <5AB3B052.4000304@oracle.com>
 <63199799-0194-a1d4-9c89-d95251c7aa7d@redhat.com>
 <5AB90C07.3020507@oracle.com>
 <4cdc8f4d-3f27-5c20-a606-251077ed9a82@redhat.com>
Message-ID: <21286315-4a62-c06b-a13a-dfe4a83d88d3@redhat.com>

On 03/26/2018 06:40 PM, Roman Kennke wrote:
>>> Differential:
>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03.diff/
>>> Full:
>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03/

Looks good. A bit unfortunate it has to have many changes around due to the rename, but oh well.

Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180403/1b0640af/signature.asc>

From thomas.schatzl at oracle.com  Tue Apr  3 12:25:29 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 03 Apr 2018 14:25:29 +0200
Subject: RFR (S/M): 8178105: Switch mark bitmaps during Remark
In-Reply-To: <c4a8f532-db1b-09f8-5b9d-aa76f2f6ae4d@oracle.com>
References: <1522334136.2451.15.camel@oracle.com>
 <c4a8f532-db1b-09f8-5b9d-aa76f2f6ae4d@oracle.com>
Message-ID: <1522758329.2573.9.camel@oracle.com>

Hi Stefan,

On Tue, 2018-04-03 at 12:58 +0200, Stefan Johansson wrote:
> Hi Thomas,
> 
> On 2018-03-29 16:35, Thomas Schatzl wrote:
> > Hi all,
> > 
> >   can I have reviews for this small change that makes G1 switch the
> > mark bitmaps already during the Remark pause as opposed waiting
> > until
> > Cleanup?
> > 
> > This is the last step before G1 can reclaim regions at Remark,
> > which means that empty regions can be cleaned up more more quickly
> > than before (JDK-8154528, coming soon :)).
> > 
> > The main changes apart from actually switching the bitmaps consist
> > of updating the liveness information, i.e. how many bytes are live
> > in a region, now already available at Remark since JDK-8197850,
> > also at the same time.
> > 
> > Previously G1 used the Rebuild Remsets phase to calculate that at
> > the same time.
> > 
> > I could not find significant differences in timing.
> > 
> > This change depends on the recent g1ConcurrentMark refactorings,
> > particularly JDK-8200234.
> > 
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8178105
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8178105/
>  Looks good, but a few comments:
> 
> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
> 1031     for (uint i = region_idx; i < (region_idx +
> num_regions_in_humongous); i++) {
> 1032       HeapRegion* const r = _g1h->region_at(i);
> 1033       size_t const words_to_add = MIN2(HeapRegion::GrainWords,
> marked_words);
> 1034       r->add_to_marked_bytes(words_to_add * HeapWordSize);
> 1035       marked_words -= words_to_add;
> 1036     }
> Could be nice to assert that marked_words is zero after the
> iteration, i.e. that everything got distributed 

Done.

> and maybe also that marked_words is greater than 0 during the
> iteration.

Can't check that - both sizes are unsigned type. The MIN2() in line
1033 prevents words_to_add to ever be greater than marked_words, so I
think a check like that will be useless.

I added a different kind of check that verifies what you probably
thought of, and that is that the number of words to add to the current
region must always be larger than zero. If it is zero, there is
something really wrong.

> 
> 1047       log_trace(gc)("Added " SIZE_FORMAT " words to region %u
> (%s)", marked_words, region_idx, hr->get_type_str());
> I think the logging should use at least one more tag, maybe "region"
> or "marking", but you probably know what makes most sense in this
> area. I also think it would be nice if we got this same log-line for
> all regions. Now we get this for "normal" regions, but we get
> "Distributing..." for humongous start regions and "Not Added..." for
> humongous continuous. So I would suggest adding the same log-line to
> the distribute-function after line 1034.

Done.

> 1045     if (!hr->is_humongous()) {
> Since the comment talks about humongous regions I would prefer not
> negating the statement and have something like:
> if (hr->is_humongous()) {
>   if (hr->is_starts_humongous()) {
>     distribute_marked_bytes(hr, marked_words);
>   } else {
>     assert(marked_words == 0, "continuous humongous are not accounted
> separately");
>   }
> } else {
>   hr->add_to_marked_bytes(marked_words * HeapWordSize);
>   log_trace(gc)("Added " SIZE_FORMAT " words to region %u (%s)",
> marked_words, region_idx, hr->get_type_str());
> }
> 
> 1058 }
> Newline before public :)
> 
> 1686   if (mark_completed) {
> 1687     is_alive = &is_alive_prev;
> 1688   } else {
> 1689     is_alive = &is_alive_next;
> 1690   }
> 1691   _gc_tracer_cm->report_object_count_after_gc(is_alive);
> 
> I would prefer moving the call into the if and only setup the closure
> when needed:
> if (mark_completed) {
>   G1ObjectCountIsAliveClosure is_alive(_g1h);
>   _gc_tracer_cm->report_object_count_after_gc(&is_alive);
> } else {
>   G1CMIsAliveClosure is_alive(_g1h);
>   _gc_tracer_cm->report_object_count_after_gc(&is_alive); 
> }

All fixed.

Webrevs:
http://cr.openjdk.java.net/~tschatzl/8178105/webrev.0_to_1/ (diff)
http://cr.openjdk.java.net/~tschatzl/8178105/webrev.1/ (full)
Testing:
locally ran all gc/g1 jtreg tests with no problems

Thomas



From magnus.ihse.bursie at oracle.com  Tue Apr  3 12:39:17 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Apr 2018 14:39:17 +0200
Subject: space.inline.hpp build failure
In-Reply-To: <CAF9Mjxnm3MdC+moxQYtOuT5m3TF0nX_EaVrzpozCWYV9WKFLYA@mail.gmail.com>
References: <CAF9Mjxnm3MdC+moxQYtOuT5m3TF0nX_EaVrzpozCWYV9WKFLYA@mail.gmail.com>
Message-ID: <bd1fc8a3-8168-5625-35cb-2254a9700f0c@oracle.com>

Hi Peter,

This is a hotspot issue, not a build issue.

/Magnus

On 2018-03-30 08:36, Peter Johnson wrote:
> When cross compiling either 9 or 10 to ARM with gcc 5.5.0, I get the
> following linker error:
> /tmp/cc7TKVtK.ltrans2.ltrans.o: In function
> `OffsetTableContigSpace::block_start_const(void const*) const':
> <artificial>:(.text+0x26e4): undefined reference to
> `BlockOffsetTable::block_start(void const*) const'
> /tmp/cc7TKVtK.ltrans13.ltrans.o: In function
> `OffsetTableContigSpace::verify() const':
> <artificial>:(.text+0x2ca6): undefined reference to
> `BlockOffsetTable::block_start(void const*) const'
> collect2: error: ld returned 1 exit status
>
> This appears to be due to a missing include in space.inline.hpp.  Applying
> the following patch fixes the build for me.
>
> Thanks,
> Peter
>
> diff -r 5ab7a67bc155 src/share/vm/gc/shared/space.inline.hpp
> --- a/src/share/vm/gc/shared/space.inline.hpp   Fri Sep 08 18:24:18 2017
> +0000
> +++ b/src/share/vm/gc/shared/space.inline.hpp   Thu Mar 29 23:25:25 2018
> -0700
> @@ -26,6 +26,7 @@
>   #define SHARE_VM_GC_SHARED_SPACE_INLINE_HPP
>
>   #include "gc/serial/markSweep.inline.hpp"
> +#include "gc/shared/blockOffsetTable.inline.hpp"
>   #include "gc/shared/collectedHeap.hpp"
>   #include "gc/shared/generation.hpp"
>   #include "gc/shared/space.hpp"



From stefan.johansson at oracle.com  Tue Apr  3 12:49:21 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 3 Apr 2018 14:49:21 +0200
Subject: RFR (S/M): 8178105: Switch mark bitmaps during Remark
In-Reply-To: <1522758329.2573.9.camel@oracle.com>
References: <1522334136.2451.15.camel@oracle.com>
 <c4a8f532-db1b-09f8-5b9d-aa76f2f6ae4d@oracle.com>
 <1522758329.2573.9.camel@oracle.com>
Message-ID: <09b374ab-a86f-bcff-00f4-4b2874fb59ff@oracle.com>



On 2018-04-03 14:25, Thomas Schatzl wrote:
> Hi Stefan,
> 
> On Tue, 2018-04-03 at 12:58 +0200, Stefan Johansson wrote:
>> Hi Thomas,
>>
>> On 2018-03-29 16:35, Thomas Schatzl wrote:
>>> Hi all,
>>>
>>>    can I have reviews for this small change that makes G1 switch the
>>> mark bitmaps already during the Remark pause as opposed waiting
>>> until
>>> Cleanup?
>>>
>>> This is the last step before G1 can reclaim regions at Remark,
>>> which means that empty regions can be cleaned up more more quickly
>>> than before (JDK-8154528, coming soon :)).
>>>
>>> The main changes apart from actually switching the bitmaps consist
>>> of updating the liveness information, i.e. how many bytes are live
>>> in a region, now already available at Remark since JDK-8197850,
>>> also at the same time.
>>>
>>> Previously G1 used the Rebuild Remsets phase to calculate that at
>>> the same time.
>>>
>>> I could not find significant differences in timing.
>>>
>>> This change depends on the recent g1ConcurrentMark refactorings,
>>> particularly JDK-8200234.
>>>
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8178105
>>> Webrev:
>>> http://cr.openjdk.java.net/~tschatzl/8178105/
>>   Looks good, but a few comments:
>>
>> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
>> 1031     for (uint i = region_idx; i < (region_idx +
>> num_regions_in_humongous); i++) {
>> 1032       HeapRegion* const r = _g1h->region_at(i);
>> 1033       size_t const words_to_add = MIN2(HeapRegion::GrainWords,
>> marked_words);
>> 1034       r->add_to_marked_bytes(words_to_add * HeapWordSize);
>> 1035       marked_words -= words_to_add;
>> 1036     }
>> Could be nice to assert that marked_words is zero after the
>> iteration, i.e. that everything got distributed
> 
> Done.
> 
>> and maybe also that marked_words is greater than 0 during the
>> iteration.
> 
> Can't check that - both sizes are unsigned type. The MIN2() in line
> 1033 prevents words_to_add to ever be greater than marked_words, so I
> think a check like that will be useless.
Yes, but it could be if equal marked_words will be 0 and I want to 
assert that this never happens before the last iteration.
> 
> I added a different kind of check that verifies what you probably
> thought of, and that is that the number of words to add to the current
> region must always be larger than zero. If it is zero, there is
> something really wrong.
Exactly, that's what I wanted. But I don't see that check now, just 
having a assert(marked_words != 0, "") on row 1032 would be enough.
> 
>>
>> 1047       log_trace(gc)("Added " SIZE_FORMAT " words to region %u
>> (%s)", marked_words, region_idx, hr->get_type_str());
>> I think the logging should use at least one more tag, maybe "region"
>> or "marking", but you probably know what makes most sense in this
>> area. I also think it would be nice if we got this same log-line for
>> all regions. Now we get this for "normal" regions, but we get
>> "Distributing..." for humongous start regions and "Not Added..." for
>> humongous continuous. So I would suggest adding the same log-line to
>> the distribute-function after line 1034.
> 
> Done.
Sorry for being picky but the current solution won't print anything for 
continuous humongous. Adding the log to distribute_marked_bytes() would 
solve this and we would still get info on region type so I see no need for:
1052         log_trace(gc, marking)("Adding " SIZE_FORMAT " words to 
humongous start region %u (%s), word size %d (%f)",
1053                                marked_words, region_idx, 
hr->get_type_str(),
1054                                oop(hr->bottom())->size(), 
(double)oop(hr->bottom())->size() / HeapRegion::GrainWords);

> 
>> 1045     if (!hr->is_humongous()) {
>> Since the comment talks about humongous regions I would prefer not
>> negating the statement and have something like:
>> if (hr->is_humongous()) {
>>    if (hr->is_starts_humongous()) {
>>      distribute_marked_bytes(hr, marked_words);
>>    } else {
>>      assert(marked_words == 0, "continuous humongous are not accounted
>> separately");
>>    }
>> } else {
>>    hr->add_to_marked_bytes(marked_words * HeapWordSize);
>>    log_trace(gc)("Added " SIZE_FORMAT " words to region %u (%s)",
>> marked_words, region_idx, hr->get_type_str());
>> }
>>
>> 1058 }
>> Newline before public :)
>>
>> 1686   if (mark_completed) {
>> 1687     is_alive = &is_alive_prev;
>> 1688   } else {
>> 1689     is_alive = &is_alive_next;
>> 1690   }
>> 1691   _gc_tracer_cm->report_object_count_after_gc(is_alive);
>>
>> I would prefer moving the call into the if and only setup the closure
>> when needed:
>> if (mark_completed) {
>>    G1ObjectCountIsAliveClosure is_alive(_g1h);
>>    _gc_tracer_cm->report_object_count_after_gc(&is_alive);
>> } else {
>>    G1CMIsAliveClosure is_alive(_g1h);
>>    _gc_tracer_cm->report_object_count_after_gc(&is_alive);
>> }
> 
> All fixed.
> 
> Webrevs:
> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.0_to_1/ (diff)
> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.1/ (full)
Apart from the small things above this looks great.

Thanks,
Stefan

> Testing:
> locally ran all gc/g1 jtreg tests with no problems
> 
> Thomas
> 


From stefan.johansson at oracle.com  Tue Apr  3 12:53:44 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 3 Apr 2018 14:53:44 +0200
Subject: RFR (S): 8154528: Reclaim regions emptied by marking in Remark
 pause
In-Reply-To: <1522334960.2451.24.camel@oracle.com>
References: <1522334960.2451.24.camel@oracle.com>
Message-ID: <a334fa57-c6b8-7459-8c08-9cfde460fbdb@oracle.com>

Thanks for yet another nice improvement of G1 Thomas,

On 2018-03-29 16:49, Thomas Schatzl wrote:
> Hi all,
> 
>    can I have reviews for this change that moves the space reclamation
> of empty regions into the Remark pause, which makes these regions
> available much sooner than before, with the obvious benefits of doing
> so.
> 
> The Cleanup pause now only contains updating the remembered set states
> after rebuilding remembered sets and determining the collection set
> candidates. In the future we might be able to make those concurrent and
> drop the Cleanup pause completely.
> 
> There is not much too say here, after all the recent refactorings this
> patch is almost trivial :)
> 
>  From a timing POV this adds a few ms to the Remark pause in my
> measurements, mostly from the code root purging moved here. I think
> there is enough opportunity in the remark pause to decrease its
> duration in the future that outweighs the mentioned benefits.
> 
> Thanks go to everyone reviewing so far, particularly StefanJ and
> Sangheon!
> 
> Depends on JDK-8178105.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8154528
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8154528/webrev/

The change looks good, but I realized that reclaim_empty_regions() uses 
a task named G1CleanupTask. This naming is a bit unfortunate now since 
this is not the cleanup phase anymore, but still correct since we are 
doing cleanup. What do you think about renaming it to G1CleanRegionTask 
or G1ReclaimRegionTask? I also see that "cleanup" ripples down a bit but 
I don't think we need to change that. I'm fine with not doing anything 
at all but if you dislike the suggestion, but I wanted to raise the 
question.

Thanks,
Stefan

> Testing:
> hs-tier 1-5
> 
> Thanks,
>    Thomas
> 
> 
> 


From thomas.schatzl at oracle.com  Tue Apr  3 14:55:07 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 03 Apr 2018 16:55:07 +0200
Subject: RFR (S/M): 8178105: Switch mark bitmaps during Remark
In-Reply-To: <09b374ab-a86f-bcff-00f4-4b2874fb59ff@oracle.com>
References: <1522334136.2451.15.camel@oracle.com>
 <c4a8f532-db1b-09f8-5b9d-aa76f2f6ae4d@oracle.com>
 <1522758329.2573.9.camel@oracle.com>
 <09b374ab-a86f-bcff-00f4-4b2874fb59ff@oracle.com>
Message-ID: <1522767307.2582.2.camel@oracle.com>

Hi,

  thanks for your patience...

On Tue, 2018-04-03 at 14:49 +0200, Stefan Johansson wrote:
> 
> On 2018-04-03 14:25, Thomas Schatzl wrote:
> > Hi Stefan,
> > 
> > On Tue, 2018-04-03 at 12:58 +0200, Stefan Johansson wrote:
> > > Hi Thomas,
> > > 
> > > On 2018-03-29 16:35, Thomas Schatzl wrote:
> > > > Hi all,
> > > > [...]
> > > > 
> > > > CR:
> > > > https://bugs.openjdk.java.net/browse/JDK-8178105
> > > > Webrev:
> > > > http://cr.openjdk.java.net/~tschatzl/8178105/
> > > 
> > >   Looks good, but a few comments:
> > > 
[...]
> > I added a different kind of check that verifies what you probably
> > thought of, and that is that the number of words to add to the
> > current region must always be larger than zero. If it is zero,
> > there is something really wrong. 
> 
> Exactly, that's what I wanted. But I don't see that check now, just 
> having a assert(marked_words != 0, "") on row 1032 would be enough.

My fault. I did not upload the latest version of the change :( It is up
now, the only difference to previous is line 

1036       assert(words_to_add > 0, "Out of space to distribute before
end of humongous object in region %u (starts %u)", i, region_idx);

But there is a new webrev anyway... in the 1_to_2 webrev it is line
1033

> > > 
> > > 1047       log_trace(gc)("Added " SIZE_FORMAT " words to region
> > > %u
> > > (%s)", marked_words, region_idx, hr->get_type_str());
> > > I think the logging should use at least one more tag, maybe
> > > "region" or "marking", but you probably know what makes most
> > > sense in this area. I also think it would be nice if we got this
> > > same log-line for all regions. Now we get this for "normal"
> > > regions, but we get "Distributing..." for humongous start regions
> > > and "Not Added..." for humongous continuous. So I would suggest
> > > adding the same log-line  to the distribute-function after line
> > > 1034.
> > 
> > Done.
> 
> Sorry for being picky but the current solution won't print anything
> for continuous humongous. Adding the log to distribute_marked_bytes()
> would solve this and we would still get info on region type so I see
> no need for:

Okay. I think I got your intention right this time :)

> 1052         log_trace(gc, marking)("Adding " SIZE_FORMAT " words to 
> humongous start region %u (%s), word size %d (%f)",
> 1053                                marked_words, region_idx, 
> hr->get_type_str(),
> 1054                                oop(hr->bottom())->size(), 
> (double)oop(hr->bottom())->size() / HeapRegion::GrainWords);
[...]
> > All fixed.
> > 
> > Webrevs:
> > http://cr.openjdk.java.net/~tschatzl/8178105/webrev.0_to_1/ (diff)
> > http://cr.openjdk.java.net/~tschatzl/8178105/webrev.1/ (full)
> 
> Apart from the small things above this looks great.

http://cr.openjdk.java.net/~tschatzl/8178105/webrev.1_to_2/ (diff)
http://cr.openjdk.java.net/~tschatzl/8178105/webrev.2/ (full)

Ran gc/g1 tests successfully with that change.

Thanks,
  Thomas



From stefan.johansson at oracle.com  Tue Apr  3 15:00:58 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 3 Apr 2018 17:00:58 +0200
Subject: RFR (S/M): 8178105: Switch mark bitmaps during Remark
In-Reply-To: <1522767307.2582.2.camel@oracle.com>
References: <1522334136.2451.15.camel@oracle.com>
 <c4a8f532-db1b-09f8-5b9d-aa76f2f6ae4d@oracle.com>
 <1522758329.2573.9.camel@oracle.com>
 <09b374ab-a86f-bcff-00f4-4b2874fb59ff@oracle.com>
 <1522767307.2582.2.camel@oracle.com>
Message-ID: <1b5b0099-97da-35b6-99c1-628e5adf75ea@oracle.com>



On 2018-04-03 16:55, Thomas Schatzl wrote:
> Hi,
> 
>    thanks for your patience...
> 
> On Tue, 2018-04-03 at 14:49 +0200, Stefan Johansson wrote:
>>
>> On 2018-04-03 14:25, Thomas Schatzl wrote:
>>> Hi Stefan,
>>>
>>> On Tue, 2018-04-03 at 12:58 +0200, Stefan Johansson wrote:
>>>> Hi Thomas,
>>>>
>>>> On 2018-03-29 16:35, Thomas Schatzl wrote:
>>>>> Hi all,
>>>>> [...]
>>>>>
>>>>> CR:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8178105
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~tschatzl/8178105/
>>>>
>>>>    Looks good, but a few comments:
>>>>
> [...]
>>> I added a different kind of check that verifies what you probably
>>> thought of, and that is that the number of words to add to the
>>> current region must always be larger than zero. If it is zero,
>>> there is something really wrong.
>>
>> Exactly, that's what I wanted. But I don't see that check now, just
>> having a assert(marked_words != 0, "") on row 1032 would be enough.
> 
> My fault. I did not upload the latest version of the change :( It is up
> now, the only difference to previous is line
> 
> 1036       assert(words_to_add > 0, "Out of space to distribute before
> end of humongous object in region %u (starts %u)", i, region_idx);
> 
> But there is a new webrev anyway... in the 1_to_2 webrev it is line
> 1033
> 
>>>>
>>>> 1047       log_trace(gc)("Added " SIZE_FORMAT " words to region
>>>> %u
>>>> (%s)", marked_words, region_idx, hr->get_type_str());
>>>> I think the logging should use at least one more tag, maybe
>>>> "region" or "marking", but you probably know what makes most
>>>> sense in this area. I also think it would be nice if we got this
>>>> same log-line for all regions. Now we get this for "normal"
>>>> regions, but we get "Distributing..." for humongous start regions
>>>> and "Not Added..." for humongous continuous. So I would suggest
>>>> adding the same log-line  to the distribute-function after line
>>>> 1034.
>>>
>>> Done.
>>
>> Sorry for being picky but the current solution won't print anything
>> for continuous humongous. Adding the log to distribute_marked_bytes()
>> would solve this and we would still get info on region type so I see
>> no need for:
> 
> Okay. I think I got your intention right this time :)
> 
>> 1052         log_trace(gc, marking)("Adding " SIZE_FORMAT " words to
>> humongous start region %u (%s), word size %d (%f)",
>> 1053                                marked_words, region_idx,
>> hr->get_type_str(),
>> 1054                                oop(hr->bottom())->size(),
>> (double)oop(hr->bottom())->size() / HeapRegion::GrainWords);
> [...]
>>> All fixed.
>>>
>>> Webrevs:
>>> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.0_to_1/ (diff)
>>> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.1/ (full)
>>
>> Apart from the small things above this looks great.
> 
> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.1_to_2/ (diff)
> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.2/ (full)
Looks good!

Thanks,
StefanJ

> 
> Ran gc/g1 tests successfully with that change.
> 
> Thanks,
>    Thomas
> 


From thomas.schatzl at oracle.com  Tue Apr  3 15:08:08 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 03 Apr 2018 17:08:08 +0200
Subject: RFR (S): 8154528: Reclaim regions emptied by marking in Remark
 pause
In-Reply-To: <a334fa57-c6b8-7459-8c08-9cfde460fbdb@oracle.com>
References: <1522334960.2451.24.camel@oracle.com>
 <a334fa57-c6b8-7459-8c08-9cfde460fbdb@oracle.com>
Message-ID: <1522768088.2582.5.camel@oracle.com>

Hi,

On Tue, 2018-04-03 at 14:53 +0200, Stefan Johansson wrote:
> Thanks for yet another nice improvement of G1 Thomas,
> 
> On 2018-03-29 16:49, Thomas Schatzl wrote:
> > Hi all,
> > 
> >    can I have reviews for this change that moves the space
> > reclamation of empty regions into the Remark pause, which makes
> > these regions available much sooner than before, with the obvious
> > benefits of doing so.
> > 
> > 
> > [...]
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8154528
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8154528/webrev/
> 
> The change looks good, but I realized that reclaim_empty_regions()
> uses a task named G1CleanupTask. This naming is a bit unfortunate now
> since this is not the cleanup phase anymore, but still correct since
> we are doing cleanup. What do you think about renaming it to
> G1CleanRegionTask or G1ReclaimRegionTask? I also see that "cleanup"
> ripples down a bit but I don't think we need to change that. I'm fine
> with not doing anything at all but if you dislike the suggestion, but
> I wanted to raise the question.

What about G1ReclaimRegionsTask? Here's a webrev just doing that:

http://cr.openjdk.java.net/~tschatzl/8154528/webrev.0_to_1/ (diff)
http://cr.openjdk.java.net/~tschatzl/8154528/webrev.1/ (full)

Thanks,
  Thomas



From sangheon.kim at oracle.com  Tue Apr  3 22:45:08 2018
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Tue, 3 Apr 2018 15:45:08 -0700
Subject: RFR (S/M): 8200234: Cleanup Remark and Cleanup pause code
In-Reply-To: <1522245966.2391.42.camel@oracle.com>
References: <1522079989.2567.43.camel@oracle.com>
 <283b9e7b-7729-718b-7bc4-22282fa3d7e1@oracle.com>
 <1522245966.2391.42.camel@oracle.com>
Message-ID: <545e7da6-8f03-277f-5b43-06642ae02141@oracle.com>

Hi Thomas,

On 03/28/2018 07:06 AM, Thomas Schatzl wrote:
> Hi,
>
> On Wed, 2018-03-28 at 14:18 +0200, Stefan Johansson wrote:
>> Hi Thomas,
>>
>> On 2018-03-26 17:59, Thomas Schatzl wrote:
>>> Hi all,
>>>
> [...]
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8200234
>>> Webrev:
>>> http://cr.openjdk.java.net/~tschatzl/8200234/webrev/
>> Looks good in general, but a few questions and suggestions:
>> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
>>    539   G1CMBitMap* const bitmap =
>> _g1h->collector_state()->mark_or_rebuild_in_progress() ?
>> _next_mark_bitmap : _prev_mark_bitmap;
>> The old code always used the _next_mark_bitmap, was this a bug or
>> has any timing changed?
> This is a (benign?) bug, and actually thinking about it again the
> current implementation is not completely correct either. :/
>
> Thanks for making me think about this again.
>
> The prev ("current") bitmap may contain the mark because of the
> humongous object surviving some previous marking.
>
> Now if you eagerly reclaim that object, the mark will simply remain
> until the next time we swap the bitmaps and clear the now "next"
> bitmap, so it's kind of self-healing after all.
>
> As for the actual impact, I do not think it has any except for stray
> verification errors I saw with some of our tests: we never use the
> bitmap for walking free regions (they are not walked at all), and if we
> reallocated into that region again, the objects would all be above
> tams, and so we would not use the bitmap either and live anyway.
>
> But I think this issue is unrelated to this cleanup change and will
> create an extra CR.
>
>> 1010     os::snprintf(buffer, BufLen, "During GC (%s)", caller);
>> Seems like jio_snprintf is more used in the HotSpot code, so maybe
>> change to use that one instead.
> Okay, I just did not know which to use. Both seemed equal to me. Fixed.
>
>> ---
>> src/hotspot/share/memory/iterator.hpp
>>    136 #ifdef ASSERT
>>    137   bool should_verify_oops() { return false; }
>>    138 #endif
>> Why is this needed? I don't see any use of NoHeaderExtendedOopClosure
>> in the new code. If needed I would prefer:
>> debug_only(bool should_verify_oops() { return false; })
> The reason is that without that change this prevents an OopClosure that
> does verification to actually trigger its typically more useful error
> message.
>
> But looking at it again at the other collector's verification closure,
> the consensus is that these verification closures should themselves
> override this method and not disable it globally.
>
> The particular issue is about G1Mux2Closure that if there is an error,
> it errors out too early, not showing G1 specific information as this
> assert triggers before the other; I will make a seperate change for
> that one too though.
>
> http://cr.openjdk.java.net/~tschatzl/8200234/webrev.0_to_1 (diff)
> http://cr.openjdk.java.net/~tschatzl/8200234/webrev.1 (full)
webrev.1 looks good.
Please update copyright year at heapRegion.inline.hpp before push.

Thanks for this cleanup!

Sangheon


>
> Thanks,
>    Thomas
>



From rkennke at redhat.com  Tue Apr  3 23:39:56 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 4 Apr 2018 01:39:56 +0200
Subject: RFR: JDK-8199735: Mark word updates need to use Access API
In-Reply-To: <21286315-4a62-c06b-a13a-dfe4a83d88d3@redhat.com>
References: <7bd73e32-a26b-2504-f069-b74807ae5e53@redhat.com>
 <859ac657-78c9-c7ab-0ec0-eddda331001b@redhat.com>
 <b8cb91fc-d332-baf6-c6ab-93d1ae39c6b1@redhat.com>
 <5AB3B052.4000304@oracle.com>
 <63199799-0194-a1d4-9c89-d95251c7aa7d@redhat.com>
 <5AB90C07.3020507@oracle.com>
 <4cdc8f4d-3f27-5c20-a606-251077ed9a82@redhat.com>
 <21286315-4a62-c06b-a13a-dfe4a83d88d3@redhat.com>
Message-ID: <e5ef0ba2-0da4-5748-1430-c6ed0eddeb2c@redhat.com>

Am 03.04.2018 um 14:21 schrieb Aleksey Shipilev:
> On 03/26/2018 06:40 PM, Roman Kennke wrote:
>>>> Differential:
>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03.diff/
>>>> Full:
>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03/
> 
> Looks good. A bit unfortunate it has to have many changes around due to the rename, but oh well.
> 
> Thanks,
> -Aleksey
> 

Something seems to make Solaris/Sparc builds unhappy. Can somebody with
access to the test/build system check it?

Thanks, Roman


Build Details: 2018-04-03-2039378.roman.source
0 Failed Tests
Mach5 Tasks Results Summary

    EXECUTED_WITH_FAILURE: 2
    KILLED: 0
    NA: 0
    UNABLE_TO_RUN: 4
    PASSED: 77
    FAILED: 0
    Build

        2 Not run
            build_jdk_solaris-solaris-sparcv9-solaris-sparcv9-build-8
error while building, return value: 2

build_jdk_solaris-solaris-sparcv9-debug-solaris-sparcv9-build-9 error
while building, return value: 2

    Test

        4 Not run

tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-70
Dependency task failed:
mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8

tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-71
Dependency task failed:
mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9

tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-68
Dependency task failed:
mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8

tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-69
Dependency task failed:
mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180404/11102fc5/signature.asc>

From mikael.vidstedt at oracle.com  Wed Apr  4 00:00:25 2018
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Tue, 3 Apr 2018 17:00:25 -0700
Subject: RFR: JDK-8199735: Mark word updates need to use Access API
In-Reply-To: <e5ef0ba2-0da4-5748-1430-c6ed0eddeb2c@redhat.com>
References: <7bd73e32-a26b-2504-f069-b74807ae5e53@redhat.com>
 <859ac657-78c9-c7ab-0ec0-eddda331001b@redhat.com>
 <b8cb91fc-d332-baf6-c6ab-93d1ae39c6b1@redhat.com>
 <5AB3B052.4000304@oracle.com>
 <63199799-0194-a1d4-9c89-d95251c7aa7d@redhat.com>
 <5AB90C07.3020507@oracle.com>
 <4cdc8f4d-3f27-5c20-a606-251077ed9a82@redhat.com>
 <21286315-4a62-c06b-a13a-dfe4a83d88d3@redhat.com>
 <e5ef0ba2-0da4-5748-1430-c6ed0eddeb2c@redhat.com>
Message-ID: <872A5E7B-5B73-42E5-869C-C6E941AE8A1A@oracle.com>


src/hotspot/share/oops/oop.hpp", line 70: Error: The function oopDesc::set_mark(markOopDesc*volatile) has not had a body defined.
src/hotspot/share/oops/oop.hpp", line 66: Error: The function oopDesc::mark() const has not had a body defined.
2 Error(s) detected.
lib/CompileJvm.gmk:212: recipe for target 'build/solaris-sparcv9-debug/hotspot/variant-server/libjvm/objs/edgeStore.o' failed
make[3]: *** [build/solaris-sparcv9-debug/hotspot/variant-server/libjvm/objs/edgeStore.o] Error 1

Cheers,
Mikael

> On Apr 3, 2018, at 4:39 PM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> Am 03.04.2018 um 14:21 schrieb Aleksey Shipilev:
>> On 03/26/2018 06:40 PM, Roman Kennke wrote:
>>>>> Differential:
>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03.diff/
>>>>> Full:
>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03/
>> 
>> Looks good. A bit unfortunate it has to have many changes around due to the rename, but oh well.
>> 
>> Thanks,
>> -Aleksey
>> 
> 
> Something seems to make Solaris/Sparc builds unhappy. Can somebody with
> access to the test/build system check it?
> 
> Thanks, Roman
> 
> 
> Build Details: 2018-04-03-2039378.roman.source
> 0 Failed Tests
> Mach5 Tasks Results Summary
> 
>    EXECUTED_WITH_FAILURE: 2
>    KILLED: 0
>    NA: 0
>    UNABLE_TO_RUN: 4
>    PASSED: 77
>    FAILED: 0
>    Build
> 
>        2 Not run
>            build_jdk_solaris-solaris-sparcv9-solaris-sparcv9-build-8
> error while building, return value: 2
> 
> build_jdk_solaris-solaris-sparcv9-debug-solaris-sparcv9-build-9 error
> while building, return value: 2
> 
>    Test
> 
>        4 Not run
> 
> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-70
> Dependency task failed:
> mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8
> 
> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-71
> Dependency task failed:
> mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
> 
> tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-68
> Dependency task failed:
> mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8
> 
> tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-69
> Dependency task failed:
> mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180403/c8d49421/attachment.htm>

From rkennke at redhat.com  Wed Apr  4 00:05:13 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 4 Apr 2018 02:05:13 +0200
Subject: RFR: JDK-8199735: Mark word updates need to use Access API
In-Reply-To: <872A5E7B-5B73-42E5-869C-C6E941AE8A1A@oracle.com>
References: <7bd73e32-a26b-2504-f069-b74807ae5e53@redhat.com>
 <859ac657-78c9-c7ab-0ec0-eddda331001b@redhat.com>
 <b8cb91fc-d332-baf6-c6ab-93d1ae39c6b1@redhat.com>
 <5AB3B052.4000304@oracle.com>
 <63199799-0194-a1d4-9c89-d95251c7aa7d@redhat.com>
 <5AB90C07.3020507@oracle.com>
 <4cdc8f4d-3f27-5c20-a606-251077ed9a82@redhat.com>
 <21286315-4a62-c06b-a13a-dfe4a83d88d3@redhat.com>
 <e5ef0ba2-0da4-5748-1430-c6ed0eddeb2c@redhat.com>
 <872A5E7B-5B73-42E5-869C-C6E941AE8A1A@oracle.com>
Message-ID: <4274c332-9509-0831-3f60-fa823d4a786c@redhat.com>

Thanks, Mikael!

What is edgeStore.o and how is it built? I suspect it needs an
additional #include "oops/oop.inline.hpp" but I can't find the
corresponding source?

Roman


> 
> src/hotspot/share/oops/oop.hpp", line 70: Error: The function oopDesc::set_mark(markOopDesc*volatile) has not had a body defined.
> src/hotspot/share/oops/oop.hpp", line 66: Error: The function oopDesc::mark() const has not had a body defined.
> 2 Error(s) detected.
> lib/CompileJvm.gmk:212: recipe for target 'build/solaris-sparcv9-debug/hotspot/variant-server/libjvm/objs/edgeStore.o' failed
> make[3]: *** [build/solaris-sparcv9-debug/hotspot/variant-server/libjvm/objs/edgeStore.o] Error 1
> 
> 
> Cheers,
> Mikael
> 
>> On Apr 3, 2018, at 4:39 PM, Roman Kennke <rkennke at redhat.com
>> <mailto:rkennke at redhat.com>> wrote:
>>
>> Am 03.04.2018 um 14:21 schrieb Aleksey Shipilev:
>>> On 03/26/2018 06:40 PM, Roman Kennke wrote:
>>>>>> Differential:
>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03.diff/
>>>>>> Full:
>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03/
>>>
>>> Looks good. A bit unfortunate it has to have many changes around due
>>> to the rename, but oh well.
>>>
>>> Thanks,
>>> -Aleksey
>>>
>>
>> Something seems to make Solaris/Sparc builds unhappy. Can somebody with
>> access to the test/build system check it?
>>
>> Thanks, Roman
>>
>>
>> Build Details: 2018-04-03-2039378.roman.source
>> 0 Failed Tests
>> Mach5 Tasks Results Summary
>>
>> ???EXECUTED_WITH_FAILURE: 2
>> ???KILLED: 0
>> ???NA: 0
>> ???UNABLE_TO_RUN: 4
>> ???PASSED: 77
>> ???FAILED: 0
>> ???Build
>>
>> ???????2 Not run
>> ???????????build_jdk_solaris-solaris-sparcv9-solaris-sparcv9-build-8
>> error while building, return value: 2
>>
>> build_jdk_solaris-solaris-sparcv9-debug-solaris-sparcv9-build-9 error
>> while building, return value: 2
>>
>> ???Test
>>
>> ???????4 Not run
>>
>> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-70
>> Dependency task failed:
>> mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8
>>
>> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-71
>> Dependency task failed:
>> mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
>>
>> tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-68
>> Dependency task failed:
>> mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8
>>
>> tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-69
>> Dependency task failed:
>> mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
>>
>>
>>
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180404/91fe7aef/signature.asc>

From mikael.vidstedt at oracle.com  Wed Apr  4 00:41:31 2018
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Tue, 3 Apr 2018 17:41:31 -0700
Subject: RFR: JDK-8199735: Mark word updates need to use Access API
In-Reply-To: <4274c332-9509-0831-3f60-fa823d4a786c@redhat.com>
References: <7bd73e32-a26b-2504-f069-b74807ae5e53@redhat.com>
 <859ac657-78c9-c7ab-0ec0-eddda331001b@redhat.com>
 <b8cb91fc-d332-baf6-c6ab-93d1ae39c6b1@redhat.com>
 <5AB3B052.4000304@oracle.com>
 <63199799-0194-a1d4-9c89-d95251c7aa7d@redhat.com>
 <5AB90C07.3020507@oracle.com>
 <4cdc8f4d-3f27-5c20-a606-251077ed9a82@redhat.com>
 <21286315-4a62-c06b-a13a-dfe4a83d88d3@redhat.com>
 <e5ef0ba2-0da4-5748-1430-c6ed0eddeb2c@redhat.com>
 <872A5E7B-5B73-42E5-869C-C6E941AE8A1A@oracle.com>
 <4274c332-9509-0831-3f60-fa823d4a786c@redhat.com>
Message-ID: <49B17F73-42A1-4786-9B9C-28B9B6BC673F@oracle.com>


Yes, it?s part of the (still closed) JFR sources. Somebody at Oracle will have to help update. Sorry for the inconvenience.

Cheers,
Mikael

> On Apr 3, 2018, at 5:05 PM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> Thanks, Mikael!
> 
> What is edgeStore.o and how is it built? I suspect it needs an
> additional #include "oops/oop.inline.hpp" but I can't find the
> corresponding source?
> 
> Roman
> 
> 
>> 
>> src/hotspot/share/oops/oop.hpp", line 70: Error: The function oopDesc::set_mark(markOopDesc*volatile) has not had a body defined.
>> src/hotspot/share/oops/oop.hpp", line 66: Error: The function oopDesc::mark() const has not had a body defined.
>> 2 Error(s) detected.
>> lib/CompileJvm.gmk:212: recipe for target 'build/solaris-sparcv9-debug/hotspot/variant-server/libjvm/objs/edgeStore.o' failed
>> make[3]: *** [build/solaris-sparcv9-debug/hotspot/variant-server/libjvm/objs/edgeStore.o] Error 1
>> 
>> 
>> Cheers,
>> Mikael
>> 
>>> On Apr 3, 2018, at 4:39 PM, Roman Kennke <rkennke at redhat.com
>>> <mailto:rkennke at redhat.com>> wrote:
>>> 
>>> Am 03.04.2018 um 14:21 schrieb Aleksey Shipilev:
>>>> On 03/26/2018 06:40 PM, Roman Kennke wrote:
>>>>>>> Differential:
>>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03.diff/
>>>>>>> Full:
>>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03/
>>>> 
>>>> Looks good. A bit unfortunate it has to have many changes around due
>>>> to the rename, but oh well.
>>>> 
>>>> Thanks,
>>>> -Aleksey
>>>> 
>>> 
>>> Something seems to make Solaris/Sparc builds unhappy. Can somebody with
>>> access to the test/build system check it?
>>> 
>>> Thanks, Roman
>>> 
>>> 
>>> Build Details: 2018-04-03-2039378.roman.source
>>> 0 Failed Tests
>>> Mach5 Tasks Results Summary
>>> 
>>>    EXECUTED_WITH_FAILURE: 2
>>>    KILLED: 0
>>>    NA: 0
>>>    UNABLE_TO_RUN: 4
>>>    PASSED: 77
>>>    FAILED: 0
>>>    Build
>>> 
>>>        2 Not run
>>>            build_jdk_solaris-solaris-sparcv9-solaris-sparcv9-build-8
>>> error while building, return value: 2
>>> 
>>> build_jdk_solaris-solaris-sparcv9-debug-solaris-sparcv9-build-9 error
>>> while building, return value: 2
>>> 
>>>    Test
>>> 
>>>        4 Not run
>>> 
>>> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-70
>>> Dependency task failed:
>>> mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8
>>> 
>>> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-71
>>> Dependency task failed:
>>> mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
>>> 
>>> tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-68
>>> Dependency task failed:
>>> mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8
>>> 
>>> tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-69
>>> Dependency task failed:
>>> mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
>>> 
>>> 
>>> 
>> 
> 
> 



From erik.helin at oracle.com  Wed Apr  4 08:17:42 2018
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 4 Apr 2018 10:17:42 +0200
Subject: RFR: 8200626: Restore history for g1ConcurrentMarkThread.*
Message-ID: <e78085aa-675d-9922-70c0-a3f495dc1e00@oracle.com>

Hi all,

this (somewhat strange) patch restores the Mercurial (hg) history for 
the files g1ConcurrentMarkThread.{hpp, inline.hpp, cpp}. This is done by 
re-doing the commit (but make sure to `hg mv`) and then performing a 
benign merge (the merge is not part of the webrev).

I don't think the webrev will highlight that `hg mv` was properly used, 
but I have verified that
`hg log --follow src/hotspot/share/gc/g1/g1ConcurrentMarkThread.hpp` 
shows the entire history.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8200626

Patch:
http://cr.openjdk.java.net/~ehelin/8200626/00/

Testing:
- hs-tier1 on Linux, macOS and Windows, all x86-64
   (mainly to ensure that everything builds correctly)

Thanks,
Erik


From shade at redhat.com  Wed Apr  4 08:24:31 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 4 Apr 2018 10:24:31 +0200
Subject: RFR: 8200626: Restore history for g1ConcurrentMarkThread.*
In-Reply-To: <e78085aa-675d-9922-70c0-a3f495dc1e00@oracle.com>
References: <e78085aa-675d-9922-70c0-a3f495dc1e00@oracle.com>
Message-ID: <c1a950f0-986c-2e1e-dc0e-53f03123b901@redhat.com>

On 04/04/2018 10:17 AM, Erik Helin wrote:
> Hi all,
> 
> this (somewhat strange) patch restores the Mercurial (hg) history for the files
> g1ConcurrentMarkThread.{hpp, inline.hpp, cpp}. This is done by re-doing the commit (but make sure to
> `hg mv`) and then performing a benign merge (the merge is not part of the webrev).
> 
> I don't think the webrev will highlight that `hg mv` was properly used, but I have verified that
> `hg log --follow src/hotspot/share/gc/g1/g1ConcurrentMarkThread.hpp` shows the entire history.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8200626
> 
> Patch:
> http://cr.openjdk.java.net/~ehelin/8200626/00/

Oh, nice trick.

The changes in src/hotspot/os/linux/os_linux.cpp seem to be the part of JDK-8199717 [1], should they
really be in webrev? I guess webrev was generated against the parent that does not include that
changeset yet? If so, I think it would be safer to generate the webrev from the merge you did
against the "real" parent head, to check that webrev did not unroll already committed changesets.
(Fun aside: we ran into the similar pitfall recently in Shenandoah!)

"hg log -G -l 5" or something would be nice to see too.

Thanks,
-Aleksey

[1] http://hg.openjdk.java.net/jdk/hs/rev/89a886b7a9cf


From stefan.johansson at oracle.com  Wed Apr  4 08:40:28 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Wed, 4 Apr 2018 10:40:28 +0200
Subject: RFR (S): 8154528: Reclaim regions emptied by marking in Remark
 pause
In-Reply-To: <1522768088.2582.5.camel@oracle.com>
References: <1522334960.2451.24.camel@oracle.com>
 <a334fa57-c6b8-7459-8c08-9cfde460fbdb@oracle.com>
 <1522768088.2582.5.camel@oracle.com>
Message-ID: <46723353-ff0a-1ed9-8d9d-d104e20142a7@oracle.com>

Hi,

On 2018-04-03 17:08, Thomas Schatzl wrote:
> Hi,
> 
> On Tue, 2018-04-03 at 14:53 +0200, Stefan Johansson wrote:
>> Thanks for yet another nice improvement of G1 Thomas,
>>
>> On 2018-03-29 16:49, Thomas Schatzl wrote:
>>> Hi all,
>>>
>>>     can I have reviews for this change that moves the space
>>> reclamation of empty regions into the Remark pause, which makes
>>> these regions available much sooner than before, with the obvious
>>> benefits of doing so.
>>>
>>>
>>> [...]
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8154528
>>> Webrev:
>>> http://cr.openjdk.java.net/~tschatzl/8154528/webrev/
>>
>> The change looks good, but I realized that reclaim_empty_regions()
>> uses a task named G1CleanupTask. This naming is a bit unfortunate now
>> since this is not the cleanup phase anymore, but still correct since
>> we are doing cleanup. What do you think about renaming it to
>> G1CleanRegionTask or G1ReclaimRegionTask? I also see that "cleanup"
>> ripples down a bit but I don't think we need to change that. I'm fine
>> with not doing anything at all but if you dislike the suggestion, but
>> I wanted to raise the question.
> 
> What about G1ReclaimRegionsTask? Here's a webrev just doing that:
> 
> http://cr.openjdk.java.net/~tschatzl/8154528/webrev.0_to_1/ (diff)
> http://cr.openjdk.java.net/~tschatzl/8154528/webrev.1/ (full)
> 
That's good, reviewed!

Thanks,
Stefan

> Thanks,
>    Thomas
> 


From erik.helin at oracle.com  Wed Apr  4 08:59:43 2018
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 4 Apr 2018 10:59:43 +0200
Subject: RFR: 8200626: Restore history for g1ConcurrentMarkThread.*
In-Reply-To: <c1a950f0-986c-2e1e-dc0e-53f03123b901@redhat.com>
References: <e78085aa-675d-9922-70c0-a3f495dc1e00@oracle.com>
 <c1a950f0-986c-2e1e-dc0e-53f03123b901@redhat.com>
Message-ID: <0b5e4a04-2a3e-eaac-29ba-ca22e3c47bf2@oracle.com>

On 04/04/2018 10:24 AM, Aleksey Shipilev wrote:
> On 04/04/2018 10:17 AM, Erik Helin wrote:
>> Hi all,
>>
>> this (somewhat strange) patch restores the Mercurial (hg) history for the files
>> g1ConcurrentMarkThread.{hpp, inline.hpp, cpp}. This is done by re-doing the commit (but make sure to
>> `hg mv`) and then performing a benign merge (the merge is not part of the webrev).
>>
>> I don't think the webrev will highlight that `hg mv` was properly used, but I have verified that
>> `hg log --follow src/hotspot/share/gc/g1/g1ConcurrentMarkThread.hpp` shows the entire history.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8200626
>>
>> Patch:
>> http://cr.openjdk.java.net/~ehelin/8200626/00/
> 
> Oh, nice trick.
> 
> The changes in src/hotspot/os/linux/os_linux.cpp seem to be the part of JDK-8199717 [1], should they
> really be in webrev? I guess webrev was generated against the parent that does not include that
> changeset yet? If so, I think it would be safer to generate the webrev from the merge you did
> against the "real" parent head, to check that webrev did not unroll already committed changesets.
> (Fun aside: we ran into the similar pitfall recently in Shenandoah!)

Nice catch, I included Claes' patch by mistake. Thanks for noticing this!

> "hg log -G -l 5" or something would be nice to see too.

Since this change involves so much hg metadata that is important, I 
uploaded a hg bundle:

http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle

To review the change, just:

$ # download the bundle
$ wget http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle

$ hg incoming 8200626.bundle # list the changesets in the bundle
$ hg pull -u 8200626.bundle # pull the changesets into your repository
$ hg log --graph # inspect the log

$ hg diff -r be49a19be03b:0ab2411f270d # verify that merge is benign
$ hg diff -r 8c78b974cd55 -r 0ed1370f52bb # verify my change is
                                           # identical to Leo's

Thanks,
Erik

> Thanks,
> -Aleksey
> 
> [1] http://hg.openjdk.java.net/jdk/hs/rev/89a886b7a9cf
> 


From shade at redhat.com  Wed Apr  4 09:04:01 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 4 Apr 2018 11:04:01 +0200
Subject: RFR: 8200626: Restore history for g1ConcurrentMarkThread.*
In-Reply-To: <0b5e4a04-2a3e-eaac-29ba-ca22e3c47bf2@oracle.com>
References: <e78085aa-675d-9922-70c0-a3f495dc1e00@oracle.com>
 <c1a950f0-986c-2e1e-dc0e-53f03123b901@redhat.com>
 <0b5e4a04-2a3e-eaac-29ba-ca22e3c47bf2@oracle.com>
Message-ID: <0aab2dab-081c-21e9-3234-b94d51264c53@redhat.com>

On 04/04/2018 10:59 AM, Erik Helin wrote:
>> "hg log -G -l 5" or something would be nice to see too.
> 
> Since this change involves so much hg metadata that is important, I uploaded a hg bundle:
> 
> http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle
> 
> To review the change, just:
> 
> $ # download the bundle
> $ wget http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle
> 
> $ hg incoming 8200626.bundle # list the changesets in the bundle
> $ hg pull -u 8200626.bundle # pull the changesets into your repository
> $ hg log --graph # inspect the log
> 
> $ hg diff -r be49a19be03b:0ab2411f270d # verify that merge is benign
> $ hg diff -r 8c78b974cd55 -r 0ed1370f52bb # verify my change is
> ????????????????????????????????????????? # identical to Leo's

Yes, verified. Thanks!

I think it is trivial code-wise, and the risk of waiting 24 hrs opens up the opportunity to screw up
the re-merge later. Therefore, I think we should push it right away. Maybe another Reviewer should
double-check :)

Thanks,
-Aleksey


From stefan.johansson at oracle.com  Wed Apr  4 09:12:46 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Wed, 4 Apr 2018 11:12:46 +0200
Subject: RFR: 8200626: Restore history for g1ConcurrentMarkThread.*
In-Reply-To: <0aab2dab-081c-21e9-3234-b94d51264c53@redhat.com>
References: <e78085aa-675d-9922-70c0-a3f495dc1e00@oracle.com>
 <c1a950f0-986c-2e1e-dc0e-53f03123b901@redhat.com>
 <0b5e4a04-2a3e-eaac-29ba-ca22e3c47bf2@oracle.com>
 <0aab2dab-081c-21e9-3234-b94d51264c53@redhat.com>
Message-ID: <09f81800-2b91-4a2e-4ef3-b60013e89358@oracle.com>



On 2018-04-04 11:04, Aleksey Shipilev wrote:
> On 04/04/2018 10:59 AM, Erik Helin wrote:
>>> "hg log -G -l 5" or something would be nice to see too.
>>
>> Since this change involves so much hg metadata that is important, I uploaded a hg bundle:
>>
>> http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle
>>
>> To review the change, just:
>>
>> $ # download the bundle
>> $ wget http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle
>>
>> $ hg incoming 8200626.bundle # list the changesets in the bundle
>> $ hg pull -u 8200626.bundle # pull the changesets into your repository
>> $ hg log --graph # inspect the log
>>
>> $ hg diff -r be49a19be03b:0ab2411f270d # verify that merge is benign
>> $ hg diff -r 8c78b974cd55 -r 0ed1370f52bb # verify my change is
>>  ????????????????????????????????????????? # identical to Leo's
> 
> Yes, verified. Thanks!
> 
> I think it is trivial code-wise, and the risk of waiting 24 hrs opens up the opportunity to screw up
> the re-merge later. Therefore, I think we should push it right away. Maybe another Reviewer should
> double-check :)
> 
I also verified it. Good work. I agree with Aleksey, push it now.

Thanks,
Stefan

> Thanks,
> -Aleksey
> 


From erik.helin at oracle.com  Wed Apr  4 09:44:11 2018
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 4 Apr 2018 11:44:11 +0200
Subject: RFR: 8200626: Restore history for g1ConcurrentMarkThread.*
In-Reply-To: <09f81800-2b91-4a2e-4ef3-b60013e89358@oracle.com>
References: <e78085aa-675d-9922-70c0-a3f495dc1e00@oracle.com>
 <c1a950f0-986c-2e1e-dc0e-53f03123b901@redhat.com>
 <0b5e4a04-2a3e-eaac-29ba-ca22e3c47bf2@oracle.com>
 <0aab2dab-081c-21e9-3234-b94d51264c53@redhat.com>
 <09f81800-2b91-4a2e-4ef3-b60013e89358@oracle.com>
Message-ID: <117ba20c-b49a-db5f-1046-fc4ca6d72b5d@oracle.com>

On 04/04/2018 11:12 AM, Stefan Johansson wrote:
> 
> 
> On 2018-04-04 11:04, Aleksey Shipilev wrote:
>> On 04/04/2018 10:59 AM, Erik Helin wrote:
>>>> "hg log -G -l 5" or something would be nice to see too.
>>>
>>> Since this change involves so much hg metadata that is important, I 
>>> uploaded a hg bundle:
>>>
>>> http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle
>>>
>>> To review the change, just:
>>>
>>> $ # download the bundle
>>> $ wget http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle
>>>
>>> $ hg incoming 8200626.bundle # list the changesets in the bundle
>>> $ hg pull -u 8200626.bundle # pull the changesets into your repository
>>> $ hg log --graph # inspect the log
>>>
>>> $ hg diff -r be49a19be03b:0ab2411f270d # verify that merge is benign
>>> $ hg diff -r 8c78b974cd55 -r 0ed1370f52bb # verify my change is
>>> ?????????????????????????????????????????? # identical to Leo's
>>
>> Yes, verified. Thanks!
>>
>> I think it is trivial code-wise, and the risk of waiting 24 hrs opens 
>> up the opportunity to screw up
>> the re-merge later. Therefore, I think we should push it right away. 
>> Maybe another Reviewer should
>> double-check :)
>>
> I also verified it. Good work. I agree with Aleksey, push it now.

Thanks Stefan and Aleksey, and nice suggestion on pushing quick, 
unfortunately I was a bit too slow :)

So, here we go again, I uploaded a new bundle, 8200626.01.bundle. To 
review, just:

wget http://cr.openjdk.java.net/~ehelin/8200626/8200626.01.bundle
hg pull -u 8200626.01.bundle
hg diff -r 334cdf15428b -r 55f8f5635ef7 # should show no changes
hg diff -r 8c78b974cd55 -r 0ed1370f52bb # should show no changes

Thanks,
Erik

> Thanks,
> Stefan
> 
>> Thanks,
>> -Aleksey
>>


From shade at redhat.com  Wed Apr  4 09:46:26 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 4 Apr 2018 11:46:26 +0200
Subject: RFR: 8200626: Restore history for g1ConcurrentMarkThread.*
In-Reply-To: <117ba20c-b49a-db5f-1046-fc4ca6d72b5d@oracle.com>
References: <e78085aa-675d-9922-70c0-a3f495dc1e00@oracle.com>
 <c1a950f0-986c-2e1e-dc0e-53f03123b901@redhat.com>
 <0b5e4a04-2a3e-eaac-29ba-ca22e3c47bf2@oracle.com>
 <0aab2dab-081c-21e9-3234-b94d51264c53@redhat.com>
 <09f81800-2b91-4a2e-4ef3-b60013e89358@oracle.com>
 <117ba20c-b49a-db5f-1046-fc4ca6d72b5d@oracle.com>
Message-ID: <6dc6661c-192f-9dba-6926-1345d6fb9833@redhat.com>

On 04/04/2018 11:44 AM, Erik Helin wrote:
> On 04/04/2018 11:12 AM, Stefan Johansson wrote:
>>
>>
>> On 2018-04-04 11:04, Aleksey Shipilev wrote:
>>> On 04/04/2018 10:59 AM, Erik Helin wrote:
>>>>> "hg log -G -l 5" or something would be nice to see too.
>>>>
>>>> Since this change involves so much hg metadata that is important, I uploaded a hg bundle:
>>>>
>>>> http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle
>>>>
>>>> To review the change, just:
>>>>
>>>> $ # download the bundle
>>>> $ wget http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle
>>>>
>>>> $ hg incoming 8200626.bundle # list the changesets in the bundle
>>>> $ hg pull -u 8200626.bundle # pull the changesets into your repository
>>>> $ hg log --graph # inspect the log
>>>>
>>>> $ hg diff -r be49a19be03b:0ab2411f270d # verify that merge is benign
>>>> $ hg diff -r 8c78b974cd55 -r 0ed1370f52bb # verify my change is
>>>> ?????????????????????????????????????????? # identical to Leo's
>>>
>>> Yes, verified. Thanks!
>>>
>>> I think it is trivial code-wise, and the risk of waiting 24 hrs opens up the opportunity to screw up
>>> the re-merge later. Therefore, I think we should push it right away. Maybe another Reviewer should
>>> double-check :)
>>>
>> I also verified it. Good work. I agree with Aleksey, push it now.
> 
> Thanks Stefan and Aleksey, and nice suggestion on pushing quick, unfortunately I was a bit too slow :)
> 
> So, here we go again, I uploaded a new bundle, 8200626.01.bundle. To review, just:
> 
> wget http://cr.openjdk.java.net/~ehelin/8200626/8200626.01.bundle
> hg pull -u 8200626.01.bundle
> hg diff -r 334cdf15428b -r 55f8f5635ef7 # should show no changes
> hg diff -r 8c78b974cd55 -r 0ed1370f52bb # should show no changes

Still looks good.

-Aleksey


From stefan.johansson at oracle.com  Wed Apr  4 09:47:15 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Wed, 4 Apr 2018 11:47:15 +0200
Subject: RFR: 8200626: Restore history for g1ConcurrentMarkThread.*
In-Reply-To: <117ba20c-b49a-db5f-1046-fc4ca6d72b5d@oracle.com>
References: <e78085aa-675d-9922-70c0-a3f495dc1e00@oracle.com>
 <c1a950f0-986c-2e1e-dc0e-53f03123b901@redhat.com>
 <0b5e4a04-2a3e-eaac-29ba-ca22e3c47bf2@oracle.com>
 <0aab2dab-081c-21e9-3234-b94d51264c53@redhat.com>
 <09f81800-2b91-4a2e-4ef3-b60013e89358@oracle.com>
 <117ba20c-b49a-db5f-1046-fc4ca6d72b5d@oracle.com>
Message-ID: <d4997fbc-44b8-22cf-1fb0-816d704daa7b@oracle.com>



On 2018-04-04 11:44, Erik Helin wrote:
> On 04/04/2018 11:12 AM, Stefan Johansson wrote:
>>
>>
>> On 2018-04-04 11:04, Aleksey Shipilev wrote:
>>> On 04/04/2018 10:59 AM, Erik Helin wrote:
>>>>> "hg log -G -l 5" or something would be nice to see too.
>>>>
>>>> Since this change involves so much hg metadata that is important, I 
>>>> uploaded a hg bundle:
>>>>
>>>> http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle
>>>>
>>>> To review the change, just:
>>>>
>>>> $ # download the bundle
>>>> $ wget http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle
>>>>
>>>> $ hg incoming 8200626.bundle # list the changesets in the bundle
>>>> $ hg pull -u 8200626.bundle # pull the changesets into your repository
>>>> $ hg log --graph # inspect the log
>>>>
>>>> $ hg diff -r be49a19be03b:0ab2411f270d # verify that merge is benign
>>>> $ hg diff -r 8c78b974cd55 -r 0ed1370f52bb # verify my change is
>>>> ?????????????????????????????????????????? # identical to Leo's
>>>
>>> Yes, verified. Thanks!
>>>
>>> I think it is trivial code-wise, and the risk of waiting 24 hrs opens 
>>> up the opportunity to screw up
>>> the re-merge later. Therefore, I think we should push it right away. 
>>> Maybe another Reviewer should
>>> double-check :)
>>>
>> I also verified it. Good work. I agree with Aleksey, push it now.
> 
> Thanks Stefan and Aleksey, and nice suggestion on pushing quick, 
> unfortunately I was a bit too slow :)
> 
> So, here we go again, I uploaded a new bundle, 8200626.01.bundle. To 
> review, just:
> 
> wget http://cr.openjdk.java.net/~ehelin/8200626/8200626.01.bundle
> hg pull -u 8200626.01.bundle
> hg diff -r 334cdf15428b -r 55f8f5635ef7 # should show no changes
> hg diff -r 8c78b974cd55 -r 0ed1370f52bb # should show no changes
> 
Push it!
StefanJ

> Thanks,
> Erik
> 
>> Thanks,
>> Stefan
>>
>>> Thanks,
>>> -Aleksey
>>>


From erik.helin at oracle.com  Wed Apr  4 09:57:30 2018
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 4 Apr 2018 11:57:30 +0200
Subject: RFR: 8200626: Restore history for g1ConcurrentMarkThread.*
In-Reply-To: <6dc6661c-192f-9dba-6926-1345d6fb9833@redhat.com>
References: <e78085aa-675d-9922-70c0-a3f495dc1e00@oracle.com>
 <c1a950f0-986c-2e1e-dc0e-53f03123b901@redhat.com>
 <0b5e4a04-2a3e-eaac-29ba-ca22e3c47bf2@oracle.com>
 <0aab2dab-081c-21e9-3234-b94d51264c53@redhat.com>
 <09f81800-2b91-4a2e-4ef3-b60013e89358@oracle.com>
 <117ba20c-b49a-db5f-1046-fc4ca6d72b5d@oracle.com>
 <6dc6661c-192f-9dba-6926-1345d6fb9833@redhat.com>
Message-ID: <a315edd2-da47-800c-9747-927c9d9c588c@oracle.com>

On 04/04/2018 11:46 AM, Aleksey Shipilev wrote:
> On 04/04/2018 11:44 AM, Erik Helin wrote:
>> On 04/04/2018 11:12 AM, Stefan Johansson wrote:
>>>
>>>
>>> On 2018-04-04 11:04, Aleksey Shipilev wrote:
>>>> On 04/04/2018 10:59 AM, Erik Helin wrote:
>>>>>> "hg log -G -l 5" or something would be nice to see too.
>>>>>
>>>>> Since this change involves so much hg metadata that is important, I uploaded a hg bundle:
>>>>>
>>>>> http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle
>>>>>
>>>>> To review the change, just:
>>>>>
>>>>> $ # download the bundle
>>>>> $ wget http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle
>>>>>
>>>>> $ hg incoming 8200626.bundle # list the changesets in the bundle
>>>>> $ hg pull -u 8200626.bundle # pull the changesets into your repository
>>>>> $ hg log --graph # inspect the log
>>>>>
>>>>> $ hg diff -r be49a19be03b:0ab2411f270d # verify that merge is benign
>>>>> $ hg diff -r 8c78b974cd55 -r 0ed1370f52bb # verify my change is
>>>>>  ?????????????????????????????????????????? # identical to Leo's
>>>>
>>>> Yes, verified. Thanks!
>>>>
>>>> I think it is trivial code-wise, and the risk of waiting 24 hrs opens up the opportunity to screw up
>>>> the re-merge later. Therefore, I think we should push it right away. Maybe another Reviewer should
>>>> double-check :)
>>>>
>>> I also verified it. Good work. I agree with Aleksey, push it now.
>>
>> Thanks Stefan and Aleksey, and nice suggestion on pushing quick, unfortunately I was a bit too slow :)
>>
>> So, here we go again, I uploaded a new bundle, 8200626.01.bundle. To review, just:
>>
>> wget http://cr.openjdk.java.net/~ehelin/8200626/8200626.01.bundle
>> hg pull -u 8200626.01.bundle
>> hg diff -r 334cdf15428b -r 55f8f5635ef7 # should show no changes
>> hg diff -r 8c78b974cd55 -r 0ed1370f52bb # should show no changes
> 
> Still looks good.

Thanks for the quick re-review, the changes are now pushed :)
Erik

> -Aleksey
> 


From erik.helin at oracle.com  Wed Apr  4 09:58:40 2018
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 4 Apr 2018 11:58:40 +0200
Subject: RFR: 8200626: Restore history for g1ConcurrentMarkThread.*
In-Reply-To: <d4997fbc-44b8-22cf-1fb0-816d704daa7b@oracle.com>
References: <e78085aa-675d-9922-70c0-a3f495dc1e00@oracle.com>
 <c1a950f0-986c-2e1e-dc0e-53f03123b901@redhat.com>
 <0b5e4a04-2a3e-eaac-29ba-ca22e3c47bf2@oracle.com>
 <0aab2dab-081c-21e9-3234-b94d51264c53@redhat.com>
 <09f81800-2b91-4a2e-4ef3-b60013e89358@oracle.com>
 <117ba20c-b49a-db5f-1046-fc4ca6d72b5d@oracle.com>
 <d4997fbc-44b8-22cf-1fb0-816d704daa7b@oracle.com>
Message-ID: <7bc2a53e-41ca-af93-3dbc-dbc29628ba3f@oracle.com>

On 04/04/2018 11:47 AM, Stefan Johansson wrote:
> 
> 
> On 2018-04-04 11:44, Erik Helin wrote:
>> On 04/04/2018 11:12 AM, Stefan Johansson wrote:
>>>
>>>
>>> On 2018-04-04 11:04, Aleksey Shipilev wrote:
>>>> On 04/04/2018 10:59 AM, Erik Helin wrote:
>>>>>> "hg log -G -l 5" or something would be nice to see too.
>>>>>
>>>>> Since this change involves so much hg metadata that is important, I 
>>>>> uploaded a hg bundle:
>>>>>
>>>>> http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle
>>>>>
>>>>> To review the change, just:
>>>>>
>>>>> $ # download the bundle
>>>>> $ wget http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle
>>>>>
>>>>> $ hg incoming 8200626.bundle # list the changesets in the bundle
>>>>> $ hg pull -u 8200626.bundle # pull the changesets into your repository
>>>>> $ hg log --graph # inspect the log
>>>>>
>>>>> $ hg diff -r be49a19be03b:0ab2411f270d # verify that merge is benign
>>>>> $ hg diff -r 8c78b974cd55 -r 0ed1370f52bb # verify my change is
>>>>> ?????????????????????????????????????????? # identical to Leo's
>>>>
>>>> Yes, verified. Thanks!
>>>>
>>>> I think it is trivial code-wise, and the risk of waiting 24 hrs 
>>>> opens up the opportunity to screw up
>>>> the re-merge later. Therefore, I think we should push it right away. 
>>>> Maybe another Reviewer should
>>>> double-check :)
>>>>
>>> I also verified it. Good work. I agree with Aleksey, push it now.
>>
>> Thanks Stefan and Aleksey, and nice suggestion on pushing quick, 
>> unfortunately I was a bit too slow :)
>>
>> So, here we go again, I uploaded a new bundle, 8200626.01.bundle. To 
>> review, just:
>>
>> wget http://cr.openjdk.java.net/~ehelin/8200626/8200626.01.bundle
>> hg pull -u 8200626.01.bundle
>> hg diff -r 334cdf15428b -r 55f8f5635ef7 # should show no changes
>> hg diff -r 8c78b974cd55 -r 0ed1370f52bb # should show no changes
>>
> Push it!

Just did :) Thanks for helping out with reviewing (and re-reviewing) 
quickly!
Erik

> StefanJ
> 
>> Thanks,
>> Erik
>>
>>> Thanks,
>>> Stefan
>>>
>>>> Thanks,
>>>> -Aleksey
>>>>


From rkennke at redhat.com  Wed Apr  4 10:11:40 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 4 Apr 2018 12:11:40 +0200
Subject: RFR: JDK-8199735: Mark word updates need to use Access API
In-Reply-To: <49B17F73-42A1-4786-9B9C-28B9B6BC673F@oracle.com>
References: <7bd73e32-a26b-2504-f069-b74807ae5e53@redhat.com>
 <859ac657-78c9-c7ab-0ec0-eddda331001b@redhat.com>
 <b8cb91fc-d332-baf6-c6ab-93d1ae39c6b1@redhat.com>
 <5AB3B052.4000304@oracle.com>
 <63199799-0194-a1d4-9c89-d95251c7aa7d@redhat.com>
 <5AB90C07.3020507@oracle.com>
 <4cdc8f4d-3f27-5c20-a606-251077ed9a82@redhat.com>
 <21286315-4a62-c06b-a13a-dfe4a83d88d3@redhat.com>
 <e5ef0ba2-0da4-5748-1430-c6ed0eddeb2c@redhat.com>
 <872A5E7B-5B73-42E5-869C-C6E941AE8A1A@oracle.com>
 <4274c332-9509-0831-3f60-fa823d4a786c@redhat.com>
 <49B17F73-42A1-4786-9B9C-28B9B6BC673F@oracle.com>
Message-ID: <f68bfc08-776c-2357-be9b-9f69109c8800@redhat.com>

Hi Mikael,

ok. So how do we go about it?
- I can hold back the patch, and have somebody inside work it out
(adding a few #include "oops/oop.inline.hpp" shouldn't hurt even without
the big patch). This would have the advantage that I can submit a round
of testing myself
- I can push the patch and you Oracles guys sort it out after the fact
- Somebody in Oracle can take my patch and sponsor it 'the old way' and
amend it with the internal fixes as necessary.
- something else?

Please let me know!

Thanks, Roman


> 
> Yes, it?s part of the (still closed) JFR sources. Somebody at Oracle will have to help update. Sorry for the inconvenience.
> 
> Cheers,
> Mikael
> 
>> On Apr 3, 2018, at 5:05 PM, Roman Kennke <rkennke at redhat.com> wrote:
>>
>> Thanks, Mikael!
>>
>> What is edgeStore.o and how is it built? I suspect it needs an
>> additional #include "oops/oop.inline.hpp" but I can't find the
>> corresponding source?
>>
>> Roman
>>
>>
>>>
>>> src/hotspot/share/oops/oop.hpp", line 70: Error: The function oopDesc::set_mark(markOopDesc*volatile) has not had a body defined.
>>> src/hotspot/share/oops/oop.hpp", line 66: Error: The function oopDesc::mark() const has not had a body defined.
>>> 2 Error(s) detected.
>>> lib/CompileJvm.gmk:212: recipe for target 'build/solaris-sparcv9-debug/hotspot/variant-server/libjvm/objs/edgeStore.o' failed
>>> make[3]: *** [build/solaris-sparcv9-debug/hotspot/variant-server/libjvm/objs/edgeStore.o] Error 1
>>>
>>>
>>> Cheers,
>>> Mikael
>>>
>>>> On Apr 3, 2018, at 4:39 PM, Roman Kennke <rkennke at redhat.com
>>>> <mailto:rkennke at redhat.com>> wrote:
>>>>
>>>> Am 03.04.2018 um 14:21 schrieb Aleksey Shipilev:
>>>>> On 03/26/2018 06:40 PM, Roman Kennke wrote:
>>>>>>>> Differential:
>>>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03.diff/
>>>>>>>> Full:
>>>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03/
>>>>>
>>>>> Looks good. A bit unfortunate it has to have many changes around due
>>>>> to the rename, but oh well.
>>>>>
>>>>> Thanks,
>>>>> -Aleksey
>>>>>
>>>>
>>>> Something seems to make Solaris/Sparc builds unhappy. Can somebody with
>>>> access to the test/build system check it?
>>>>
>>>> Thanks, Roman
>>>>
>>>>
>>>> Build Details: 2018-04-03-2039378.roman.source
>>>> 0 Failed Tests
>>>> Mach5 Tasks Results Summary
>>>>
>>>>    EXECUTED_WITH_FAILURE: 2
>>>>    KILLED: 0
>>>>    NA: 0
>>>>    UNABLE_TO_RUN: 4
>>>>    PASSED: 77
>>>>    FAILED: 0
>>>>    Build
>>>>
>>>>        2 Not run
>>>>            build_jdk_solaris-solaris-sparcv9-solaris-sparcv9-build-8
>>>> error while building, return value: 2
>>>>
>>>> build_jdk_solaris-solaris-sparcv9-debug-solaris-sparcv9-build-9 error
>>>> while building, return value: 2
>>>>
>>>>    Test
>>>>
>>>>        4 Not run
>>>>
>>>> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-70
>>>> Dependency task failed:
>>>> mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8
>>>>
>>>> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-71
>>>> Dependency task failed:
>>>> mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
>>>>
>>>> tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-68
>>>> Dependency task failed:
>>>> mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8
>>>>
>>>> tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-69
>>>> Dependency task failed:
>>>> mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
>>>>
>>>>
>>>>
>>>
>>
>>
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180404/9952f8f8/signature.asc>

From thomas.schatzl at oracle.com  Wed Apr  4 10:35:25 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 04 Apr 2018 12:35:25 +0200
Subject: RFR (XS): 8200723: Suppress rs_length and predicted_cards sampling
 during mixed gcs
Message-ID: <1522838125.2398.13.camel@oracle.com>

Hi all,

  can I have reviews for this small change that fixes a throughput
problem G1 may show after mixed gc phase?

The problem is that after mixed gc young gen sizing is heavily
influenced by mixed gc due to in many cases highly different RS lengths
and number of cards processed. Almost always in a negative way (if not
neutral), i.e. during mixed gc these values are almost always much
higher than during young gc, meaning that young gen of the first few
young-only gcs is much smaller than it should be.

There is another related problem with adaptive IHOP, where due to these
changes to the young gen, the survival rate increases (smaller young
gen means less time to die), which decreases IHOP, which in turn
increases the number of mixed phases (e.g. mixed gc's), which in turn
make young gen stay small.

JDK-8035557 has a graph showing how eden size over time in relation to
rs_length could look like without this change.

Contrary to JDK-8035557 this change kind of arbitrarily suppresses the
sampling for rs_length and predicted_cards during mixed gc, so these
"bad" values never enter the prediction logic. Mixed gc is not
affected, since we do not use any prediction for sizing young during
that time.

The proper fix would be JDK-8035557, completely separating predictions
for young-only and mixed gc.

CR:
https://bugs.openjdk.java.net/browse/JDK-8200723
Webrev:
http://cr.openjdk.java.net/~tschatzl/8200723/webrev
Testing:
hs-tier 1-5 with many other changes over time; manual inspection of
eden sizing behavior of several known to be affected benchmarks

Thanks,
  Thomas



From thomas.schatzl at oracle.com  Wed Apr  4 10:40:46 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 04 Apr 2018 12:40:46 +0200
Subject: RFR (S): 8200305: Update gc,liveness output with remset state
 after rebuild remset concurrently changes
In-Reply-To: <4c392558-fa1f-9703-6880-d996bc90083c@oracle.com>
References: <1522250812.15321.7.camel@oracle.com>
 <db0db6d9-42e4-7a16-d8b0-a36cf238422b@oracle.com>
 <1522262138.5658.6.camel@oracle.com>
 <4c392558-fa1f-9703-6880-d996bc90083c@oracle.com>
Message-ID: <1522838446.2398.16.camel@oracle.com>

On Thu, 2018-03-29 at 15:50 +0200, Stefan Johansson wrote:
> Hi,
> 
> On 2018-03-28 20:35, Thomas Schatzl wrote:
> > Hi,
> > 
> > On Wed, 2018-03-28 at 11:18 -0700, sangheon.kim wrote:
> > > Hi Thomas,
> > > 
> > > On 03/28/2018 08:26 AM, Thomas Schatzl wrote:
> > > > Hi all,
> > > > 
> > > >     can I have reviews for this change that updates the
> > > > gc,liveness output to add the remembered set state?
> > > > 
> > > > This change adds a column next to "remset" called "state" that
> > > > can be either UNTRA (Untracked), UPDAT (Updating) and CMPLT
> > > > (Complete).
> > > > 
> > > > There is a log snippet attached that shows the new output.
> > > > 
> > > > If somebody asks, I kind of agree that we should probably
> > > > rethink this output (remove some of the addresses, add region
> > > > number), but this is imho out of scope for this change. ;]
> > > > 
> > > > CR:
> > > > https://bugs.openjdk.java.net/browse/JDK-8200305
> > > > Webrev:
> > > > http://cr.openjdk.java.net/~tschatzl/8200305/webrev/
> > > > Testing:
> > > > local verification
> > > 
> > > Looks good as is.
> > > 
> > > Adding the state is a good idea.
> > > But these short version strings are not easy to catch. Just
> > > printing original strings(9 characters) are too long? :)
> > > 
> > 
> >    yes, I am aware of this issue, I actually thought about this for
> > an unusual amount of time too. After all I decided to keep the
> > abbreviations. And I understand that particularly UNTRA vs. UPDAT
> > might be a candidate for confusion, but then again it seemed better
> > than the long strings.
> > 
> > However if somebody else also prefers the long strings, I will
> > change that without further delay.
> 
> I'm fine either way, but an alternative, not sure it's better, could
> be  to add a footer explaining the short names. In that case the
> short name could be even shorter:
> - = Untracked
> + = Updating
> # = Complete
> 
> An other alternative is would be to revisit the state-names and
> maybe come up with something only needing one state_string, but I
> don't have  any ideas here. So I suggest going with either what you
> have or the footer-approach.

I think I will go with what I have if you don't mind. A change that
removes useless information from the output quite a bit is needed
anyway.

Thanks,
  Thomas



From leo.korinth at oracle.com  Wed Apr  4 10:55:56 2018
From: leo.korinth at oracle.com (Leo Korinth)
Date: Wed, 4 Apr 2018 12:55:56 +0200
Subject: RFR: 8200626: Restore history for g1ConcurrentMarkThread.*
In-Reply-To: <7bc2a53e-41ca-af93-3dbc-dbc29628ba3f@oracle.com>
References: <e78085aa-675d-9922-70c0-a3f495dc1e00@oracle.com>
 <c1a950f0-986c-2e1e-dc0e-53f03123b901@redhat.com>
 <0b5e4a04-2a3e-eaac-29ba-ca22e3c47bf2@oracle.com>
 <0aab2dab-081c-21e9-3234-b94d51264c53@redhat.com>
 <09f81800-2b91-4a2e-4ef3-b60013e89358@oracle.com>
 <117ba20c-b49a-db5f-1046-fc4ca6d72b5d@oracle.com>
 <d4997fbc-44b8-22cf-1fb0-816d704daa7b@oracle.com>
 <7bc2a53e-41ca-af93-3dbc-dbc29628ba3f@oracle.com>
Message-ID: <0c50d38d-040d-3fe1-13fe-21db7938d810@oracle.com>

Hi!

Many thanks Erik (and reviewers) for correcting my mistake.

Thanks,
Leo

On 04/04/18 11:58, Erik Helin wrote:
> On 04/04/2018 11:47 AM, Stefan Johansson wrote:
>>
>>
>> On 2018-04-04 11:44, Erik Helin wrote:
>>> On 04/04/2018 11:12 AM, Stefan Johansson wrote:
>>>>
>>>>
>>>> On 2018-04-04 11:04, Aleksey Shipilev wrote:
>>>>> On 04/04/2018 10:59 AM, Erik Helin wrote:
>>>>>>> "hg log -G -l 5" or something would be nice to see too.
>>>>>>
>>>>>> Since this change involves so much hg metadata that is important, 
>>>>>> I uploaded a hg bundle:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle
>>>>>>
>>>>>> To review the change, just:
>>>>>>
>>>>>> $ # download the bundle
>>>>>> $ wget http://cr.openjdk.java.net/~ehelin/8200626/8200626.bundle
>>>>>>
>>>>>> $ hg incoming 8200626.bundle # list the changesets in the bundle
>>>>>> $ hg pull -u 8200626.bundle # pull the changesets into your 
>>>>>> repository
>>>>>> $ hg log --graph # inspect the log
>>>>>>
>>>>>> $ hg diff -r be49a19be03b:0ab2411f270d # verify that merge is benign
>>>>>> $ hg diff -r 8c78b974cd55 -r 0ed1370f52bb # verify my change is
>>>>>> ?????????????????????????????????????????? # identical to Leo's
>>>>>
>>>>> Yes, verified. Thanks!
>>>>>
>>>>> I think it is trivial code-wise, and the risk of waiting 24 hrs 
>>>>> opens up the opportunity to screw up
>>>>> the re-merge later. Therefore, I think we should push it right 
>>>>> away. Maybe another Reviewer should
>>>>> double-check :)
>>>>>
>>>> I also verified it. Good work. I agree with Aleksey, push it now.
>>>
>>> Thanks Stefan and Aleksey, and nice suggestion on pushing quick, 
>>> unfortunately I was a bit too slow :)
>>>
>>> So, here we go again, I uploaded a new bundle, 8200626.01.bundle. To 
>>> review, just:
>>>
>>> wget http://cr.openjdk.java.net/~ehelin/8200626/8200626.01.bundle
>>> hg pull -u 8200626.01.bundle
>>> hg diff -r 334cdf15428b -r 55f8f5635ef7 # should show no changes
>>> hg diff -r 8c78b974cd55 -r 0ed1370f52bb # should show no changes
>>>
>> Push it!
> 
> Just did :) Thanks for helping out with reviewing (and re-reviewing) 
> quickly!
> Erik
> 
>> StefanJ
>>
>>> Thanks,
>>> Erik
>>>
>>>> Thanks,
>>>> Stefan
>>>>
>>>>> Thanks,
>>>>> -Aleksey
>>>>>


From stefan.johansson at oracle.com  Wed Apr  4 11:27:46 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Wed, 4 Apr 2018 13:27:46 +0200
Subject: RFR (S): 8200305: Update gc,liveness output with remset state
 after rebuild remset concurrently changes
In-Reply-To: <1522838446.2398.16.camel@oracle.com>
References: <1522250812.15321.7.camel@oracle.com>
 <db0db6d9-42e4-7a16-d8b0-a36cf238422b@oracle.com>
 <1522262138.5658.6.camel@oracle.com>
 <4c392558-fa1f-9703-6880-d996bc90083c@oracle.com>
 <1522838446.2398.16.camel@oracle.com>
Message-ID: <76fe0575-8d0c-3bce-d37a-f32fa75a20f9@oracle.com>



On 2018-04-04 12:40, Thomas Schatzl wrote:
> On Thu, 2018-03-29 at 15:50 +0200, Stefan Johansson wrote:
>> Hi,
>>
>> On 2018-03-28 20:35, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Wed, 2018-03-28 at 11:18 -0700, sangheon.kim wrote:
>>>> Hi Thomas,
>>>>
>>>> On 03/28/2018 08:26 AM, Thomas Schatzl wrote:
>>>>> Hi all,
>>>>>
>>>>>      can I have reviews for this change that updates the
>>>>> gc,liveness output to add the remembered set state?
>>>>>
>>>>> This change adds a column next to "remset" called "state" that
>>>>> can be either UNTRA (Untracked), UPDAT (Updating) and CMPLT
>>>>> (Complete).
>>>>>
>>>>> There is a log snippet attached that shows the new output.
>>>>>
>>>>> If somebody asks, I kind of agree that we should probably
>>>>> rethink this output (remove some of the addresses, add region
>>>>> number), but this is imho out of scope for this change. ;]
>>>>>
>>>>> CR:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8200305
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~tschatzl/8200305/webrev/
>>>>> Testing:
>>>>> local verification
>>>>
>>>> Looks good as is.
>>>>
>>>> Adding the state is a good idea.
>>>> But these short version strings are not easy to catch. Just
>>>> printing original strings(9 characters) are too long? :)
>>>>
>>>
>>>     yes, I am aware of this issue, I actually thought about this for
>>> an unusual amount of time too. After all I decided to keep the
>>> abbreviations. And I understand that particularly UNTRA vs. UPDAT
>>> might be a candidate for confusion, but then again it seemed better
>>> than the long strings.
>>>
>>> However if somebody else also prefers the long strings, I will
>>> change that without further delay.
>>
>> I'm fine either way, but an alternative, not sure it's better, could
>> be  to add a footer explaining the short names. In that case the
>> short name could be even shorter:
>> - = Untracked
>> + = Updating
>> # = Complete
>>
>> An other alternative is would be to revisit the state-names and
>> maybe come up with something only needing one state_string, but I
>> don't have  any ideas here. So I suggest going with either what you
>> have or the footer-approach.
> 
> I think I will go with what I have if you don't mind. A change that
> removes useless information from the output quite a bit is needed
> anyway.
I'm fine with that.

Thanks,
Stefan
> 
> Thanks,
>    Thomas
> 


From thomas.schatzl at oracle.com  Wed Apr  4 12:26:09 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 04 Apr 2018 14:26:09 +0200
Subject: RFR (XS): 8200730: Fix debug=gc+phases time tracking in Remark and
 Cleanup
Message-ID: <1522844769.2398.20.camel@oracle.com>

Hi all,

  can I have reviews to let the recently introduced timing measurements
in Remark and Cleanup pauses actually show useful numbers?

The problem is that the GCTraceTime instances were not assigned to a
variable inside a scope so the compiler immediately destructed it,
always giving "0.000ms" lengths.

Also added to use the gc timer to these lines for JFR support.

I would like to think this is a trivial change.

CR:
https://bugs.openjdk.java.net/browse/JDK-8200730
Webrev:
http://cr.openjdk.java.net/~tschatzl/8200730/webrev
Testing:
manual verification that the shown numbers are sane

Thanks,
  Thomas



From thomas.schatzl at oracle.com  Wed Apr  4 12:29:09 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 04 Apr 2018 14:29:09 +0200
Subject: RFR (S/M): 8200234: Cleanup Remark and Cleanup pause code
In-Reply-To: <545e7da6-8f03-277f-5b43-06642ae02141@oracle.com>
References: <1522079989.2567.43.camel@oracle.com>
 <283b9e7b-7729-718b-7bc4-22282fa3d7e1@oracle.com>
 <1522245966.2391.42.camel@oracle.com>
 <545e7da6-8f03-277f-5b43-06642ae02141@oracle.com>
Message-ID: <1522844949.2398.23.camel@oracle.com>

Hi Sangheon, Stefan,

On Tue, 2018-04-03 at 15:45 -0700, sangheon.kim wrote:
> Hi Thomas,
> 
> On 03/28/2018 07:06 AM, Thomas Schatzl wrote:
> > Hi,
> > 
> > [...]
> > 
> > http://cr.openjdk.java.net/~tschatzl/8200234/webrev.0_to_1 (diff)
> > http://cr.openjdk.java.net/~tschatzl/8200234/webrev.1 (full)
> 
> webrev.1 looks good.
> Please update copyright year at heapRegion.inline.hpp before push.
> 
> Thanks for this cleanup!

  thanks for your reviews.

Thanks,
  Thomas



From thomas.schatzl at oracle.com  Wed Apr  4 12:42:51 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 04 Apr 2018 14:42:51 +0200
Subject: RFR (S/M): 8178105: Switch mark bitmaps during Remark
In-Reply-To: <1b5b0099-97da-35b6-99c1-628e5adf75ea@oracle.com>
References: <1522334136.2451.15.camel@oracle.com>
 <c4a8f532-db1b-09f8-5b9d-aa76f2f6ae4d@oracle.com>
 <1522758329.2573.9.camel@oracle.com>
 <09b374ab-a86f-bcff-00f4-4b2874fb59ff@oracle.com>
 <1522767307.2582.2.camel@oracle.com>
 <1b5b0099-97da-35b6-99c1-628e5adf75ea@oracle.com>
Message-ID: <1522845771.2398.26.camel@oracle.com>

Hi all,

  while looking at some parallelizing work in this area I noticed that
one assert in the rebuild remsets code that has been changed in this
change already needs an update too.
It uses a wrong value for the informational text, which makes it really
confusing.

Since this change touches this code already, I would like to amend this
change with this small fix:

Webrev:
http://cr.openjdk.java.net/~tschatzl/8178105/webrev.2_to_3/ (diff)
http://cr.openjdk.java.net/~tschatzl/8178105/webrev.3/ (full)

Sorry for the trouble.

Thanks,
  Thomas

On Tue, 2018-04-03 at 17:00 +0200, Stefan Johansson wrote:
> 
> On 2018-04-03 16:55, Thomas Schatzl wrote:
> > Hi,
> > 
> >    thanks for your patience...
> > 
> > On Tue, 2018-04-03 at 14:49 +0200, Stefan Johansson wrote:
> > > 
> > > On 2018-04-03 14:25, Thomas Schatzl wrote:
> > > > Hi Stefan,
> > > > 
> > > > On Tue, 2018-04-03 at 12:58 +0200, Stefan Johansson wrote:
> > > > > Hi Thomas,
> > > > > 
> > > > > On 2018-03-29 16:35, Thomas Schatzl wrote:
> > > > > > Hi all,
> > > > > > [...]
> > > > > > 
> > > > > > CR:
> > > > > > https://bugs.openjdk.java.net/browse/JDK-8178105
> > > > > > Webrev:
> > > > > > http://cr.openjdk.java.net/~tschatzl/8178105/
> > > > > 
> > > > >    Looks good, but a few comments:
> > > > > 
> > 
> > [...]
> > > > I added a different kind of check that verifies what you
> > > > probably
> > > > thought of, and that is that the number of words to add to the
> > > > current region must always be larger than zero. If it is zero,
> > > > there is something really wrong.
> > > 
> > > Exactly, that's what I wanted. But I don't see that check now,
> > > just
> > > having a assert(marked_words != 0, "") on row 1032 would be
> > > enough.
> > 
> > My fault. I did not upload the latest version of the change :( It
> > is up
> > now, the only difference to previous is line
> > 
> > 1036       assert(words_to_add > 0, "Out of space to distribute
> > before
> > end of humongous object in region %u (starts %u)", i, region_idx);
> > 
> > But there is a new webrev anyway... in the 1_to_2 webrev it is line
> > 1033
> > 
> > > > > 
> > > > > 1047       log_trace(gc)("Added " SIZE_FORMAT " words to
> > > > > region
> > > > > %u
> > > > > (%s)", marked_words, region_idx, hr->get_type_str());
> > > > > I think the logging should use at least one more tag, maybe
> > > > > "region" or "marking", but you probably know what makes most
> > > > > sense in this area. I also think it would be nice if we got
> > > > > this
> > > > > same log-line for all regions. Now we get this for "normal"
> > > > > regions, but we get "Distributing..." for humongous start
> > > > > regions
> > > > > and "Not Added..." for humongous continuous. So I would
> > > > > suggest
> > > > > adding the same log-line  to the distribute-function after
> > > > > line
> > > > > 1034.
> > > > 
> > > > Done.
> > > 
> > > Sorry for being picky but the current solution won't print
> > > anything
> > > for continuous humongous. Adding the log to
> > > distribute_marked_bytes()
> > > would solve this and we would still get info on region type so I
> > > see
> > > no need for:
> > 
> > Okay. I think I got your intention right this time :)
> > 
> > > 1052         log_trace(gc, marking)("Adding " SIZE_FORMAT " words
> > > to
> > > humongous start region %u (%s), word size %d (%f)",
> > > 1053                                marked_words, region_idx,
> > > hr->get_type_str(),
> > > 1054                                oop(hr->bottom())->size(),
> > > (double)oop(hr->bottom())->size() / HeapRegion::GrainWords);
> > 
> > [...]
> > > > All fixed.
> > > > 
> > > > Webrevs:
> > > > http://cr.openjdk.java.net/~tschatzl/8178105/webrev.0_to_1/
> > > > (diff)
> > > > http://cr.openjdk.java.net/~tschatzl/8178105/webrev.1/ (full)
> > > 
> > > Apart from the small things above this looks great.
> > 
> > http://cr.openjdk.java.net/~tschatzl/8178105/webrev.1_to_2/ (diff)
> > http://cr.openjdk.java.net/~tschatzl/8178105/webrev.2/ (full)
> 
> Looks good!
> 
> Thanks,
> StefanJ
> 
> > 
> > Ran gc/g1 tests successfully with that change.
> > 
> > Thanks,
> >    Thomas
> > 



From stefan.karlsson at oracle.com  Wed Apr  4 13:26:29 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 4 Apr 2018 15:26:29 +0200
Subject: RFR: 8200736: Move CMSGCStats to the cms directory
Message-ID: <ae5fae7f-70b4-0326-eaa8-62c422da3a5c@oracle.com>

Hi all,

Please review this trivial patch to move the CMSGCStats class to the cms 
directory.

http://cr.openjdk.java.net/~stefank/8200736/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8200736

Thanks,
StefanK


From stefan.johansson at oracle.com  Wed Apr  4 13:32:20 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Wed, 4 Apr 2018 15:32:20 +0200
Subject: RFR (S/M): 8178105: Switch mark bitmaps during Remark
In-Reply-To: <1522845771.2398.26.camel@oracle.com>
References: <1522334136.2451.15.camel@oracle.com>
 <c4a8f532-db1b-09f8-5b9d-aa76f2f6ae4d@oracle.com>
 <1522758329.2573.9.camel@oracle.com>
 <09b374ab-a86f-bcff-00f4-4b2874fb59ff@oracle.com>
 <1522767307.2582.2.camel@oracle.com>
 <1b5b0099-97da-35b6-99c1-628e5adf75ea@oracle.com>
 <1522845771.2398.26.camel@oracle.com>
Message-ID: <6f573d7e-f91a-1dc8-f4f7-c6a71781e256@oracle.com>



On 2018-04-04 14:42, Thomas Schatzl wrote:
> Hi all,
> 
>    while looking at some parallelizing work in this area I noticed that
> one assert in the rebuild remsets code that has been changed in this
> change already needs an update too.
> It uses a wrong value for the informational text, which makes it really
> confusing.
> 
> Since this change touches this code already, I would like to amend this
> change with this small fix:
> 
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.2_to_3/ (diff)
> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.3/ (full)
> 
> Sorry for the trouble.
NP, still good!

Stefan
> 
> Thanks,
>    Thomas
> 
> On Tue, 2018-04-03 at 17:00 +0200, Stefan Johansson wrote:
>>
>> On 2018-04-03 16:55, Thomas Schatzl wrote:
>>> Hi,
>>>
>>>     thanks for your patience...
>>>
>>> On Tue, 2018-04-03 at 14:49 +0200, Stefan Johansson wrote:
>>>>
>>>> On 2018-04-03 14:25, Thomas Schatzl wrote:
>>>>> Hi Stefan,
>>>>>
>>>>> On Tue, 2018-04-03 at 12:58 +0200, Stefan Johansson wrote:
>>>>>> Hi Thomas,
>>>>>>
>>>>>> On 2018-03-29 16:35, Thomas Schatzl wrote:
>>>>>>> Hi all,
>>>>>>> [...]
>>>>>>>
>>>>>>> CR:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8178105
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~tschatzl/8178105/
>>>>>>
>>>>>>     Looks good, but a few comments:
>>>>>>
>>>
>>> [...]
>>>>> I added a different kind of check that verifies what you
>>>>> probably
>>>>> thought of, and that is that the number of words to add to the
>>>>> current region must always be larger than zero. If it is zero,
>>>>> there is something really wrong.
>>>>
>>>> Exactly, that's what I wanted. But I don't see that check now,
>>>> just
>>>> having a assert(marked_words != 0, "") on row 1032 would be
>>>> enough.
>>>
>>> My fault. I did not upload the latest version of the change :( It
>>> is up
>>> now, the only difference to previous is line
>>>
>>> 1036       assert(words_to_add > 0, "Out of space to distribute
>>> before
>>> end of humongous object in region %u (starts %u)", i, region_idx);
>>>
>>> But there is a new webrev anyway... in the 1_to_2 webrev it is line
>>> 1033
>>>
>>>>>>
>>>>>> 1047       log_trace(gc)("Added " SIZE_FORMAT " words to
>>>>>> region
>>>>>> %u
>>>>>> (%s)", marked_words, region_idx, hr->get_type_str());
>>>>>> I think the logging should use at least one more tag, maybe
>>>>>> "region" or "marking", but you probably know what makes most
>>>>>> sense in this area. I also think it would be nice if we got
>>>>>> this
>>>>>> same log-line for all regions. Now we get this for "normal"
>>>>>> regions, but we get "Distributing..." for humongous start
>>>>>> regions
>>>>>> and "Not Added..." for humongous continuous. So I would
>>>>>> suggest
>>>>>> adding the same log-line  to the distribute-function after
>>>>>> line
>>>>>> 1034.
>>>>>
>>>>> Done.
>>>>
>>>> Sorry for being picky but the current solution won't print
>>>> anything
>>>> for continuous humongous. Adding the log to
>>>> distribute_marked_bytes()
>>>> would solve this and we would still get info on region type so I
>>>> see
>>>> no need for:
>>>
>>> Okay. I think I got your intention right this time :)
>>>
>>>> 1052         log_trace(gc, marking)("Adding " SIZE_FORMAT " words
>>>> to
>>>> humongous start region %u (%s), word size %d (%f)",
>>>> 1053                                marked_words, region_idx,
>>>> hr->get_type_str(),
>>>> 1054                                oop(hr->bottom())->size(),
>>>> (double)oop(hr->bottom())->size() / HeapRegion::GrainWords);
>>>
>>> [...]
>>>>> All fixed.
>>>>>
>>>>> Webrevs:
>>>>> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.0_to_1/
>>>>> (diff)
>>>>> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.1/ (full)
>>>>
>>>> Apart from the small things above this looks great.
>>>
>>> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.1_to_2/ (diff)
>>> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.2/ (full)
>>
>> Looks good!
>>
>> Thanks,
>> StefanJ
>>
>>>
>>> Ran gc/g1 tests successfully with that change.
>>>
>>> Thanks,
>>>     Thomas
>>>
> 


From stefan.johansson at oracle.com  Wed Apr  4 13:41:16 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Wed, 4 Apr 2018 15:41:16 +0200
Subject: RFR: 8200736: Move CMSGCStats to the cms directory
In-Reply-To: <ae5fae7f-70b4-0326-eaa8-62c422da3a5c@oracle.com>
References: <ae5fae7f-70b4-0326-eaa8-62c422da3a5c@oracle.com>
Message-ID: <b3eff5f0-89f1-ca8e-c863-55c7adcc3c45@oracle.com>



On 2018-04-04 15:26, Stefan Karlsson wrote:
> Hi all,
> 
> Please review this trivial patch to move the CMSGCStats class to the cms 
> directory.
> 
> http://cr.openjdk.java.net/~stefank/8200736/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8200736
> 
Nice cleanup, looks good!

StefanJ
> Thanks,
> StefanK


From stefan.karlsson at oracle.com  Wed Apr  4 13:42:04 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 4 Apr 2018 15:42:04 +0200
Subject: RFR: 8200737: Move GC code out of
 Arguments::check_vm_args_consistency into GCArguments
Message-ID: <39139bd0-07b5-4a40-b5ae-eb8834a31e83@oracle.com>

Hi all,

Please review this patch to move GC code out of 
Arguments::check_vm_args_consistency into GCArguments.

http://cr.openjdk.java.net/~stefank/8200737/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8200737

This moves one of the usages of INCLUDE_ALL_GCS out of the runtime code 
into GC code, which helps the code in:
https://bugs.openjdk.java.net/browse/JDK-8200729

I've verified that the changed flags are not used between the previous 
location and the new location.

Thanks,
StefanK


From stefan.karlsson at oracle.com  Wed Apr  4 13:43:05 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 4 Apr 2018 15:43:05 +0200
Subject: RFR: 8200736: Move CMSGCStats to the cms directory
In-Reply-To: <b3eff5f0-89f1-ca8e-c863-55c7adcc3c45@oracle.com>
References: <ae5fae7f-70b4-0326-eaa8-62c422da3a5c@oracle.com>
 <b3eff5f0-89f1-ca8e-c863-55c7adcc3c45@oracle.com>
Message-ID: <c210fc73-2f34-5600-8a0c-9e00b124cf6a@oracle.com>

Thanks, StefanJ.

StefanK

On 2018-04-04 15:41, Stefan Johansson wrote:
> 
> 
> On 2018-04-04 15:26, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this trivial patch to move the CMSGCStats class to the 
>> cms directory.
>>
>> http://cr.openjdk.java.net/~stefank/8200736/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8200736
>>
> Nice cleanup, looks good!
> 
> StefanJ
>> Thanks,
>> StefanK


From rkennke at redhat.com  Wed Apr  4 20:30:57 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 4 Apr 2018 22:30:57 +0200
Subject: RFR: JDK-8199735: Mark word updates need to use Access API
In-Reply-To: <f68bfc08-776c-2357-be9b-9f69109c8800@redhat.com>
References: <7bd73e32-a26b-2504-f069-b74807ae5e53@redhat.com>
 <859ac657-78c9-c7ab-0ec0-eddda331001b@redhat.com>
 <b8cb91fc-d332-baf6-c6ab-93d1ae39c6b1@redhat.com>
 <5AB3B052.4000304@oracle.com>
 <63199799-0194-a1d4-9c89-d95251c7aa7d@redhat.com>
 <5AB90C07.3020507@oracle.com>
 <4cdc8f4d-3f27-5c20-a606-251077ed9a82@redhat.com>
 <21286315-4a62-c06b-a13a-dfe4a83d88d3@redhat.com>
 <e5ef0ba2-0da4-5748-1430-c6ed0eddeb2c@redhat.com>
 <872A5E7B-5B73-42E5-869C-C6E941AE8A1A@oracle.com>
 <4274c332-9509-0831-3f60-fa823d4a786c@redhat.com>
 <49B17F73-42A1-4786-9B9C-28B9B6BC673F@oracle.com>
 <f68bfc08-776c-2357-be9b-9f69109c8800@redhat.com>
Message-ID: <97ba2822-4869-d54f-ee6d-163cc6f916f1@redhat.com>

Ping? Should I go ahead and push it?

Thanks,
Roman

> Hi Mikael,
> 
> ok. So how do we go about it?
> - I can hold back the patch, and have somebody inside work it out
> (adding a few #include "oops/oop.inline.hpp" shouldn't hurt even without
> the big patch). This would have the advantage that I can submit a round
> of testing myself
> - I can push the patch and you Oracles guys sort it out after the fact
> - Somebody in Oracle can take my patch and sponsor it 'the old way' and
> amend it with the internal fixes as necessary.
> - something else?
> 
> Please let me know!
> 
> Thanks, Roman
> 
> 
>>
>> Yes, it?s part of the (still closed) JFR sources. Somebody at Oracle will have to help update. Sorry for the inconvenience.
>>
>> Cheers,
>> Mikael
>>
>>> On Apr 3, 2018, at 5:05 PM, Roman Kennke <rkennke at redhat.com> wrote:
>>>
>>> Thanks, Mikael!
>>>
>>> What is edgeStore.o and how is it built? I suspect it needs an
>>> additional #include "oops/oop.inline.hpp" but I can't find the
>>> corresponding source?
>>>
>>> Roman
>>>
>>>
>>>>
>>>> src/hotspot/share/oops/oop.hpp", line 70: Error: The function oopDesc::set_mark(markOopDesc*volatile) has not had a body defined.
>>>> src/hotspot/share/oops/oop.hpp", line 66: Error: The function oopDesc::mark() const has not had a body defined.
>>>> 2 Error(s) detected.
>>>> lib/CompileJvm.gmk:212: recipe for target 'build/solaris-sparcv9-debug/hotspot/variant-server/libjvm/objs/edgeStore.o' failed
>>>> make[3]: *** [build/solaris-sparcv9-debug/hotspot/variant-server/libjvm/objs/edgeStore.o] Error 1
>>>>
>>>>
>>>> Cheers,
>>>> Mikael
>>>>
>>>>> On Apr 3, 2018, at 4:39 PM, Roman Kennke <rkennke at redhat.com
>>>>> <mailto:rkennke at redhat.com>> wrote:
>>>>>
>>>>> Am 03.04.2018 um 14:21 schrieb Aleksey Shipilev:
>>>>>> On 03/26/2018 06:40 PM, Roman Kennke wrote:
>>>>>>>>> Differential:
>>>>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03.diff/
>>>>>>>>> Full:
>>>>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03/
>>>>>>
>>>>>> Looks good. A bit unfortunate it has to have many changes around due
>>>>>> to the rename, but oh well.
>>>>>>
>>>>>> Thanks,
>>>>>> -Aleksey
>>>>>>
>>>>>
>>>>> Something seems to make Solaris/Sparc builds unhappy. Can somebody with
>>>>> access to the test/build system check it?
>>>>>
>>>>> Thanks, Roman
>>>>>
>>>>>
>>>>> Build Details: 2018-04-03-2039378.roman.source
>>>>> 0 Failed Tests
>>>>> Mach5 Tasks Results Summary
>>>>>
>>>>>    EXECUTED_WITH_FAILURE: 2
>>>>>    KILLED: 0
>>>>>    NA: 0
>>>>>    UNABLE_TO_RUN: 4
>>>>>    PASSED: 77
>>>>>    FAILED: 0
>>>>>    Build
>>>>>
>>>>>        2 Not run
>>>>>            build_jdk_solaris-solaris-sparcv9-solaris-sparcv9-build-8
>>>>> error while building, return value: 2
>>>>>
>>>>> build_jdk_solaris-solaris-sparcv9-debug-solaris-sparcv9-build-9 error
>>>>> while building, return value: 2
>>>>>
>>>>>    Test
>>>>>
>>>>>        4 Not run
>>>>>
>>>>> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-70
>>>>> Dependency task failed:
>>>>> mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8
>>>>>
>>>>> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-71
>>>>> Dependency task failed:
>>>>> mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
>>>>>
>>>>> tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-68
>>>>> Dependency task failed:
>>>>> mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8
>>>>>
>>>>> tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-69
>>>>> Dependency task failed:
>>>>> mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180404/0bd4f528/signature.asc>

From erik.osterlund at oracle.com  Wed Apr  4 20:54:24 2018
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Wed, 4 Apr 2018 22:54:24 +0200
Subject: RFR: JDK-8199735: Mark word updates need to use Access API
In-Reply-To: <97ba2822-4869-d54f-ee6d-163cc6f916f1@redhat.com>
References: <7bd73e32-a26b-2504-f069-b74807ae5e53@redhat.com>
 <859ac657-78c9-c7ab-0ec0-eddda331001b@redhat.com>
 <b8cb91fc-d332-baf6-c6ab-93d1ae39c6b1@redhat.com>
 <5AB3B052.4000304@oracle.com>
 <63199799-0194-a1d4-9c89-d95251c7aa7d@redhat.com>
 <5AB90C07.3020507@oracle.com>
 <4cdc8f4d-3f27-5c20-a606-251077ed9a82@redhat.com>
 <21286315-4a62-c06b-a13a-dfe4a83d88d3@redhat.com>
 <e5ef0ba2-0da4-5748-1430-c6ed0eddeb2c@redhat.com>
 <872A5E7B-5B73-42E5-869C-C6E941AE8A1A@oracle.com>
 <4274c332-9509-0831-3f60-fa823d4a786c@redhat.com>
 <49B17F73-42A1-4786-9B9C-28B9B6BC673F@oracle.com>
 <f68bfc08-776c-2357-be9b-9f69109c8800@redhat.com>
 <97ba2822-4869-d54f-ee6d-163cc6f916f1@redhat.com>
Message-ID: <BA0B7803-3F8B-47DF-87EE-8DC109C6FFB8@oracle.com>

Hi Roman,

I will sponsor this for you.

/Erik

> On 4 Apr 2018, at 22:30, Roman Kennke <rkennke at redhat.com> wrote:
> 
> Ping? Should I go ahead and push it?
> 
> Thanks,
> Roman
> 
>> Hi Mikael,
>> 
>> ok. So how do we go about it?
>> - I can hold back the patch, and have somebody inside work it out
>> (adding a few #include "oops/oop.inline.hpp" shouldn't hurt even without
>> the big patch). This would have the advantage that I can submit a round
>> of testing myself
>> - I can push the patch and you Oracles guys sort it out after the fact
>> - Somebody in Oracle can take my patch and sponsor it 'the old way' and
>> amend it with the internal fixes as necessary.
>> - something else?
>> 
>> Please let me know!
>> 
>> Thanks, Roman
>> 
>> 
>>> 
>>> Yes, it?s part of the (still closed) JFR sources. Somebody at Oracle will have to help update. Sorry for the inconvenience.
>>> 
>>> Cheers,
>>> Mikael
>>> 
>>>> On Apr 3, 2018, at 5:05 PM, Roman Kennke <rkennke at redhat.com> wrote:
>>>> 
>>>> Thanks, Mikael!
>>>> 
>>>> What is edgeStore.o and how is it built? I suspect it needs an
>>>> additional #include "oops/oop.inline.hpp" but I can't find the
>>>> corresponding source?
>>>> 
>>>> Roman
>>>> 
>>>> 
>>>>> 
>>>>> src/hotspot/share/oops/oop.hpp", line 70: Error: The function oopDesc::set_mark(markOopDesc*volatile) has not had a body defined.
>>>>> src/hotspot/share/oops/oop.hpp", line 66: Error: The function oopDesc::mark() const has not had a body defined.
>>>>> 2 Error(s) detected.
>>>>> lib/CompileJvm.gmk:212: recipe for target 'build/solaris-sparcv9-debug/hotspot/variant-server/libjvm/objs/edgeStore.o' failed
>>>>> make[3]: *** [build/solaris-sparcv9-debug/hotspot/variant-server/libjvm/objs/edgeStore.o] Error 1
>>>>> 
>>>>> 
>>>>> Cheers,
>>>>> Mikael
>>>>> 
>>>>>> On Apr 3, 2018, at 4:39 PM, Roman Kennke <rkennke at redhat.com
>>>>>> <mailto:rkennke at redhat.com>> wrote:
>>>>>> 
>>>>>>> Am 03.04.2018 um 14:21 schrieb Aleksey Shipilev:
>>>>>>> On 03/26/2018 06:40 PM, Roman Kennke wrote:
>>>>>>>>>> Differential:
>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03.diff/
>>>>>>>>>> Full:
>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03/
>>>>>>> 
>>>>>>> Looks good. A bit unfortunate it has to have many changes around due
>>>>>>> to the rename, but oh well.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> -Aleksey
>>>>>>> 
>>>>>> 
>>>>>> Something seems to make Solaris/Sparc builds unhappy. Can somebody with
>>>>>> access to the test/build system check it?
>>>>>> 
>>>>>> Thanks, Roman
>>>>>> 
>>>>>> 
>>>>>> Build Details: 2018-04-03-2039378.roman.source
>>>>>> 0 Failed Tests
>>>>>> Mach5 Tasks Results Summary
>>>>>> 
>>>>>>   EXECUTED_WITH_FAILURE: 2
>>>>>>   KILLED: 0
>>>>>>   NA: 0
>>>>>>   UNABLE_TO_RUN: 4
>>>>>>   PASSED: 77
>>>>>>   FAILED: 0
>>>>>>   Build
>>>>>> 
>>>>>>       2 Not run
>>>>>>           build_jdk_solaris-solaris-sparcv9-solaris-sparcv9-build-8
>>>>>> error while building, return value: 2
>>>>>> 
>>>>>> build_jdk_solaris-solaris-sparcv9-debug-solaris-sparcv9-build-9 error
>>>>>> while building, return value: 2
>>>>>> 
>>>>>>   Test
>>>>>> 
>>>>>>       4 Not run
>>>>>> 
>>>>>> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-70
>>>>>> Dependency task failed:
>>>>>> mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8
>>>>>> 
>>>>>> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-71
>>>>>> Dependency task failed:
>>>>>> mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
>>>>>> 
>>>>>> tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-68
>>>>>> Dependency task failed:
>>>>>> mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8
>>>>>> 
>>>>>> tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-69
>>>>>> Dependency task failed:
>>>>>> mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 



From rkennke at redhat.com  Wed Apr  4 20:56:03 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 4 Apr 2018 22:56:03 +0200
Subject: RFR: JDK-8199735: Mark word updates need to use Access API
In-Reply-To: <BA0B7803-3F8B-47DF-87EE-8DC109C6FFB8@oracle.com>
References: <7bd73e32-a26b-2504-f069-b74807ae5e53@redhat.com>
 <859ac657-78c9-c7ab-0ec0-eddda331001b@redhat.com>
 <b8cb91fc-d332-baf6-c6ab-93d1ae39c6b1@redhat.com>
 <5AB3B052.4000304@oracle.com>
 <63199799-0194-a1d4-9c89-d95251c7aa7d@redhat.com>
 <5AB90C07.3020507@oracle.com>
 <4cdc8f4d-3f27-5c20-a606-251077ed9a82@redhat.com>
 <21286315-4a62-c06b-a13a-dfe4a83d88d3@redhat.com>
 <e5ef0ba2-0da4-5748-1430-c6ed0eddeb2c@redhat.com>
 <872A5E7B-5B73-42E5-869C-C6E941AE8A1A@oracle.com>
 <4274c332-9509-0831-3f60-fa823d4a786c@redhat.com>
 <49B17F73-42A1-4786-9B9C-28B9B6BC673F@oracle.com>
 <f68bfc08-776c-2357-be9b-9f69109c8800@redhat.com>
 <97ba2822-4869-d54f-ee6d-163cc6f916f1@redhat.com>
 <BA0B7803-3F8B-47DF-87EE-8DC109C6FFB8@oracle.com>
Message-ID: <4c176920-eaf3-7f09-0123-4400c5084156@redhat.com>

Tack! ;-)

> Hi Roman,
> 
> I will sponsor this for you.
> 
> /Erik
> 
>> On 4 Apr 2018, at 22:30, Roman Kennke <rkennke at redhat.com> wrote:
>>
>> Ping? Should I go ahead and push it?
>>
>> Thanks,
>> Roman
>>
>>> Hi Mikael,
>>>
>>> ok. So how do we go about it?
>>> - I can hold back the patch, and have somebody inside work it out
>>> (adding a few #include "oops/oop.inline.hpp" shouldn't hurt even without
>>> the big patch). This would have the advantage that I can submit a round
>>> of testing myself
>>> - I can push the patch and you Oracles guys sort it out after the fact
>>> - Somebody in Oracle can take my patch and sponsor it 'the old way' and
>>> amend it with the internal fixes as necessary.
>>> - something else?
>>>
>>> Please let me know!
>>>
>>> Thanks, Roman
>>>
>>>
>>>>
>>>> Yes, it?s part of the (still closed) JFR sources. Somebody at Oracle will have to help update. Sorry for the inconvenience.
>>>>
>>>> Cheers,
>>>> Mikael
>>>>
>>>>> On Apr 3, 2018, at 5:05 PM, Roman Kennke <rkennke at redhat.com> wrote:
>>>>>
>>>>> Thanks, Mikael!
>>>>>
>>>>> What is edgeStore.o and how is it built? I suspect it needs an
>>>>> additional #include "oops/oop.inline.hpp" but I can't find the
>>>>> corresponding source?
>>>>>
>>>>> Roman
>>>>>
>>>>>
>>>>>>
>>>>>> src/hotspot/share/oops/oop.hpp", line 70: Error: The function oopDesc::set_mark(markOopDesc*volatile) has not had a body defined.
>>>>>> src/hotspot/share/oops/oop.hpp", line 66: Error: The function oopDesc::mark() const has not had a body defined.
>>>>>> 2 Error(s) detected.
>>>>>> lib/CompileJvm.gmk:212: recipe for target 'build/solaris-sparcv9-debug/hotspot/variant-server/libjvm/objs/edgeStore.o' failed
>>>>>> make[3]: *** [build/solaris-sparcv9-debug/hotspot/variant-server/libjvm/objs/edgeStore.o] Error 1
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Mikael
>>>>>>
>>>>>>> On Apr 3, 2018, at 4:39 PM, Roman Kennke <rkennke at redhat.com
>>>>>>> <mailto:rkennke at redhat.com>> wrote:
>>>>>>>
>>>>>>>> Am 03.04.2018 um 14:21 schrieb Aleksey Shipilev:
>>>>>>>> On 03/26/2018 06:40 PM, Roman Kennke wrote:
>>>>>>>>>>> Differential:
>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03.diff/
>>>>>>>>>>> Full:
>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199735/webrev.03/
>>>>>>>>
>>>>>>>> Looks good. A bit unfortunate it has to have many changes around due
>>>>>>>> to the rename, but oh well.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> -Aleksey
>>>>>>>>
>>>>>>>
>>>>>>> Something seems to make Solaris/Sparc builds unhappy. Can somebody with
>>>>>>> access to the test/build system check it?
>>>>>>>
>>>>>>> Thanks, Roman
>>>>>>>
>>>>>>>
>>>>>>> Build Details: 2018-04-03-2039378.roman.source
>>>>>>> 0 Failed Tests
>>>>>>> Mach5 Tasks Results Summary
>>>>>>>
>>>>>>>   EXECUTED_WITH_FAILURE: 2
>>>>>>>   KILLED: 0
>>>>>>>   NA: 0
>>>>>>>   UNABLE_TO_RUN: 4
>>>>>>>   PASSED: 77
>>>>>>>   FAILED: 0
>>>>>>>   Build
>>>>>>>
>>>>>>>       2 Not run
>>>>>>>           build_jdk_solaris-solaris-sparcv9-solaris-sparcv9-build-8
>>>>>>> error while building, return value: 2
>>>>>>>
>>>>>>> build_jdk_solaris-solaris-sparcv9-debug-solaris-sparcv9-build-9 error
>>>>>>> while building, return value: 2
>>>>>>>
>>>>>>>   Test
>>>>>>>
>>>>>>>       4 Not run
>>>>>>>
>>>>>>> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-70
>>>>>>> Dependency task failed:
>>>>>>> mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8
>>>>>>>
>>>>>>> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-71
>>>>>>> Dependency task failed:
>>>>>>> mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
>>>>>>>
>>>>>>> tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-68
>>>>>>> Dependency task failed:
>>>>>>> mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8
>>>>>>>
>>>>>>> tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-69
>>>>>>> Dependency task failed:
>>>>>>> mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180404/2b2f1792/signature.asc>

From stefan.johansson at oracle.com  Thu Apr  5 08:16:53 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 5 Apr 2018 10:16:53 +0200
Subject: RFR: 8200737: Move GC code out of
 Arguments::check_vm_args_consistency into GCArguments
In-Reply-To: <39139bd0-07b5-4a40-b5ae-eb8834a31e83@oracle.com>
References: <39139bd0-07b5-4a40-b5ae-eb8834a31e83@oracle.com>
Message-ID: <fa84f661-2b1b-b09c-d85b-2706dd0ef2da@oracle.com>

Hi,

On 2018-04-04 15:42, Stefan Karlsson wrote:
> Hi all,
> 
> Please review this patch to move GC code out of 
> Arguments::check_vm_args_consistency into GCArguments.
> 
> http://cr.openjdk.java.net/~stefank/8200737/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8200737
Looks good,
StefanJ
> 
> This moves one of the usages of INCLUDE_ALL_GCS out of the runtime code 
> into GC code, which helps the code in:
> https://bugs.openjdk.java.net/browse/JDK-8200729
> 
> I've verified that the changed flags are not used between the previous 
> location and the new location.
> 
> Thanks,
> StefanK


From thomas.schatzl at oracle.com  Thu Apr  5 08:33:45 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 05 Apr 2018 10:33:45 +0200
Subject: RFR: 8200736: Move CMSGCStats to the cms directory
In-Reply-To: <ae5fae7f-70b4-0326-eaa8-62c422da3a5c@oracle.com>
References: <ae5fae7f-70b4-0326-eaa8-62c422da3a5c@oracle.com>
Message-ID: <1522917225.2395.1.camel@oracle.com>

Hi,

On Wed, 2018-04-04 at 15:26 +0200, Stefan Karlsson wrote:
> Hi all,
> 
> Please review this trivial patch to move the CMSGCStats class to the
> cms 
> directory.
> 
> http://cr.openjdk.java.net/~stefank/8200736/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8200736
> 

  looks good.

Thomas


From stefan.karlsson at oracle.com  Thu Apr  5 09:32:55 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Apr 2018 11:32:55 +0200
Subject: RFR: 8200737: Move GC code out of
 Arguments::check_vm_args_consistency into GCArguments
In-Reply-To: <fa84f661-2b1b-b09c-d85b-2706dd0ef2da@oracle.com>
References: <39139bd0-07b5-4a40-b5ae-eb8834a31e83@oracle.com>
 <fa84f661-2b1b-b09c-d85b-2706dd0ef2da@oracle.com>
Message-ID: <a241831d-9dc3-8f09-0f4e-0c9c4909e2cb@oracle.com>

Thanks, StefanJ.

StefanK

On 2018-04-05 10:16, Stefan Johansson wrote:
> Hi,
> 
> On 2018-04-04 15:42, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to move GC code out of 
>> Arguments::check_vm_args_consistency into GCArguments.
>>
>> http://cr.openjdk.java.net/~stefank/8200737/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8200737
> Looks good,
> StefanJ
>>
>> This moves one of the usages of INCLUDE_ALL_GCS out of the runtime 
>> code into GC code, which helps the code in:
>> https://bugs.openjdk.java.net/browse/JDK-8200729
>>
>> I've verified that the changed flags are not used between the previous 
>> location and the new location.
>>
>> Thanks,
>> StefanK


From stefan.karlsson at oracle.com  Thu Apr  5 09:34:16 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Apr 2018 11:34:16 +0200
Subject: RFR: 8200736: Move CMSGCStats to the cms directory
In-Reply-To: <1522917225.2395.1.camel@oracle.com>
References: <ae5fae7f-70b4-0326-eaa8-62c422da3a5c@oracle.com>
 <1522917225.2395.1.camel@oracle.com>
Message-ID: <611bcd44-1d39-e005-ff2f-d117f0974f64@oracle.com>

Thanks, Thomas.

StefanK

On 2018-04-05 10:33, Thomas Schatzl wrote:
> Hi,
> 
> On Wed, 2018-04-04 at 15:26 +0200, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this trivial patch to move the CMSGCStats class to the
>> cms
>> directory.
>>
>> http://cr.openjdk.java.net/~stefank/8200736/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8200736
>>
> 
>    looks good.
> 
> Thomas
> 


From leo.korinth at oracle.com  Thu Apr  5 11:50:58 2018
From: leo.korinth at oracle.com (Leo Korinth)
Date: Thu, 5 Apr 2018 13:50:58 +0200
Subject: RFR: 8201171: Cleanup in g1CollectedHeap, change CamelCase to
 snake_case
Message-ID: <c8327fdd-85b9-9116-a223-666a47f0cb4d@oracle.com>

Hi,

I am cleaning up code with regard to style: CamelCase to snake_case.

_cmThread -> _cm_thread
isMarkedNext(oop obj) -> is_marked_next(oop obj)

Bug:
https://bugs.openjdk.java.net/browse/JDK-8201171

Webrev:
http://cr.openjdk.java.net/~lkorinth/8201171/00/index.html

Testing:
- hs-tier1, hs-tier2

Thanks,
Leo


From stefan.johansson at oracle.com  Thu Apr  5 12:01:59 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 5 Apr 2018 14:01:59 +0200
Subject: RFR: 8201171: Cleanup in g1CollectedHeap, change CamelCase to
 snake_case
In-Reply-To: <c8327fdd-85b9-9116-a223-666a47f0cb4d@oracle.com>
References: <c8327fdd-85b9-9116-a223-666a47f0cb4d@oracle.com>
Message-ID: <35e217c5-087d-9a00-2778-2b1e6da495b3@oracle.com>

Hi,

On 2018-04-05 13:50, Leo Korinth wrote:
> Hi,
> 
> I am cleaning up code with regard to style: CamelCase to snake_case.
> 
> _cmThread -> _cm_thread
> isMarkedNext(oop obj) -> is_marked_next(oop obj)
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8201171
> 
> Webrev:
> http://cr.openjdk.java.net/~lkorinth/8201171/00/index.html
> 
Looks good!

Thanks for doing this cleanup Leo,
Stefan

> Testing:
> - hs-tier1, hs-tier2
> 
> Thanks,
> Leo


From stefan.johansson at oracle.com  Thu Apr  5 12:04:24 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 5 Apr 2018 14:04:24 +0200
Subject: RFR: 8200169: Flatten G1Allocator class hierarchy
In-Reply-To: <241196aa-4313-fe29-b199-edd4ba5d7640@oracle.com>
References: <50c3c960-8bed-29d4-edf0-e7009d969c0a@oracle.com>
 <1521820928.4147.8.camel@oracle.com>
 <241196aa-4313-fe29-b199-edd4ba5d7640@oracle.com>
Message-ID: <88dcc422-e53e-8088-8737-483c45e3c217@oracle.com>

Can I please have a second review?

Cheers,
Stefan

On 2018-03-26 10:27, Stefan Johansson wrote:
> Thanks for the review Thomas,
> Stefan
> 
> On 2018-03-23 17:02, Thomas Schatzl wrote:
>> Hi,
>>
>> On Fri, 2018-03-23 at 14:32 +0100, Stefan Johansson wrote:
>>> Hi,
>>>
>>> Please review this change to remove some unnecessary class
>>> hierarchies
>>> in G1.
>>>
>>> Links
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8200169
>>> Webrev: http://cr.openjdk.java.net/~sjohanss/8200169/00/
>>>
>>> Summary
>>> After the removal of several extension points and some other cleanups
>>> in G1, there is no longer any need for the two class hierarchies in
>>> g1Allocator.hpp. These can be flattened to only consist of two
>>> concrete classes instead.
>> ?? looks good to me.
>>
>> Thomas
>>
> 


From stefan.johansson at oracle.com  Thu Apr  5 12:05:24 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 5 Apr 2018 14:05:24 +0200
Subject: RFR: 8196071: Change G1 Full GC heap and thread sizing ergonomics
In-Reply-To: <1522059162.8723.1.camel@oracle.com>
References: <7497d3fb-044d-35f2-f02f-70ea79f0e2aa@oracle.com>
 <1522054707.2471.7.camel@oracle.com>
 <217a9dd1-5e01-d46d-7e0e-7ab79e3381fd@oracle.com>
 <1522059162.8723.1.camel@oracle.com>
Message-ID: <69ab6ed5-372e-a0bd-3e42-76c7ca435796@oracle.com>

Change looking for second reviewer.

Cheers,
Stefan

On 2018-03-26 12:12, Thomas Schatzl wrote:
> Hi,
> 
> On Mon, 2018-03-26 at 11:47 +0200, Stefan Johansson wrote:
>>
>> On 2018-03-26 10:58, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Thu, 2018-03-22 at 16:42 +0100, Stefan Johansson wrote:
>>>> Hi,
>>>>
>>>> Please review or comment on this change to let the G1 Full GC
>>>> calculate the number of worker threads.
>>>>
> [...]
>>>
>>>     looks good, although I would prefer to separate the
>>> HeapSizePerGCWorker change into a separate CR.
>>
>> Good point. Created JDK-8200228 for this and just realized I
>> probably
>> need a CSR for that as well. Here's a new webrev without the flag-
>> change:
>> http://cr.openjdk.java.net/~sjohanss/8196071/01/
> 
>    still good.
> 
> Thomas
> 


From stefan.karlsson at oracle.com  Thu Apr  5 12:02:33 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Apr 2018 14:02:33 +0200
Subject: RFR: 8201175: Move FilteringClosure::do_oop to genOopClosures.cpp
Message-ID: <daeaa0df-124a-76a4-5ed7-eaf6e52461a7@oracle.com>

Hi all,

Please review this small change to move FilteringClosure::do_oop to 
genOopClosure.cpp.

http://cr.openjdk.java.net/~stefank/8201175/webrev.01
https://bugs.openjdk.java.net/browse/JDK-8201175

The FilteringClosure class is declared in genOopClosures.hpp and 
FilteringClosure::do_oop_work and FilteringClosure::do_oop_nv is located 
in genOopClosures.inline.hpp. So, moving FilteringClosure to 
genOopClosures.cpp shouldn't cause any surprises.

Thanks,
StefanK


From thomas.schatzl at oracle.com  Thu Apr  5 12:04:50 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 05 Apr 2018 14:04:50 +0200
Subject: RFR: 8201171: Cleanup in g1CollectedHeap, change CamelCase to
 snake_case
In-Reply-To: <c8327fdd-85b9-9116-a223-666a47f0cb4d@oracle.com>
References: <c8327fdd-85b9-9116-a223-666a47f0cb4d@oracle.com>
Message-ID: <1522929890.2478.0.camel@oracle.com>

Hi,

On Thu, 2018-04-05 at 13:50 +0200, Leo Korinth wrote:
> Hi,
> 
> I am cleaning up code with regard to style: CamelCase to snake_case.
> 
> _cmThread -> _cm_thread
> isMarkedNext(oop obj) -> is_marked_next(oop obj)
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8201171
> 
> Webrev:
> http://cr.openjdk.java.net/~lkorinth/8201171/00/index.html

  looks good.

Thomas


From leo.korinth at oracle.com  Thu Apr  5 12:10:48 2018
From: leo.korinth at oracle.com (Leo Korinth)
Date: Thu, 5 Apr 2018 14:10:48 +0200
Subject: RFR: 8201171: Cleanup in g1CollectedHeap, change CamelCase to
 snake_case
In-Reply-To: <35e217c5-087d-9a00-2778-2b1e6da495b3@oracle.com>
References: <c8327fdd-85b9-9116-a223-666a47f0cb4d@oracle.com>
 <35e217c5-087d-9a00-2778-2b1e6da495b3@oracle.com>
Message-ID: <451f6faf-1abe-0200-ebdf-22c7b4b915d2@oracle.com>

Thanks for the review Stefan,
Leo

On 05/04/18 14:01, Stefan Johansson wrote:
> Hi,
> 
> On 2018-04-05 13:50, Leo Korinth wrote:
>> Hi,
>>
>> I am cleaning up code with regard to style: CamelCase to snake_case.
>>
>> _cmThread -> _cm_thread
>> isMarkedNext(oop obj) -> is_marked_next(oop obj)
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8201171
>>
>> Webrev:
>> http://cr.openjdk.java.net/~lkorinth/8201171/00/index.html
>>
> Looks good!
> 
> Thanks for doing this cleanup Leo,
> Stefan
> 
>> Testing:
>> - hs-tier1, hs-tier2
>>
>> Thanks,
>> Leo


From leo.korinth at oracle.com  Thu Apr  5 12:11:32 2018
From: leo.korinth at oracle.com (Leo Korinth)
Date: Thu, 5 Apr 2018 14:11:32 +0200
Subject: RFR: 8201171: Cleanup in g1CollectedHeap, change CamelCase to
 snake_case
In-Reply-To: <1522929890.2478.0.camel@oracle.com>
References: <c8327fdd-85b9-9116-a223-666a47f0cb4d@oracle.com>
 <1522929890.2478.0.camel@oracle.com>
Message-ID: <694c0a62-ecc1-fd18-594e-69406060ce68@oracle.com>

Thanks for the review Thomas,
Leo

On 05/04/18 14:04, Thomas Schatzl wrote:
> Hi,
> 
> On Thu, 2018-04-05 at 13:50 +0200, Leo Korinth wrote:
>> Hi,
>>
>> I am cleaning up code with regard to style: CamelCase to snake_case.
>>
>> _cmThread -> _cm_thread
>> isMarkedNext(oop obj) -> is_marked_next(oop obj)
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8201171
>>
>> Webrev:
>> http://cr.openjdk.java.net/~lkorinth/8201171/00/index.html
> 
>    looks good.
> 
> Thomas
> 


From sangheon.kim at oracle.com  Thu Apr  5 20:15:12 2018
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Thu, 5 Apr 2018 13:15:12 -0700
Subject: RFR: 8200169: Flatten G1Allocator class hierarchy
In-Reply-To: <88dcc422-e53e-8088-8737-483c45e3c217@oracle.com>
References: <50c3c960-8bed-29d4-edf0-e7009d969c0a@oracle.com>
 <1521820928.4147.8.camel@oracle.com>
 <241196aa-4313-fe29-b199-edd4ba5d7640@oracle.com>
 <88dcc422-e53e-8088-8737-483c45e3c217@oracle.com>
Message-ID: <a0a41240-9584-feeb-a1c7-72a79be4a775@oracle.com>

Hi Stefan,

On 04/05/2018 05:04 AM, Stefan Johansson wrote:
> Can I please have a second review?
>
> Cheers,
> Stefan
>
> On 2018-03-26 10:27, Stefan Johansson wrote:
>> Thanks for the review Thomas,
>> Stefan
>>
>> On 2018-03-23 17:02, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Fri, 2018-03-23 at 14:32 +0100, Stefan Johansson wrote:
>>>> Hi,
>>>>
>>>> Please review this change to remove some unnecessary class
>>>> hierarchies
>>>> in G1.
>>>>
>>>> Links
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8200169
>>>> Webrev: http://cr.openjdk.java.net/~sjohanss/8200169/00/
This looks good.

If you are interested, please update copyright year at g1Allocator.hpp 
and g1Allocator.inline.hpp.

Thanks,
Sangheon


>>>>
>>>> Summary
>>>> After the removal of several extension points and some other cleanups
>>>> in G1, there is no longer any need for the two class hierarchies in
>>>> g1Allocator.hpp. These can be flattened to only consist of two
>>>> concrete classes instead.
>>> ?? looks good to me.
>>>
>>> Thomas
>>>
>>



From stefan.karlsson at oracle.com  Thu Apr  5 20:42:56 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Apr 2018 22:42:56 +0200
Subject: RFR: 8201209: Separate out CMS specific functions into CMSCardTable
Message-ID: <20e48c95-55b0-9f39-4db0-9bd66a9ac1bb@oracle.com>

Hi all,

Please review this patch to move CMS specific CardTableRS code into a 
new CMSCardTable class.

 ?http://cr.openjdk.java.net/~stefank/8201209/webrev.01/
 ?https://bugs.openjdk.java.net/browse/JDK-8201209

Erik ? suggested that I named the class CMSCardTable instead of 
CMSCardTableRS, because CardTableRS would probably renamed in the future.

This patch makes it easier to conditionally compile out CMS in:
 ?https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional 
compilation of GCs

Thanks,
StefanK


From stefan.karlsson at oracle.com  Thu Apr  5 21:10:47 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Apr 2018 23:10:47 +0200
Subject: RFR: 8201212: Remove INCLUDE_ALL_GCS from OopStorage files
Message-ID: <e170b5b7-4019-edb3-e43d-fa3500c3d146@oracle.com>

Hi all,

Please review this patch to remove the INCLUDE_ALL_GCS checks from the 
OopStorages files.

http://cr.openjdk.java.net/~stefank/8201212/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8201212

This will make it easier to conditionally compile out GCs in JDK-8200729 
and only marginally increases the libjvm.so file. The libjvm.so file 
increase from 22031664 bytes to 22032200 bytes, when this code is added 
to the jvm.

Thanks,
StefanK


From stefan.karlsson at oracle.com  Thu Apr  5 21:21:04 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Apr 2018 23:21:04 +0200
Subject: RFR: 8201213: Remove INCLUDE_ALL_GCS from
 memset_with_concurrent_readers
Message-ID: <b9183a96-6776-8751-1a93-fc81d04ed615@oracle.com>

Hi all,

Please review this patch to remove the INCLUDE_ALL_GCS checks from 
memset_with_concurrent_readers.

http://cr.openjdk.java.net/~stefank/8201213/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8201213

This only marginally reduces the libjvm.so size, and it would be easier 
to implement JDK-820729 without it, so I propose that we remove these 
checks.

Thanks,
StefanK


From stefan.karlsson at oracle.com  Thu Apr  5 22:24:22 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 6 Apr 2018 00:24:22 +0200
Subject: RFR: 8201217: Split specialized_oop_closures.hpp into GC specific
 files
Message-ID: <831df1cc-724b-f828-49d4-e4db274e2ea1@oracle.com>

Hi all,

Please review this patch to split up the specialized_oop_closures.hpp 
file into GC specific files.

http://cr.openjdk.java.net/~stefank/8201217/webrev.01
https://bugs.openjdk.java.net/browse/JDK-8201217

Thanks,
StefanK


From kim.barrett at oracle.com  Fri Apr  6 05:13:25 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 6 Apr 2018 01:13:25 -0400
Subject: RFR: 8201212: Remove INCLUDE_ALL_GCS from OopStorage files
In-Reply-To: <e170b5b7-4019-edb3-e43d-fa3500c3d146@oracle.com>
References: <e170b5b7-4019-edb3-e43d-fa3500c3d146@oracle.com>
Message-ID: <4FF104D9-FD4B-4352-8A13-9B9E5949EAB0@oracle.com>

> On Apr 5, 2018, at 5:10 PM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
> 
> Hi all,
> 
> Please review this patch to remove the INCLUDE_ALL_GCS checks from the OopStorages files.
> 
> http://cr.openjdk.java.net/~stefank/8201212/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8201212
> 
> This will make it easier to conditionally compile out GCs in JDK-8200729 and only marginally increases the libjvm.so file. The libjvm.so file increase from 22031664 bytes to 22032200 bytes, when this code is added to the jvm.
> 
> Thanks,
> StefanK

Looks good.  And trivial.



From kim.barrett at oracle.com  Fri Apr  6 05:15:07 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 6 Apr 2018 01:15:07 -0400
Subject: RFR: 8201213: Remove INCLUDE_ALL_GCS from
 memset_with_concurrent_readers
In-Reply-To: <b9183a96-6776-8751-1a93-fc81d04ed615@oracle.com>
References: <b9183a96-6776-8751-1a93-fc81d04ed615@oracle.com>
Message-ID: <D949D896-065B-44BF-82F1-54B5D6878042@oracle.com>

> On Apr 5, 2018, at 5:21 PM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
> 
> Hi all,
> 
> Please review this patch to remove the INCLUDE_ALL_GCS checks from memset_with_concurrent_readers.
> 
> http://cr.openjdk.java.net/~stefank/8201213/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8201213
> 
> This only marginally reduces the libjvm.so size, and it would be easier to implement JDK-820729 without it, so I propose that we remove these checks.
> 
> Thanks,
> StefanK

Looks good.  And trivial.



From erik.osterlund at oracle.com  Fri Apr  6 06:59:00 2018
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Fri, 6 Apr 2018 08:59:00 +0200
Subject: RFR: 8201209: Separate out CMS specific functions into
 CMSCardTable
In-Reply-To: <20e48c95-55b0-9f39-4db0-9bd66a9ac1bb@oracle.com>
References: <20e48c95-55b0-9f39-4db0-9bd66a9ac1bb@oracle.com>
Message-ID: <183D7593-1620-4F80-A100-7E1D40D533D2@oracle.com>

Hi Stefan,

Nice! This one has been at the back of my head for a while. This looks good.

One thing though. I wonder if the CMSCardTable constructor should take that argument whether the table is scanned concurrently or not (when pre-cleaning is enabled). Perhaps that logic could be in the constructor of CMSCardTable instead. I tend to think it belongs in the constructor. It is not a strong preference though, so I will leave it as your call, and will not need another webrev.

Thanks,
/Erik

> On 5 Apr 2018, at 22:42, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
> 
> Hi all,
> 
> Please review this patch to move CMS specific CardTableRS code into a new CMSCardTable class.
> 
>  http://cr.openjdk.java.net/~stefank/8201209/webrev.01/
>  https://bugs.openjdk.java.net/browse/JDK-8201209
> 
> Erik ? suggested that I named the class CMSCardTable instead of CMSCardTableRS, because CardTableRS would probably renamed in the future.
> 
> This patch makes it easier to conditionally compile out CMS in:
>  https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional compilation of GCs
> 
> Thanks,
> StefanK



From stefan.karlsson at oracle.com  Fri Apr  6 06:59:32 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 6 Apr 2018 08:59:32 +0200
Subject: RFR: 8201212: Remove INCLUDE_ALL_GCS from OopStorage files
In-Reply-To: <4FF104D9-FD4B-4352-8A13-9B9E5949EAB0@oracle.com>
References: <e170b5b7-4019-edb3-e43d-fa3500c3d146@oracle.com>
 <4FF104D9-FD4B-4352-8A13-9B9E5949EAB0@oracle.com>
Message-ID: <f5380a18-903e-01b7-7c2d-e089708fee4f@oracle.com>

Thanks, Kim!

StefanK

On 2018-04-06 07:13, Kim Barrett wrote:
>> On Apr 5, 2018, at 5:10 PM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
>>
>> Hi all,
>>
>> Please review this patch to remove the INCLUDE_ALL_GCS checks from the OopStorages files.
>>
>> http://cr.openjdk.java.net/~stefank/8201212/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8201212
>>
>> This will make it easier to conditionally compile out GCs in JDK-8200729 and only marginally increases the libjvm.so file. The libjvm.so file increase from 22031664 bytes to 22032200 bytes, when this code is added to the jvm.
>>
>> Thanks,
>> StefanK
> 
> Looks good.  And trivial.
> 


From stefan.karlsson at oracle.com  Fri Apr  6 06:59:41 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 6 Apr 2018 08:59:41 +0200
Subject: RFR: 8201213: Remove INCLUDE_ALL_GCS from
 memset_with_concurrent_readers
In-Reply-To: <D949D896-065B-44BF-82F1-54B5D6878042@oracle.com>
References: <b9183a96-6776-8751-1a93-fc81d04ed615@oracle.com>
 <D949D896-065B-44BF-82F1-54B5D6878042@oracle.com>
Message-ID: <68a99c6a-47d9-b126-2305-1ffb63f3f395@oracle.com>

Thanks, Kim!

StefanK

On 2018-04-06 07:15, Kim Barrett wrote:
>> On Apr 5, 2018, at 5:21 PM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
>>
>> Hi all,
>>
>> Please review this patch to remove the INCLUDE_ALL_GCS checks from memset_with_concurrent_readers.
>>
>> http://cr.openjdk.java.net/~stefank/8201213/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8201213
>>
>> This only marginally reduces the libjvm.so size, and it would be easier to implement JDK-820729 without it, so I propose that we remove these checks.
>>
>> Thanks,
>> StefanK
> 
> Looks good.  And trivial.
> 


From stefan.karlsson at oracle.com  Fri Apr  6 08:59:56 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 6 Apr 2018 10:59:56 +0200
Subject: RFR: 8201209: Separate out CMS specific functions into
 CMSCardTable
In-Reply-To: <183D7593-1620-4F80-A100-7E1D40D533D2@oracle.com>
References: <20e48c95-55b0-9f39-4db0-9bd66a9ac1bb@oracle.com>
 <183D7593-1620-4F80-A100-7E1D40D533D2@oracle.com>
Message-ID: <8ba63310-b1a9-5658-dc44-ac31ad2baaa4@oracle.com>

On 2018-04-06 08:59, Erik Osterlund wrote:
> Hi Stefan,
> 
> Nice! This one has been at the back of my head for a while. This looks good.

Thanks!

> 
> One thing though. I wonder if the CMSCardTable constructor should take that argument whether the table is scanned concurrently or not (when pre-cleaning is enabled). Perhaps that logic could be in the constructor of CMSCardTable instead. I tend to think it belongs in the constructor. It is not a strong preference though, so I will leave it as your call, and will not need another webrev.
> 

Yes, this sounds good to me. Updated webrevs:

http://cr.openjdk.java.net/~stefank/8201209/webrev.02.delta
http://cr.openjdk.java.net/~stefank/8201209/webrev.02

StefanK

> Thanks,
> /Erik
> 
>> On 5 Apr 2018, at 22:42, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
>>
>> Hi all,
>>
>> Please review this patch to move CMS specific CardTableRS code into a new CMSCardTable class.
>>
>>   http://cr.openjdk.java.net/~stefank/8201209/webrev.01/
>>   https://bugs.openjdk.java.net/browse/JDK-8201209
>>
>> Erik ? suggested that I named the class CMSCardTable instead of CMSCardTableRS, because CardTableRS would probably renamed in the future.
>>
>> This patch makes it easier to conditionally compile out CMS in:
>>   https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional compilation of GCs
>>
>> Thanks,
>> StefanK
> 


From stefan.johansson at oracle.com  Fri Apr  6 14:49:54 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Fri, 6 Apr 2018 16:49:54 +0200
Subject: RFR: 8200169: Flatten G1Allocator class hierarchy
In-Reply-To: <a0a41240-9584-feeb-a1c7-72a79be4a775@oracle.com>
References: <50c3c960-8bed-29d4-edf0-e7009d969c0a@oracle.com>
 <1521820928.4147.8.camel@oracle.com>
 <241196aa-4313-fe29-b199-edd4ba5d7640@oracle.com>
 <88dcc422-e53e-8088-8737-483c45e3c217@oracle.com>
 <a0a41240-9584-feeb-a1c7-72a79be4a775@oracle.com>
Message-ID: <32d6ef66-0b1b-d3c6-ca3b-e31939e8ac76@oracle.com>



On 2018-04-05 22:15, sangheon.kim wrote:
> Hi Stefan,
> 
> On 04/05/2018 05:04 AM, Stefan Johansson wrote:
>> Can I please have a second review?
>>
>> Cheers,
>> Stefan
>>
>> On 2018-03-26 10:27, Stefan Johansson wrote:
>>> Thanks for the review Thomas,
>>> Stefan
>>>
>>> On 2018-03-23 17:02, Thomas Schatzl wrote:
>>>> Hi,
>>>>
>>>> On Fri, 2018-03-23 at 14:32 +0100, Stefan Johansson wrote:
>>>>> Hi,
>>>>>
>>>>> Please review this change to remove some unnecessary class
>>>>> hierarchies
>>>>> in G1.
>>>>>
>>>>> Links
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8200169
>>>>> Webrev: http://cr.openjdk.java.net/~sjohanss/8200169/00/
> This looks good.
> 
> If you are interested, please update copyright year at g1Allocator.hpp 
> and g1Allocator.inline.hpp.
> 
Thanks Sangheon,

I updated the copyright and pushed it.

Cheers,
Stefan

> Thanks,
> Sangheon
> 
> 
>>>>>
>>>>> Summary
>>>>> After the removal of several extension points and some other cleanups
>>>>> in G1, there is no longer any need for the two class hierarchies in
>>>>> g1Allocator.hpp. These can be flattened to only consist of two
>>>>> concrete classes instead.
>>>> ?? looks good to me.
>>>>
>>>> Thomas
>>>>
>>>
> 


From thomas.schatzl at oracle.com  Fri Apr  6 17:58:43 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 06 Apr 2018 19:58:43 +0200
Subject: RFR (S): 8200385: Eagerly reclaimed humongous objects leave
 mark in prev bitmap
In-Reply-To: <1522314727.2400.10.camel@oracle.com>
References: <1522314727.2400.10.camel@oracle.com>
Message-ID: <1523037523.11489.0.camel@oracle.com>

Hi,

  could a second person look at this please?

Thanks,
  Thomas

On Thu, 2018-03-29 at 11:12 +0200, Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews for this small fix to a benign bug, that is I
> haven't seen any actual product failure from it but some very rare
> test
> failures, where when we eagerly reclaim humongous objects we leave a
> mark on the prev bitmap in some cases?
> 
> The suggested fix is to always look at the prev bitmap and clear it,
> and if needed also clear potential marks in the next bitmap.
> 
> To make the failure appear basically 100% in that test, I added a
> simple assert after reclaiming the humongous object.
> 
> With the fix, this failure goes away completely.
> 
> Note that this is more a "data structure hygiene" fix - the stray
> mark
> on the prev bitmap will be automatically cleared after switching the
> bitmaps at cleanup and preparing that bitmap for the next mark.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8200385
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8200385/webrev/
> Testing:
> local testing with existing tests
> (gc/g1/TestEagerReclaimHumongousRegionsClearMarkBits.java)
> 
> Thanks,
>   Thomas



From thomas.schatzl at oracle.com  Fri Apr  6 17:59:23 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 06 Apr 2018 19:59:23 +0200
Subject: RFR (S/M): 8178105: Switch mark bitmaps during Remark
In-Reply-To: <1522334136.2451.15.camel@oracle.com>
References: <1522334136.2451.15.camel@oracle.com>
Message-ID: <1523037563.11489.1.camel@oracle.com>

Hi,

  ping for a second reviewer....

Thomas

On Thu, 2018-03-29 at 16:35 +0200, Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews for this small change that makes G1 switch the
> mark bitmaps already during the Remark pause as opposed waiting until
> Cleanup?
> 
> This is the last step before G1 can reclaim regions at Remark, which
> means that empty regions can be cleaned up more more quickly than
> before (JDK-8154528, coming soon :)).
> 
> The main changes apart from actually switching the bitmaps consist of
> updating the liveness information, i.e. how many bytes are live in a
> region, now already available at Remark since JDK-8197850, also at
> the
> same time.
> 
> Previously G1 used the Rebuild Remsets phase to calculate that at the
> same time.
> 
> I could not find significant differences in timing.
> 
> This change depends on the recent g1ConcurrentMark refactorings,
> particularly JDK-8200234.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8178105
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8178105/
> Testing:
> hs-tier 1-5
> 
> Thanks,
>   Thomas
> 



From thomas.schatzl at oracle.com  Fri Apr  6 19:14:16 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 06 Apr 2018 21:14:16 +0200
Subject: RFR (S): 8200233: Simple G1 evacuation path performance
 enhancements
In-Reply-To: <1522064935.8723.7.camel@oracle.com>
References: <1522064935.8723.7.camel@oracle.com>
Message-ID: <1523042056.11489.3.camel@oracle.com>

Hi,

  pinging for a second review... :)

Thomas

On Mon, 2018-03-26 at 13:48 +0200, Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews for these very tiny (and ultimately note really
> measureable) improvements to the G1 evacuation path?
> 
> They are:
> 
> - some stores can be made OOP_NOT_NULL 
> - the path for compressed/uncompressed oops when popping elements
> from
> the task queue during evacuation can be specialized: compressed oops
> are never array oops so saving the useless test
> - some load of the "from" region in the evacuation path can be
> delayed
> and in many cases actually avoided
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8200233
> 
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8200233/webrev/
> 
> Testing:
> hs-tier-1
> 
> Thanks,
>   Thomas



From kim.barrett at oracle.com  Sun Apr  8 07:31:08 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Sun, 8 Apr 2018 03:31:08 -0400
Subject: RFR (S): 8200233: Simple G1 evacuation path performance
 enhancements
In-Reply-To: <1522064935.8723.7.camel@oracle.com>
References: <1522064935.8723.7.camel@oracle.com>
Message-ID: <6AAE2487-8AB4-404F-84AB-F8B69F9F429C@oracle.com>

> On Mar 26, 2018, at 7:48 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi all,
> 
>  can I have reviews for these very tiny (and ultimately note really
> measureable) improvements to the G1 evacuation path?
> 
> They are:
> 
> - some stores can be made OOP_NOT_NULL 
> - the path for compressed/uncompressed oops when popping elements from
> the task queue during evacuation can be specialized: compressed oops
> are never array oops so saving the useless test
> - some load of the "from" region in the evacuation path can be delayed
> and in many cases actually avoided
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8200233
> 
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8200233/webrev/
> 
> Testing:
> hs-tier-1
> 
> Thanks,
>  Thomas

Looks good.



From thomas.schatzl at oracle.com  Sun Apr  8 17:23:26 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Sun, 08 Apr 2018 19:23:26 +0200
Subject: RFR (S): 8200233: Simple G1 evacuation path performance
 enhancements
In-Reply-To: <6AAE2487-8AB4-404F-84AB-F8B69F9F429C@oracle.com>
References: <1522064935.8723.7.camel@oracle.com>
 <6AAE2487-8AB4-404F-84AB-F8B69F9F429C@oracle.com>
Message-ID: <1523208206.4906.0.camel@oracle.com>

Hi Kim,

On Sun, 2018-04-08 at 03:31 -0400, Kim Barrett wrote:
> > On Mar 26, 2018, at 7:48 AM, Thomas Schatzl <thomas.schatzl at oracle.
> > com> wrote:
> > 
> > Hi all,
> > 
> >  can I have reviews for these very tiny (and ultimately note really
> > measureable) improvements to the G1 evacuation path?
> > 
> > They are:
> > 
> > [...]
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8200233/webrev/
> 
> Looks good.

  thanks for your review.

Thomas



From stefan.johansson at oracle.com  Mon Apr  9 08:46:18 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Mon, 9 Apr 2018 10:46:18 +0200
Subject: RFR: 8201209: Separate out CMS specific functions into
 CMSCardTable
In-Reply-To: <8ba63310-b1a9-5658-dc44-ac31ad2baaa4@oracle.com>
References: <20e48c95-55b0-9f39-4db0-9bd66a9ac1bb@oracle.com>
 <183D7593-1620-4F80-A100-7E1D40D533D2@oracle.com>
 <8ba63310-b1a9-5658-dc44-ac31ad2baaa4@oracle.com>
Message-ID: <45975430-3928-8551-6194-dae6dff2c1b2@oracle.com>

Hi Stefan,

On 2018-04-06 10:59, Stefan Karlsson wrote:
> On 2018-04-06 08:59, Erik Osterlund wrote:
>> Hi Stefan,
>>
>> Nice! This one has been at the back of my head for a while. This looks 
>> good.
> 
> Thanks!
> 
>>
>> One thing though. I wonder if the CMSCardTable constructor should take 
>> that argument whether the table is scanned concurrently or not (when 
>> pre-cleaning is enabled). Perhaps that logic could be in the 
>> constructor of CMSCardTable instead. I tend to think it belongs in the 
>> constructor. It is not a strong preference though, so I will leave it 
>> as your call, and will not need another webrev.
>>
> 
> Yes, this sounds good to me. Updated webrevs:
> 
> http://cr.openjdk.java.net/~stefank/8201209/webrev.02.delta
> http://cr.openjdk.java.net/~stefank/8201209/webrev.02
Looks good,
StefanJ

> 
> StefanK
> 
>> Thanks,
>> /Erik
>>
>>> On 5 Apr 2018, at 22:42, Stefan Karlsson <stefan.karlsson at oracle.com> 
>>> wrote:
>>>
>>> Hi all,
>>>
>>> Please review this patch to move CMS specific CardTableRS code into a 
>>> new CMSCardTable class.
>>>
>>> ? http://cr.openjdk.java.net/~stefank/8201209/webrev.01/
>>> ? https://bugs.openjdk.java.net/browse/JDK-8201209
>>>
>>> Erik ? suggested that I named the class CMSCardTable instead of 
>>> CMSCardTableRS, because CardTableRS would probably renamed in the 
>>> future.
>>>
>>> This patch makes it easier to conditionally compile out CMS in:
>>> ? https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional 
>>> compilation of GCs
>>>
>>> Thanks,
>>> StefanK
>>


From stefan.johansson at oracle.com  Mon Apr  9 09:08:27 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Mon, 9 Apr 2018 11:08:27 +0200
Subject: RFR: 8201175: Move FilteringClosure::do_oop to genOopClosures.cpp
In-Reply-To: <daeaa0df-124a-76a4-5ed7-eaf6e52461a7@oracle.com>
References: <daeaa0df-124a-76a4-5ed7-eaf6e52461a7@oracle.com>
Message-ID: <a28a521b-2293-e9a6-da0f-4672b5278f1a@oracle.com>

Hi Stefan,

On 2018-04-05 14:02, Stefan Karlsson wrote:
> Hi all,
> 
> Please review this small change to move FilteringClosure::do_oop to 
> genOopClosure.cpp.
> 
> http://cr.openjdk.java.net/~stefank/8201175/webrev.01
> https://bugs.openjdk.java.net/browse/JDK-8201175
> 
Looks good,
StefanJ

> The FilteringClosure class is declared in genOopClosures.hpp and 
> FilteringClosure::do_oop_work and FilteringClosure::do_oop_nv is located 
> in genOopClosures.inline.hpp. So, moving FilteringClosure to 
> genOopClosures.cpp shouldn't cause any surprises.
> 
> Thanks,
> StefanK


From thomas.schatzl at oracle.com  Mon Apr  9 09:09:51 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 09 Apr 2018 11:09:51 +0200
Subject: RFR: 8201175: Move FilteringClosure::do_oop to genOopClosures.cpp
In-Reply-To: <a28a521b-2293-e9a6-da0f-4672b5278f1a@oracle.com>
References: <daeaa0df-124a-76a4-5ed7-eaf6e52461a7@oracle.com>
 <a28a521b-2293-e9a6-da0f-4672b5278f1a@oracle.com>
Message-ID: <1523264991.4326.5.camel@oracle.com>

Hi,

On Mon, 2018-04-09 at 11:08 +0200, Stefan Johansson wrote:
> Hi Stefan,
> 
> On 2018-04-05 14:02, Stefan Karlsson wrote:
> > Hi all,
> > 
> > Please review this small change to move FilteringClosure::do_oop
> > to 
> > genOopClosure.cpp.
> > 
> > http://cr.openjdk.java.net/~stefank/8201175/webrev.01
> > https://bugs.openjdk.java.net/browse/JDK-8201175
> > 
> 
> Looks good,
> StefanJ

  same here.

Thomas



From stefan.johansson at oracle.com  Mon Apr  9 09:24:59 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Mon, 9 Apr 2018 11:24:59 +0200
Subject: RFR: 8201217: Split specialized_oop_closures.hpp into GC specific
 files
In-Reply-To: <831df1cc-724b-f828-49d4-e4db274e2ea1@oracle.com>
References: <831df1cc-724b-f828-49d4-e4db274e2ea1@oracle.com>
Message-ID: <82d15949-fb1e-9655-1b41-f81ef3f353e9@oracle.com>



On 2018-04-06 00:24, Stefan Karlsson wrote:
> Hi all,
> 
> Please review this patch to split up the specialized_oop_closures.hpp 
> file into GC specific files.
> 
> http://cr.openjdk.java.net/~stefank/8201217/webrev.01
> https://bugs.openjdk.java.net/browse/JDK-8201217
Thanks for cleaning this up, looks good!

Thanks,
Stefan

> 
> Thanks,
> StefanK


From erik.osterlund at oracle.com  Mon Apr  9 09:40:25 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Mon, 9 Apr 2018 11:40:25 +0200
Subject: RFR: 8201217: Split specialized_oop_closures.hpp into GC specific
 files
In-Reply-To: <831df1cc-724b-f828-49d4-e4db274e2ea1@oracle.com>
References: <831df1cc-724b-f828-49d4-e4db274e2ea1@oracle.com>
Message-ID: <5ACB3509.8060300@oracle.com>

Hi StefanK,

I'm guessing the SPECIALIZED_OOP_OOP_ITERATE_CLOSURES_1 vs 
SPECIALIZED_OOP_OOP_ITERATE_CLOSURES_2 distinction can be removed 
assuming that the MSVC problems that motivated their introduction is 
gone today. Same goes for how 
PromotionInfo::promoted_oops_iterate##nv_suffix is generated with 
SPECIALIZED_SINCE_SAVE_MARKS_CLOSURES_YOUNG as a workaround for the same 
problem as described in a comment in promotionInfo.cpp. But that seems 
like going beyond the intended scope of this change.

Looks good.

Thanks,
/Erik

On 2018-04-06 00:24, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to split up the specialized_oop_closures.hpp 
> file into GC specific files.
>
> http://cr.openjdk.java.net/~stefank/8201217/webrev.01
> https://bugs.openjdk.java.net/browse/JDK-8201217
>
> Thanks,
> StefanK



From thomas.schatzl at oracle.com  Mon Apr  9 11:16:51 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 09 Apr 2018 13:16:51 +0200
Subject: RFR (M): 8201172: Parallelize Remset Tracking Update Before Rebuild
 phase
Message-ID: <1523272611.4326.30.camel@oracle.com>

Hi all,

  can I have reviews for this straightforward change that improves the
"Remset Tracking Update Before Rebuild" phase of the Remark pause?

Performance of this phase has not been a big issue, with ~3000 regions
you get around 1ms of time taken, but now it's even faster and
hopefully if run with 30k regions, there are no nasty suprises (or not
as nasty at least).

Determining the number of threads to use has been done by doing a few
measurements and tests and look at which point there does not seem to
be any more scaling (i.e. the noise seems higher than the
improvements), and the pause time much smaller than a millisecond.

CR:
https://bugs.openjdk.java.net/browse/JDK-8201172
Webrev:
http://cr.openjdk.java.net/~tschatzl/8201172/webrev/
Testing:
hs-tier 1-3

Thanks,
  Thomas


From thomas.schatzl at oracle.com  Mon Apr  9 11:20:05 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 09 Apr 2018 13:20:05 +0200
Subject: RFR (M): JDK-6672778:  G1 should trim task queues more aggressively
 during evacuation pauses
Message-ID: <1523272805.4326.33.camel@oracle.com>

Hi all,

  I am happy to finally bring this, one of the oldest G1 issues we
have, to a happy ending :)

So until now G1 buffered all oop locations it encountered during root
scanning (including from remembered sets and refinement queues) in the
per-thread work queues, and only drained them at the very end of the
evacuation pause.

I am not completely sure why this has been implemented this way, but it
has serious drawbacks:
- the work queues and overflow stacks may use a lot of memory, and I
mean *a lot*
- since we buffer all oop references, the prefetching G1 does goes to
waste as G1 always prefetches (during root scan) without following up
on it, wasting memory bandwidth.

Other GC's already employ this technique, so my best guess why G1 did
not so far is that G1 needs sub-timings for the various phases to get
prediction right, and even if doing timing is cheap, doing it too often
just adds up.

Anyway, this problem has been solved by implementing a hysteresis, i.e.
start trimming the work queues at a threshold higher than ending it,
and time the length of the trimming inbetween. So the timing
measurement overhead gets distributed across many work queue
operations.
Note that I did not do much testing about the optimal hysteresis range,
the suggested guess of 2xGCDrainStackTargetSize seems to be a pretty
good value (i.e. reduces overhead well enough).

Results are pretty good: I have seen reductions of the maximum task
queue size by multiple orders of magnitudes (i.e. less memory usage
during GC), and reduction of total pause time by up to 50%,
particularly on larger applications in the few GB heap range where
quite a bit of data is copied around every gc.

But also smaller applications and applications doing less copying
benefit quite a bit, reducing pause times significantly.

Note that there is a known, actually pre-existing bug with buffering up
references (by the now obsolete and removed BufferingOopClosure): the
sum of timings for the sub-phases of ext root scan may be larger than
the printed total. This will be addressed with the follow-up JDK-
8201313 to keep this change small, and it's a pre-existing issue anyway
:P

CR:
https://bugs.openjdk.java.net/browse/JDK-6672778
Webrev:
http://cr.openjdk.java.net/~tschatzl/6672778/webrev/
Testing:
hs-tier 1-3, perf tests

Thanks,
  Thomas



From stefan.karlsson at oracle.com  Mon Apr  9 12:18:15 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 9 Apr 2018 14:18:15 +0200
Subject: RFR: 8201209: Separate out CMS specific functions into
 CMSCardTable
In-Reply-To: <45975430-3928-8551-6194-dae6dff2c1b2@oracle.com>
References: <20e48c95-55b0-9f39-4db0-9bd66a9ac1bb@oracle.com>
 <183D7593-1620-4F80-A100-7E1D40D533D2@oracle.com>
 <8ba63310-b1a9-5658-dc44-ac31ad2baaa4@oracle.com>
 <45975430-3928-8551-6194-dae6dff2c1b2@oracle.com>
Message-ID: <f52d9593-87fc-ccb9-e6d0-efb5e425c21f@oracle.com>

Thanks, StefanJ.

StefanK

On 2018-04-09 10:46, Stefan Johansson wrote:
> Hi Stefan,
> 
> On 2018-04-06 10:59, Stefan Karlsson wrote:
>> On 2018-04-06 08:59, Erik Osterlund wrote:
>>> Hi Stefan,
>>>
>>> Nice! This one has been at the back of my head for a while. This 
>>> looks good.
>>
>> Thanks!
>>
>>>
>>> One thing though. I wonder if the CMSCardTable constructor should 
>>> take that argument whether the table is scanned concurrently or not 
>>> (when pre-cleaning is enabled). Perhaps that logic could be in the 
>>> constructor of CMSCardTable instead. I tend to think it belongs in 
>>> the constructor. It is not a strong preference though, so I will 
>>> leave it as your call, and will not need another webrev.
>>>
>>
>> Yes, this sounds good to me. Updated webrevs:
>>
>> http://cr.openjdk.java.net/~stefank/8201209/webrev.02.delta
>> http://cr.openjdk.java.net/~stefank/8201209/webrev.02
> Looks good,
> StefanJ
> 
>>
>> StefanK
>>
>>> Thanks,
>>> /Erik
>>>
>>>> On 5 Apr 2018, at 22:42, Stefan Karlsson 
>>>> <stefan.karlsson at oracle.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Please review this patch to move CMS specific CardTableRS code into 
>>>> a new CMSCardTable class.
>>>>
>>>> ? http://cr.openjdk.java.net/~stefank/8201209/webrev.01/
>>>> ? https://bugs.openjdk.java.net/browse/JDK-8201209
>>>>
>>>> Erik ? suggested that I named the class CMSCardTable instead of 
>>>> CMSCardTableRS, because CardTableRS would probably renamed in the 
>>>> future.
>>>>
>>>> This patch makes it easier to conditionally compile out CMS in:
>>>> ? https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional 
>>>> compilation of GCs
>>>>
>>>> Thanks,
>>>> StefanK
>>>


From stefan.karlsson at oracle.com  Mon Apr  9 12:18:27 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 9 Apr 2018 14:18:27 +0200
Subject: RFR: 8201175: Move FilteringClosure::do_oop to genOopClosures.cpp
In-Reply-To: <a28a521b-2293-e9a6-da0f-4672b5278f1a@oracle.com>
References: <daeaa0df-124a-76a4-5ed7-eaf6e52461a7@oracle.com>
 <a28a521b-2293-e9a6-da0f-4672b5278f1a@oracle.com>
Message-ID: <28517a62-363f-afa1-74f8-4bba09c781f9@oracle.com>

Thanks, StefanJ.

StefanK

On 2018-04-09 11:08, Stefan Johansson wrote:
> Hi Stefan,
> 
> On 2018-04-05 14:02, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this small change to move FilteringClosure::do_oop to 
>> genOopClosure.cpp.
>>
>> http://cr.openjdk.java.net/~stefank/8201175/webrev.01
>> https://bugs.openjdk.java.net/browse/JDK-8201175
>>
> Looks good,
> StefanJ
> 
>> The FilteringClosure class is declared in genOopClosures.hpp and 
>> FilteringClosure::do_oop_work and FilteringClosure::do_oop_nv is 
>> located in genOopClosures.inline.hpp. So, moving FilteringClosure to 
>> genOopClosures.cpp shouldn't cause any surprises.
>>
>> Thanks,
>> StefanK


From stefan.karlsson at oracle.com  Mon Apr  9 12:18:38 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 9 Apr 2018 14:18:38 +0200
Subject: RFR: 8201175: Move FilteringClosure::do_oop to genOopClosures.cpp
In-Reply-To: <1523264991.4326.5.camel@oracle.com>
References: <daeaa0df-124a-76a4-5ed7-eaf6e52461a7@oracle.com>
 <a28a521b-2293-e9a6-da0f-4672b5278f1a@oracle.com>
 <1523264991.4326.5.camel@oracle.com>
Message-ID: <6aab0037-1831-5769-9d38-21da1f025297@oracle.com>

Thanks, Thomas.

StefanK

On 2018-04-09 11:09, Thomas Schatzl wrote:
> Hi,
> 
> On Mon, 2018-04-09 at 11:08 +0200, Stefan Johansson wrote:
>> Hi Stefan,
>>
>> On 2018-04-05 14:02, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> Please review this small change to move FilteringClosure::do_oop
>>> to
>>> genOopClosure.cpp.
>>>
>>> http://cr.openjdk.java.net/~stefank/8201175/webrev.01
>>> https://bugs.openjdk.java.net/browse/JDK-8201175
>>>
>>
>> Looks good,
>> StefanJ
> 
>    same here.
> 
> Thomas
> 


From stefan.karlsson at oracle.com  Mon Apr  9 12:19:11 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 9 Apr 2018 14:19:11 +0200
Subject: RFR: 8201217: Split specialized_oop_closures.hpp into GC specific
 files
In-Reply-To: <82d15949-fb1e-9655-1b41-f81ef3f353e9@oracle.com>
References: <831df1cc-724b-f828-49d4-e4db274e2ea1@oracle.com>
 <82d15949-fb1e-9655-1b41-f81ef3f353e9@oracle.com>
Message-ID: <d8680a73-5332-0427-4cba-d17c2a845fde@oracle.com>

Thanks, StefanJ.

StefanK

On 2018-04-09 11:24, Stefan Johansson wrote:
> 
> 
> On 2018-04-06 00:24, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to split up the specialized_oop_closures.hpp 
>> file into GC specific files.
>>
>> http://cr.openjdk.java.net/~stefank/8201217/webrev.01
>> https://bugs.openjdk.java.net/browse/JDK-8201217
> Thanks for cleaning this up, looks good!
> 
> Thanks,
> Stefan
> 
>>
>> Thanks,
>> StefanK


From stefan.karlsson at oracle.com  Mon Apr  9 12:20:32 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 9 Apr 2018 14:20:32 +0200
Subject: RFR: 8201217: Split specialized_oop_closures.hpp into GC specific
 files
In-Reply-To: <5ACB3509.8060300@oracle.com>
References: <831df1cc-724b-f828-49d4-e4db274e2ea1@oracle.com>
 <5ACB3509.8060300@oracle.com>
Message-ID: <d5022aff-4ed1-93b6-d10b-07f4d50b6a33@oracle.com>

On 2018-04-09 11:40, Erik ?sterlund wrote:
> Hi StefanK,
> 
> I'm guessing the SPECIALIZED_OOP_OOP_ITERATE_CLOSURES_1 vs 
> SPECIALIZED_OOP_OOP_ITERATE_CLOSURES_2 distinction can be removed 
> assuming that the MSVC problems that motivated their introduction is 
> gone today. Same goes for how 
> PromotionInfo::promoted_oops_iterate##nv_suffix is generated with 
> SPECIALIZED_SINCE_SAVE_MARKS_CLOSURES_YOUNG as a workaround for the same 
> problem as described in a comment in promotionInfo.cpp. But that seems 
> like going beyond the intended scope of this change.

Yes, I agree. We should clean that up. I'll take care of this in a 
separate RFE.

> 
> Looks good.

Thanks.

StefanK

> 
> Thanks,
> /Erik
> 
> On 2018-04-06 00:24, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to split up the specialized_oop_closures.hpp 
>> file into GC specific files.
>>
>> http://cr.openjdk.java.net/~stefank/8201217/webrev.01
>> https://bugs.openjdk.java.net/browse/JDK-8201217
>>
>> Thanks,
>> StefanK
> 


From sangheon.kim at oracle.com  Mon Apr  9 16:32:04 2018
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Mon, 9 Apr 2018 09:32:04 -0700
Subject: RFR (S): 8200385: Eagerly reclaimed humongous objects leave mark
 in prev bitmap
In-Reply-To: <1523037523.11489.0.camel@oracle.com>
References: <1522314727.2400.10.camel@oracle.com>
 <1523037523.11489.0.camel@oracle.com>
Message-ID: <9b641916-5074-e7e2-2fb6-dabbfadd30ad@oracle.com>

Hi Thomas,

On 04/06/2018 10:58 AM, Thomas Schatzl wrote:
> Hi,
>
>    could a second person look at this please?
>
> Thanks,
>    Thomas
>
> On Thu, 2018-03-29 at 11:12 +0200, Thomas Schatzl wrote:
>> Hi all,
>>
>>    can I have reviews for this small fix to a benign bug, that is I
>> haven't seen any actual product failure from it but some very rare
>> test
>> failures, where when we eagerly reclaim humongous objects we leave a
>> mark on the prev bitmap in some cases?
>>
>> The suggested fix is to always look at the prev bitmap and clear it,
>> and if needed also clear potential marks in the next bitmap.
>>
>> To make the failure appear basically 100% in that test, I added a
>> simple assert after reclaiming the humongous object.
>>
>> With the fix, this failure goes away completely.
>>
>> Note that this is more a "data structure hygiene" fix - the stray
>> mark
>> on the prev bitmap will be automatically cleared after switching the
>> bitmaps at cleanup and preparing that bitmap for the next mark.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8200385
>> Webrev:
>> http://cr.openjdk.java.net/~tschatzl/8200385/webrev/
Webrev.1 looks good.

Thanks,
Sangheon


>> Testing:
>> local testing with existing tests
>> (gc/g1/TestEagerReclaimHumongousRegionsClearMarkBits.java)
>>
>> Thanks,
>>    Thomas



From thomas.schatzl at oracle.com  Mon Apr  9 17:23:37 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 09 Apr 2018 19:23:37 +0200
Subject: RFR (S): 8200385: Eagerly reclaimed humongous objects leave
 mark in prev bitmap
In-Reply-To: <9b641916-5074-e7e2-2fb6-dabbfadd30ad@oracle.com>
References: <1522314727.2400.10.camel@oracle.com>
 <1523037523.11489.0.camel@oracle.com>
 <9b641916-5074-e7e2-2fb6-dabbfadd30ad@oracle.com>
Message-ID: <1523294617.2278.0.camel@oracle.com>

Hi Sangheon,

On Mon, 2018-04-09 at 09:32 -0700, sangheon.kim wrote:
> Hi Thomas,
> 
> On 04/06/2018 10:58 AM, Thomas Schatzl wrote:
> > Hi,
> > 
> >    could a second person look at this please?
> > 
> > Thanks,
> >    Thomas
> > 
> > On Thu, 2018-03-29 at 11:12 +0200, Thomas Schatzl wrote:
> > > Hi all,
> > > 
> > >    can I have reviews for this small fix to a benign bug, that is
> > > I
> > > haven't seen any actual product failure from it but some very
> > > rare
> > > test
> > > failures, where when we eagerly reclaim humongous objects we
> > > leave a
> > > mark on the prev bitmap in some cases?
> > > 
> > > The suggested fix is to always look at the prev bitmap and clear
> > > it,
> > > and if needed also clear potential marks in the next bitmap.
> > > 
> > > To make the failure appear basically 100% in that test, I added a
> > > simple assert after reclaiming the humongous object.
> > > 
> > > With the fix, this failure goes away completely.
> > > 
> > > Note that this is more a "data structure hygiene" fix - the stray
> > > mark
> > > on the prev bitmap will be automatically cleared after switching
> > > the
> > > bitmaps at cleanup and preparing that bitmap for the next mark.
> > > 
> > > CR:
> > > https://bugs.openjdk.java.net/browse/JDK-8200385
> > > Webrev:
> > > http://cr.openjdk.java.net/~tschatzl/8200385/webrev/
> 
> Webrev.1 looks good.
> 

  thank you for your review.

Thomas



From jcbeyler at google.com  Mon Apr  9 17:24:07 2018
From: jcbeyler at google.com (JC Beyler)
Date: Mon, 09 Apr 2018 17:24:07 +0000
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
 current_end
Message-ID: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>

Hi all,

Small pre-amble to this request:
In my work to try to get a heap sampler in OpenJDK (via JEP 331
<https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm trying to reduce
the footprint of my change so that the integration can be easier. I was
told that generally a JEP webrev should be feature complete and go in
at-once. However, with the change touching quite a bit of various code
pieces, I was trying to figure out what could be separated as not "part of
the feature".

I asked around and said that perhaps a solution would be to cut up the
renaming of TLAB's end field that I do in that webrev. Because I'm renaming
a field in TLAB used by various backends for that work, I have to update
every architecture dependent code to reflect it.

I entirely understand that perhaps this is not in the habits and very
potentially might not be the way things are generally done. If so, I
apologize and let me know if you would not want this to go in separately :)

Final note: there is still a chance JEP-331 does not go in. If it does not,
we can leave the new name in place or I'll happily revert it. I can even
create an issue to track this if that makes it easier for all.

End of the pre-amble.


The 33-line change webrev in question is here:
http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/

I fixed all the architectures and JVMCI and ran a few sanity tests to
ensure I had not missed anything.

Thanks for your help and I hope this is not too much trouble,
Jc

Ps: there is a graal change that needs to happen but I was not sure
who/where to ask about it. I was told it could happen in a separate webrev.
Can anyone point me to the right direction? Should it just be
hotspot-compiler-dev?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180409/4a6010b4/attachment.htm>

From karen.kinnear at oracle.com  Mon Apr  9 20:16:34 2018
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Mon, 9 Apr 2018 16:16:34 -0400
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
 current_end
In-Reply-To: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
Message-ID: <4D77DBA1-CB54-4E1D-BD6A-8530B2138C52@oracle.com>

JC,

So I am the one who suggested that you ask the GC folks if they were ok with name change going in in advance,
since the merging includes a number of files in a rapidly changing repository. Thank you for pointing out the risks.

I am going to assume that this is a review for the approach, not the final source code review because:
- I do not see the full set of tests run - which you would coordinate with your sponsor

If the GC team is ok with the approach and you have all the tests passing - please send the actual code review request to
hotspot-dev at openjdk.java.net. We use the team aliases for design consulting. We use the larger alias before anything goes in.

See below ...

> On Apr 9, 2018, at 1:24 PM, JC Beyler <jcbeyler at google.com> wrote:
> 
> Hi all,
> 
> Small pre-amble to this request:
> In my work to try to get a heap sampler in OpenJDK (via JEP 331 <https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm trying to reduce the footprint of my change so that the integration can be easier. I was told that generally a JEP webrev should be feature complete and go in at-once. However, with the change touching quite a bit of various code pieces, I was trying to figure out what could be separated as not "part of the feature".
> 
> I asked around and said that perhaps a solution would be to cut up the renaming of TLAB's end field that I do in that webrev. Because I'm renaming a field in TLAB used by various backends for that work, I have to update every architecture dependent code to reflect it.
> 
> I entirely understand that perhaps this is not in the habits and very potentially might not be the way things are generally done. If so, I apologize and let me know if you would not want this to go in separately :)
> 
> Final note: there is still a chance JEP-331 does not go in. If it does not, we can leave the new name in place or I'll happily revert it. I can even create an issue to track this if that makes it easier for all.
> 
> End of the pre-amble.
> 
> 
> The 33-line change webrev in question is here:
> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/ <http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/>
> 
> I fixed all the architectures and JVMCI and ran a few sanity tests to ensure I had not missed anything.
> 
> Thanks for your help and I hope this is not too much trouble,
> Jc
> 
> Ps: there is a graal change that needs to happen but I was not sure who/where to ask about it. I was told it could happen in a separate webrev. Can anyone point me to the right direction? Should it just be hotspot-compiler-dev?
Can I assume the graal change is not related to 8201326, but part of the 8171119 heap sampler collection email thread? That already
includes the compiler team, so you should be set there.

thanks,
Karen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180409/22de2ccf/attachment.htm>

From alexander.harlap at oracle.com  Mon Apr  9 20:24:01 2018
From: alexander.harlap at oracle.com (Alexander Harlap)
Date: Mon, 9 Apr 2018 16:24:01 -0400
Subject: Review request for trivial change - 8201330: Add
 java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java to the
 ProblemList
Message-ID: <13a5d42b-b520-4134-a9dd-85aff70f2c00@oracle.com>

Please review trivial change:

Bug: JDK-8201330 <https://bugs.openjdk.java.net/browse/JDK-8201330>

Related/blocking bug: JDK-8081652 
<https://bugs.openjdk.java.net/browse/JDK-8081652>

webrev: http://cr.openjdk.java.net/~aharlap/8201330/webrev.00/

Thanks,

Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180409/70497d42/attachment.htm>

From jcbeyler at google.com  Mon Apr  9 20:57:47 2018
From: jcbeyler at google.com (JC Beyler)
Date: Mon, 09 Apr 2018 20:57:47 +0000
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
 current_end
In-Reply-To: <4D77DBA1-CB54-4E1D-BD6A-8530B2138C52@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
 <4D77DBA1-CB54-4E1D-BD6A-8530B2138C52@oracle.com>
Message-ID: <CAF9BGBwFBw=PUDaXCqN=bGcZg4kuci9t5aHz5o8x417JAZyYWA@mail.gmail.com>

Hi Karen,

Fair enough and thanks for your help :) First time I ask for a GC change :)

So exactly: this is not a final review at all. I provide the webrev so
people can see what it looks like and that there is no confusion. Here are
some additional points:

- It really is not the final review since as you say, last time I had a
change that modified various architectures, I got help from different
people to do the testing on the different architectures that were affected.

- To answer the graal question, technically there are two graal changes
required:
   - A first one is due to this change, where the field name change will be
needed to be done on the graal side; and that is relevant to this change
8201326
   - Second is the fact Graal still does a FastTlabRefill and should not;
that is related to graal change 8171119; I had opened GRAAL-64
<https://bugs.openjdk.java.net/browse/GRAAL-64?filter=-1> for that change

So therefore, the question becomes a two-parter:
  - Would someone be willing to sponsor this change for me and help with
the tests?
  - Would that person and/or others able to perform the testing for the
various architectures want to help run a set of tests on the change?

Then, if people do agree to the design of the change and I can get a
sponsor, I can move this after initial testing (or after full testing) to
the main hotspot-dev email list.

Thanks again for all your help!
Jc


On Mon, Apr 9, 2018 at 1:16 PM Karen Kinnear <karen.kinnear at oracle.com>
wrote:

> JC,
>
> So I am the one who suggested that you ask the GC folks if they were ok
> with name change going in in advance,
> since the merging includes a number of files in a rapidly changing
> repository. Thank you for pointing out the risks.
>
> I am going to assume that this is a review for the approach, not the final
> source code review because:
> - I do not see the full set of tests run - which you would coordinate with
> your sponsor
>
> If the GC team is ok with the approach and you have all the tests passing
> - please send the actual code review request to
> hotspot-dev at openjdk.java.net. We use the team aliases for design
> consulting. We use the larger alias before anything goes in.
>
> See below ...
>
> On Apr 9, 2018, at 1:24 PM, JC Beyler <jcbeyler at google.com> wrote:
>
> Hi all,
>
> Small pre-amble to this request:
> In my work to try to get a heap sampler in OpenJDK (via JEP 331
> <https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm trying to reduce
> the footprint of my change so that the integration can be easier. I was
> told that generally a JEP webrev should be feature complete and go in
> at-once. However, with the change touching quite a bit of various code
> pieces, I was trying to figure out what could be separated as not "part of
> the feature".
>
> I asked around and said that perhaps a solution would be to cut up the
> renaming of TLAB's end field that I do in that webrev. Because I'm renaming
> a field in TLAB used by various backends for that work, I have to update
> every architecture dependent code to reflect it.
>
> I entirely understand that perhaps this is not in the habits and very
> potentially might not be the way things are generally done. If so, I
> apologize and let me know if you would not want this to go in separately :)
>
> Final note: there is still a chance JEP-331 does not go in. If it does
> not, we can leave the new name in place or I'll happily revert it. I can
> even create an issue to track this if that makes it easier for all.
>
> End of the pre-amble.
>
>
> The 33-line change webrev in question is here:
> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>
> I fixed all the architectures and JVMCI and ran a few sanity tests to
> ensure I had not missed anything.
>
> Thanks for your help and I hope this is not too much trouble,
> Jc
>
> Ps: there is a graal change that needs to happen but I was not sure
> who/where <https://teams.googleplex.com/u/where> to ask about it. I was
> told it could happen in a separate webrev. Can anyone point me to the right
> direction? Should it just be hotspot-compiler-dev?
>
> Can I assume the graal change is not related to 8201326, but part of the
> 8171119 heap sampler collection email thread? That already
> includes the compiler team, so you should be set there.
>
> thanks,
> Karen
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180409/a50d7976/attachment.htm>

From stefan.johansson at oracle.com  Tue Apr 10 11:04:01 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 10 Apr 2018 13:04:01 +0200
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
 current_end
In-Reply-To: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
Message-ID: <fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>

Hi JC,

I realize that the names have been discussed before but I'm leaning 
towards suggesting something new. We discussed this briefly here in the 
office and others might have different opinions. One point that came up 
is that if we do this change and change all usages of 
JavaThread::tlab_end_offset() it would be good to make sure the new name 
is good. To us _current_end is not very descriptive, but naming is hard 
and the best we could come up with is _fast_path_end which would give 
the code:
   cmpptr(end, Address(thread, JavaThread::tlab_fast_path_end_offset()));
   jcc(Assembler::above, slow_case);

I think this reads pretty good and is fairly clear. If we do this rename 
I think you can re-use _end in JEP-331 instead of calling it 
_allocation_end. But that is a later review :)

Also, is there a good reason for renaming hard_end() to reserved_end()?

One additional thing, you need to update the SA to reflect this change. 
I think the only place you need to fix is in:
src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java

Thanks,
Stefan

On 2018-04-09 19:24, JC Beyler wrote:
> Hi all,
> 
> Small pre-amble to this request:
> In my work to try to get a heap sampler in OpenJDK (via JEP 331 
> <https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm trying to 
> reduce the footprint of my change so that the integration can be easier. 
> I was told that generally a JEP webrev should be feature complete and go 
> in at-once. However, with the change touching quite a bit of various 
> code pieces, I was trying to figure out what could be separated as not 
> "part of the feature".
> 
> I asked around and said that perhaps a solution would be to cut up the 
> renaming of TLAB's end field that I do in that webrev. Because I'm 
> renaming a field in TLAB used by various backends for that work, I have 
> to update every architecture dependent code to reflect it.
> 
> I entirely understand that perhaps this is not in the habits and very 
> potentially might not be the way things are generally done. If so, I 
> apologize and let me know if you would not want this to go in separately :)
> 
> Final note: there is still a chance JEP-331 does not go in. If it does 
> not, we can leave the new name in place or I'll happily revert it. I can 
> even create an issue to track this if that makes it easier for all.
> 
> End of the pre-amble.
> 
> 
> The 33-line change webrev in question is here:
> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
> 
> I fixed all the architectures and JVMCI and ran a few sanity tests to 
> ensure I had not missed anything.
> 
> Thanks for your help and I hope this is not too much trouble,
> Jc
> 
> Ps: there is a graal change that needs to happen but I was not sure 
> who/where to ask about it. I was told it could happen in a separate 
> webrev. Can anyone point me to the right direction? Should it just be 
> hotspot-compiler-dev?


From per.liden at oracle.com  Tue Apr 10 11:05:20 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 10 Apr 2018 13:05:20 +0200
Subject: RFR: 8201316: Move G1-related static members from JavaThread to
 G1BarrierSet
Message-ID: <e389f349-6766-9a85-1ed6-6e5d03aeef6d@oracle.com>

As part of the effort to make GCs more pluggable, the G1-specific data 
in JavaThread should be moved out into a more appropriate abstraction.

The first step is to move G1's static members (_satb_mark_queue_set and 
_dirty_card_queue_set) from JavaThread to the G1BarrierSet.

This will be followed up by JDK-8201318, which is a more complex change, 
to remove the non-static G1 members in JavaThread.

Bug: https://bugs.openjdk.java.net/browse/JDK-8201316
Webrev: http://cr.openjdk.java.net/~pliden/8201316/webrev.0

/Per


From shade at redhat.com  Tue Apr 10 11:19:57 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 10 Apr 2018 13:19:57 +0200
Subject: RFR: 8201316: Move G1-related static members from JavaThread to
 G1BarrierSet
In-Reply-To: <e389f349-6766-9a85-1ed6-6e5d03aeef6d@oracle.com>
References: <e389f349-6766-9a85-1ed6-6e5d03aeef6d@oracle.com>
Message-ID: <d4ef4675-9bb7-540a-2f7c-4f1bde28ba68@redhat.com>

On 04/10/2018 01:05 PM, Per Liden wrote:
> As part of the effort to make GCs more pluggable, the G1-specific data in JavaThread should be moved
> out into a more appropriate abstraction.
> 
> The first step is to move G1's static members (_satb_mark_queue_set and _dirty_card_queue_set) from
> JavaThread to the G1BarrierSet.
> 
> This will be followed up by JDK-8201318, which is a more complex change, to remove the non-static G1
> members in JavaThread.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201316
> Webrev: http://cr.openjdk.java.net/~pliden/8201316/webrev.0

I actually think we should instead move SATB machinery into gc/shared (Shenandoah uses it!), and
leave these static members in the JavaThread.

See:
  https://bugs.openjdk.java.net/browse/JDK-8154343

-Aleksey


From stefan.karlsson at oracle.com  Tue Apr 10 11:35:44 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 10 Apr 2018 13:35:44 +0200
Subject: RFR: 8201316: Move G1-related static members from JavaThread to
 G1BarrierSet
In-Reply-To: <e389f349-6766-9a85-1ed6-6e5d03aeef6d@oracle.com>
References: <e389f349-6766-9a85-1ed6-6e5d03aeef6d@oracle.com>
Message-ID: <965f7cb5-7f55-b6f6-8b74-e25778bf9002@oracle.com>

Looks good.

StefanK

On 2018-04-10 13:05, Per Liden wrote:
> As part of the effort to make GCs more pluggable, the G1-specific data 
> in JavaThread should be moved out into a more appropriate abstraction.
> 
> The first step is to move G1's static members (_satb_mark_queue_set and 
> _dirty_card_queue_set) from JavaThread to the G1BarrierSet.
> 
> This will be followed up by JDK-8201318, which is a more complex change, 
> to remove the non-static G1 members in JavaThread.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201316
> Webrev: http://cr.openjdk.java.net/~pliden/8201316/webrev.0
> 
> /Per


From stefan.johansson at oracle.com  Tue Apr 10 11:43:54 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 10 Apr 2018 13:43:54 +0200
Subject: RFR: 8200228: Change default value of HeapSizePerGCThread
In-Reply-To: <05493def-e244-8710-04e0-cbb70a40f3f2@oracle.com>
References: <2690ce00-921f-9310-648f-69fd41afca19@oracle.com>
 <05493def-e244-8710-04e0-cbb70a40f3f2@oracle.com>
Message-ID: <493ded08-ee06-595f-5934-0383fbd4574c@oracle.com>

CSR is now approved. Do I need a second reviewer for this default value 
change?

Stefan

On 2018-03-29 10:52, Stefan Johansson wrote:
> I've now created a CSR as well:
> https://bugs.openjdk.java.net/browse/JDK-8200417
> 
> Please have a look at it and add yourself as a reviewer if everything 
> looks good.
> 
> Thanks,
> Stefan
> 
> On 2018-03-28 15:52, Stefan Johansson wrote:
>> Hi,
>>
>> Please review this change of the default value for HeapSizePerGCThread.
>>
>> Links
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8200228
>> Webrev: http://cr.openjdk.java.net/~sjohanss/8200228/00/
>>
>> Summary
>> My testing shows that for DaCapo, SpecJVM98 and GCBasher (gc intensive 
>> stress test) with small heaps we get better pause times with the flag 
>> set to 32M. There might be other arguments, such as not using to much 
>> resources on small systems that might also be important so please let 
>> me know if you have reasons why the flag should be left unchanged.
>>
>> Thanks,
>> Stefan
>>
> 


From per.liden at oracle.com  Tue Apr 10 12:09:55 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 10 Apr 2018 14:09:55 +0200
Subject: RFR: 8201316: Move G1-related static members from JavaThread to
 G1BarrierSet
In-Reply-To: <d4ef4675-9bb7-540a-2f7c-4f1bde28ba68@redhat.com>
References: <e389f349-6766-9a85-1ed6-6e5d03aeef6d@oracle.com>
 <d4ef4675-9bb7-540a-2f7c-4f1bde28ba68@redhat.com>
Message-ID: <3b8408bf-8001-19f6-250e-50e25b887d25@oracle.com>

Hi Aleksey,

On 04/10/2018 01:19 PM, Aleksey Shipilev wrote:
> On 04/10/2018 01:05 PM, Per Liden wrote:
>> As part of the effort to make GCs more pluggable, the G1-specific data in JavaThread should be moved
>> out into a more appropriate abstraction.
>>
>> The first step is to move G1's static members (_satb_mark_queue_set and _dirty_card_queue_set) from
>> JavaThread to the G1BarrierSet.
>>
>> This will be followed up by JDK-8201318, which is a more complex change, to remove the non-static G1
>> members in JavaThread.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201316
>> Webrev: http://cr.openjdk.java.net/~pliden/8201316/webrev.0
> 
> I actually think we should instead move SATB machinery into gc/shared (Shenandoah uses it!), and
> leave these static members in the JavaThread.

I agree, and I don't think this change stops you from working towards 
that goal. As you know, we're working towards having more appropriate 
abstractions to make GCs more pluggable, which this RFE and the followup 
change JDK-8201318 (sent to hotspot-dev) is trying to address.

With the G1-specific stuff is cleaned out from JavaThread, I think it 
will be easier for you to see what G1-dependencies you really have in 
Shenandoah, and start work to break those dependencies or move code to 
gc/shared if needed.

/Per

> 
> See:
>    https://bugs.openjdk.java.net/browse/JDK-8154343
> 
> -Aleksey
> 


From thomas.schatzl at oracle.com  Tue Apr 10 12:26:01 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 10 Apr 2018 14:26:01 +0200
Subject: RFR (XS): 8201365: Remove G1Policy::should_process_references()
Message-ID: <1523363161.2373.3.camel@oracle.com>

Hi all,

  can I have reviews for the following trivial change that removes some
obsolete functionality, in this case, the ability to not do reference
processing during gc?

(Actually it is not possible to not do reference processing since
G1Policy::should_do_reference_processing() is not virtual anyway).

CR:
https://bugs.openjdk.java.net/browse/JDK-8201365
Webrev:
http://cr.openjdk.java.net/~tschatzl/8201365/webrev/
Testing:
local compilation

Thanks,
  Thomas



From stefan.johansson at oracle.com  Tue Apr 10 12:29:56 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 10 Apr 2018 14:29:56 +0200
Subject: RFR (M): 8201172: Parallelize Remset Tracking Update Before
 Rebuild phase
In-Reply-To: <1523272611.4326.30.camel@oracle.com>
References: <1523272611.4326.30.camel@oracle.com>
Message-ID: <f0f0d1e2-be9f-e0b7-a8ed-af145464f8f0@oracle.com>

Hi Thomas,

On 2018-04-09 13:16, Thomas Schatzl wrote:
> Hi all,
> 
>    can I have reviews for this straightforward change that improves the
> "Remset Tracking Update Before Rebuild" phase of the Remark pause?
> 
> Performance of this phase has not been a big issue, with ~3000 regions
> you get around 1ms of time taken, but now it's even faster and
> hopefully if run with 30k regions, there are no nasty suprises (or not
> as nasty at least).
> 
> Determining the number of threads to use has been done by doing a few
> measurements and tests and look at which point there does not seem to
> be any more scaling (i.e. the noise seems higher than the
> improvements), and the pause time much smaller than a millisecond.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8201172
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8201172/webrev/
Looks good, just a few minor things:
src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
1108     G1UpdateRemSetTrackingBeforeRebuild cl(_g1h, _cm, &_cl);
1109     _g1h->heap_region_par_iterate_from_worker_offset(&cl, 
&_hrclaimer, worker_id);
1110     Atomic::add(cl.num_selected_for_rebuild(), 
&_num_selected_for_rebuild);

Using the same names for all closures and and having 
num_selected_for_rebuild in both the task and the closure, makes this 
code a bit hard to follow. I suggest calling the task member 
_total_selected_for_rebuild and also have the getter name match the 
member for the closure.

For the closures I'm fine with the members being named _cl, but it would 
help if the instance above were name something else, like rebuild.
-----

Thanks,
Stefan

> Testing:
> hs-tier 1-3
> 
> Thanks,
>    Thomas
> 


From jesper.wilhelmsson at oracle.com  Tue Apr 10 13:15:56 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Tue, 10 Apr 2018 15:15:56 +0200
Subject: RFR: 8200228: Change default value of HeapSizePerGCThread
In-Reply-To: <493ded08-ee06-595f-5934-0383fbd4574c@oracle.com>
References: <2690ce00-921f-9310-648f-69fd41afca19@oracle.com>
 <05493def-e244-8710-04e0-cbb70a40f3f2@oracle.com>
 <493ded08-ee06-595f-5934-0383fbd4574c@oracle.com>
Message-ID: <E9780B47-F1BF-4303-876D-D9094FDA5B5F@oracle.com>

Looks good to me.
/Jesper

> On 10 Apr 2018, at 13:43, Stefan Johansson <stefan.johansson at oracle.com> wrote:
> 
> CSR is now approved. Do I need a second reviewer for this default value change?
> 
> Stefan
> 
> On 2018-03-29 10:52, Stefan Johansson wrote:
>> I've now created a CSR as well:
>> https://bugs.openjdk.java.net/browse/JDK-8200417
>> Please have a look at it and add yourself as a reviewer if everything looks good.
>> Thanks,
>> Stefan
>> On 2018-03-28 15:52, Stefan Johansson wrote:
>>> Hi,
>>> 
>>> Please review this change of the default value for HeapSizePerGCThread.
>>> 
>>> Links
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8200228
>>> Webrev: http://cr.openjdk.java.net/~sjohanss/8200228/00/
>>> 
>>> Summary
>>> My testing shows that for DaCapo, SpecJVM98 and GCBasher (gc intensive stress test) with small heaps we get better pause times with the flag set to 32M. There might be other arguments, such as not using to much resources on small systems that might also be important so please let me know if you have reasons why the flag should be left unchanged.
>>> 
>>> Thanks,
>>> Stefan
>>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180410/0b76e599/signature.asc>

From shade at redhat.com  Tue Apr 10 13:18:34 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 10 Apr 2018 15:18:34 +0200
Subject: RFR: 8200228: Change default value of HeapSizePerGCThread
In-Reply-To: <493ded08-ee06-595f-5934-0383fbd4574c@oracle.com>
References: <2690ce00-921f-9310-648f-69fd41afca19@oracle.com>
 <05493def-e244-8710-04e0-cbb70a40f3f2@oracle.com>
 <493ded08-ee06-595f-5934-0383fbd4574c@oracle.com>
Message-ID: <f5d33b01-88f9-45f8-00de-d2b13b7bb010@redhat.com>

This change is fine with me. Count me as Reviewer.

-Aleksey

On 04/10/2018 01:43 PM, Stefan Johansson wrote:
> CSR is now approved. Do I need a second reviewer for this default value change?
> 
> Stefan
> 
> On 2018-03-29 10:52, Stefan Johansson wrote:
>> I've now created a CSR as well:
>> https://bugs.openjdk.java.net/browse/JDK-8200417
>>
>> Please have a look at it and add yourself as a reviewer if everything looks good.
>>
>> Thanks,
>> Stefan
>>
>> On 2018-03-28 15:52, Stefan Johansson wrote:
>>> Hi,
>>>
>>> Please review this change of the default value for HeapSizePerGCThread.
>>>
>>> Links
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8200228
>>> Webrev: http://cr.openjdk.java.net/~sjohanss/8200228/00/
>>>
>>> Summary
>>> My testing shows that for DaCapo, SpecJVM98 and GCBasher (gc intensive stress test) with small
>>> heaps we get better pause times with the flag set to 32M. There might be other arguments, such as
>>> not using to much resources on small systems that might also be important so please let me know
>>> if you have reasons why the flag should be left unchanged.
>>>
>>> Thanks,
>>> Stefan
>>>
>>



From shade at redhat.com  Tue Apr 10 13:31:13 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 10 Apr 2018 15:31:13 +0200
Subject: RFR (XS): 8201365: Remove G1Policy::should_process_references()
In-Reply-To: <1523363161.2373.3.camel@oracle.com>
References: <1523363161.2373.3.camel@oracle.com>
Message-ID: <53ff6128-f5af-6a91-cce9-0afe9758bff9@redhat.com>

On 04/10/2018 02:26 PM, Thomas Schatzl wrote:
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8201365
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8201365/webrev/

Patch looks good.

But, don't you actually want to control refprocessing, especially when pause times are concerned?

Thanks,
-Aleksey


From karen.kinnear at oracle.com  Tue Apr 10 13:56:22 2018
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Tue, 10 Apr 2018 09:56:22 -0400
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
 current_end
In-Reply-To: <fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
 <fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
Message-ID: <3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>

Hi JC,

A comment about Graal. The impact on Graal for this particular change would be to break it - so you?ll need
to complete the Graal changes for this renaming. That isn?t optional or something that could be a follow-on. It
is not ok to break a feature, even an experimental one. We will discuss in the other thread potential phasing of adding sampling.

I did not do a thorough search -you can do that - I did find 
src/jdk.internal.vm.compiler/share/classes/
org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:    public final int threadTlabOffset = getFieldOffset("Thread::_tlab", Integer.class, "ThreadLocalAllocBuffer");
org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:    private final int threadLocalAllocBufferStartOffset = getFieldOffset("ThreadLocalAllocBuffer::_start", Integer.class, "HeapWord*");
org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:    private final int threadLocalAllocBufferEndOffset = getFieldOffset("ThreadLocalAllocBuffer::_end", Integer.class, "HeapWord*");
org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:    private final int threadLocalAllocBufferTopOffset = getFieldOffset("ThreadLocalAllocBuffer::_top", Integer.class, "HeapWord*");
org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:    private final int threadLocalAllocBufferPfTopOffset = getFieldOffset("ThreadLocalAllocBuffer::_pf_top", Integer.class, "HeapWord*");
org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:    private final int threadLocalAllocBufferSlowAllocationsOffset = getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations", Integer.class, "unsigned");
org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:    private final int threadLocalAllocBufferFastRefillWasteOffset = getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste", Integer.class, "unsigned");
org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:    private final int threadLocalAllocBufferNumberOfRefillsOffset = getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills", Integer.class, "unsigned");
org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:    private final int threadLocalAllocBufferRefillWasteLimitOffset = getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit", Integer.class, "size_t");
org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:    private final int threadLocalAllocBufferDesiredSizeOffset = getFieldOffset("ThreadLocalAllocBuffer::_desired_size", Integer.class, "size_t");
org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:    public final int tlabAlignmentReserve = getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve", Integer.class, "size_t?);

hope this helps,
Karen

> On Apr 10, 2018, at 7:04 AM, Stefan Johansson <stefan.johansson at oracle.com> wrote:
> 
> Hi JC,
> 
> I realize that the names have been discussed before but I'm leaning towards suggesting something new. We discussed this briefly here in the office and others might have different opinions. One point that came up is that if we do this change and change all usages of JavaThread::tlab_end_offset() it would be good to make sure the new name is good. To us _current_end is not very descriptive, but naming is hard and the best we could come up with is _fast_path_end which would give the code:
>  cmpptr(end, Address(thread, JavaThread::tlab_fast_path_end_offset()));
>  jcc(Assembler::above, slow_case);
> 
> I think this reads pretty good and is fairly clear. If we do this rename I think you can re-use _end in JEP-331 instead of calling it _allocation_end. But that is a later review :)
> 
> Also, is there a good reason for renaming hard_end() to reserved_end()?
> 
> One additional thing, you need to update the SA to reflect this change. I think the only place you need to fix is in:
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
> 
> Thanks,
> Stefan
> 
> On 2018-04-09 19:24, JC Beyler wrote:
>> Hi all,
>> Small pre-amble to this request:
>> In my work to try to get a heap sampler in OpenJDK (via JEP 331 <https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm trying to reduce the footprint of my change so that the integration can be easier. I was told that generally a JEP webrev should be feature complete and go in at-once. However, with the change touching quite a bit of various code pieces, I was trying to figure out what could be separated as not "part of the feature".
>> I asked around and said that perhaps a solution would be to cut up the renaming of TLAB's end field that I do in that webrev. Because I'm renaming a field in TLAB used by various backends for that work, I have to update every architecture dependent code to reflect it.
>> I entirely understand that perhaps this is not in the habits and very potentially might not be the way things are generally done. If so, I apologize and let me know if you would not want this to go in separately :)
>> Final note: there is still a chance JEP-331 does not go in. If it does not, we can leave the new name in place or I'll happily revert it. I can even create an issue to track this if that makes it easier for all.
>> End of the pre-amble.
>> The 33-line change webrev in question is here:
>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>> I fixed all the architectures and JVMCI and ran a few sanity tests to ensure I had not missed anything.
>> Thanks for your help and I hope this is not too much trouble,
>> Jc
>> Ps: there is a graal change that needs to happen but I was not sure who/where to ask about it. I was told it could happen in a separate webrev. Can anyone point me to the right direction? Should it just be hotspot-compiler-dev?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180410/a0dd978b/attachment.htm>

From thomas.schatzl at oracle.com  Tue Apr 10 14:06:12 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 10 Apr 2018 16:06:12 +0200
Subject: RFR (XS): 8201365: Remove G1Policy::should_process_references()
In-Reply-To: <53ff6128-f5af-6a91-cce9-0afe9758bff9@redhat.com>
References: <1523363161.2373.3.camel@oracle.com>
 <53ff6128-f5af-6a91-cce9-0afe9758bff9@redhat.com>
Message-ID: <1523369172.2373.20.camel@oracle.com>

Hi,

On Tue, 2018-04-10 at 15:31 +0200, Aleksey Shipilev wrote:
> On 04/10/2018 02:26 PM, Thomas Schatzl wrote:
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8201365
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8201365/webrev/
> 
> Patch looks good.
> 
> But, don't you actually want to control refprocessing, especially
> when pause times are concerned?

  the removed code does not control reference processing at all, it
simply always enables it; this is some renmant of some removed closed
code. The change is simple enough to be added again if somebody wants
to experiment with that.

Regarding pause times, in the future all but the parts that actually
copy data (finalizers) for global reference processing could be done
concurrently too.

Maybe at some point in the future finalizers will be removed (they are
deprecated already), so that issue may go away.

Only clearing out referent fields may be predictable enough for the
reference processing after young gcs (or moving it to some concurrent
phase too).

Thanks,
  Thomas


From shade at redhat.com  Tue Apr 10 14:16:22 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 10 Apr 2018 16:16:22 +0200
Subject: RFR: 8201316: Move G1-related static members from JavaThread to
 G1BarrierSet
In-Reply-To: <3b8408bf-8001-19f6-250e-50e25b887d25@oracle.com>
References: <e389f349-6766-9a85-1ed6-6e5d03aeef6d@oracle.com>
 <d4ef4675-9bb7-540a-2f7c-4f1bde28ba68@redhat.com>
 <3b8408bf-8001-19f6-250e-50e25b887d25@oracle.com>
Message-ID: <514873aa-9bea-5fac-f3ff-357350679533@redhat.com>

On 04/10/2018 02:09 PM, Per Liden wrote:
> On 04/10/2018 01:19 PM, Aleksey Shipilev wrote:
>> On 04/10/2018 01:05 PM, Per Liden wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201316
>>> Webrev: http://cr.openjdk.java.net/~pliden/8201316/webrev.0
>>
>> I actually think we should instead move SATB machinery into gc/shared (Shenandoah uses it!), and
>> leave these static members in the JavaThread.
> 
> I agree, and I don't think this change stops you from working towards that goal. As you know, we're
> working towards having more appropriate abstractions to make GCs more pluggable, which this RFE and
> the followup change JDK-8201318 (sent to hotspot-dev) is trying to address.

All right, fine! As long as these changes go in hand-in-hand, Shenandoah can temporarily hack into
satbMarkQueue and inject the reference to it in its own BarrierSet and ThreadLocalData.

> With the G1-specific stuff is cleaned out from JavaThread, I think it will be easier for you to see
> what G1-dependencies you really have in Shenandoah, and start work to break those dependencies or
> move code to gc/shared if needed.

We do know what dependencies Shenandoah has. The development convenience is about the choice between
the destructive cleanup that requires dealing with immediately, or the cleanup that can still be
worked around to keep the project functional, albeit in a hacky way. This pair of changes seems the
be the latter.

Thanks,
-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180410/33e7959f/signature.asc>

From shade at redhat.com  Tue Apr 10 14:18:01 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 10 Apr 2018 16:18:01 +0200
Subject: RFR (XS): 8201365: Remove G1Policy::should_process_references()
In-Reply-To: <1523369172.2373.20.camel@oracle.com>
References: <1523363161.2373.3.camel@oracle.com>
 <53ff6128-f5af-6a91-cce9-0afe9758bff9@redhat.com>
 <1523369172.2373.20.camel@oracle.com>
Message-ID: <bb0d2639-97e7-77e3-638a-4fd60483c43d@redhat.com>

On 04/10/2018 04:06 PM, Thomas Schatzl wrote:
> Hi,
> 
> On Tue, 2018-04-10 at 15:31 +0200, Aleksey Shipilev wrote:
>> On 04/10/2018 02:26 PM, Thomas Schatzl wrote:
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8201365
>>> Webrev:
>>> http://cr.openjdk.java.net/~tschatzl/8201365/webrev/
>>
>> Patch looks good.
>>
>> But, don't you actually want to control refprocessing, especially
>> when pause times are concerned?
> 
>   the removed code does not control reference processing at all, it
> simply always enables it; this is some renmant of some removed closed
> code. The change is simple enough to be added again if somebody wants
> to experiment with that.
> 
> Regarding pause times, in the future all but the parts that actually
> copy data (finalizers) for global reference processing could be done
> concurrently too.
> 
> Maybe at some point in the future finalizers will be removed (they are
> deprecated already), so that issue may go away.
> 
> Only clearing out referent fields may be predictable enough for the
> reference processing after young gcs (or moving it to some concurrent
> phase too).

OK, I see. I was asking that because we have Shenandoah users who control reference processing
frequency, and thus balance pause times when refprocessing is not yet concurrent. I would understand
if that is ruled not to be the priority in current G1.

-Aleksey



From stefan.johansson at oracle.com  Tue Apr 10 14:51:51 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 10 Apr 2018 16:51:51 +0200
Subject: RFR: 8200228: Change default value of HeapSizePerGCThread
In-Reply-To: <f5d33b01-88f9-45f8-00de-d2b13b7bb010@redhat.com>
References: <2690ce00-921f-9310-648f-69fd41afca19@oracle.com>
 <05493def-e244-8710-04e0-cbb70a40f3f2@oracle.com>
 <493ded08-ee06-595f-5934-0383fbd4574c@oracle.com>
 <f5d33b01-88f9-45f8-00de-d2b13b7bb010@redhat.com>
Message-ID: <8572a1e3-8109-f2b6-1433-cf1e4f8bc821@oracle.com>

Thanks Aleksey and Jesper :)

Cheers,
Stefan

On 2018-04-10 15:18, Aleksey Shipilev wrote:
> This change is fine with me. Count me as Reviewer.
> 
> -Aleksey
> 
> On 04/10/2018 01:43 PM, Stefan Johansson wrote:
>> CSR is now approved. Do I need a second reviewer for this default value change?
>>
>> Stefan
>>
>> On 2018-03-29 10:52, Stefan Johansson wrote:
>>> I've now created a CSR as well:
>>> https://bugs.openjdk.java.net/browse/JDK-8200417
>>>
>>> Please have a look at it and add yourself as a reviewer if everything looks good.
>>>
>>> Thanks,
>>> Stefan
>>>
>>> On 2018-03-28 15:52, Stefan Johansson wrote:
>>>> Hi,
>>>>
>>>> Please review this change of the default value for HeapSizePerGCThread.
>>>>
>>>> Links
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8200228
>>>> Webrev: http://cr.openjdk.java.net/~sjohanss/8200228/00/
>>>>
>>>> Summary
>>>> My testing shows that for DaCapo, SpecJVM98 and GCBasher (gc intensive stress test) with small
>>>> heaps we get better pause times with the flag set to 32M. There might be other arguments, such as
>>>> not using to much resources on small systems that might also be important so please let me know
>>>> if you have reasons why the flag should be left unchanged.
>>>>
>>>> Thanks,
>>>> Stefan
>>>>
>>>
> 


From per.liden at oracle.com  Tue Apr 10 15:11:11 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 10 Apr 2018 17:11:11 +0200
Subject: RFR: 8201316: Move G1-related static members from JavaThread to
 G1BarrierSet
In-Reply-To: <514873aa-9bea-5fac-f3ff-357350679533@redhat.com>
References: <e389f349-6766-9a85-1ed6-6e5d03aeef6d@oracle.com>
 <d4ef4675-9bb7-540a-2f7c-4f1bde28ba68@redhat.com>
 <3b8408bf-8001-19f6-250e-50e25b887d25@oracle.com>
 <514873aa-9bea-5fac-f3ff-357350679533@redhat.com>
Message-ID: <7a3c05a1-145b-c466-ddea-558c94a2dbd8@oracle.com>

Hi Aleksey,

Yep, I'll integrate both changes at the same time.

I don't actually think this causes a lot of work for you. As you say, 
you can just continue to hack into G1 for now (not a lot of work, and no 
better or worse than what you do now), and break that dependency at some 
point later (doesn't look like a lot of work either, unless I'm missing 
something).

cheers,
Per

On 04/10/2018 04:16 PM, Aleksey Shipilev wrote:
> On 04/10/2018 02:09 PM, Per Liden wrote:
>> On 04/10/2018 01:19 PM, Aleksey Shipilev wrote:
>>> On 04/10/2018 01:05 PM, Per Liden wrote:
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201316
>>>> Webrev: http://cr.openjdk.java.net/~pliden/8201316/webrev.0
>>>
>>> I actually think we should instead move SATB machinery into gc/shared (Shenandoah uses it!), and
>>> leave these static members in the JavaThread.
>>
>> I agree, and I don't think this change stops you from working towards that goal. As you know, we're
>> working towards having more appropriate abstractions to make GCs more pluggable, which this RFE and
>> the followup change JDK-8201318 (sent to hotspot-dev) is trying to address.
> 
> All right, fine! As long as these changes go in hand-in-hand, Shenandoah can temporarily hack into
> satbMarkQueue and inject the reference to it in its own BarrierSet and ThreadLocalData.
> 
>> With the G1-specific stuff is cleaned out from JavaThread, I think it will be easier for you to see
>> what G1-dependencies you really have in Shenandoah, and start work to break those dependencies or
>> move code to gc/shared if needed.
> 
> We do know what dependencies Shenandoah has. The development convenience is about the choice between
> the destructive cleanup that requires dealing with immediately, or the cleanup that can still be
> worked around to keep the project functional, albeit in a hacky way. This pair of changes seems the
> be the latter.
> 
> Thanks,
> -Aleksey
> 
> 


From jcbeyler at google.com  Tue Apr 10 22:21:08 2018
From: jcbeyler at google.com (JC Beyler)
Date: Tue, 10 Apr 2018 22:21:08 +0000
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
 current_end
In-Reply-To: <3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
 <fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
 <3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
Message-ID: <CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>

Hi Karen and Stefan,

@Stefan: Naming is hard :)
@Karen: thanks for the Graal comment, I fixed it in the new webrev, let me
know what you think :)

I think the naming convention suggested in this webrev came from
conversations in for JEP-331 and I am actually relatively indifferent to
the final result (as long as we have some form of forward progress :)). To
be honest, I'd also be happy to just leave _end as is for all architectures
and Graal and have a new _allocation_end. However, during initial reviews
of JEP-331 it was deemed complicated to understand:

_end -> the _end or sampling end
_allocation_end -> end pointer for the last possible allocation
hard_end -> allocation end + reserved space

That is how this naming came up and why hard_end went to "reserved_end".

I'm really indifferent, so I offer as a perusal:
http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/

I noticed a few problems of alignement of '{' so I'll go fix that.
Basically this webrev does the following:

- Uses fast_path_end instead of end
- Reverts hard_end back to where it was
- Adds the changes to Graal; there is a bunch of changes in Graal because
Graal still contains a bit of code doing fasttlabrefills.

Let me know what you think!

Thanks,
Jc


On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear <karen.kinnear at oracle.com>
wrote:

> Hi JC,
>
> A comment about Graal. The impact on Graal for this particular change
> would be to break it - so you?ll need
> to complete the Graal changes for this renaming. That isn?t optional or
> something that could be a follow-on. It
> is not ok to break a feature, even an experimental one. We will discuss in
> the other thread potential phasing of adding sampling.
>
> I did not do a thorough search -you can do that - I did find
> src/jdk.internal.vm.compiler/share/classes/
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>   public final int threadTlabOffset = getFieldOffset("Thread::_tlab",
> Integer.class, "ThreadLocalAllocBuffer");
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>   private final int threadLocalAllocBufferStartOffset =
> getFieldOffset("ThreadLocalAllocBuffer::_start", Integer.class,
> "HeapWord*");
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>   private final int threadLocalAllocBufferEndOffset =
> getFieldOffset("ThreadLocalAllocBuffer::_end", Integer.class, "HeapWord*");
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>   private final int threadLocalAllocBufferTopOffset =
> getFieldOffset("ThreadLocalAllocBuffer::_top", Integer.class, "HeapWord*");
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>   private final int threadLocalAllocBufferPfTopOffset =
> getFieldOffset("ThreadLocalAllocBuffer::_pf_top", Integer.class,
> "HeapWord*");
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>   private final int threadLocalAllocBufferSlowAllocationsOffset =
> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations", Integer.class,
> "unsigned");
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>   private final int threadLocalAllocBufferFastRefillWasteOffset =
> getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste", Integer.class,
> "unsigned");
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>   private final int threadLocalAllocBufferNumberOfRefillsOffset =
> getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills", Integer.class,
> "unsigned");
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>   private final int threadLocalAllocBufferRefillWasteLimitOffset =
> getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
> Integer.class, "size_t");
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>   private final int threadLocalAllocBufferDesiredSizeOffset =
> getFieldOffset("ThreadLocalAllocBuffer::_desired_size", Integer.class,
> "size_t");
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>   public final int tlabAlignmentReserve =
> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
> Integer.class, "size_t?);
>
> hope this helps,
> Karen
>
> On Apr 10, 2018, at 7:04 AM, Stefan Johansson <stefan.johansson at oracle.com>
> wrote:
>
> Hi JC,
>
> I realize that the names have been discussed before but I'm leaning
> towards suggesting something new. We discussed this briefly here in the
> office and others might have different opinions. One point that came up is
> that if we do this change and change all usages of
> JavaThread::tlab_end_offset() it would be good to make sure the new name is
> good. To us _current_end is not very descriptive, but naming is hard and
> the best we could come up with is _fast_path_end which would give the code:
>  cmpptr(end, Address(thread, JavaThread::tlab_fast_path_end_offset()));
>  jcc(Assembler::above, slow_case);
>
> I think this reads pretty good and is fairly clear. If we do this rename I
> think you can re-use _end in JEP-331 instead of calling it _allocation_end.
> But that is a later review :)
>
> Also, is there a good reason for renaming hard_end() to reserved_end()?
>
> One additional thing, you need to update the SA to reflect this change. I
> think the only place you need to fix is in:
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
>
> Thanks,
> Stefan
>
> On 2018-04-09 19:24, JC Beyler wrote:
>
> Hi all,
> Small pre-amble to this request:
> In my work to try to get a heap sampler in OpenJDK (via JEP 331 <
> https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm trying to reduce
> the footprint of my change so that the integration can be easier. I was
> told that generally a JEP webrev should be feature complete and go in
> at-once. However, with the change touching quite a bit of various code
> pieces, I was trying to figure out what could be separated as not "part of
> the feature".
> I asked around and said that perhaps a solution would be to cut up the
> renaming of TLAB's end field that I do in that webrev. Because I'm renaming
> a field in TLAB used by various backends for that work, I have to update
> every architecture dependent code to reflect it.
> I entirely understand that perhaps this is not in the habits and very
> potentially might not be the way things are generally done. If so, I
> apologize and let me know if you would not want this to go in separately :)
> Final note: there is still a chance JEP-331 does not go in. If it does
> not, we can leave the new name in place or I'll happily revert it. I can
> even create an issue to track this if that makes it easier for all.
> End of the pre-amble.
> The 33-line change webrev in question is here:
> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
> I fixed all the architectures and JVMCI and ran a few sanity tests to
> ensure I had not missed anything.
> Thanks for your help and I hope this is not too much trouble,
> Jc
> Ps: there is a graal change that needs to happen but I was not sure
> who/where <https://teams.googleplex.com/u/where> to ask about it. I was
> told it could happen in a separate webrev. Can anyone point me to the right
> direction? Should it just be hotspot-compiler-dev?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180410/e655faf2/attachment.htm>

From jcbeyler at google.com  Tue Apr 10 22:56:22 2018
From: jcbeyler at google.com (JC Beyler)
Date: Tue, 10 Apr 2018 22:56:22 +0000
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
 current_end
In-Reply-To: <CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
 <fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
 <3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
 <CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
Message-ID: <CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>

Small update:

Here is the fixed webrev for the '{' that were out of alignment. This
passed release build JTREG for hotspot/jtreg/compiler/jvmti (just to run
something as a smoke screen) and hotspot/jtreg/compiler/aot/ (to test
Graal).
http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/

Let me know what you think,
Jc

On Tue, Apr 10, 2018 at 3:21 PM JC Beyler <jcbeyler at google.com> wrote:

> Hi Karen and Stefan,
>
> @Stefan: Naming is hard :)
> @Karen: thanks for the Graal comment, I fixed it in the new webrev, let me
> know what you think :)
>
> I think the naming convention suggested in this webrev came from
> conversations in for JEP-331 and I am actually relatively indifferent to
> the final result (as long as we have some form of forward progress :)). To
> be honest, I'd also be happy to just leave _end as is for all architectures
> and Graal and have a new _allocation_end. However, during initial reviews
> of JEP-331 it was deemed complicated to understand:
>
> _end -> the _end or sampling end
> _allocation_end -> end pointer for the last possible allocation
> hard_end -> allocation end + reserved space
>
> That is how this naming came up and why hard_end went to "reserved_end".
>
> I'm really indifferent, so I offer as a perusal:
> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
>
> I noticed a few problems of alignement of '{' so I'll go fix that.
> Basically this webrev does the following:
>
> - Uses fast_path_end instead of end
> - Reverts hard_end back to where it was
> - Adds the changes to Graal; there is a bunch of changes in Graal because
> Graal still contains a bit of code doing fasttlabrefills.
>
> Let me know what you think!
>
> Thanks,
> Jc
>
>
> On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear <karen.kinnear at oracle.com>
> wrote:
>
>> Hi JC,
>>
>> A comment about Graal. The impact on Graal for this particular change
>> would be to break it - so you?ll need
>> to complete the Graal changes for this renaming. That isn?t optional or
>> something that could be a follow-on. It
>> is not ok to break a feature, even an experimental one. We will discuss
>> in the other thread potential phasing of adding sampling.
>>
>> I did not do a thorough search -you can do that - I did find
>> src/jdk.internal.vm.compiler/share/classes/
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>   public final int threadTlabOffset = getFieldOffset("Thread::_tlab",
>> Integer.class, "ThreadLocalAllocBuffer");
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>   private final int threadLocalAllocBufferStartOffset =
>> getFieldOffset("ThreadLocalAllocBuffer::_start", Integer.class,
>> "HeapWord*");
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>   private final int threadLocalAllocBufferEndOffset =
>> getFieldOffset("ThreadLocalAllocBuffer::_end", Integer.class, "HeapWord*");
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>   private final int threadLocalAllocBufferTopOffset =
>> getFieldOffset("ThreadLocalAllocBuffer::_top", Integer.class, "HeapWord*");
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>   private final int threadLocalAllocBufferPfTopOffset =
>> getFieldOffset("ThreadLocalAllocBuffer::_pf_top", Integer.class,
>> "HeapWord*");
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>   private final int threadLocalAllocBufferSlowAllocationsOffset =
>> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations", Integer.class,
>> "unsigned");
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>   private final int threadLocalAllocBufferFastRefillWasteOffset =
>> getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste", Integer.class,
>> "unsigned");
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>   private final int threadLocalAllocBufferNumberOfRefillsOffset =
>> getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills", Integer.class,
>> "unsigned");
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>   private final int threadLocalAllocBufferRefillWasteLimitOffset =
>> getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
>> Integer.class, "size_t");
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>   private final int threadLocalAllocBufferDesiredSizeOffset =
>> getFieldOffset("ThreadLocalAllocBuffer::_desired_size", Integer.class,
>> "size_t");
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>   public final int tlabAlignmentReserve =
>> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
>> Integer.class, "size_t?);
>>
>> hope this helps,
>> Karen
>>
>> On Apr 10, 2018, at 7:04 AM, Stefan Johansson <
>> stefan.johansson at oracle.com> wrote:
>>
>> Hi JC,
>>
>> I realize that the names have been discussed before but I'm leaning
>> towards suggesting something new. We discussed this briefly here in the
>> office and others might have different opinions. One point that came up is
>> that if we do this change and change all usages of
>> JavaThread::tlab_end_offset() it would be good to make sure the new name is
>> good. To us _current_end is not very descriptive, but naming is hard and
>> the best we could come up with is _fast_path_end which would give the code:
>>  cmpptr(end, Address(thread, JavaThread::tlab_fast_path_end_offset()));
>>  jcc(Assembler::above, slow_case);
>>
>> I think this reads pretty good and is fairly clear. If we do this rename
>> I think you can re-use _end in JEP-331 instead of calling it
>> _allocation_end. But that is a later review :)
>>
>> Also, is there a good reason for renaming hard_end() to reserved_end()?
>>
>> One additional thing, you need to update the SA to reflect this change. I
>> think the only place you need to fix is in:
>>
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
>>
>> Thanks,
>> Stefan
>>
>> On 2018-04-09 19:24, JC Beyler wrote:
>>
>> Hi all,
>> Small pre-amble to this request:
>> In my work to try to get a heap sampler in OpenJDK (via JEP 331 <
>> https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm trying to reduce
>> the footprint of my change so that the integration can be easier. I was
>> told that generally a JEP webrev should be feature complete and go in
>> at-once. However, with the change touching quite a bit of various code
>> pieces, I was trying to figure out what could be separated as not "part of
>> the feature".
>> I asked around and said that perhaps a solution would be to cut up the
>> renaming of TLAB's end field that I do in that webrev. Because I'm renaming
>> a field in TLAB used by various backends for that work, I have to update
>> every architecture dependent code to reflect it.
>> I entirely understand that perhaps this is not in the habits and very
>> potentially might not be the way things are generally done. If so, I
>> apologize and let me know if you would not want this to go in separately :)
>> Final note: there is still a chance JEP-331 does not go in. If it does
>> not, we can leave the new name in place or I'll happily revert it. I can
>> even create an issue to track this if that makes it easier for all.
>> End of the pre-amble.
>> The 33-line change webrev in question is here:
>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>> I fixed all the architectures and JVMCI and ran a few sanity tests to
>> ensure I had not missed anything.
>> Thanks for your help and I hope this is not too much trouble,
>> Jc
>> Ps: there is a graal change that needs to happen but I was not sure
>> who/where <https://teams.googleplex.com/u/where> to ask about it. I was
>> told it could happen in a separate webrev. Can anyone point me to the right
>> direction? Should it just be hotspot-compiler-dev?
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180410/6d68cac4/attachment.htm>

From thomas.schatzl at oracle.com  Wed Apr 11 09:34:37 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 11 Apr 2018 11:34:37 +0200
Subject: RFR (XS): 8201365: Remove G1Policy::should_process_references()
In-Reply-To: <bb0d2639-97e7-77e3-638a-4fd60483c43d@redhat.com>
References: <1523363161.2373.3.camel@oracle.com>
 <53ff6128-f5af-6a91-cce9-0afe9758bff9@redhat.com>
 <1523369172.2373.20.camel@oracle.com>
 <bb0d2639-97e7-77e3-638a-4fd60483c43d@redhat.com>
Message-ID: <1523439277.2377.12.camel@oracle.com>

Hi Aleksey,

On Tue, 2018-04-10 at 16:18 +0200, Aleksey Shipilev wrote:
> On 04/10/2018 04:06 PM, Thomas Schatzl wrote:
> > Hi,
> > 
> > On Tue, 2018-04-10 at 15:31 +0200, Aleksey Shipilev wrote:
> > > On 04/10/2018 02:26 PM, Thomas Schatzl wrote:
> > > > CR:
> > > > https://bugs.openjdk.java.net/browse/JDK-8201365
> > > > Webrev:
> > > > http://cr.openjdk.java.net/~tschatzl/8201365/webrev/
> > > 
> > > Patch looks good.
> > > 
> > > But, don't you actually want to control refprocessing, especially
> > > when pause times are concerned?
> > 
> >   the removed code does not control reference processing at all, it
> > simply always enables it; this is some renmant of some removed
> > closed code. The change is simple enough to be added again if
> > somebody wants to experiment with that.
> > 
> > Regarding pause times, in the future all but the parts that
> > actually copy data (finalizers) for global reference processing
> > could be done concurrently too.
> > 
> > Maybe at some point in the future finalizers will be removed (they
> > are deprecated already), so that issue may go away.
> >
> > Only clearing out referent fields may be predictable enough for the
> > reference processing after young gcs (or moving it to some
> > concurrent phase too).
> 
> OK, I see. I was asking that because we have Shenandoah users who
> control reference processing frequency, and thus balance pause times
> when refprocessing is not yet concurrent. I would understand
> if that is ruled not to be the priority in current G1.

  nobody from us is working on reference processing frequency control
as this change suggests right now, I am also not aware of anybody
requesting it. I filed JDK-8201419 though for later reference.

I also forgot to thank you for your review - thanks!

Thanks,
  Thomas



From per.liden at oracle.com  Wed Apr 11 10:01:17 2018
From: per.liden at oracle.com (Per Liden)
Date: Wed, 11 Apr 2018 12:01:17 +0200
Subject: RFR: 8201316: Move G1-related static members from JavaThread to
 G1BarrierSet
In-Reply-To: <965f7cb5-7f55-b6f6-8b74-e25778bf9002@oracle.com>
References: <e389f349-6766-9a85-1ed6-6e5d03aeef6d@oracle.com>
 <965f7cb5-7f55-b6f6-8b74-e25778bf9002@oracle.com>
Message-ID: <ab7483ef-3125-f823-c4a2-4325e10ec70e@oracle.com>

Thanks Stefan!

/Per

On 04/10/2018 01:35 PM, Stefan Karlsson wrote:
> Looks good.
> 
> StefanK
> 
> On 2018-04-10 13:05, Per Liden wrote:
>> As part of the effort to make GCs more pluggable, the G1-specific data 
>> in JavaThread should be moved out into a more appropriate abstraction.
>>
>> The first step is to move G1's static members (_satb_mark_queue_set 
>> and _dirty_card_queue_set) from JavaThread to the G1BarrierSet.
>>
>> This will be followed up by JDK-8201318, which is a more complex 
>> change, to remove the non-static G1 members in JavaThread.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201316
>> Webrev: http://cr.openjdk.java.net/~pliden/8201316/webrev.0
>>
>> /Per


From thomas.schatzl at oracle.com  Wed Apr 11 11:42:59 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 11 Apr 2018 13:42:59 +0200
Subject: RFR (M): 8201172: Parallelize Remset Tracking Update Before
 Rebuild phase
In-Reply-To: <f0f0d1e2-be9f-e0b7-a8ed-af145464f8f0@oracle.com>
References: <1523272611.4326.30.camel@oracle.com>
 <f0f0d1e2-be9f-e0b7-a8ed-af145464f8f0@oracle.com>
Message-ID: <1523446979.9657.4.camel@oracle.com>

Hi Stefan,

On Tue, 2018-04-10 at 14:29 +0200, Stefan Johansson wrote:
> Hi Thomas,
> 
> On 2018-04-09 13:16, Thomas Schatzl wrote:
> > Hi all,
> > 
> >    can I have reviews for this straightforward change that improves
> > the
> > "Remset Tracking Update Before Rebuild" phase of the Remark pause?
> > 
> > Performance of this phase has not been a big issue, with ~3000
> > regions
> > you get around 1ms of time taken, but now it's even faster and
> > hopefully if run with 30k regions, there are no nasty suprises (or
> > not
> > as nasty at least).
> > 
> > Determining the number of threads to use has been done by doing a
> > few
> > measurements and tests and look at which point there does not seem
> > to
> > be any more scaling (i.e. the noise seems higher than the
> > improvements), and the pause time much smaller than a millisecond.
> > 
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8201172
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8201172/webrev/
> 
> Looks good, just a few minor things:
> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
> 1108     G1UpdateRemSetTrackingBeforeRebuild cl(_g1h, _cm, &_cl);
> 1109     _g1h->heap_region_par_iterate_from_worker_offset(&cl, 
> &_hrclaimer, worker_id);
> 1110     Atomic::add(cl.num_selected_for_rebuild(), 
> &_num_selected_for_rebuild);
> 
> Using the same names for all closures and and having 
> num_selected_for_rebuild in both the task and the closure, makes
> this code a bit hard to follow. I suggest calling the task member 
> _total_selected_for_rebuild and also have the getter name match the 
> member for the closure.
> 
> For the closures I'm fine with the members being named _cl, but it
> would help if the instance above were name something else, like
> rebuild.

Done.

http://cr.openjdk.java.net/~tschatzl/8201172/webrev.0_to_1 (diff)
http://cr.openjdk.java.net/~tschatzl/8201172/webrev.1 (full)

This change contains one difference that I actually forgot to fix in
the last webrev - my notes tell me that the "best" value for
RegionsPerThread is 384, not 512. I forgot to change this after fixing
the ceil() operation in line 1174. I.e. originally I had
align_size_up() there, but it requires a power-of-2 alignment value,
that of course asserted when using 384. I fixed the align_size_up, but
did not change the RegionsPerThread value. Sorry.

Thanks,
  Thomas


From thomas.schatzl at oracle.com  Wed Apr 11 11:46:37 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 11 Apr 2018 13:46:37 +0200
Subject: RFR (M): 6672778:  G1 should trim task queues more aggressively
 during evacuation pauses
In-Reply-To: <1523272805.4326.33.camel@oracle.com>
References: <1523272805.4326.33.camel@oracle.com>
Message-ID: <1523447197.9657.6.camel@oracle.com>

Hi all,

  I updated and (hopefully) improved the change a bit after some more
thinking.

Particularly I thought that tracking the partial trim time in the
closures would be confusing and too intrusive, so I moved it out from
them to the G1ParScanThreadState.
This also removed quite a few otherwise necessary includes to
utilities/ticks.hpp.

Also the time accounting has been a bit messy as you needed to
add/subtract the trim time in various places that were non-obvious. I
tried to improve that by avoiding (existing) nested timing (remembered
set cards/remembered set code roots and updateRS/scanHCC), which made
the code imho much more easier to follow.

These two changes also make the follow-up "JDK-8201313: Sub-phases of
ext root scan may be larger than the sum of individual timings"
somewhat simpler.

Note that to gather the timings the code uses Tickspan for holding
intermediate values, i.e. basically nanoseconds. Unfortunately G1
logging uses seconds encoded as doubles everywhere for historical
reasons; there is a really huge change fixing this coming, but for now
more and more places are going to use Tickspan.

Webrevs:
http://cr.openjdk.java.net/~tschatzl/6672778/webrev.0_to_1/ (diff)
http://cr.openjdk.java.net/~tschatzl/6672778/webrev.1/ (full)
Testing:
hs-tier 1-3

Thanks,
  Thomas

On Mon, 2018-04-09 at 13:20 +0200, Thomas Schatzl wrote:
> Hi all,
> 
>   I am happy to finally bring this, one of the oldest G1 issues we
> have, to a happy ending :)
> 
> So until now G1 buffered all oop locations it encountered during root
> scanning (including from remembered sets and refinement queues) in
> the
> per-thread work queues, and only drained them at the very end of the
> evacuation pause.
> 
> I am not completely sure why this has been implemented this way, but
> it
> has serious drawbacks:
> - the work queues and overflow stacks may use a lot of memory, and I
> mean *a lot*
> - since we buffer all oop references, the prefetching G1 does goes to
> waste as G1 always prefetches (during root scan) without following up
> on it, wasting memory bandwidth.
> 
> Other GC's already employ this technique, so my best guess why G1 did
> not so far is that G1 needs sub-timings for the various phases to get
> prediction right, and even if doing timing is cheap, doing it too
> often
> just adds up.
> 
> Anyway, this problem has been solved by implementing a hysteresis,
> i.e.
> start trimming the work queues at a threshold higher than ending it,
> and time the length of the trimming inbetween. So the timing
> measurement overhead gets distributed across many work queue
> operations.
> Note that I did not do much testing about the optimal hysteresis
> range,
> the suggested guess of 2xGCDrainStackTargetSize seems to be a pretty
> good value (i.e. reduces overhead well enough).
> 
> Results are pretty good: I have seen reductions of the maximum task
> queue size by multiple orders of magnitudes (i.e. less memory usage
> during GC), and reduction of total pause time by up to 50%,
> particularly on larger applications in the few GB heap range where
> quite a bit of data is copied around every gc.
> 
> But also smaller applications and applications doing less copying
> benefit quite a bit, reducing pause times significantly.
> 
> Note that there is a known, actually pre-existing bug with buffering
> up
> references (by the now obsolete and removed BufferingOopClosure): the
> sum of timings for the sub-phases of ext root scan may be larger than
> the printed total. This will be addressed with the follow-up JDK-
> 8201313 to keep this change small, and it's a pre-existing issue
> anyway
> :P
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-6672778
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/6672778/webrev/
> Testing:
> hs-tier 1-3, perf tests
> 
> Thanks,
>   Thomas
> 



From stefan.johansson at oracle.com  Wed Apr 11 14:44:55 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Wed, 11 Apr 2018 16:44:55 +0200
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
 current_end
In-Reply-To: <CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
 <fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
 <3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
 <CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
 <CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
Message-ID: <3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>

Hi JC,

On 2018-04-11 00:56, JC Beyler wrote:
> Small update:
> 
> Here is the fixed webrev for the '{' that were out of alignment. This 
> passed release build JTREG for?hotspot/jtreg/compiler/jvmti (just to run 
> something as a smoke screen) and?hotspot/jtreg/compiler/aot/ (to test 
> Graal).
> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
> 
I think this looks better, I agree that leaving _end is tempting to 
avoid a lot of change, but I think this will be better in the long run.

I still miss the changes to make the SA work. To see a problem you can run:
make CONF=fast run-test 
TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java

Cheers,
Stefan

> Let me know what you think,
> Jc
> 
> On Tue, Apr 10, 2018 at 3:21 PM JC Beyler <jcbeyler at google.com 
> <mailto:jcbeyler at google.com>> wrote:
> 
>     Hi Karen and Stefan,
> 
>     @Stefan: Naming is hard :)
>     @Karen: thanks for the Graal comment, I fixed it in the new webrev,
>     let me know what you think :)
> 
>     I think the naming convention suggested in this webrev came from
>     conversations in for JEP-331 and I am actually relatively
>     indifferent to the final result (as long as we have some form of
>     forward progress :)). To be honest, I'd also be happy to just leave
>     _end as is for all architectures and Graal and have a new
>     _allocation_end. However, during initial reviews of JEP-331 it was
>     deemed complicated to understand:
> 
>     _end -> the _end or sampling end
>     _allocation_end -> end pointer for the last possible allocation
>     hard_end -> allocation end?+ reserved space
> 
>     That is how this naming came up and why hard_end went to "reserved_end".
> 
>     I'm really indifferent, so I offer as a perusal:
>     http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
> 
>     I noticed a few problems of alignement of '{' so I'll go fix that.
>     Basically this webrev does the following:
> 
>     - Uses fast_path_end instead of end
>     - Reverts hard_end back to where it was
>     - Adds the changes to Graal; there is a bunch of changes in Graal
>     because Graal still contains a bit of code doing fasttlabrefills.
> 
>     Let me know what you think!
> 
>     Thanks,
>     Jc
> 
> 
>     On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear
>     <karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>> wrote:
> 
>         Hi JC,
> 
>         A comment about Graal. The impact on Graal for this particular
>         change would be to break it - so you?ll need
>         to complete the Graal changes for this renaming. That isn?t
>         optional or something that could be a follow-on. It
>         is not ok to break a feature, even an experimental one. We will
>         discuss in the other thread potential phasing of adding sampling.
> 
>         I did not do a thorough search -you can do that - I did find
>         src/jdk.internal.vm.compiler/share/classes/
>         org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>          ? public final int threadTlabOffset =
>         getFieldOffset("Thread::_tlab", Integer.class,
>         "ThreadLocalAllocBuffer");
>         org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>          ? private final int threadLocalAllocBufferStartOffset =
>         getFieldOffset("ThreadLocalAllocBuffer::_start", Integer.class,
>         "HeapWord*");
>         org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>          ? private final int threadLocalAllocBufferEndOffset =
>         getFieldOffset("ThreadLocalAllocBuffer::_end", Integer.class,
>         "HeapWord*");
>         org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>          ? private final int threadLocalAllocBufferTopOffset =
>         getFieldOffset("ThreadLocalAllocBuffer::_top", Integer.class,
>         "HeapWord*");
>         org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>          ? private final int threadLocalAllocBufferPfTopOffset =
>         getFieldOffset("ThreadLocalAllocBuffer::_pf_top", Integer.class,
>         "HeapWord*");
>         org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>          ? private final int threadLocalAllocBufferSlowAllocationsOffset
>         = getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
>         Integer.class, "unsigned");
>         org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>          ? private final int threadLocalAllocBufferFastRefillWasteOffset
>         = getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
>         Integer.class, "unsigned");
>         org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>          ? private final int threadLocalAllocBufferNumberOfRefillsOffset
>         = getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
>         Integer.class, "unsigned");
>         org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>          ? private final int
>         threadLocalAllocBufferRefillWasteLimitOffset =
>         getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
>         Integer.class, "size_t");
>         org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>          ? private final int threadLocalAllocBufferDesiredSizeOffset =
>         getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
>         Integer.class, "size_t");
>         org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>          ? public final int tlabAlignmentReserve =
>         getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
>         Integer.class, "size_t?);
> 
>         hope this helps,
>         Karen
> 
>>         On Apr 10, 2018, at 7:04 AM, Stefan Johansson
>>         <stefan.johansson at oracle.com
>>         <mailto:stefan.johansson at oracle.com>> wrote:
>>
>>         Hi JC,
>>
>>         I realize that the names have been discussed before but I'm
>>         leaning towards suggesting something new. We discussed this
>>         briefly here in the office and others might have different
>>         opinions. One point that came up is that if we do this change
>>         and change all usages of JavaThread::tlab_end_offset() it
>>         would be good to make sure the new name is good. To us
>>         _current_end is not very descriptive, but naming is hard and
>>         the best we could come up with is _fast_path_end which would
>>         give the code:
>>         ?cmpptr(end, Address(thread,
>>         JavaThread::tlab_fast_path_end_offset()));
>>         ?jcc(Assembler::above, slow_case);
>>
>>         I think this reads pretty good and is fairly clear. If we do
>>         this rename I think you can re-use _end in JEP-331 instead of
>>         calling it _allocation_end. But that is a later review :)
>>
>>         Also, is there a good reason for renaming hard_end() to
>>         reserved_end()?
>>
>>         One additional thing, you need to update the SA to reflect
>>         this change. I think the only place you need to fix is in:
>>         src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
>>
>>         Thanks,
>>         Stefan
>>
>>         On 2018-04-09 19:24, JC Beyler wrote:
>>>         Hi all,
>>>         Small pre-amble to this request:
>>>         In my work to try to get a heap sampler in OpenJDK (via JEP
>>>         331 <https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm
>>>         trying to reduce the footprint of my change so that the
>>>         integration can be easier. I was told that generally a JEP
>>>         webrev should be feature complete and go in at-once. However,
>>>         with the change touching quite a bit of various code pieces,
>>>         I was trying to figure out what could be separated as not
>>>         "part of the feature".
>>>         I asked around and said that perhaps a solution would be to
>>>         cut up the renaming of TLAB's end field that I do in that
>>>         webrev. Because I'm renaming a field in TLAB used by various
>>>         backends for that work, I have to update every architecture
>>>         dependent code to reflect it.
>>>         I entirely understand that perhaps this is not in the habits
>>>         and very potentially might not be the way things are
>>>         generally done. If so, I apologize and let me know if you
>>>         would not want this to go in separately :)
>>>         Final note: there is still a chance JEP-331 does not go in.
>>>         If it does not, we can leave the new name in place or I'll
>>>         happily revert it. I can even create an issue to track this
>>>         if that makes it easier for all.
>>>         End of the pre-amble.
>>>         The 33-line change webrev in question is here:
>>>         http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>>>         I fixed all the architectures and JVMCI and ran a few sanity
>>>         tests to ensure I had not missed anything.
>>>         Thanks for your help and I hope this is not too much trouble,
>>>         Jc
>>>         Ps: there is a graal change that needs to happen but I was
>>>         not sure who/where <https://teams.googleplex.com/u/where> to
>>>         ask about it. I was told it could happen in a separate
>>>         webrev. Can anyone point me to the right direction? Should it
>>>         just be hotspot-compiler-dev?
> 


From thomas.schatzl at oracle.com  Wed Apr 11 15:14:21 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 11 Apr 2018 17:14:21 +0200
Subject: Review request for trivial change - 8201330: Add
 java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java to the
 ProblemList
In-Reply-To: <13a5d42b-b520-4134-a9dd-85aff70f2c00@oracle.com>
References: <13a5d42b-b520-4134-a9dd-85aff70f2c00@oracle.com>
Message-ID: <1523459661.16569.0.camel@oracle.com>

Hi,

On Mon, 2018-04-09 at 16:24 -0400, Alexander Harlap wrote:
> Please review trivial change:
> Bug: JDK-8201330
> Related/blocking bug: JDK-8081652
> webrev: http://cr.openjdk.java.net/~aharlap/8201330/webrev.00/

  ship it.

Thomas


From jcbeyler at google.com  Wed Apr 11 15:48:27 2018
From: jcbeyler at google.com (JC Beyler)
Date: Wed, 11 Apr 2018 15:48:27 +0000
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
 current_end
In-Reply-To: <3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
 <fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
 <3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
 <CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
 <CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
 <3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
Message-ID: <CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>

Hi Stefan,

Sorry about that, I must have missed adding the files or something. Here is
a webrev that added the changes for the SA file:
http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/

I changed the method name, which propagated a change to:
src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java

I tried testing your test file. It exists in my branch (if the same) under:
hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java

and interestingly (which generally means I did something wrong), it passed
before/after the change so I could not verify that this is a test showing
that all is well in the world on my side. Any ideas of what I did wrong?

I did again test it for hotspot/jtreg/compiler/aot/ and
hotspot/jtreg/serviceability/jvmti and it passes those.

Thanks for all your help,
Jc



On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson <
stefan.johansson at oracle.com> wrote:

> Hi JC,
>
> On 2018-04-11 00:56, JC Beyler wrote:
> > Small update:
> >
> > Here is the fixed webrev for the '{' that were out of alignment. This
> > passed release build JTREG for hotspot/jtreg/compiler/jvmti (just to run
> > something as a smoke screen) and hotspot/jtreg/compiler/aot/ (to test
> > Graal).
> > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
> >
> I think this looks better, I agree that leaving _end is tempting to
> avoid a lot of change, but I think this will be better in the long run.
>
> I still miss the changes to make the SA work. To see a problem you can run:
> make CONF=fast run-test
> TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
>
> Cheers,
> Stefan
>
> > Let me know what you think,
> > Jc
> >
> > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler <jcbeyler at google.com
> > <mailto:jcbeyler at google.com>> wrote:
> >
> >     Hi Karen and Stefan,
> >
> >     @Stefan: Naming is hard :)
> >     @Karen: thanks for the Graal comment, I fixed it in the new webrev,
> >     let me know what you think :)
> >
> >     I think the naming convention suggested in this webrev came from
> >     conversations in for JEP-331 and I am actually relatively
> >     indifferent to the final result (as long as we have some form of
> >     forward progress :)). To be honest, I'd also be happy to just leave
> >     _end as is for all architectures and Graal and have a new
> >     _allocation_end. However, during initial reviews of JEP-331 it was
> >     deemed complicated to understand:
> >
> >     _end -> the _end or sampling end
> >     _allocation_end -> end pointer for the last possible allocation
> >     hard_end -> allocation end + reserved space
> >
> >     That is how this naming came up and why hard_end went to
> "reserved_end".
> >
> >     I'm really indifferent, so I offer as a perusal:
> >     http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
> >
> >     I noticed a few problems of alignement of '{' so I'll go fix that.
> >     Basically this webrev does the following:
> >
> >     - Uses fast_path_end instead of end
> >     - Reverts hard_end back to where it was
> >     - Adds the changes to Graal; there is a bunch of changes in Graal
> >     because Graal still contains a bit of code doing fasttlabrefills.
> >
> >     Let me know what you think!
> >
> >     Thanks,
> >     Jc
> >
> >
> >     On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear
> >     <karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>> wrote:
> >
> >         Hi JC,
> >
> >         A comment about Graal. The impact on Graal for this particular
> >         change would be to break it - so you?ll need
> >         to complete the Graal changes for this renaming. That isn?t
> >         optional or something that could be a follow-on. It
> >         is not ok to break a feature, even an experimental one. We will
> >         discuss in the other thread potential phasing of adding sampling.
> >
> >         I did not do a thorough search -you can do that - I did find
> >         src/jdk.internal.vm.compiler/share/classes/
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>
> >            public final int threadTlabOffset =
> >         getFieldOffset("Thread::_tlab", Integer.class,
> >         "ThreadLocalAllocBuffer");
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>
> >            private final int threadLocalAllocBufferStartOffset =
> >         getFieldOffset("ThreadLocalAllocBuffer::_start", Integer.class,
> >         "HeapWord*");
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>
> >            private final int threadLocalAllocBufferEndOffset =
> >         getFieldOffset("ThreadLocalAllocBuffer::_end", Integer.class,
> >         "HeapWord*");
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>
> >            private final int threadLocalAllocBufferTopOffset =
> >         getFieldOffset("ThreadLocalAllocBuffer::_top", Integer.class,
> >         "HeapWord*");
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>
> >            private final int threadLocalAllocBufferPfTopOffset =
> >         getFieldOffset("ThreadLocalAllocBuffer::_pf_top", Integer.class,
> >         "HeapWord*");
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>
> >            private final int threadLocalAllocBufferSlowAllocationsOffset
> >         = getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
> >         Integer.class, "unsigned");
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>
> >            private final int threadLocalAllocBufferFastRefillWasteOffset
> >         = getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
> >         Integer.class, "unsigned");
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>
> >            private final int threadLocalAllocBufferNumberOfRefillsOffset
> >         = getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
> >         Integer.class, "unsigned");
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>
> >            private final int
> >         threadLocalAllocBufferRefillWasteLimitOffset =
> >         getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
> >         Integer.class, "size_t");
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>
> >            private final int threadLocalAllocBufferDesiredSizeOffset =
> >         getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
> >         Integer.class, "size_t");
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>
> >            public final int tlabAlignmentReserve =
> >
>  getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
> >         Integer.class, "size_t?);
> >
> >         hope this helps,
> >         Karen
> >
> >>         On Apr 10, 2018, at 7:04 AM, Stefan Johansson
> >>         <stefan.johansson at oracle.com
> >>         <mailto:stefan.johansson at oracle.com>> wrote:
> >>
> >>         Hi JC,
> >>
> >>         I realize that the names have been discussed before but I'm
> >>         leaning towards suggesting something new. We discussed this
> >>         briefly here in the office and others might have different
> >>         opinions. One point that came up is that if we do this change
> >>         and change all usages of JavaThread::tlab_end_offset() it
> >>         would be good to make sure the new name is good. To us
> >>         _current_end is not very descriptive, but naming is hard and
> >>         the best we could come up with is _fast_path_end which would
> >>         give the code:
> >>          cmpptr(end, Address(thread,
> >>         JavaThread::tlab_fast_path_end_offset()));
> >>          jcc(Assembler::above, slow_case);
> >>
> >>         I think this reads pretty good and is fairly clear. If we do
> >>         this rename I think you can re-use _end in JEP-331 instead of
> >>         calling it _allocation_end. But that is a later review :)
> >>
> >>         Also, is there a good reason for renaming hard_end() to
> >>         reserved_end()?
> >>
> >>         One additional thing, you need to update the SA to reflect
> >>         this change. I think the only place you need to fix is in:
> >>
>  src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
> >>
> >>         Thanks,
> >>         Stefan
> >>
> >>         On 2018-04-09 19:24, JC Beyler wrote:
> >>>         Hi all,
> >>>         Small pre-amble to this request:
> >>>         In my work to try to get a heap sampler in OpenJDK (via JEP
> >>>         331 <https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm
> >>>         trying to reduce the footprint of my change so that the
> >>>         integration can be easier. I was told that generally a JEP
> >>>         webrev should be feature complete and go in at-once. However,
> >>>         with the change touching quite a bit of various code pieces,
> >>>         I was trying to figure out what could be separated as not
> >>>         "part of the feature".
> >>>         I asked around and said that perhaps a solution would be to
> >>>         cut up the renaming of TLAB's end field that I do in that
> >>>         webrev. Because I'm renaming a field in TLAB used by various
> >>>         backends for that work, I have to update every architecture
> >>>         dependent code to reflect it.
> >>>         I entirely understand that perhaps this is not in the habits
> >>>         and very potentially might not be the way things are
> >>>         generally done. If so, I apologize and let me know if you
> >>>         would not want this to go in separately :)
> >>>         Final note: there is still a chance JEP-331 does not go in.
> >>>         If it does not, we can leave the new name in place or I'll
> >>>         happily revert it. I can even create an issue to track this
> >>>         if that makes it easier for all.
> >>>         End of the pre-amble.
> >>>         The 33-line change webrev in question is here:
> >>>         http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
> >>>         I fixed all the architectures and JVMCI and ran a few sanity
> >>>         tests to ensure I had not missed anything.
> >>>         Thanks for your help and I hope this is not too much trouble,
> >>>         Jc
> >>>         Ps: there is a graal change that needs to happen but I was
> >>>         not sure who/where <https://teams.googleplex.com/u/where> <
> https://teams.googleplex.com/u/where> to
> >>>         ask about it. I was told it could happen in a separate
> >>>         webrev. Can anyone point me to the right direction? Should it
> >>>         just be hotspot-compiler-dev?
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180411/784fcbb2/attachment.htm>

From rkennke at redhat.com  Wed Apr 11 17:54:38 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 11 Apr 2018 19:54:38 +0200
Subject: RFR: JDK-8198285: More consistent Access API for arraycopy
Message-ID: <b57660bf-6c92-f243-6abd-2ea69570389c@redhat.com>

 Currently, the arraycopy API in access.hpp gets the src and dst oops,
plus the src and dst addresses. In order to be most useful to garbage
collectors, it should receive the src and dst oops together with the src
and dst offsets instead, and let the Access API / GC calculate the src
and dst addresses.

For example, Shenandoah needs to resolve the src and dst objects for
arraycopy, and then apply the corresponding offsets. With the current
API (obj+ptr) it would calculate the ptr-diff from obj to ptr, then
resolve obj, then re-add the calculate ptr-diff. This is fragile because
we also may resolve obj in the runtime before calculating ptr (e.g. via
arrayOop::base()). If we then pass in the original obj and a ptr
calculated from another copy of the same obj, the above resolution logic
would not work. This is currently the case for obj-arraycopy.

I propose to change the API to accept obj+offset, in addition to ptr for
both src and dst. Only one or the other should be used. Heap accesses
should use obj+offset and pass NULL for raw-ptr, off-heap accesses (or
heap accesses that are already resolved.. use with care) should pass
NULL+0 for obj+offset and the raw-ptr. Notice that this also allows the
API to be used for Java<->native array bulk transfers.

An alternative would be to break the API up into 4 variants:

Java->Java transfer:
arraycopy(oop src, size_t src_offs, oop dst, size_t dst_offs, size_t len)

Java->Native transfer:
arraycopy(oop src, size_t src_offs, D* raw_dst, size_t len)

Native->Java transfer:
arraycopy(S* src_raw, oop dst, size_t dst_offs, size_t len)

'Unsafe' transfer:
arraycopy(S* src_raw, D* dst_raw, size_t len)


But that seemed to be too much boilerplate copy+pasting for my taste.
(See how having this overly complicated template layer hurts us?)

Plus, I had a better idea: instead of accepting oop+offset OR T* for
almost every Access API, we may want to abstract that and take an
Address type argument, which would be either HeapAddress(obj, offset) or
RawAddress(T* ptr). GCs may then just call addr->address() to get the
actual address, or specialize for HeapAddress variants and resolve the
objs and then resolve the address. This would also allow us to get rid
of almost half of the API (all the *_at variants would go) and some
other simplifications. However, this seemed to explode the scope of this
RFE, and would be better handled in another RFE.

This changes makes both typeArrayKlass and objArrayKlass use the changed
API, plus I identified all (hopefully) places where we do bulk
Java<->native array transfers and make them use the API too. Gets us rid
of a bunch of memcpy calls :-)

Please review the change:
http://cr.openjdk.java.net/~rkennke/JDK-8198285/webrev.00/

Thanks, Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180411/b9c93605/signature.asc>

From rkennke at redhat.com  Wed Apr 11 19:49:01 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 11 Apr 2018 21:49:01 +0200
Subject: RFR: JDK-8201442: objArrayOopDesc::atomic_compare_exchange_oop() must
 use obj+offset in HeapAccess call
Message-ID: <1f0c6263-8dfc-1059-cdce-3f1847733dad@redhat.com>

Please review the following little change.


objArrayOopDesc::atomic_compare_exchange_oop() currently computes and
uses a raw pointer to pass to HeapAccess::oop_atomic_cmpxchg(). It
should use the object+offset variant because it's accessing the heap and
GC might need to resolve the target object (e.g. Shenandoah).

http://cr.openjdk.java.net/~rkennke/JDK-8201442/webrev.01/

Testing: hotspot-tier1


Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180411/710a7f1a/signature.asc>

From rkennke at redhat.com  Wed Apr 11 20:18:09 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 11 Apr 2018 22:18:09 +0200
Subject: RFR: JDK-8198285: More consistent Access API for arraycopy
In-Reply-To: <b57660bf-6c92-f243-6abd-2ea69570389c@redhat.com>
References: <b57660bf-6c92-f243-6abd-2ea69570389c@redhat.com>
Message-ID: <e495295b-beb7-908a-f81b-7183e38dd41a@redhat.com>

I just realized we use ptrdiff_t for offset in the rest of the API. I am
not sure that it's really a good fit. ptrdiff_t is meant to be used in
pointer arithmetic and is relative to the size of the pointer type. We
use it to give an offset in bytes from object start to the field, which
is always positive and can be unsigned (ptrdiff_t is signed) and is
always in bytes. Alas, I changed the API to use ptrdiff_t for now to
make it consistent. If we want to change this, we shall change them all.

Please review the updated full webrev:
http://cr.openjdk.java.net/~rkennke/JDK-8198285/webrev.01/

Thanks, Roman

>  Currently, the arraycopy API in access.hpp gets the src and dst oops,
> plus the src and dst addresses. In order to be most useful to garbage
> collectors, it should receive the src and dst oops together with the src
> and dst offsets instead, and let the Access API / GC calculate the src
> and dst addresses.
> 
> For example, Shenandoah needs to resolve the src and dst objects for
> arraycopy, and then apply the corresponding offsets. With the current
> API (obj+ptr) it would calculate the ptr-diff from obj to ptr, then
> resolve obj, then re-add the calculate ptr-diff. This is fragile because
> we also may resolve obj in the runtime before calculating ptr (e.g. via
> arrayOop::base()). If we then pass in the original obj and a ptr
> calculated from another copy of the same obj, the above resolution logic
> would not work. This is currently the case for obj-arraycopy.
> 
> I propose to change the API to accept obj+offset, in addition to ptr for
> both src and dst. Only one or the other should be used. Heap accesses
> should use obj+offset and pass NULL for raw-ptr, off-heap accesses (or
> heap accesses that are already resolved.. use with care) should pass
> NULL+0 for obj+offset and the raw-ptr. Notice that this also allows the
> API to be used for Java<->native array bulk transfers.
> 
> An alternative would be to break the API up into 4 variants:
> 
> Java->Java transfer:
> arraycopy(oop src, size_t src_offs, oop dst, size_t dst_offs, size_t len)
> 
> Java->Native transfer:
> arraycopy(oop src, size_t src_offs, D* raw_dst, size_t len)
> 
> Native->Java transfer:
> arraycopy(S* src_raw, oop dst, size_t dst_offs, size_t len)
> 
> 'Unsafe' transfer:
> arraycopy(S* src_raw, D* dst_raw, size_t len)
> 
> 
> But that seemed to be too much boilerplate copy+pasting for my taste.
> (See how having this overly complicated template layer hurts us?)
> 
> Plus, I had a better idea: instead of accepting oop+offset OR T* for
> almost every Access API, we may want to abstract that and take an
> Address type argument, which would be either HeapAddress(obj, offset) or
> RawAddress(T* ptr). GCs may then just call addr->address() to get the
> actual address, or specialize for HeapAddress variants and resolve the
> objs and then resolve the address. This would also allow us to get rid
> of almost half of the API (all the *_at variants would go) and some
> other simplifications. However, this seemed to explode the scope of this
> RFE, and would be better handled in another RFE.
> 
> This changes makes both typeArrayKlass and objArrayKlass use the changed
> API, plus I identified all (hopefully) places where we do bulk
> Java<->native array transfers and make them use the API too. Gets us rid
> of a bunch of memcpy calls :-)
> 
> Please review the change:
> http://cr.openjdk.java.net/~rkennke/JDK-8198285/webrev.00/
> 
> Thanks, Roman
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180411/dd3c778a/signature.asc>

From sangheon.kim at oracle.com  Thu Apr 12 04:47:14 2018
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Wed, 11 Apr 2018 21:47:14 -0700
Subject: RFR (S/M): 8178105: Switch mark bitmaps during Remark
In-Reply-To: <1522845771.2398.26.camel@oracle.com>
References: <1522334136.2451.15.camel@oracle.com>
 <c4a8f532-db1b-09f8-5b9d-aa76f2f6ae4d@oracle.com>
 <1522758329.2573.9.camel@oracle.com>
 <09b374ab-a86f-bcff-00f4-4b2874fb59ff@oracle.com>
 <1522767307.2582.2.camel@oracle.com>
 <1b5b0099-97da-35b6-99c1-628e5adf75ea@oracle.com>
 <1522845771.2398.26.camel@oracle.com>
Message-ID: <826503d3-a373-ac7b-aeeb-5e4168e0cbaa@oracle.com>

Hi Thomas,

On 04/04/2018 05:42 AM, Thomas Schatzl wrote:
> Hi all,
>
>    while looking at some parallelizing work in this area I noticed that
> one assert in the rebuild remsets code that has been changed in this
> change already needs an update too.
> It uses a wrong value for the informational text, which makes it really
> confusing.
>
> Since this change touches this code already, I would like to amend this
> change with this small fix:
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.2_to_3/ (diff)
> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.3/ (full)
Webrev.3 looks good.

Thanks,
Sangheon


>
> Sorry for the trouble.
>
> Thanks,
>    Thomas
>
> On Tue, 2018-04-03 at 17:00 +0200, Stefan Johansson wrote:
>> On 2018-04-03 16:55, Thomas Schatzl wrote:
>>> Hi,
>>>
>>>     thanks for your patience...
>>>
>>> On Tue, 2018-04-03 at 14:49 +0200, Stefan Johansson wrote:
>>>> On 2018-04-03 14:25, Thomas Schatzl wrote:
>>>>> Hi Stefan,
>>>>>
>>>>> On Tue, 2018-04-03 at 12:58 +0200, Stefan Johansson wrote:
>>>>>> Hi Thomas,
>>>>>>
>>>>>> On 2018-03-29 16:35, Thomas Schatzl wrote:
>>>>>>> Hi all,
>>>>>>> [...]
>>>>>>>
>>>>>>> CR:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8178105
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~tschatzl/8178105/
>>>>>>     Looks good, but a few comments:
>>>>>>
>>> [...]
>>>>> I added a different kind of check that verifies what you
>>>>> probably
>>>>> thought of, and that is that the number of words to add to the
>>>>> current region must always be larger than zero. If it is zero,
>>>>> there is something really wrong.
>>>> Exactly, that's what I wanted. But I don't see that check now,
>>>> just
>>>> having a assert(marked_words != 0, "") on row 1032 would be
>>>> enough.
>>> My fault. I did not upload the latest version of the change :( It
>>> is up
>>> now, the only difference to previous is line
>>>
>>> 1036       assert(words_to_add > 0, "Out of space to distribute
>>> before
>>> end of humongous object in region %u (starts %u)", i, region_idx);
>>>
>>> But there is a new webrev anyway... in the 1_to_2 webrev it is line
>>> 1033
>>>
>>>>>> 1047       log_trace(gc)("Added " SIZE_FORMAT " words to
>>>>>> region
>>>>>> %u
>>>>>> (%s)", marked_words, region_idx, hr->get_type_str());
>>>>>> I think the logging should use at least one more tag, maybe
>>>>>> "region" or "marking", but you probably know what makes most
>>>>>> sense in this area. I also think it would be nice if we got
>>>>>> this
>>>>>> same log-line for all regions. Now we get this for "normal"
>>>>>> regions, but we get "Distributing..." for humongous start
>>>>>> regions
>>>>>> and "Not Added..." for humongous continuous. So I would
>>>>>> suggest
>>>>>> adding the same log-line  to the distribute-function after
>>>>>> line
>>>>>> 1034.
>>>>> Done.
>>>> Sorry for being picky but the current solution won't print
>>>> anything
>>>> for continuous humongous. Adding the log to
>>>> distribute_marked_bytes()
>>>> would solve this and we would still get info on region type so I
>>>> see
>>>> no need for:
>>> Okay. I think I got your intention right this time :)
>>>
>>>> 1052         log_trace(gc, marking)("Adding " SIZE_FORMAT " words
>>>> to
>>>> humongous start region %u (%s), word size %d (%f)",
>>>> 1053                                marked_words, region_idx,
>>>> hr->get_type_str(),
>>>> 1054                                oop(hr->bottom())->size(),
>>>> (double)oop(hr->bottom())->size() / HeapRegion::GrainWords);
>>> [...]
>>>>> All fixed.
>>>>>
>>>>> Webrevs:
>>>>> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.0_to_1/
>>>>> (diff)
>>>>> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.1/ (full)
>>>> Apart from the small things above this looks great.
>>> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.1_to_2/ (diff)
>>> http://cr.openjdk.java.net/~tschatzl/8178105/webrev.2/ (full)
>> Looks good!
>>
>> Thanks,
>> StefanJ
>>
>>> Ran gc/g1 tests successfully with that change.
>>>
>>> Thanks,
>>>     Thomas
>>>



From per.liden at oracle.com  Thu Apr 12 08:26:45 2018
From: per.liden at oracle.com (Per Liden)
Date: Thu, 12 Apr 2018 10:26:45 +0200
Subject: RFR: 8201362: Remove CollectedHeap::barrier_set()
Message-ID: <22d76df6-b96b-f092-064f-66ed7444cc93@oracle.com>

This patch removes the redundant CollectedHeap::_barrier_set and the
setter/getter. Throughout the code, we currently have a mix of calls to 
BarrierSet::barrier_set() and Universe::heap()->barrier_set(). This 
patch unifies all that to always use BarrierSet::barrier_set().

Bug: https://bugs.openjdk.java.net/browse/JDK-8201362
Webrev: http://cr.openjdk.java.net/~pliden/8201362/webrev.0

/Per


From shade at redhat.com  Thu Apr 12 08:31:02 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 12 Apr 2018 10:31:02 +0200
Subject: RFR: 8201362: Remove CollectedHeap::barrier_set()
In-Reply-To: <22d76df6-b96b-f092-064f-66ed7444cc93@oracle.com>
References: <22d76df6-b96b-f092-064f-66ed7444cc93@oracle.com>
Message-ID: <c677c76f-94e1-9c6b-70f0-45feb88fefc5@redhat.com>

On 04/12/2018 10:26 AM, Per Liden wrote:
> This patch removes the redundant CollectedHeap::_barrier_set and the
> setter/getter. Throughout the code, we currently have a mix of calls to BarrierSet::barrier_set()
> and Universe::heap()->barrier_set(). This patch unifies all that to always use
> BarrierSet::barrier_set().
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201362
> Webrev: http://cr.openjdk.java.net/~pliden/8201362/webrev.0

Yes, please. This looks trivial.

(If we are pushing this today, it is better to do this early, so we would be able to catch up with
build errors before jdk/hs closing today)

-Aleksey



From shade at redhat.com  Thu Apr 12 08:44:34 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 12 Apr 2018 10:44:34 +0200
Subject: RFR: JDK-8201442: objArrayOopDesc::atomic_compare_exchange_oop()
 must use obj+offset in HeapAccess call
In-Reply-To: <1f0c6263-8dfc-1059-cdce-3f1847733dad@redhat.com>
References: <1f0c6263-8dfc-1059-cdce-3f1847733dad@redhat.com>
Message-ID: <2eb38349-cff7-c51f-515e-aa01da27cfee@redhat.com>

On 04/11/2018 09:49 PM, Roman Kennke wrote:
> http://cr.openjdk.java.net/~rkennke/JDK-8201442/webrev.01/

Looks good to me.

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180412/71663fe2/signature.asc>

From rkennke at redhat.com  Thu Apr 12 08:48:30 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 12 Apr 2018 10:48:30 +0200
Subject: RFR: 8201362: Remove CollectedHeap::barrier_set()
In-Reply-To: <c677c76f-94e1-9c6b-70f0-45feb88fefc5@redhat.com>
References: <22d76df6-b96b-f092-064f-66ed7444cc93@oracle.com>
 <c677c76f-94e1-9c6b-70f0-45feb88fefc5@redhat.com>
Message-ID: <a8301a14-0444-eb75-fdaf-2f0af69d3d39@redhat.com>

Am 12.04.2018 um 10:31 schrieb Aleksey Shipilev:
> On 04/12/2018 10:26 AM, Per Liden wrote:
>> This patch removes the redundant CollectedHeap::_barrier_set and the
>> setter/getter. Throughout the code, we currently have a mix of calls to BarrierSet::barrier_set()
>> and Universe::heap()->barrier_set(). This patch unifies all that to always use
>> BarrierSet::barrier_set().
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201362
>> Webrev: http://cr.openjdk.java.net/~pliden/8201362/webrev.0
> 
> Yes, please. This looks trivial.
> 
> (If we are pushing this today, it is better to do this early, so we would be able to catch up with
> build errors before jdk/hs closing today)
> 

I wouldn't say it's trivial ;-) But the change looks good to me too and
is welcome. Thank you!

Roman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180412/33b5b7d0/signature.asc>

From thomas.stuefe at gmail.com  Thu Apr 12 09:02:28 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Apr 2018 11:02:28 +0200
Subject: RFR: 8201362: Remove CollectedHeap::barrier_set()
In-Reply-To: <a8301a14-0444-eb75-fdaf-2f0af69d3d39@redhat.com>
References: <22d76df6-b96b-f092-064f-66ed7444cc93@oracle.com>
 <c677c76f-94e1-9c6b-70f0-45feb88fefc5@redhat.com>
 <a8301a14-0444-eb75-fdaf-2f0af69d3d39@redhat.com>
Message-ID: <CAA-vtUwV5ohiXPV6_N3ycU7bdGmX+1hi1yd6yiO0_xeKQOHkJQ@mail.gmail.com>

Hi Per,

took a quick stab in the dark at
src/hotspot/cpu/s390/templateTable_s390.cpp and it seems to miss, at
first glance, barrierSet.hpp.

Since ppc, s390 and aarch64 are already broken, could we please delay
pushing this until 8201475 is resolved? An hour or so?

Thanks, Thomas

On Thu, Apr 12, 2018 at 10:48 AM, Roman Kennke <rkennke at redhat.com> wrote:
> Am 12.04.2018 um 10:31 schrieb Aleksey Shipilev:
>> On 04/12/2018 10:26 AM, Per Liden wrote:
>>> This patch removes the redundant CollectedHeap::_barrier_set and the
>>> setter/getter. Throughout the code, we currently have a mix of calls to BarrierSet::barrier_set()
>>> and Universe::heap()->barrier_set(). This patch unifies all that to always use
>>> BarrierSet::barrier_set().
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201362
>>> Webrev: http://cr.openjdk.java.net/~pliden/8201362/webrev.0
>>
>> Yes, please. This looks trivial.
>>
>> (If we are pushing this today, it is better to do this early, so we would be able to catch up with
>> build errors before jdk/hs closing today)
>>
>
> I wouldn't say it's trivial ;-) But the change looks good to me too and
> is welcome. Thank you!
>
> Roman
>
>


From erik.osterlund at oracle.com  Thu Apr 12 09:11:08 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Thu, 12 Apr 2018 11:11:08 +0200
Subject: RFR: JDK-8201442: objArrayOopDesc::atomic_compare_exchange_oop()
 must use obj+offset in HeapAccess call
In-Reply-To: <1f0c6263-8dfc-1059-cdce-3f1847733dad@redhat.com>
References: <1f0c6263-8dfc-1059-cdce-3f1847733dad@redhat.com>
Message-ID: <5ACF22AC.30806@oracle.com>

Hi Roman,

Looks good. Would be great to stick that IN_HEAP_ARRAY decorator in the 
mix as well, so that when we decide runtime code should use precise 
marking for arrays, we catch this case. I don't need another webrev for 
that.

Thanks,
/Erik

On 2018-04-11 21:49, Roman Kennke wrote:
> Please review the following little change.
>
>
> objArrayOopDesc::atomic_compare_exchange_oop() currently computes and
> uses a raw pointer to pass to HeapAccess::oop_atomic_cmpxchg(). It
> should use the object+offset variant because it's accessing the heap and
> GC might need to resolve the target object (e.g. Shenandoah).
>
> http://cr.openjdk.java.net/~rkennke/JDK-8201442/webrev.01/
>
> Testing: hotspot-tier1
>
>
> Roman
>



From stefan.johansson at oracle.com  Thu Apr 12 09:09:19 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 12 Apr 2018 11:09:19 +0200
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
 current_end
In-Reply-To: <CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
 <fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
 <3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
 <CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
 <CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
 <3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
 <CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
Message-ID: <5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>



On 2018-04-11 17:48, JC Beyler wrote:
> Hi Stefan,
> 
> Sorry about that, I must have missed adding the files or something. Here 
> is a webrev that added the changes for the SA file:
> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
> 
No problem, this looks good. I kicked of a run in our test system to get 
some more coverage and have tried to include some Graal testing. I'll 
let you know the results once they are done.

Please also update the bug title both in JBS and the changeset.

Cheers,
Stefan

> I changed the method name, which propagated a change to:
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
> 
> I tried testing your test file. It exists in my branch (if the same) under:
> hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
> 
> and interestingly (which generally means I did something wrong), it 
> passed before/after the change so I could not verify that this is a test 
> showing that all is well in the world on my side. Any ideas of what I 
> did wrong?
> 
> I did again test it for?hotspot/jtreg/compiler/aot/ and 
> hotspot/jtreg/serviceability/jvmti and it passes those.
> 
> Thanks for all your help,
> Jc
> 
> 
> 
> On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson 
> <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>> wrote:
> 
>     Hi JC,
> 
>     On 2018-04-11 00:56, JC Beyler wrote:
>      > Small update:
>      >
>      > Here is the fixed webrev for the '{' that were out of alignment.
>     This
>      > passed release build JTREG for?hotspot/jtreg/compiler/jvmti (just
>     to run
>      > something as a smoke screen) and?hotspot/jtreg/compiler/aot/ (to
>     test
>      > Graal).
>      > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
>      >
>     I think this looks better, I agree that leaving _end is tempting to
>     avoid a lot of change, but I think this will be better in the long run.
> 
>     I still miss the changes to make the SA work. To see a problem you
>     can run:
>     make CONF=fast run-test
>     TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
> 
>     Cheers,
>     Stefan
> 
>      > Let me know what you think,
>      > Jc
>      >
>      > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler <jcbeyler at google.com
>     <mailto:jcbeyler at google.com>
>      > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>> wrote:
>      >
>      >? ? ?Hi Karen and Stefan,
>      >
>      >? ? ?@Stefan: Naming is hard :)
>      >? ? ?@Karen: thanks for the Graal comment, I fixed it in the new
>     webrev,
>      >? ? ?let me know what you think :)
>      >
>      >? ? ?I think the naming convention suggested in this webrev came from
>      >? ? ?conversations in for JEP-331 and I am actually relatively
>      >? ? ?indifferent to the final result (as long as we have some form of
>      >? ? ?forward progress :)). To be honest, I'd also be happy to just
>     leave
>      >? ? ?_end as is for all architectures and Graal and have a new
>      >? ? ?_allocation_end. However, during initial reviews of JEP-331
>     it was
>      >? ? ?deemed complicated to understand:
>      >
>      >? ? ?_end -> the _end or sampling end
>      >? ? ?_allocation_end -> end pointer for the last possible allocation
>      >? ? ?hard_end -> allocation end?+ reserved space
>      >
>      >? ? ?That is how this naming came up and why hard_end went to
>     "reserved_end".
>      >
>      >? ? ?I'm really indifferent, so I offer as a perusal:
>      > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
>      >
>      >? ? ?I noticed a few problems of alignement of '{' so I'll go fix
>     that.
>      >? ? ?Basically this webrev does the following:
>      >
>      >? ? ?- Uses fast_path_end instead of end
>      >? ? ?- Reverts hard_end back to where it was
>      >? ? ?- Adds the changes to Graal; there is a bunch of changes in Graal
>      >? ? ?because Graal still contains a bit of code doing fasttlabrefills.
>      >
>      >? ? ?Let me know what you think!
>      >
>      >? ? ?Thanks,
>      >? ? ?Jc
>      >
>      >
>      >? ? ?On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear
>      >? ? ?<karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>
>     <mailto:karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>>>
>     wrote:
>      >
>      >? ? ? ? ?Hi JC,
>      >
>      >? ? ? ? ?A comment about Graal. The impact on Graal for this
>     particular
>      >? ? ? ? ?change would be to break it - so you?ll need
>      >? ? ? ? ?to complete the Graal changes for this renaming. That isn?t
>      >? ? ? ? ?optional or something that could be a follow-on. It
>      >? ? ? ? ?is not ok to break a feature, even an experimental one.
>     We will
>      >? ? ? ? ?discuss in the other thread potential phasing of adding
>     sampling.
>      >
>      >? ? ? ? ?I did not do a thorough search -you can do that - I did find
>      >? ? ? ? ?src/jdk.internal.vm.compiler/share/classes/
>      >       
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? ? ? ? public final int threadTlabOffset =
>      >? ? ? ? ?getFieldOffset("Thread::_tlab", Integer.class,
>      >? ? ? ? ?"ThreadLocalAllocBuffer");
>      >       
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? ? ? ? private final int threadLocalAllocBufferStartOffset =
>      >? ? ? ? ?getFieldOffset("ThreadLocalAllocBuffer::_start",
>     Integer.class,
>      >? ? ? ? ?"HeapWord*");
>      >       
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? ? ? ? private final int threadLocalAllocBufferEndOffset =
>      >? ? ? ? ?getFieldOffset("ThreadLocalAllocBuffer::_end", Integer.class,
>      >? ? ? ? ?"HeapWord*");
>      >       
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? ? ? ? private final int threadLocalAllocBufferTopOffset =
>      >? ? ? ? ?getFieldOffset("ThreadLocalAllocBuffer::_top", Integer.class,
>      >? ? ? ? ?"HeapWord*");
>      >       
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? ? ? ? private final int threadLocalAllocBufferPfTopOffset =
>      >? ? ? ? ?getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
>     Integer.class,
>      >? ? ? ? ?"HeapWord*");
>      >       
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? ? ? ? private final int
>     threadLocalAllocBufferSlowAllocationsOffset
>      >? ? ? ? ?= getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
>      >? ? ? ? ?Integer.class, "unsigned");
>      >       
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? ? ? ? private final int
>     threadLocalAllocBufferFastRefillWasteOffset
>      >? ? ? ? ?=
>     getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
>      >? ? ? ? ?Integer.class, "unsigned");
>      >       
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? ? ? ? private final int
>     threadLocalAllocBufferNumberOfRefillsOffset
>      >? ? ? ? ?=
>     getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
>      >? ? ? ? ?Integer.class, "unsigned");
>      >       
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? ? ? ? private final int
>      >? ? ? ? ?threadLocalAllocBufferRefillWasteLimitOffset =
>      >? ? ? ? ?getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
>      >? ? ? ? ?Integer.class, "size_t");
>      >       
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? ? ? ? private final int
>     threadLocalAllocBufferDesiredSizeOffset =
>      >? ? ? ? ?getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
>      >? ? ? ? ?Integer.class, "size_t");
>      >       
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? ? ? ? public final int tlabAlignmentReserve =
>      >       
>      ?getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
>      >? ? ? ? ?Integer.class, "size_t?);
>      >
>      >? ? ? ? ?hope this helps,
>      >? ? ? ? ?Karen
>      >
>      >>? ? ? ? ?On Apr 10, 2018, at 7:04 AM, Stefan Johansson
>      >>? ? ? ? ?<stefan.johansson at oracle.com
>     <mailto:stefan.johansson at oracle.com>
>      >>? ? ? ? ?<mailto:stefan.johansson at oracle.com
>     <mailto:stefan.johansson at oracle.com>>> wrote:
>      >>
>      >>? ? ? ? ?Hi JC,
>      >>
>      >>? ? ? ? ?I realize that the names have been discussed before but I'm
>      >>? ? ? ? ?leaning towards suggesting something new. We discussed this
>      >>? ? ? ? ?briefly here in the office and others might have different
>      >>? ? ? ? ?opinions. One point that came up is that if we do this
>     change
>      >>? ? ? ? ?and change all usages of JavaThread::tlab_end_offset() it
>      >>? ? ? ? ?would be good to make sure the new name is good. To us
>      >>? ? ? ? ?_current_end is not very descriptive, but naming is hard and
>      >>? ? ? ? ?the best we could come up with is _fast_path_end which would
>      >>? ? ? ? ?give the code:
>      >>? ? ? ? ??cmpptr(end, Address(thread,
>      >>? ? ? ? ?JavaThread::tlab_fast_path_end_offset()));
>      >>? ? ? ? ??jcc(Assembler::above, slow_case);
>      >>
>      >>? ? ? ? ?I think this reads pretty good and is fairly clear. If we do
>      >>? ? ? ? ?this rename I think you can re-use _end in JEP-331
>     instead of
>      >>? ? ? ? ?calling it _allocation_end. But that is a later review :)
>      >>
>      >>? ? ? ? ?Also, is there a good reason for renaming hard_end() to
>      >>? ? ? ? ?reserved_end()?
>      >>
>      >>? ? ? ? ?One additional thing, you need to update the SA to reflect
>      >>? ? ? ? ?this change. I think the only place you need to fix is in:
>      >>       
>      ?src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
>      >>
>      >>? ? ? ? ?Thanks,
>      >>? ? ? ? ?Stefan
>      >>
>      >>? ? ? ? ?On 2018-04-09 19:24, JC Beyler wrote:
>      >>>? ? ? ? ?Hi all,
>      >>>? ? ? ? ?Small pre-amble to this request:
>      >>>? ? ? ? ?In my work to try to get a heap sampler in OpenJDK (via JEP
>      >>>? ? ? ? ?331
>     <https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm
>      >>>? ? ? ? ?trying to reduce the footprint of my change so that the
>      >>>? ? ? ? ?integration can be easier. I was told that generally a JEP
>      >>>? ? ? ? ?webrev should be feature complete and go in at-once.
>     However,
>      >>>? ? ? ? ?with the change touching quite a bit of various code
>     pieces,
>      >>>? ? ? ? ?I was trying to figure out what could be separated as not
>      >>>? ? ? ? ?"part of the feature".
>      >>>? ? ? ? ?I asked around and said that perhaps a solution would be to
>      >>>? ? ? ? ?cut up the renaming of TLAB's end field that I do in that
>      >>>? ? ? ? ?webrev. Because I'm renaming a field in TLAB used by
>     various
>      >>>? ? ? ? ?backends for that work, I have to update every architecture
>      >>>? ? ? ? ?dependent code to reflect it.
>      >>>? ? ? ? ?I entirely understand that perhaps this is not in the
>     habits
>      >>>? ? ? ? ?and very potentially might not be the way things are
>      >>>? ? ? ? ?generally done. If so, I apologize and let me know if you
>      >>>? ? ? ? ?would not want this to go in separately :)
>      >>>? ? ? ? ?Final note: there is still a chance JEP-331 does not go in.
>      >>>? ? ? ? ?If it does not, we can leave the new name in place or I'll
>      >>>? ? ? ? ?happily revert it. I can even create an issue to track this
>      >>>? ? ? ? ?if that makes it easier for all.
>      >>>? ? ? ? ?End of the pre-amble.
>      >>>? ? ? ? ?The 33-line change webrev in question is here:
>      >>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>      >>>? ? ? ? ?I fixed all the architectures and JVMCI and ran a few
>     sanity
>      >>>? ? ? ? ?tests to ensure I had not missed anything.
>      >>>? ? ? ? ?Thanks for your help and I hope this is not too much
>     trouble,
>      >>>? ? ? ? ?Jc
>      >>>? ? ? ? ?Ps: there is a graal change that needs to happen but I was
>      >>>? ? ? ? ?not sure who/where
>     <https://teams.googleplex.com/u/where>
>     <https://teams.googleplex.com/u/where> to
>      >>>? ? ? ? ?ask about it. I was told it could happen in a separate
>      >>>? ? ? ? ?webrev. Can anyone point me to the right direction?
>     Should it
>      >>>? ? ? ? ?just be hotspot-compiler-dev?
>      >
> 


From per.liden at oracle.com  Thu Apr 12 09:11:23 2018
From: per.liden at oracle.com (Per Liden)
Date: Thu, 12 Apr 2018 11:11:23 +0200
Subject: RFR: 8201362: Remove CollectedHeap::barrier_set()
In-Reply-To: <a8301a14-0444-eb75-fdaf-2f0af69d3d39@redhat.com>
References: <22d76df6-b96b-f092-064f-66ed7444cc93@oracle.com>
 <c677c76f-94e1-9c6b-70f0-45feb88fefc5@redhat.com>
 <a8301a14-0444-eb75-fdaf-2f0af69d3d39@redhat.com>
Message-ID: <4576a2a3-7e7f-358e-ef44-630e3025a03f@oracle.com>

On 04/12/2018 10:48 AM, Roman Kennke wrote:
> Am 12.04.2018 um 10:31 schrieb Aleksey Shipilev:
>> On 04/12/2018 10:26 AM, Per Liden wrote:
>>> This patch removes the redundant CollectedHeap::_barrier_set and the
>>> setter/getter. Throughout the code, we currently have a mix of calls to BarrierSet::barrier_set()
>>> and Universe::heap()->barrier_set(). This patch unifies all that to always use
>>> BarrierSet::barrier_set().
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201362
>>> Webrev: http://cr.openjdk.java.net/~pliden/8201362/webrev.0
>>
>> Yes, please. This looks trivial.
>>
>> (If we are pushing this today, it is better to do this early, so we would be able to catch up with
>> build errors before jdk/hs closing today)
>>
> 
> I wouldn't say it's trivial ;-) But the change looks good to me too and
> is welcome. Thank you!

Thanks for reviewing, Aleksey and Roman!

I wouldn't say this is trivial either ;) But since I have two reviews 
now, I agree it's better to push this sooner rather than later, given 
that jdk/hs will close.

It's currently running in mach5, I'll push as soon as I see that 
everything looks green.

/Per

> 
> Roman
> 
> 


From thomas.stuefe at gmail.com  Thu Apr 12 09:13:12 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Apr 2018 11:13:12 +0200
Subject: RFR: 8201362: Remove CollectedHeap::barrier_set()
In-Reply-To: <CAA-vtUwV5ohiXPV6_N3ycU7bdGmX+1hi1yd6yiO0_xeKQOHkJQ@mail.gmail.com>
References: <22d76df6-b96b-f092-064f-66ed7444cc93@oracle.com>
 <c677c76f-94e1-9c6b-70f0-45feb88fefc5@redhat.com>
 <a8301a14-0444-eb75-fdaf-2f0af69d3d39@redhat.com>
 <CAA-vtUwV5ohiXPV6_N3ycU7bdGmX+1hi1yd6yiO0_xeKQOHkJQ@mail.gmail.com>
Message-ID: <CAA-vtUwa5E+5uDM6C8NW83S+S5Od1X=P5StCSPP7FMuqRQbVTw@mail.gmail.com>

I pushed 8201475, all good now. Thanks.

On Thu, Apr 12, 2018 at 11:02 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> Hi Per,
>
> took a quick stab in the dark at
> src/hotspot/cpu/s390/templateTable_s390.cpp and it seems to miss, at
> first glance, barrierSet.hpp.
>
> Since ppc, s390 and aarch64 are already broken, could we please delay
> pushing this until 8201475 is resolved? An hour or so?
>
> Thanks, Thomas
>
> On Thu, Apr 12, 2018 at 10:48 AM, Roman Kennke <rkennke at redhat.com> wrote:
>> Am 12.04.2018 um 10:31 schrieb Aleksey Shipilev:
>>> On 04/12/2018 10:26 AM, Per Liden wrote:
>>>> This patch removes the redundant CollectedHeap::_barrier_set and the
>>>> setter/getter. Throughout the code, we currently have a mix of calls to BarrierSet::barrier_set()
>>>> and Universe::heap()->barrier_set(). This patch unifies all that to always use
>>>> BarrierSet::barrier_set().
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201362
>>>> Webrev: http://cr.openjdk.java.net/~pliden/8201362/webrev.0
>>>
>>> Yes, please. This looks trivial.
>>>
>>> (If we are pushing this today, it is better to do this early, so we would be able to catch up with
>>> build errors before jdk/hs closing today)
>>>
>>
>> I wouldn't say it's trivial ;-) But the change looks good to me too and
>> is welcome. Thank you!
>>
>> Roman
>>
>>


From per.liden at oracle.com  Thu Apr 12 09:17:06 2018
From: per.liden at oracle.com (Per Liden)
Date: Thu, 12 Apr 2018 11:17:06 +0200
Subject: RFR: 8201362: Remove CollectedHeap::barrier_set()
In-Reply-To: <CAA-vtUwa5E+5uDM6C8NW83S+S5Od1X=P5StCSPP7FMuqRQbVTw@mail.gmail.com>
References: <22d76df6-b96b-f092-064f-66ed7444cc93@oracle.com>
 <c677c76f-94e1-9c6b-70f0-45feb88fefc5@redhat.com>
 <a8301a14-0444-eb75-fdaf-2f0af69d3d39@redhat.com>
 <CAA-vtUwV5ohiXPV6_N3ycU7bdGmX+1hi1yd6yiO0_xeKQOHkJQ@mail.gmail.com>
 <CAA-vtUwa5E+5uDM6C8NW83S+S5Od1X=P5StCSPP7FMuqRQbVTw@mail.gmail.com>
Message-ID: <92528b68-eb67-d5f9-8ee9-11a560c93646@oracle.com>

Ok, thanks Thomas!

Do you want to double check that 8201362 doesn't break more stuff before 
I push it, or are we good to go?

/Per

On 04/12/2018 11:13 AM, Thomas St?fe wrote:
> I pushed 8201475, all good now. Thanks.
> 
> On Thu, Apr 12, 2018 at 11:02 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>> Hi Per,
>>
>> took a quick stab in the dark at
>> src/hotspot/cpu/s390/templateTable_s390.cpp and it seems to miss, at
>> first glance, barrierSet.hpp.
>>
>> Since ppc, s390 and aarch64 are already broken, could we please delay
>> pushing this until 8201475 is resolved? An hour or so?
>>
>> Thanks, Thomas
>>
>> On Thu, Apr 12, 2018 at 10:48 AM, Roman Kennke <rkennke at redhat.com> wrote:
>>> Am 12.04.2018 um 10:31 schrieb Aleksey Shipilev:
>>>> On 04/12/2018 10:26 AM, Per Liden wrote:
>>>>> This patch removes the redundant CollectedHeap::_barrier_set and the
>>>>> setter/getter. Throughout the code, we currently have a mix of calls to BarrierSet::barrier_set()
>>>>> and Universe::heap()->barrier_set(). This patch unifies all that to always use
>>>>> BarrierSet::barrier_set().
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201362
>>>>> Webrev: http://cr.openjdk.java.net/~pliden/8201362/webrev.0
>>>>
>>>> Yes, please. This looks trivial.
>>>>
>>>> (If we are pushing this today, it is better to do this early, so we would be able to catch up with
>>>> build errors before jdk/hs closing today)
>>>>
>>>
>>> I wouldn't say it's trivial ;-) But the change looks good to me too and
>>> is welcome. Thank you!
>>>
>>> Roman
>>>
>>>


From stefan.johansson at oracle.com  Thu Apr 12 09:17:39 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 12 Apr 2018 11:17:39 +0200
Subject: RFR (M): 8201172: Parallelize Remset Tracking Update Before
 Rebuild phase
In-Reply-To: <1523446979.9657.4.camel@oracle.com>
References: <1523272611.4326.30.camel@oracle.com>
 <f0f0d1e2-be9f-e0b7-a8ed-af145464f8f0@oracle.com>
 <1523446979.9657.4.camel@oracle.com>
Message-ID: <54166fce-8a91-3305-90df-2b247ebb93dd@oracle.com>

Thanks Thomas,

This looks good,
Stefan

On 2018-04-11 13:42, Thomas Schatzl wrote:
> Hi Stefan,
> 
> On Tue, 2018-04-10 at 14:29 +0200, Stefan Johansson wrote:
>> Hi Thomas,
>>
>> On 2018-04-09 13:16, Thomas Schatzl wrote:
>>> Hi all,
>>>
>>>     can I have reviews for this straightforward change that improves
>>> the
>>> "Remset Tracking Update Before Rebuild" phase of the Remark pause?
>>>
>>> Performance of this phase has not been a big issue, with ~3000
>>> regions
>>> you get around 1ms of time taken, but now it's even faster and
>>> hopefully if run with 30k regions, there are no nasty suprises (or
>>> not
>>> as nasty at least).
>>>
>>> Determining the number of threads to use has been done by doing a
>>> few
>>> measurements and tests and look at which point there does not seem
>>> to
>>> be any more scaling (i.e. the noise seems higher than the
>>> improvements), and the pause time much smaller than a millisecond.
>>>
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8201172
>>> Webrev:
>>> http://cr.openjdk.java.net/~tschatzl/8201172/webrev/
>>
>> Looks good, just a few minor things:
>> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
>> 1108     G1UpdateRemSetTrackingBeforeRebuild cl(_g1h, _cm, &_cl);
>> 1109     _g1h->heap_region_par_iterate_from_worker_offset(&cl,
>> &_hrclaimer, worker_id);
>> 1110     Atomic::add(cl.num_selected_for_rebuild(),
>> &_num_selected_for_rebuild);
>>
>> Using the same names for all closures and and having
>> num_selected_for_rebuild in both the task and the closure, makes
>> this code a bit hard to follow. I suggest calling the task member
>> _total_selected_for_rebuild and also have the getter name match the
>> member for the closure.
>>
>> For the closures I'm fine with the members being named _cl, but it
>> would help if the instance above were name something else, like
>> rebuild.
> 
> Done.
> 
> http://cr.openjdk.java.net/~tschatzl/8201172/webrev.0_to_1 (diff)
> http://cr.openjdk.java.net/~tschatzl/8201172/webrev.1 (full)
> 
> This change contains one difference that I actually forgot to fix in
> the last webrev - my notes tell me that the "best" value for
> RegionsPerThread is 384, not 512. I forgot to change this after fixing
> the ceil() operation in line 1174. I.e. originally I had
> align_size_up() there, but it requires a power-of-2 alignment value,
> that of course asserted when using 384. I fixed the align_size_up, but
> did not change the RegionsPerThread value. Sorry.
> 
> Thanks,
>    Thomas
> 


From thomas.stuefe at gmail.com  Thu Apr 12 09:17:54 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Apr 2018 11:17:54 +0200
Subject: RFR: 8201362: Remove CollectedHeap::barrier_set()
In-Reply-To: <92528b68-eb67-d5f9-8ee9-11a560c93646@oracle.com>
References: <22d76df6-b96b-f092-064f-66ed7444cc93@oracle.com>
 <c677c76f-94e1-9c6b-70f0-45feb88fefc5@redhat.com>
 <a8301a14-0444-eb75-fdaf-2f0af69d3d39@redhat.com>
 <CAA-vtUwV5ohiXPV6_N3ycU7bdGmX+1hi1yd6yiO0_xeKQOHkJQ@mail.gmail.com>
 <CAA-vtUwa5E+5uDM6C8NW83S+S5Od1X=P5StCSPP7FMuqRQbVTw@mail.gmail.com>
 <92528b68-eb67-d5f9-8ee9-11a560c93646@oracle.com>
Message-ID: <CAA-vtUw_f5x7H-fTYsiCqfZzmnT7Q9PddNDPP9CaBh26qssg2Q@mail.gmail.com>

Sure, give me a minute...

..Thomas

On Thu, Apr 12, 2018 at 11:17 AM, Per Liden <per.liden at oracle.com> wrote:
> Ok, thanks Thomas!
>
> Do you want to double check that 8201362 doesn't break more stuff before I
> push it, or are we good to go?
>
> /Per
>
>
> On 04/12/2018 11:13 AM, Thomas St?fe wrote:
>>
>> I pushed 8201475, all good now. Thanks.
>>
>> On Thu, Apr 12, 2018 at 11:02 AM, Thomas St?fe <thomas.stuefe at gmail.com>
>> wrote:
>>>
>>> Hi Per,
>>>
>>> took a quick stab in the dark at
>>> src/hotspot/cpu/s390/templateTable_s390.cpp and it seems to miss, at
>>> first glance, barrierSet.hpp.
>>>
>>> Since ppc, s390 and aarch64 are already broken, could we please delay
>>> pushing this until 8201475 is resolved? An hour or so?
>>>
>>> Thanks, Thomas
>>>
>>> On Thu, Apr 12, 2018 at 10:48 AM, Roman Kennke <rkennke at redhat.com>
>>> wrote:
>>>>
>>>> Am 12.04.2018 um 10:31 schrieb Aleksey Shipilev:
>>>>>
>>>>> On 04/12/2018 10:26 AM, Per Liden wrote:
>>>>>>
>>>>>> This patch removes the redundant CollectedHeap::_barrier_set and the
>>>>>> setter/getter. Throughout the code, we currently have a mix of calls
>>>>>> to BarrierSet::barrier_set()
>>>>>> and Universe::heap()->barrier_set(). This patch unifies all that to
>>>>>> always use
>>>>>> BarrierSet::barrier_set().
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201362
>>>>>> Webrev: http://cr.openjdk.java.net/~pliden/8201362/webrev.0
>>>>>
>>>>>
>>>>> Yes, please. This looks trivial.
>>>>>
>>>>> (If we are pushing this today, it is better to do this early, so we
>>>>> would be able to catch up with
>>>>> build errors before jdk/hs closing today)
>>>>>
>>>>
>>>> I wouldn't say it's trivial ;-) But the change looks good to me too and
>>>> is welcome. Thank you!
>>>>
>>>> Roman
>>>>
>>>>
>


From thomas.stuefe at gmail.com  Thu Apr 12 09:51:15 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Apr 2018 11:51:15 +0200
Subject: RFR: 8201362: Remove CollectedHeap::barrier_set()
In-Reply-To: <CAA-vtUw_f5x7H-fTYsiCqfZzmnT7Q9PddNDPP9CaBh26qssg2Q@mail.gmail.com>
References: <22d76df6-b96b-f092-064f-66ed7444cc93@oracle.com>
 <c677c76f-94e1-9c6b-70f0-45feb88fefc5@redhat.com>
 <a8301a14-0444-eb75-fdaf-2f0af69d3d39@redhat.com>
 <CAA-vtUwV5ohiXPV6_N3ycU7bdGmX+1hi1yd6yiO0_xeKQOHkJQ@mail.gmail.com>
 <CAA-vtUwa5E+5uDM6C8NW83S+S5Od1X=P5StCSPP7FMuqRQbVTw@mail.gmail.com>
 <92528b68-eb67-d5f9-8ee9-11a560c93646@oracle.com>
 <CAA-vtUw_f5x7H-fTYsiCqfZzmnT7Q9PddNDPP9CaBh26qssg2Q@mail.gmail.com>
Message-ID: <CAA-vtUw3ew7e9W5_-DmUwr=E3qjPEPxMjS5ZY3JHy9xz1bpgsA@mail.gmail.com>

Hi Per,

I did build on AIX and linux s390 with your patch, builds are okay.
Thanks for waiting!

..Thomas

On Thu, Apr 12, 2018 at 11:17 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> Sure, give me a minute...
>
> ..Thomas
>
> On Thu, Apr 12, 2018 at 11:17 AM, Per Liden <per.liden at oracle.com> wrote:
>> Ok, thanks Thomas!
>>
>> Do you want to double check that 8201362 doesn't break more stuff before I
>> push it, or are we good to go?
>>
>> /Per
>>
>>
>> On 04/12/2018 11:13 AM, Thomas St?fe wrote:
>>>
>>> I pushed 8201475, all good now. Thanks.
>>>
>>> On Thu, Apr 12, 2018 at 11:02 AM, Thomas St?fe <thomas.stuefe at gmail.com>
>>> wrote:
>>>>
>>>> Hi Per,
>>>>
>>>> took a quick stab in the dark at
>>>> src/hotspot/cpu/s390/templateTable_s390.cpp and it seems to miss, at
>>>> first glance, barrierSet.hpp.
>>>>
>>>> Since ppc, s390 and aarch64 are already broken, could we please delay
>>>> pushing this until 8201475 is resolved? An hour or so?
>>>>
>>>> Thanks, Thomas
>>>>
>>>> On Thu, Apr 12, 2018 at 10:48 AM, Roman Kennke <rkennke at redhat.com>
>>>> wrote:
>>>>>
>>>>> Am 12.04.2018 um 10:31 schrieb Aleksey Shipilev:
>>>>>>
>>>>>> On 04/12/2018 10:26 AM, Per Liden wrote:
>>>>>>>
>>>>>>> This patch removes the redundant CollectedHeap::_barrier_set and the
>>>>>>> setter/getter. Throughout the code, we currently have a mix of calls
>>>>>>> to BarrierSet::barrier_set()
>>>>>>> and Universe::heap()->barrier_set(). This patch unifies all that to
>>>>>>> always use
>>>>>>> BarrierSet::barrier_set().
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201362
>>>>>>> Webrev: http://cr.openjdk.java.net/~pliden/8201362/webrev.0
>>>>>>
>>>>>>
>>>>>> Yes, please. This looks trivial.
>>>>>>
>>>>>> (If we are pushing this today, it is better to do this early, so we
>>>>>> would be able to catch up with
>>>>>> build errors before jdk/hs closing today)
>>>>>>
>>>>>
>>>>> I wouldn't say it's trivial ;-) But the change looks good to me too and
>>>>> is welcome. Thank you!
>>>>>
>>>>> Roman
>>>>>
>>>>>
>>


From thomas.schatzl at oracle.com  Thu Apr 12 10:01:46 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 12 Apr 2018 12:01:46 +0200
Subject: RFR (M): 8201172: Parallelize Remset Tracking Update Before
 Rebuild phase
In-Reply-To: <54166fce-8a91-3305-90df-2b247ebb93dd@oracle.com>
References: <1523272611.4326.30.camel@oracle.com>
 <f0f0d1e2-be9f-e0b7-a8ed-af145464f8f0@oracle.com>
 <1523446979.9657.4.camel@oracle.com>
 <54166fce-8a91-3305-90df-2b247ebb93dd@oracle.com>
Message-ID: <1523527306.2349.0.camel@oracle.com>

Hi,

On Thu, 2018-04-12 at 11:17 +0200, Stefan Johansson wrote:
> Thanks Thomas,
> 
> This looks good,
> Stefan
> 

  thanks for your review.

Thomas


From thomas.schatzl at oracle.com  Thu Apr 12 10:02:33 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 12 Apr 2018 12:02:33 +0200
Subject: RFR (S/M): 8178105: Switch mark bitmaps during Remark
In-Reply-To: <826503d3-a373-ac7b-aeeb-5e4168e0cbaa@oracle.com>
References: <1522334136.2451.15.camel@oracle.com>
 <c4a8f532-db1b-09f8-5b9d-aa76f2f6ae4d@oracle.com>
 <1522758329.2573.9.camel@oracle.com>
 <09b374ab-a86f-bcff-00f4-4b2874fb59ff@oracle.com>
 <1522767307.2582.2.camel@oracle.com>
 <1b5b0099-97da-35b6-99c1-628e5adf75ea@oracle.com>
 <1522845771.2398.26.camel@oracle.com>
 <826503d3-a373-ac7b-aeeb-5e4168e0cbaa@oracle.com>
Message-ID: <1523527353.2349.1.camel@oracle.com>

Hi Sangheon, Stefan,

  thanks for your reviews.

Thomas

On Wed, 2018-04-11 at 21:47 -0700, sangheon.kim wrote:
> Hi Thomas,
> 
> On 04/04/2018 05:42 AM, Thomas Schatzl wrote:
> > Hi all,
> > 
> >    while looking at some parallelizing work in this area I noticed
> > that one assert in the rebuild remsets code that has been changed
> > in this change already needs an update too.
> > It uses a wrong value for the informational text, which makes it
> > really confusing.
> > 
> > Since this change touches this code already, I would like to amend
> > this change with this small fix:
> > 
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8178105/webrev.2_to_3/ (diff)
> > http://cr.openjdk.java.net/~tschatzl/8178105/webrev.3/ (full)
> 
> Webrev.3 looks good.
> 
> Thanks,
> Sangheon
> 
> 
> > 
> > Sorry for the trouble.
> > 
> > Thanks,
> >    Thomas
> > 
> > On Tue, 2018-04-03 at 17:00 +0200, Stefan Johansson wrote:
> > > On 2018-04-03 16:55, Thomas Schatzl wrote:
> > > > Hi,
> > > > 
> > > >     thanks for your patience...
> > > > 
> > > > On Tue, 2018-04-03 at 14:49 +0200, Stefan Johansson wrote:
> > > > > On 2018-04-03 14:25, Thomas Schatzl wrote:
> > > > > > Hi Stefan,
> > > > > > 
> > > > > > On Tue, 2018-04-03 at 12:58 +0200, Stefan Johansson wrote:
> > > > > > > Hi Thomas,
> > > > > > > 
> > > > > > > On 2018-03-29 16:35, Thomas Schatzl wrote:
> > > > > > > > Hi all,
> > > > > > > > [...]
> > > > > > > > 
> > > > > > > > CR:
> > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8178105
> > > > > > > > Webrev:
> > > > > > > > http://cr.openjdk.java.net/~tschatzl/8178105/
> > > > > > > 
> > > > > > >     Looks good, but a few comments:
> > > > > > > 
> > > > 
> > > > [...]
> > > > > > I added a different kind of check that verifies what you
> > > > > > probably
> > > > > > thought of, and that is that the number of words to add to
> > > > > > the
> > > > > > current region must always be larger than zero. If it is
> > > > > > zero,
> > > > > > there is something really wrong.
> > > > > 
> > > > > Exactly, that's what I wanted. But I don't see that check
> > > > > now,
> > > > > just
> > > > > having a assert(marked_words != 0, "") on row 1032 would be
> > > > > enough.
> > > > 
> > > > My fault. I did not upload the latest version of the change :(
> > > > It
> > > > is up
> > > > now, the only difference to previous is line
> > > > 
> > > > 1036       assert(words_to_add > 0, "Out of space to distribute
> > > > before
> > > > end of humongous object in region %u (starts %u)", i,
> > > > region_idx);
> > > > 
> > > > But there is a new webrev anyway... in the 1_to_2 webrev it is
> > > > line
> > > > 1033
> > > > 
> > > > > > > 1047       log_trace(gc)("Added " SIZE_FORMAT " words to
> > > > > > > region
> > > > > > > %u
> > > > > > > (%s)", marked_words, region_idx, hr->get_type_str());
> > > > > > > I think the logging should use at least one more tag,
> > > > > > > maybe
> > > > > > > "region" or "marking", but you probably know what makes
> > > > > > > most
> > > > > > > sense in this area. I also think it would be nice if we
> > > > > > > got
> > > > > > > this
> > > > > > > same log-line for all regions. Now we get this for
> > > > > > > "normal"
> > > > > > > regions, but we get "Distributing..." for humongous start
> > > > > > > regions
> > > > > > > and "Not Added..." for humongous continuous. So I would
> > > > > > > suggest
> > > > > > > adding the same log-line  to the distribute-function
> > > > > > > after
> > > > > > > line
> > > > > > > 1034.
> > > > > > 
> > > > > > Done.
> > > > > 
> > > > > Sorry for being picky but the current solution won't print
> > > > > anything
> > > > > for continuous humongous. Adding the log to
> > > > > distribute_marked_bytes()
> > > > > would solve this and we would still get info on region type
> > > > > so I
> > > > > see
> > > > > no need for:
> > > > 
> > > > Okay. I think I got your intention right this time :)
> > > > 
> > > > > 1052         log_trace(gc, marking)("Adding " SIZE_FORMAT "
> > > > > words
> > > > > to
> > > > > humongous start region %u (%s), word size %d (%f)",
> > > > > 1053                                marked_words, region_idx,
> > > > > hr->get_type_str(),
> > > > > 1054                                oop(hr->bottom())-
> > > > > >size(),
> > > > > (double)oop(hr->bottom())->size() / HeapRegion::GrainWords);
> > > > 
> > > > [...]
> > > > > > All fixed.
> > > > > > 
> > > > > > Webrevs:
> > > > > > http://cr.openjdk.java.net/~tschatzl/8178105/webrev.0_to_1/
> > > > > > (diff)
> > > > > > http://cr.openjdk.java.net/~tschatzl/8178105/webrev.1/
> > > > > > (full)
> > > > > 
> > > > > Apart from the small things above this looks great.
> > > > 
> > > > http://cr.openjdk.java.net/~tschatzl/8178105/webrev.1_to_2/
> > > > (diff)
> > > > http://cr.openjdk.java.net/~tschatzl/8178105/webrev.2/ (full)
> > > 
> > > Looks good!
> > > 
> > > Thanks,
> > > StefanJ
> > > 
> > > > Ran gc/g1 tests successfully with that change.
> > > > 
> > > > Thanks,
> > > >     Thomas
> > > > 
> 
> 



From per.liden at oracle.com  Thu Apr 12 10:05:51 2018
From: per.liden at oracle.com (Per Liden)
Date: Thu, 12 Apr 2018 12:05:51 +0200
Subject: RFR: 8201362: Remove CollectedHeap::barrier_set()
In-Reply-To: <CAA-vtUw3ew7e9W5_-DmUwr=E3qjPEPxMjS5ZY3JHy9xz1bpgsA@mail.gmail.com>
References: <22d76df6-b96b-f092-064f-66ed7444cc93@oracle.com>
 <c677c76f-94e1-9c6b-70f0-45feb88fefc5@redhat.com>
 <a8301a14-0444-eb75-fdaf-2f0af69d3d39@redhat.com>
 <CAA-vtUwV5ohiXPV6_N3ycU7bdGmX+1hi1yd6yiO0_xeKQOHkJQ@mail.gmail.com>
 <CAA-vtUwa5E+5uDM6C8NW83S+S5Od1X=P5StCSPP7FMuqRQbVTw@mail.gmail.com>
 <92528b68-eb67-d5f9-8ee9-11a560c93646@oracle.com>
 <CAA-vtUw_f5x7H-fTYsiCqfZzmnT7Q9PddNDPP9CaBh26qssg2Q@mail.gmail.com>
 <CAA-vtUw3ew7e9W5_-DmUwr=E3qjPEPxMjS5ZY3JHy9xz1bpgsA@mail.gmail.com>
Message-ID: <96928866-2e48-ad2f-7cd3-0385d64a0cf8@oracle.com>

Thanks for verifying, Thomas!

/Per

On 04/12/2018 11:51 AM, Thomas St?fe wrote:
> Hi Per,
> 
> I did build on AIX and linux s390 with your patch, builds are okay.
> Thanks for waiting!
> 
> ..Thomas
> 
> On Thu, Apr 12, 2018 at 11:17 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>> Sure, give me a minute...
>>
>> ..Thomas
>>
>> On Thu, Apr 12, 2018 at 11:17 AM, Per Liden <per.liden at oracle.com> wrote:
>>> Ok, thanks Thomas!
>>>
>>> Do you want to double check that 8201362 doesn't break more stuff before I
>>> push it, or are we good to go?
>>>
>>> /Per
>>>
>>>
>>> On 04/12/2018 11:13 AM, Thomas St?fe wrote:
>>>>
>>>> I pushed 8201475, all good now. Thanks.
>>>>
>>>> On Thu, Apr 12, 2018 at 11:02 AM, Thomas St?fe <thomas.stuefe at gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi Per,
>>>>>
>>>>> took a quick stab in the dark at
>>>>> src/hotspot/cpu/s390/templateTable_s390.cpp and it seems to miss, at
>>>>> first glance, barrierSet.hpp.
>>>>>
>>>>> Since ppc, s390 and aarch64 are already broken, could we please delay
>>>>> pushing this until 8201475 is resolved? An hour or so?
>>>>>
>>>>> Thanks, Thomas
>>>>>
>>>>> On Thu, Apr 12, 2018 at 10:48 AM, Roman Kennke <rkennke at redhat.com>
>>>>> wrote:
>>>>>>
>>>>>> Am 12.04.2018 um 10:31 schrieb Aleksey Shipilev:
>>>>>>>
>>>>>>> On 04/12/2018 10:26 AM, Per Liden wrote:
>>>>>>>>
>>>>>>>> This patch removes the redundant CollectedHeap::_barrier_set and the
>>>>>>>> setter/getter. Throughout the code, we currently have a mix of calls
>>>>>>>> to BarrierSet::barrier_set()
>>>>>>>> and Universe::heap()->barrier_set(). This patch unifies all that to
>>>>>>>> always use
>>>>>>>> BarrierSet::barrier_set().
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201362
>>>>>>>> Webrev: http://cr.openjdk.java.net/~pliden/8201362/webrev.0
>>>>>>>
>>>>>>>
>>>>>>> Yes, please. This looks trivial.
>>>>>>>
>>>>>>> (If we are pushing this today, it is better to do this early, so we
>>>>>>> would be able to catch up with
>>>>>>> build errors before jdk/hs closing today)
>>>>>>>
>>>>>>
>>>>>> I wouldn't say it's trivial ;-) But the change looks good to me too and
>>>>>> is welcome. Thank you!
>>>>>>
>>>>>> Roman
>>>>>>
>>>>>>
>>>


From rkennke at redhat.com  Thu Apr 12 10:23:17 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 12 Apr 2018 12:23:17 +0200
Subject: RFR: JDK-8201442: objArrayOopDesc::atomic_compare_exchange_oop()
 must use obj+offset in HeapAccess call
In-Reply-To: <5ACF22AC.30806@oracle.com>
References: <1f0c6263-8dfc-1059-cdce-3f1847733dad@redhat.com>
 <5ACF22AC.30806@oracle.com>
Message-ID: <e8ad1c03-c7f2-8fd9-9f90-46245c0a78be@redhat.com>

Thanks Erik & Aleksey for reviewing!

I just submitted the change for testing.

I do need to wait 24h from posting RFR, do I? That means it's gonna miss
the integration and need to wait till next week. Or do you think it's
safe to go ahead and push it, given that submit repo comes back green?

Thanks, Roman

> Looks good. Would be great to stick that IN_HEAP_ARRAY decorator in the
> mix as well, so that when we decide runtime code should use precise
> marking for arrays, we catch this case. I don't need another webrev for
> that.
> 
> Thanks,
> /Erik
> 
> On 2018-04-11 21:49, Roman Kennke wrote:
>> Please review the following little change.
>>
>>
>> objArrayOopDesc::atomic_compare_exchange_oop() currently computes and
>> uses a raw pointer to pass to HeapAccess::oop_atomic_cmpxchg(). It
>> should use the object+offset variant because it's accessing the heap and
>> GC might need to resolve the target object (e.g. Shenandoah).
>>
>> http://cr.openjdk.java.net/~rkennke/JDK-8201442/webrev.01/
>>
>> Testing: hotspot-tier1
>>
>>
>> Roman
>>
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180412/51c864e2/signature.asc>

From rkennke at redhat.com  Thu Apr 12 12:47:24 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 12 Apr 2018 14:47:24 +0200
Subject: RFR: JDK-8201442: objArrayOopDesc::atomic_compare_exchange_oop()
 must use obj+offset in HeapAccess call
In-Reply-To: <e8ad1c03-c7f2-8fd9-9f90-46245c0a78be@redhat.com>
References: <1f0c6263-8dfc-1059-cdce-3f1847733dad@redhat.com>
 <5ACF22AC.30806@oracle.com> <e8ad1c03-c7f2-8fd9-9f90-46245c0a78be@redhat.com>
Message-ID: <42d2c948-55bc-8d96-f9b4-31209bd41d3c@redhat.com>

Mach5 is not clean (see below). Can someone with access please have a look?

Thanks, Roman


Build Details: 2018-04-12-1133048.roman.source
0 Failed Tests
Mach5 Tasks Results Summary

    PASSED: 60
    UNABLE_TO_RUN: 21
    EXECUTED_WITH_FAILURE: 2
    NA: 0
    KILLED: 0
    FAILED: 0
    Build

        2 Not run
            build_jdk_windows-windows-x64-windows-x64-build-10 error
while building, return value: 2
            build_jdk_windows-windows-x64-debug-windows-x64-build-11
error while building, return value: 2

    Test

        21 Not run

tier1-product-jdk_closed_test_hotspot_jtreg_tier1_common-windows-x64-22
Dependency task failed: YLFraZAoY

tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_common-windows-x64-debug-58
Dependency task failed: YLFraZApY

tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_compiler_closed-windows-x64-debug-61
Dependency task failed: YLFraZApY

tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_gc_closed-windows-x64-debug-64
Dependency task failed: YLFraZApY

tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_runtime-windows-x64-debug-67
Dependency task failed: YLFraZApY
            jdk_closed_test_jdk_tier1-windows-x64-77 Dependency task
failed: YLFraZAoY

tier1-product-jdk_open_test_hotspot_jtreg_tier1_common-windows-x64-16
Dependency task failed: YLFraZAoY

tier1-debug-jdk_open_test_hotspot_jtreg_tier1_common-windows-x64-debug-25
Dependency task failed: YLFraZApY

tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_1-windows-x64-debug-28
Dependency task failed: YLFraZApY

tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-debug-31
Dependency task failed: YLFraZApY


> Thanks Erik & Aleksey for reviewing!
> 
> I just submitted the change for testing.
> 
> I do need to wait 24h from posting RFR, do I? That means it's gonna miss
> the integration and need to wait till next week. Or do you think it's
> safe to go ahead and push it, given that submit repo comes back green?
> 
> Thanks, Roman
> 
>> Looks good. Would be great to stick that IN_HEAP_ARRAY decorator in the
>> mix as well, so that when we decide runtime code should use precise
>> marking for arrays, we catch this case. I don't need another webrev for
>> that.
>>
>> Thanks,
>> /Erik
>>
>> On 2018-04-11 21:49, Roman Kennke wrote:
>>> Please review the following little change.
>>>
>>>
>>> objArrayOopDesc::atomic_compare_exchange_oop() currently computes and
>>> uses a raw pointer to pass to HeapAccess::oop_atomic_cmpxchg(). It
>>> should use the object+offset variant because it's accessing the heap and
>>> GC might need to resolve the target object (e.g. Shenandoah).
>>>
>>> http://cr.openjdk.java.net/~rkennke/JDK-8201442/webrev.01/
>>>
>>> Testing: hotspot-tier1
>>>
>>>
>>> Roman
>>>
>>
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180412/f71d3502/signature.asc>

From stefan.karlsson at oracle.com  Thu Apr 12 13:11:36 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 12 Apr 2018 15:11:36 +0200
Subject: RFR: JDK-8201442: objArrayOopDesc::atomic_compare_exchange_oop()
 must use obj+offset in HeapAccess call
In-Reply-To: <42d2c948-55bc-8d96-f9b4-31209bd41d3c@redhat.com>
References: <1f0c6263-8dfc-1059-cdce-3f1847733dad@redhat.com>
 <5ACF22AC.30806@oracle.com> <e8ad1c03-c7f2-8fd9-9f90-46245c0a78be@redhat.com>
 <42d2c948-55bc-8d96-f9b4-31209bd41d3c@redhat.com>
Message-ID: <e514f79f-56ea-64f9-e128-e9f94bd31e73@oracle.com>

Hi Roman,

It looks like a mismatch between your open code and our closed code.

Can you verify that you have the following changeset?:

changeset:   49651:4ae63fcabe2e
user:        rwestberg
date:        Mon Apr 09 10:09:38 2018 +0200
summary:     8199736: Define WIN32_LEAN_AND_MEAN before including windows.h

StefanK


On 2018-04-12 14:47, Roman Kennke wrote:
> Mach5 is not clean (see below). Can someone with access please have a look?
> 
> Thanks, Roman
> 
> 
> Build Details: 2018-04-12-1133048.roman.source
> 0 Failed Tests
> Mach5 Tasks Results Summary
> 
>      PASSED: 60
>      UNABLE_TO_RUN: 21
>      EXECUTED_WITH_FAILURE: 2
>      NA: 0
>      KILLED: 0
>      FAILED: 0
>      Build
> 
>          2 Not run
>              build_jdk_windows-windows-x64-windows-x64-build-10 error
> while building, return value: 2
>              build_jdk_windows-windows-x64-debug-windows-x64-build-11
> error while building, return value: 2
> 
>      Test
> 
>          21 Not run
> 
> tier1-product-jdk_closed_test_hotspot_jtreg_tier1_common-windows-x64-22
> Dependency task failed: YLFraZAoY
> 
> tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_common-windows-x64-debug-58
> Dependency task failed: YLFraZApY
> 
> tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_compiler_closed-windows-x64-debug-61
> Dependency task failed: YLFraZApY
> 
> tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_gc_closed-windows-x64-debug-64
> Dependency task failed: YLFraZApY
> 
> tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_runtime-windows-x64-debug-67
> Dependency task failed: YLFraZApY
>              jdk_closed_test_jdk_tier1-windows-x64-77 Dependency task
> failed: YLFraZAoY
> 
> tier1-product-jdk_open_test_hotspot_jtreg_tier1_common-windows-x64-16
> Dependency task failed: YLFraZAoY
> 
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_common-windows-x64-debug-25
> Dependency task failed: YLFraZApY
> 
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_1-windows-x64-debug-28
> Dependency task failed: YLFraZApY
> 
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-debug-31
> Dependency task failed: YLFraZApY
> 
> 
>> Thanks Erik & Aleksey for reviewing!
>>
>> I just submitted the change for testing.
>>
>> I do need to wait 24h from posting RFR, do I? That means it's gonna miss
>> the integration and need to wait till next week. Or do you think it's
>> safe to go ahead and push it, given that submit repo comes back green?
>>
>> Thanks, Roman
>>
>>> Looks good. Would be great to stick that IN_HEAP_ARRAY decorator in the
>>> mix as well, so that when we decide runtime code should use precise
>>> marking for arrays, we catch this case. I don't need another webrev for
>>> that.
>>>
>>> Thanks,
>>> /Erik
>>>
>>> On 2018-04-11 21:49, Roman Kennke wrote:
>>>> Please review the following little change.
>>>>
>>>>
>>>> objArrayOopDesc::atomic_compare_exchange_oop() currently computes and
>>>> uses a raw pointer to pass to HeapAccess::oop_atomic_cmpxchg(). It
>>>> should use the object+offset variant because it's accessing the heap and
>>>> GC might need to resolve the target object (e.g. Shenandoah).
>>>>
>>>> http://cr.openjdk.java.net/~rkennke/JDK-8201442/webrev.01/
>>>>
>>>> Testing: hotspot-tier1
>>>>
>>>>
>>>> Roman
>>>>
>>>
>>
>>
> 
> 


From rkennke at redhat.com  Thu Apr 12 14:21:44 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 12 Apr 2018 16:21:44 +0200
Subject: RFR: JDK-8201442: objArrayOopDesc::atomic_compare_exchange_oop()
 must use obj+offset in HeapAccess call
In-Reply-To: <e514f79f-56ea-64f9-e128-e9f94bd31e73@oracle.com>
References: <1f0c6263-8dfc-1059-cdce-3f1847733dad@redhat.com>
 <5ACF22AC.30806@oracle.com> <e8ad1c03-c7f2-8fd9-9f90-46245c0a78be@redhat.com>
 <42d2c948-55bc-8d96-f9b4-31209bd41d3c@redhat.com>
 <e514f79f-56ea-64f9-e128-e9f94bd31e73@oracle.com>
Message-ID: <13DCA6C4-4575-43F6-BD0E-77605977B86B@redhat.com>

Duh. I was sitting on an old branch when creating the new one. I re-submitted it. Thank you!

Am 12. April 2018 15:11:36 MESZ schrieb Stefan Karlsson <stefan.karlsson at oracle.com>:
>Hi Roman,
>
>It looks like a mismatch between your open code and our closed code.
>
>Can you verify that you have the following changeset?:
>
>changeset:   49651:4ae63fcabe2e
>user:        rwestberg
>date:        Mon Apr 09 10:09:38 2018 +0200
>summary:     8199736: Define WIN32_LEAN_AND_MEAN before including
>windows.h
>
>StefanK
>
>
>On 2018-04-12 14:47, Roman Kennke wrote:
>> Mach5 is not clean (see below). Can someone with access please have a
>look?
>> 
>> Thanks, Roman
>> 
>> 
>> Build Details: 2018-04-12-1133048.roman.source
>> 0 Failed Tests
>> Mach5 Tasks Results Summary
>> 
>>      PASSED: 60
>>      UNABLE_TO_RUN: 21
>>      EXECUTED_WITH_FAILURE: 2
>>      NA: 0
>>      KILLED: 0
>>      FAILED: 0
>>      Build
>> 
>>          2 Not run
>>              build_jdk_windows-windows-x64-windows-x64-build-10 error
>> while building, return value: 2
>>              build_jdk_windows-windows-x64-debug-windows-x64-build-11
>> error while building, return value: 2
>> 
>>      Test
>> 
>>          21 Not run
>> 
>>
>tier1-product-jdk_closed_test_hotspot_jtreg_tier1_common-windows-x64-22
>> Dependency task failed: YLFraZAoY
>> 
>>
>tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_common-windows-x64-debug-58
>> Dependency task failed: YLFraZApY
>> 
>>
>tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_compiler_closed-windows-x64-debug-61
>> Dependency task failed: YLFraZApY
>> 
>>
>tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_gc_closed-windows-x64-debug-64
>> Dependency task failed: YLFraZApY
>> 
>>
>tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_runtime-windows-x64-debug-67
>> Dependency task failed: YLFraZApY
>>              jdk_closed_test_jdk_tier1-windows-x64-77 Dependency task
>> failed: YLFraZAoY
>> 
>> tier1-product-jdk_open_test_hotspot_jtreg_tier1_common-windows-x64-16
>> Dependency task failed: YLFraZAoY
>> 
>>
>tier1-debug-jdk_open_test_hotspot_jtreg_tier1_common-windows-x64-debug-25
>> Dependency task failed: YLFraZApY
>> 
>>
>tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_1-windows-x64-debug-28
>> Dependency task failed: YLFraZApY
>> 
>>
>tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-debug-31
>> Dependency task failed: YLFraZApY
>> 
>> 
>>> Thanks Erik & Aleksey for reviewing!
>>>
>>> I just submitted the change for testing.
>>>
>>> I do need to wait 24h from posting RFR, do I? That means it's gonna
>miss
>>> the integration and need to wait till next week. Or do you think
>it's
>>> safe to go ahead and push it, given that submit repo comes back
>green?
>>>
>>> Thanks, Roman
>>>
>>>> Looks good. Would be great to stick that IN_HEAP_ARRAY decorator in
>the
>>>> mix as well, so that when we decide runtime code should use precise
>>>> marking for arrays, we catch this case. I don't need another webrev
>for
>>>> that.
>>>>
>>>> Thanks,
>>>> /Erik
>>>>
>>>> On 2018-04-11 21:49, Roman Kennke wrote:
>>>>> Please review the following little change.
>>>>>
>>>>>
>>>>> objArrayOopDesc::atomic_compare_exchange_oop() currently computes
>and
>>>>> uses a raw pointer to pass to HeapAccess::oop_atomic_cmpxchg(). It
>>>>> should use the object+offset variant because it's accessing the
>heap and
>>>>> GC might need to resolve the target object (e.g. Shenandoah).
>>>>>
>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8201442/webrev.01/
>>>>>
>>>>> Testing: hotspot-tier1
>>>>>
>>>>>
>>>>> Roman
>>>>>
>>>>
>>>
>>>
>> 
>> 

-- 
Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet.


From stefan.johansson at oracle.com  Thu Apr 12 15:15:01 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 12 Apr 2018 17:15:01 +0200
Subject: RFR (M): 6672778: G1 should trim task queues more aggressively
 during evacuation pauses
In-Reply-To: <1523447197.9657.6.camel@oracle.com>
References: <1523272805.4326.33.camel@oracle.com>
 <1523447197.9657.6.camel@oracle.com>
Message-ID: <43f37e0f-74c4-b9f9-bef7-934180518261@oracle.com>

Hi Thomas,

On 2018-04-11 13:46, Thomas Schatzl wrote:
> Hi all,
> 
>    I updated and (hopefully) improved the change a bit after some more
> thinking.
> 
> Particularly I thought that tracking the partial trim time in the
> closures would be confusing and too intrusive, so I moved it out from
> them to the G1ParScanThreadState.
> This also removed quite a few otherwise necessary includes to
> utilities/ticks.hpp.
> 
> Also the time accounting has been a bit messy as you needed to
> add/subtract the trim time in various places that were non-obvious. I
> tried to improve that by avoiding (existing) nested timing (remembered
> set cards/remembered set code roots and updateRS/scanHCC), which made
> the code imho much more easier to follow.
> 
> These two changes also make the follow-up "JDK-8201313: Sub-phases of
> ext root scan may be larger than the sum of individual timings"
> somewhat simpler.
> 
> Note that to gather the timings the code uses Tickspan for holding
> intermediate values, i.e. basically nanoseconds. Unfortunately G1
> logging uses seconds encoded as doubles everywhere for historical
> reasons; there is a really huge change fixing this coming, but for now
> more and more places are going to use Tickspan.
> 
> Webrevs:
> http://cr.openjdk.java.net/~tschatzl/6672778/webrev.0_to_1/ (diff)
> http://cr.openjdk.java.net/~tschatzl/6672778/webrev.1/ (full)

Thanks for this update, I had a glance at the first version and I think 
this is indeed simpler. Still have some comments though:
src/hotspot/share/gc/g1/g1CollectedHeap.cpp
3129 root_processor->evacuate_roots(pss, pss->closures(), worker_id);

Only pass in pss, and get the closures inside evactuate_roots.
-----
src/hotspot/share/gc/g1/g1SharedClosures.hpp
48 double trim_time_sec() {
49   return TicksToTimeHelper::seconds(_oops.trim_ticks_and_reset()) +
50     TicksToTimeHelper::seconds(_oops_in_cld.trim_ticks_and_reset());
51 }

This could be removed now, right?
-----

Apart from this me and Thomas has also spoken a bit offline so there 
might be some additional changes.

Thanks,
Stefan


> Testing:
> hs-tier 1-3
> 
> Thanks,
>    Thomas
> 
> On Mon, 2018-04-09 at 13:20 +0200, Thomas Schatzl wrote:
>> Hi all,
>>
>>    I am happy to finally bring this, one of the oldest G1 issues we
>> have, to a happy ending :)
>>
>> So until now G1 buffered all oop locations it encountered during root
>> scanning (including from remembered sets and refinement queues) in
>> the
>> per-thread work queues, and only drained them at the very end of the
>> evacuation pause.
>>
>> I am not completely sure why this has been implemented this way, but
>> it
>> has serious drawbacks:
>> - the work queues and overflow stacks may use a lot of memory, and I
>> mean *a lot*
>> - since we buffer all oop references, the prefetching G1 does goes to
>> waste as G1 always prefetches (during root scan) without following up
>> on it, wasting memory bandwidth.
>>
>> Other GC's already employ this technique, so my best guess why G1 did
>> not so far is that G1 needs sub-timings for the various phases to get
>> prediction right, and even if doing timing is cheap, doing it too
>> often
>> just adds up.
>>
>> Anyway, this problem has been solved by implementing a hysteresis,
>> i.e.
>> start trimming the work queues at a threshold higher than ending it,
>> and time the length of the trimming inbetween. So the timing
>> measurement overhead gets distributed across many work queue
>> operations.
>> Note that I did not do much testing about the optimal hysteresis
>> range,
>> the suggested guess of 2xGCDrainStackTargetSize seems to be a pretty
>> good value (i.e. reduces overhead well enough).
>>
>> Results are pretty good: I have seen reductions of the maximum task
>> queue size by multiple orders of magnitudes (i.e. less memory usage
>> during GC), and reduction of total pause time by up to 50%,
>> particularly on larger applications in the few GB heap range where
>> quite a bit of data is copied around every gc.
>>
>> But also smaller applications and applications doing less copying
>> benefit quite a bit, reducing pause times significantly.
>>
>> Note that there is a known, actually pre-existing bug with buffering
>> up
>> references (by the now obsolete and removed BufferingOopClosure): the
>> sum of timings for the sub-phases of ext root scan may be larger than
>> the printed total. This will be addressed with the follow-up JDK-
>> 8201313 to keep this change small, and it's a pre-existing issue
>> anyway
>> :P
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-6672778
>> Webrev:
>> http://cr.openjdk.java.net/~tschatzl/6672778/webrev/
>> Testing:
>> hs-tier 1-3, perf tests
>>
>> Thanks,
>>    Thomas
>>
> 


From stefan.johansson at oracle.com  Thu Apr 12 15:20:02 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 12 Apr 2018 17:20:02 +0200
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
 current_end
In-Reply-To: <5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
 <fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
 <3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
 <CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
 <CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
 <3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
 <CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
 <5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
Message-ID: <fb679957-5903-bf5a-9d07-db540a5621ed@oracle.com>

Hi again,

On 2018-04-12 11:09, Stefan Johansson wrote:
> 
> 
> On 2018-04-11 17:48, JC Beyler wrote:
>> Hi Stefan,
>>
>> Sorry about that, I must have missed adding the files or something. 
>> Here is a webrev that added the changes for the SA file:
>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
>>
> No problem, this looks good. I kicked of a run in our test system to get 
> some more coverage and have tried to include some Graal testing. I'll 
> let you know the results once they are done.
> 

The normal testing looks good, but the Graal task I started had some 
errors. To me they didn't look related to your change but you should 
probably reach out to a compiler engineer and ask them to run through 
some Graal testing to be sure.

Cheers,
Stefan

> Please also update the bug title both in JBS and the changeset.
> 
> Cheers,
> Stefan
> 
>> I changed the method name, which propagated a change to:
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
>>
>> I tried testing your test file. It exists in my branch (if the same) 
>> under:
>> hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
>>
>> and interestingly (which generally means I did something wrong), it 
>> passed before/after the change so I could not verify that this is a 
>> test showing that all is well in the world on my side. Any ideas of 
>> what I did wrong?
>>
>> I did again test it for?hotspot/jtreg/compiler/aot/ and 
>> hotspot/jtreg/serviceability/jvmti and it passes those.
>>
>> Thanks for all your help,
>> Jc
>>
>>
>>
>> On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson 
>> <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>> wrote:
>>
>> ??? Hi JC,
>>
>> ??? On 2018-04-11 00:56, JC Beyler wrote:
>> ???? > Small update:
>> ???? >
>> ???? > Here is the fixed webrev for the '{' that were out of alignment.
>> ??? This
>> ???? > passed release build JTREG for?hotspot/jtreg/compiler/jvmti (just
>> ??? to run
>> ???? > something as a smoke screen) and?hotspot/jtreg/compiler/aot/ (to
>> ??? test
>> ???? > Graal).
>> ???? > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
>> ???? >
>> ??? I think this looks better, I agree that leaving _end is tempting to
>> ??? avoid a lot of change, but I think this will be better in the long 
>> run.
>>
>> ??? I still miss the changes to make the SA work. To see a problem you
>> ??? can run:
>> ??? make CONF=fast run-test
>> ??? TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
>>
>> ??? Cheers,
>> ??? Stefan
>>
>> ???? > Let me know what you think,
>> ???? > Jc
>> ???? >
>> ???? > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler <jcbeyler at google.com
>> ??? <mailto:jcbeyler at google.com>
>> ???? > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>> wrote:
>> ???? >
>> ???? >? ? ?Hi Karen and Stefan,
>> ???? >
>> ???? >? ? ?@Stefan: Naming is hard :)
>> ???? >? ? ?@Karen: thanks for the Graal comment, I fixed it in the new
>> ??? webrev,
>> ???? >? ? ?let me know what you think :)
>> ???? >
>> ???? >? ? ?I think the naming convention suggested in this webrev came 
>> from
>> ???? >? ? ?conversations in for JEP-331 and I am actually relatively
>> ???? >? ? ?indifferent to the final result (as long as we have some 
>> form of
>> ???? >? ? ?forward progress :)). To be honest, I'd also be happy to just
>> ??? leave
>> ???? >? ? ?_end as is for all architectures and Graal and have a new
>> ???? >? ? ?_allocation_end. However, during initial reviews of JEP-331
>> ??? it was
>> ???? >? ? ?deemed complicated to understand:
>> ???? >
>> ???? >? ? ?_end -> the _end or sampling end
>> ???? >? ? ?_allocation_end -> end pointer for the last possible 
>> allocation
>> ???? >? ? ?hard_end -> allocation end?+ reserved space
>> ???? >
>> ???? >? ? ?That is how this naming came up and why hard_end went to
>> ??? "reserved_end".
>> ???? >
>> ???? >? ? ?I'm really indifferent, so I offer as a perusal:
>> ???? > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
>> ???? >
>> ???? >? ? ?I noticed a few problems of alignement of '{' so I'll go fix
>> ??? that.
>> ???? >? ? ?Basically this webrev does the following:
>> ???? >
>> ???? >? ? ?- Uses fast_path_end instead of end
>> ???? >? ? ?- Reverts hard_end back to where it was
>> ???? >? ? ?- Adds the changes to Graal; there is a bunch of changes in 
>> Graal
>> ???? >? ? ?because Graal still contains a bit of code doing 
>> fasttlabrefills.
>> ???? >
>> ???? >? ? ?Let me know what you think!
>> ???? >
>> ???? >? ? ?Thanks,
>> ???? >? ? ?Jc
>> ???? >
>> ???? >
>> ???? >? ? ?On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear
>> ???? >? ? ?<karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>
>> ??? <mailto:karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>>>
>> ??? wrote:
>> ???? >
>> ???? >? ? ? ? ?Hi JC,
>> ???? >
>> ???? >? ? ? ? ?A comment about Graal. The impact on Graal for this
>> ??? particular
>> ???? >? ? ? ? ?change would be to break it - so you?ll need
>> ???? >? ? ? ? ?to complete the Graal changes for this renaming. That 
>> isn?t
>> ???? >? ? ? ? ?optional or something that could be a follow-on. It
>> ???? >? ? ? ? ?is not ok to break a feature, even an experimental one.
>> ??? We will
>> ???? >? ? ? ? ?discuss in the other thread potential phasing of adding
>> ??? sampling.
>> ???? >
>> ???? >? ? ? ? ?I did not do a thorough search -you can do that - I did 
>> find
>> ???? >? ? ? ? ?src/jdk.internal.vm.compiler/share/classes/
>> ???? >      
>> ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>>
>> ???? >? ? ? ? ? ? public final int threadTlabOffset =
>> ???? >? ? ? ? ?getFieldOffset("Thread::_tlab", Integer.class,
>> ???? >? ? ? ? ?"ThreadLocalAllocBuffer");
>> ???? >      
>> ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>>
>> ???? >? ? ? ? ? ? private final int threadLocalAllocBufferStartOffset =
>> ???? >? ? ? ? ?getFieldOffset("ThreadLocalAllocBuffer::_start",
>> ??? Integer.class,
>> ???? >? ? ? ? ?"HeapWord*");
>> ???? >      
>> ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>>
>> ???? >? ? ? ? ? ? private final int threadLocalAllocBufferEndOffset =
>> ???? >? ? ? ? ?getFieldOffset("ThreadLocalAllocBuffer::_end", 
>> Integer.class,
>> ???? >? ? ? ? ?"HeapWord*");
>> ???? >      
>> ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>>
>> ???? >? ? ? ? ? ? private final int threadLocalAllocBufferTopOffset =
>> ???? >? ? ? ? ?getFieldOffset("ThreadLocalAllocBuffer::_top", 
>> Integer.class,
>> ???? >? ? ? ? ?"HeapWord*");
>> ???? >      
>> ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>>
>> ???? >? ? ? ? ? ? private final int threadLocalAllocBufferPfTopOffset =
>> ???? >? ? ? ? ?getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
>> ??? Integer.class,
>> ???? >? ? ? ? ?"HeapWord*");
>> ???? >      
>> ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>>
>> ???? >? ? ? ? ? ? private final int
>> ??? threadLocalAllocBufferSlowAllocationsOffset
>> ???? >? ? ? ? ?= 
>> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
>> ???? >? ? ? ? ?Integer.class, "unsigned");
>> ???? >      
>> ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>>
>> ???? >? ? ? ? ? ? private final int
>> ??? threadLocalAllocBufferFastRefillWasteOffset
>> ???? >? ? ? ? ?=
>> ??? getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
>> ???? >? ? ? ? ?Integer.class, "unsigned");
>> ???? >      
>> ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>>
>> ???? >? ? ? ? ? ? private final int
>> ??? threadLocalAllocBufferNumberOfRefillsOffset
>> ???? >? ? ? ? ?=
>> ??? getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
>> ???? >? ? ? ? ?Integer.class, "unsigned");
>> ???? >      
>> ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>>
>> ???? >? ? ? ? ? ? private final int
>> ???? >? ? ? ? ?threadLocalAllocBufferRefillWasteLimitOffset =
>> ???? >        
>> ?getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
>> ???? >? ? ? ? ?Integer.class, "size_t");
>> ???? >      
>> ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>>
>> ???? >? ? ? ? ? ? private final int
>> ??? threadLocalAllocBufferDesiredSizeOffset =
>> ???? >? ? ? ? ?getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
>> ???? >? ? ? ? ?Integer.class, "size_t");
>> ???? >      
>> ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java: 
>>
>> ???? >? ? ? ? ? ? public final int tlabAlignmentReserve =
>> ???? >      
>> ?getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve", 
>>
>> ???? >? ? ? ? ?Integer.class, "size_t?);
>> ???? >
>> ???? >? ? ? ? ?hope this helps,
>> ???? >? ? ? ? ?Karen
>> ???? >
>> ???? >>? ? ? ? ?On Apr 10, 2018, at 7:04 AM, Stefan Johansson
>> ???? >>? ? ? ? ?<stefan.johansson at oracle.com
>> ??? <mailto:stefan.johansson at oracle.com>
>> ???? >>? ? ? ? ?<mailto:stefan.johansson at oracle.com
>> ??? <mailto:stefan.johansson at oracle.com>>> wrote:
>> ???? >>
>> ???? >>? ? ? ? ?Hi JC,
>> ???? >>
>> ???? >>? ? ? ? ?I realize that the names have been discussed before 
>> but I'm
>> ???? >>? ? ? ? ?leaning towards suggesting something new. We discussed 
>> this
>> ???? >>? ? ? ? ?briefly here in the office and others might have 
>> different
>> ???? >>? ? ? ? ?opinions. One point that came up is that if we do this
>> ??? change
>> ???? >>? ? ? ? ?and change all usages of JavaThread::tlab_end_offset() it
>> ???? >>? ? ? ? ?would be good to make sure the new name is good. To us
>> ???? >>? ? ? ? ?_current_end is not very descriptive, but naming is 
>> hard and
>> ???? >>? ? ? ? ?the best we could come up with is _fast_path_end which 
>> would
>> ???? >>? ? ? ? ?give the code:
>> ???? >>? ? ? ? ??cmpptr(end, Address(thread,
>> ???? >>? ? ? ? ?JavaThread::tlab_fast_path_end_offset()));
>> ???? >>? ? ? ? ??jcc(Assembler::above, slow_case);
>> ???? >>
>> ???? >>? ? ? ? ?I think this reads pretty good and is fairly clear. If 
>> we do
>> ???? >>? ? ? ? ?this rename I think you can re-use _end in JEP-331
>> ??? instead of
>> ???? >>? ? ? ? ?calling it _allocation_end. But that is a later review :)
>> ???? >>
>> ???? >>? ? ? ? ?Also, is there a good reason for renaming hard_end() to
>> ???? >>? ? ? ? ?reserved_end()?
>> ???? >>
>> ???? >>? ? ? ? ?One additional thing, you need to update the SA to 
>> reflect
>> ???? >>? ? ? ? ?this change. I think the only place you need to fix is 
>> in:
>> ???? >>      
>> ?src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java 
>>
>> ???? >>
>> ???? >>? ? ? ? ?Thanks,
>> ???? >>? ? ? ? ?Stefan
>> ???? >>
>> ???? >>? ? ? ? ?On 2018-04-09 19:24, JC Beyler wrote:
>> ???? >>>? ? ? ? ?Hi all,
>> ???? >>>? ? ? ? ?Small pre-amble to this request:
>> ???? >>>? ? ? ? ?In my work to try to get a heap sampler in OpenJDK 
>> (via JEP
>> ???? >>>? ? ? ? ?331
>> ??? <https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm
>> ???? >>>? ? ? ? ?trying to reduce the footprint of my change so that the
>> ???? >>>? ? ? ? ?integration can be easier. I was told that generally 
>> a JEP
>> ???? >>>? ? ? ? ?webrev should be feature complete and go in at-once.
>> ??? However,
>> ???? >>>? ? ? ? ?with the change touching quite a bit of various code
>> ??? pieces,
>> ???? >>>? ? ? ? ?I was trying to figure out what could be separated as 
>> not
>> ???? >>>? ? ? ? ?"part of the feature".
>> ???? >>>? ? ? ? ?I asked around and said that perhaps a solution would 
>> be to
>> ???? >>>? ? ? ? ?cut up the renaming of TLAB's end field that I do in 
>> that
>> ???? >>>? ? ? ? ?webrev. Because I'm renaming a field in TLAB used by
>> ??? various
>> ???? >>>? ? ? ? ?backends for that work, I have to update every 
>> architecture
>> ???? >>>? ? ? ? ?dependent code to reflect it.
>> ???? >>>? ? ? ? ?I entirely understand that perhaps this is not in the
>> ??? habits
>> ???? >>>? ? ? ? ?and very potentially might not be the way things are
>> ???? >>>? ? ? ? ?generally done. If so, I apologize and let me know if 
>> you
>> ???? >>>? ? ? ? ?would not want this to go in separately :)
>> ???? >>>? ? ? ? ?Final note: there is still a chance JEP-331 does not 
>> go in.
>> ???? >>>? ? ? ? ?If it does not, we can leave the new name in place or 
>> I'll
>> ???? >>>? ? ? ? ?happily revert it. I can even create an issue to 
>> track this
>> ???? >>>? ? ? ? ?if that makes it easier for all.
>> ???? >>>? ? ? ? ?End of the pre-amble.
>> ???? >>>? ? ? ? ?The 33-line change webrev in question is here:
>> ???? >>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>> ???? >>>? ? ? ? ?I fixed all the architectures and JVMCI and ran a few
>> ??? sanity
>> ???? >>>? ? ? ? ?tests to ensure I had not missed anything.
>> ???? >>>? ? ? ? ?Thanks for your help and I hope this is not too much
>> ??? trouble,
>> ???? >>>? ? ? ? ?Jc
>> ???? >>>? ? ? ? ?Ps: there is a graal change that needs to happen but 
>> I was
>> ???? >>>? ? ? ? ?not sure who/where
>> ??? <https://teams.googleplex.com/u/where>
>> ??? <https://teams.googleplex.com/u/where> to
>> ???? >>>? ? ? ? ?ask about it. I was told it could happen in a separate
>> ???? >>>? ? ? ? ?webrev. Can anyone point me to the right direction?
>> ??? Should it
>> ???? >>>? ? ? ? ?just be hotspot-compiler-dev?
>> ???? >
>>

From jcbeyler at google.com  Thu Apr 12 15:26:48 2018
From: jcbeyler at google.com (JC Beyler)
Date: Thu, 12 Apr 2018 15:26:48 +0000
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
 current_end
In-Reply-To: <5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
 <fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
 <3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
 <CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
 <CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
 <3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
 <CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
 <5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
Message-ID: <CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>

Hi Stefan,

Thanks for testing :). I've renamed the bug title in the JBS and will emit
a new webrev shortly. Do you have the name of a compiler engineer in mind
or should I perhaps now move this conversation to the general hotspot-dev
mailing list and ask there?

The alternative is to add the compiler-mailing list to this email thread
and ask there before sending to the general list. What do you think is best?

Thanks for all your help,
Jc

On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson <
stefan.johansson at oracle.com> wrote:

>
>
> On 2018-04-11 17:48, JC Beyler wrote:
> > Hi Stefan,
> >
> > Sorry about that, I must have missed adding the files or something. Here
> > is a webrev that added the changes for the SA file:
> > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
> >
> No problem, this looks good. I kicked of a run in our test system to get
> some more coverage and have tried to include some Graal testing. I'll
> let you know the results once they are done.
>
> Please also update the bug title both in JBS and the changeset.
>
> Cheers,
> Stefan
>
> > I changed the method name, which propagated a change to:
> > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
> >
> > I tried testing your test file. It exists in my branch (if the same)
> under:
> > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
> >
> > and interestingly (which generally means I did something wrong), it
> > passed before/after the change so I could not verify that this is a test
> > showing that all is well in the world on my side. Any ideas of what I
> > did wrong?
> >
> > I did again test it for hotspot/jtreg/compiler/aot/ and
> > hotspot/jtreg/serviceability/jvmti and it passes those.
> >
> > Thanks for all your help,
> > Jc
> >
> >
> >
> > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
> > <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>
> wrote:
> >
> >     Hi JC,
> >
> >     On 2018-04-11 00:56, JC Beyler wrote:
> >      > Small update:
> >      >
> >      > Here is the fixed webrev for the '{' that were out of alignment.
> >     This
> >      > passed release build JTREG for hotspot/jtreg/compiler/jvmti (just
> >     to run
> >      > something as a smoke screen) and hotspot/jtreg/compiler/aot/ (to
> >     test
> >      > Graal).
> >      > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
> >      >
> >     I think this looks better, I agree that leaving _end is tempting to
> >     avoid a lot of change, but I think this will be better in the long
> run.
> >
> >     I still miss the changes to make the SA work. To see a problem you
> >     can run:
> >     make CONF=fast run-test
> >     TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
> >
> >     Cheers,
> >     Stefan
> >
> >      > Let me know what you think,
> >      > Jc
> >      >
> >      > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler <jcbeyler at google.com
> >     <mailto:jcbeyler at google.com>
> >      > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>> wrote:
> >      >
> >      >     Hi Karen and Stefan,
> >      >
> >      >     @Stefan: Naming is hard :)
> >      >     @Karen: thanks for the Graal comment, I fixed it in the new
> >     webrev,
> >      >     let me know what you think :)
> >      >
> >      >     I think the naming convention suggested in this webrev came
> from
> >      >     conversations in for JEP-331 and I am actually relatively
> >      >     indifferent to the final result (as long as we have some form
> of
> >      >     forward progress :)). To be honest, I'd also be happy to just
> >     leave
> >      >     _end as is for all architectures and Graal and have a new
> >      >     _allocation_end. However, during initial reviews of JEP-331
> >     it was
> >      >     deemed complicated to understand:
> >      >
> >      >     _end -> the _end or sampling end
> >      >     _allocation_end -> end pointer for the last possible
> allocation
> >      >     hard_end -> allocation end + reserved space
> >      >
> >      >     That is how this naming came up and why hard_end went to
> >     "reserved_end".
> >      >
> >      >     I'm really indifferent, so I offer as a perusal:
> >      > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
> >      >
> >      >     I noticed a few problems of alignement of '{' so I'll go fix
> >     that.
> >      >     Basically this webrev does the following:
> >      >
> >      >     - Uses fast_path_end instead of end
> >      >     - Reverts hard_end back to where it was
> >      >     - Adds the changes to Graal; there is a bunch of changes in
> Graal
> >      >     because Graal still contains a bit of code doing
> fasttlabrefills.
> >      >
> >      >     Let me know what you think!
> >      >
> >      >     Thanks,
> >      >     Jc
> >      >
> >      >
> >      >     On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear
> >      >     <karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>
> >     <mailto:karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>>>
> >     wrote:
> >      >
> >      >         Hi JC,
> >      >
> >      >         A comment about Graal. The impact on Graal for this
> >     particular
> >      >         change would be to break it - so you?ll need
> >      >         to complete the Graal changes for this renaming. That
> isn?t
> >      >         optional or something that could be a follow-on. It
> >      >         is not ok to break a feature, even an experimental one.
> >     We will
> >      >         discuss in the other thread potential phasing of adding
> >     sampling.
> >      >
> >      >         I did not do a thorough search -you can do that - I did
> find
> >      >         src/jdk.internal.vm.compiler/share/classes/
> >      >
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >      >            public final int threadTlabOffset =
> >      >         getFieldOffset("Thread::_tlab", Integer.class,
> >      >         "ThreadLocalAllocBuffer");
> >      >
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >      >            private final int threadLocalAllocBufferStartOffset =
> >      >         getFieldOffset("ThreadLocalAllocBuffer::_start",
> >     Integer.class,
> >      >         "HeapWord*");
> >      >
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >      >            private final int threadLocalAllocBufferEndOffset =
> >      >         getFieldOffset("ThreadLocalAllocBuffer::_end",
> Integer.class,
> >      >         "HeapWord*");
> >      >
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >      >            private final int threadLocalAllocBufferTopOffset =
> >      >         getFieldOffset("ThreadLocalAllocBuffer::_top",
> Integer.class,
> >      >         "HeapWord*");
> >      >
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >      >            private final int threadLocalAllocBufferPfTopOffset =
> >      >         getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
> >     Integer.class,
> >      >         "HeapWord*");
> >      >
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >      >            private final int
> >     threadLocalAllocBufferSlowAllocationsOffset
> >      >         =
> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
> >      >         Integer.class, "unsigned");
> >      >
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >      >            private final int
> >     threadLocalAllocBufferFastRefillWasteOffset
> >      >         =
> >     getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
> >      >         Integer.class, "unsigned");
> >      >
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >      >            private final int
> >     threadLocalAllocBufferNumberOfRefillsOffset
> >      >         =
> >     getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
> >      >         Integer.class, "unsigned");
> >      >
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >      >            private final int
> >      >         threadLocalAllocBufferRefillWasteLimitOffset =
> >      >
>  getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
> >      >         Integer.class, "size_t");
> >      >
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >      >            private final int
> >     threadLocalAllocBufferDesiredSizeOffset =
> >      >         getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
> >      >         Integer.class, "size_t");
> >      >
> >
>  org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >      >            public final int tlabAlignmentReserve =
> >      >
> >
>  getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
> >      >         Integer.class, "size_t?);
> >      >
> >      >         hope this helps,
> >      >         Karen
> >      >
> >      >>         On Apr 10, 2018, at 7:04 AM, Stefan Johansson
> >      >>         <stefan.johansson at oracle.com
> >     <mailto:stefan.johansson at oracle.com>
> >      >>         <mailto:stefan.johansson at oracle.com
> >     <mailto:stefan.johansson at oracle.com>>> wrote:
> >      >>
> >      >>         Hi JC,
> >      >>
> >      >>         I realize that the names have been discussed before but
> I'm
> >      >>         leaning towards suggesting something new. We discussed
> this
> >      >>         briefly here in the office and others might have
> different
> >      >>         opinions. One point that came up is that if we do this
> >     change
> >      >>         and change all usages of JavaThread::tlab_end_offset() it
> >      >>         would be good to make sure the new name is good. To us
> >      >>         _current_end is not very descriptive, but naming is hard
> and
> >      >>         the best we could come up with is _fast_path_end which
> would
> >      >>         give the code:
> >      >>          cmpptr(end, Address(thread,
> >      >>         JavaThread::tlab_fast_path_end_offset()));
> >      >>          jcc(Assembler::above, slow_case);
> >      >>
> >      >>         I think this reads pretty good and is fairly clear. If
> we do
> >      >>         this rename I think you can re-use _end in JEP-331
> >     instead of
> >      >>         calling it _allocation_end. But that is a later review :)
> >      >>
> >      >>         Also, is there a good reason for renaming hard_end() to
> >      >>         reserved_end()?
> >      >>
> >      >>         One additional thing, you need to update the SA to
> reflect
> >      >>         this change. I think the only place you need to fix is
> in:
> >      >>
> >
>  src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
> >      >>
> >      >>         Thanks,
> >      >>         Stefan
> >      >>
> >      >>         On 2018-04-09 19:24, JC Beyler wrote:
> >      >>>         Hi all,
> >      >>>         Small pre-amble to this request:
> >      >>>         In my work to try to get a heap sampler in OpenJDK (via
> JEP
> >      >>>         331
> >     <https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm
> >      >>>         trying to reduce the footprint of my change so that the
> >      >>>         integration can be easier. I was told that generally a
> JEP
> >      >>>         webrev should be feature complete and go in at-once.
> >     However,
> >      >>>         with the change touching quite a bit of various code
> >     pieces,
> >      >>>         I was trying to figure out what could be separated as
> not
> >      >>>         "part of the feature".
> >      >>>         I asked around and said that perhaps a solution would
> be to
> >      >>>         cut up the renaming of TLAB's end field that I do in
> that
> >      >>>         webrev. Because I'm renaming a field in TLAB used by
> >     various
> >      >>>         backends for that work, I have to update every
> architecture
> >      >>>         dependent code to reflect it.
> >      >>>         I entirely understand that perhaps this is not in the
> >     habits
> >      >>>         and very potentially might not be the way things are
> >      >>>         generally done. If so, I apologize and let me know if
> you
> >      >>>         would not want this to go in separately :)
> >      >>>         Final note: there is still a chance JEP-331 does not go
> in.
> >      >>>         If it does not, we can leave the new name in place or
> I'll
> >      >>>         happily revert it. I can even create an issue to track
> this
> >      >>>         if that makes it easier for all.
> >      >>>         End of the pre-amble.
> >      >>>         The 33-line change webrev in question is here:
> >      >>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
> >      >>>         I fixed all the architectures and JVMCI and ran a few
> >     sanity
> >      >>>         tests to ensure I had not missed anything.
> >      >>>         Thanks for your help and I hope this is not too much
> >     trouble,
> >      >>>         Jc
> >      >>>         Ps: there is a graal change that needs to happen but I
> was
> >      >>>         not sure who/where
> <https://teams.googleplex.com/u/where>
> >     <https://teams.googleplex.com/u/where>
> >     <https://teams.googleplex.com/u/where> to
> >      >>>         ask about it. I was told it could happen in a separate
> >      >>>         webrev. Can anyone point me to the right direction?
> >     Should it
> >      >>>         just be hotspot-compiler-dev?
> >      >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180412/16c77cb9/attachment.htm>

From thomas.schatzl at oracle.com  Thu Apr 12 19:57:11 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 12 Apr 2018 21:57:11 +0200
Subject: RFR (S): 8201490: Improve concurrent mark keep alive closure
 performance
Message-ID: <1523563031.2265.3.camel@oracle.com>

Hi,

  can I have reviews for this change that improves the performance of
the G1CMKeepAliveAndDrainClosure used for reference processing in some
(sometimes common) special case?

This particular change makes sure that the actual marking will not be
called for NULL referents in the keep-alive closure, and do not count
against the threshold that starts marking, so that marking will not
start without actual work.

Setup/teardown of G1 marking is very big.

CR:
https://bugs.openjdk.java.net/browse/JDK-8201490
Webrev:
http://cr.openjdk.java.net/~tschatzl/8201490/webrev
Testing:
hs-tier1-3

Thanks,
  Thomas


From thomas.schatzl at oracle.com  Thu Apr 12 20:03:42 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 12 Apr 2018 22:03:42 +0200
Subject: RFR (XS): 8201487: Do not rebalance reference processing queues if
 not doing parallel reference processing
Message-ID: <1523563422.2265.6.camel@oracle.com>

Hi all,

  can I have reviews for this small change that removes discovered list
rebalancing for better work distribution across threads if running
serially.

This can save hundreds of ms in reference processing time.

CR:
https://bugs.openjdk.java.net/browse/JDK-8201487
Webrev:
http://cr.openjdk.java.net/~tschatzl/8201487/webrev/
Testing:
hs-tier1-3

Thanks,
  Thomas



From kim.barrett at oracle.com  Thu Apr 12 21:07:54 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 12 Apr 2018 17:07:54 -0400
Subject: RFR (XS): 8201487: Do not rebalance reference processing queues
 if not doing parallel reference processing
In-Reply-To: <1523563422.2265.6.camel@oracle.com>
References: <1523563422.2265.6.camel@oracle.com>
Message-ID: <7241C475-044F-412A-A1F9-CF41C9743BC0@oracle.com>

> On Apr 12, 2018, at 4:03 PM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi all,
> 
>  can I have reviews for this small change that removes discovered list
> rebalancing for better work distribution across threads if running
> serially.
> 
> This can save hundreds of ms in reference processing time.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8201487
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8201487/webrev/
> Testing:
> hs-tier1-3
> 
> Thanks,
>  Thomas

Looks good.



From kim.barrett at oracle.com  Thu Apr 12 21:28:28 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 12 Apr 2018 17:28:28 -0400
Subject: RFR (S): 8201490: Improve concurrent mark keep alive closure
 performance
In-Reply-To: <1523563031.2265.3.camel@oracle.com>
References: <1523563031.2265.3.camel@oracle.com>
Message-ID: <390AF736-8FBB-4985-A8D7-AF41032E1257@oracle.com>

> On Apr 12, 2018, at 3:57 PM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi,
> 
>  can I have reviews for this change that improves the performance of
> the G1CMKeepAliveAndDrainClosure used for reference processing in some
> (sometimes common) special case?
> 
> This particular change makes sure that the actual marking will not be
> called for NULL referents in the keep-alive closure, and do not count
> against the threshold that starts marking, so that marking will not
> start without actual work.
> 
> Setup/teardown of G1 marking is very big.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8201490
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8201490/webrev
> Testing:
> hs-tier1-3
> 
> Thanks,
>  Thomas

Looks good.  Just a couple minor comments.

------------------------------------------------------------------------------ 
src/hotspot/share/gc/g1/g1ConcurrentMark.hpp
 782   // Returns whether there has been a mark to the bitmap.
 788   // Returns true if the reference caused a mark to be set in the next bitmap.

Consider making these the same, and something like:
Returns true if a mark was added to the bitmap.

------------------------------------------------------------------------------
src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp
 243   if (obj == NULL) {
 244     return false;
 245   }
 246   return make_reference_grey(obj);

For me, something like the following would be easier to read:

  return (obj != NULL) && make_reference_grey(obj)

Up to you...

------------------------------------------------------------------------------



From sangheon.kim at oracle.com  Thu Apr 12 21:58:27 2018
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Thu, 12 Apr 2018 14:58:27 -0700
Subject: RFR (XS): 8201487: Do not rebalance reference processing queues
 if not doing parallel reference processing
In-Reply-To: <1523563422.2265.6.camel@oracle.com>
References: <1523563422.2265.6.camel@oracle.com>
Message-ID: <560dc311-9fcd-a6e7-4afd-01aeb8e4fa80@oracle.com>

Hi Thomas,

On 04/12/2018 01:03 PM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for this small change that removes discovered list
> rebalancing for better work distribution across threads if running
> serially.
>
> This can save hundreds of ms in reference processing time.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8201487
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8201487/webrev/
Looks good.

Thanks,
Sangheon


> Testing:
> hs-tier1-3
>
> Thanks,
>    Thomas
>



From thomas.schatzl at oracle.com  Fri Apr 13 08:18:17 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 13 Apr 2018 10:18:17 +0200
Subject: RFR (S): 8201490: Improve concurrent mark keep alive closure
 performance
In-Reply-To: <390AF736-8FBB-4985-A8D7-AF41032E1257@oracle.com>
References: <1523563031.2265.3.camel@oracle.com>
 <390AF736-8FBB-4985-A8D7-AF41032E1257@oracle.com>
Message-ID: <1523607497.2360.9.camel@oracle.com>

Hi Kim,

  thanks for your review.

On Thu, 2018-04-12 at 17:28 -0400, Kim Barrett wrote:
> > On Apr 12, 2018, at 3:57 PM, Thomas Schatzl <thomas.schatzl at oracle.
> > com> wrote:
> > 
> > Hi,
> > 
> >  can I have reviews for this change that improves the performance
> > of [...]
> > 
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8201490
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8201490/webrev
> > Testing:
> > hs-tier1-3
> > 
> > Thanks,
> >  Thomas
> 
> Looks good.  Just a couple minor comments.
> 
> -------------------------------------------------------------------
> ----------- 
> src/hotspot/share/gc/g1/g1ConcurrentMark.hpp
>  782   // Returns whether there has been a mark to the bitmap.
>  788   // Returns true if the reference caused a mark to be set in
> the next bitmap.
> 
> Consider making these the same, and something like:
> Returns true if a mark was added to the bitmap.
> 
> -------------------------------------------------------------------
> -----------
> src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp
>  243   if (obj == NULL) {
>  244     return false;
>  245   }
>  246   return make_reference_grey(obj);
> 
> For me, something like the following would be easier to read:
> 
>   return (obj != NULL) && make_reference_grey(obj)
> 
> Up to you...
> 
> -------------------------------------------------------------------
> -----------
> 

All fixed.

http://cr.openjdk.java.net/~tschatzl/8201490/webrev.0_to_1 (diff)
http://cr.openjdk.java.net/~tschatzl/8201490/webrev.1 (full)

Thanks,
  Thomas



From thomas.schatzl at oracle.com  Fri Apr 13 08:35:16 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 13 Apr 2018 10:35:16 +0200
Subject: RFR (M): 6672778: G1 should trim task queues more aggressively
 during evacuation pauses
In-Reply-To: <43f37e0f-74c4-b9f9-bef7-934180518261@oracle.com>
References: <1523272805.4326.33.camel@oracle.com>
 <1523447197.9657.6.camel@oracle.com>
 <43f37e0f-74c4-b9f9-bef7-934180518261@oracle.com>
Message-ID: <1523608516.2360.10.camel@oracle.com>

Hi Stefan, 

  thanks for your review... :)

On Thu, 2018-04-12 at 17:15 +0200, Stefan Johansson wrote:
> Hi Thomas,
> 
> On 2018-04-11 13:46, Thomas Schatzl wrote:
> > Hi all,
> > 
> >    I updated and (hopefully) improved the change a bit after some
> > more thinking.
[...]
> > 
> > Webrevs:
> > http://cr.openjdk.java.net/~tschatzl/6672778/webrev.0_to_1/ (diff)
> > http://cr.openjdk.java.net/~tschatzl/6672778/webrev.1/ (full)
> 
> Thanks for this update, I had a glance at the first version and I
> think this is indeed simpler. Still have some comments though:
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp
> 3129 root_processor->evacuate_roots(pss, pss->closures(), worker_id);
> 
> Only pass in pss, and get the closures inside evactuate_roots.
> -----
> src/hotspot/share/gc/g1/g1SharedClosures.hpp
> 48 double trim_time_sec() {
> 49   return TicksToTimeHelper::seconds(_oops.trim_ticks_and_reset())
> +
> 50     TicksToTimeHelper::seconds(_oops_in_cld.trim_ticks_and_reset()
> );
> 51 }
> 
> This could be removed now, right?
> -----
> 
> Apart from this me and Thomas has also spoken a bit offline so there 
> might be some additional changes.
> 
> Thanks,
> Stefan

  all done.

http://cr.openjdk.java.net/~tschatzl/6672778/webrev.1_to_2/ (diff)
http://cr.openjdk.java.net/~tschatzl/6672778/webrev.2/ (full)

Thanks,
  Thomas


From thomas.schatzl at oracle.com  Fri Apr 13 09:10:54 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 13 Apr 2018 11:10:54 +0200
Subject: RFR (S): 8201527: Bump default value of G1RefProcDrainInterval
Message-ID: <1523610654.2360.20.camel@oracle.com>

Hi all,

  can I have reviews for this change that bumps the default value of
G1RefProcDrainInterval to 1000?

The G1RefProcDrainInterval flag determines the frequency at which new
marks are actually processed while keeping alive references during
reference processing. 

The current value is 10, i.e. every ten references we try to drain the
mark stack. However, due to how expensive setup and teardown of G1
marking is, this seriously inhibits performance. 

Tests showed that with a significantly higher value, 1000, reference
processing time can halve.

There is a graph attached to the CR showing that somewhere between 500
and 1000 the improvement levels out, so I chose the higher value. Users
may still try out higher values if they want. Also, we might want to
change this back if/when somebody fixes marking, but that seems to be a
much larger effort than changing this default value :)

There is no issue with filling up the mark stack during reference
processing, by default it may contains 128k entries. So no worries
here.

This improvement is in addition to the other improvements to reference
processing posted just recently.

Internal perf runs are on its way, however they typically do not
exercise reference processing, so there should be no issue.

I will do the CSR work as soon as I have reviews for this (trivial)
change.

CR:
https://bugs.openjdk.java.net/browse/JDK-8201527
Webrev:
http://cr.openjdk.java.net/~tschatzl/8201527/webrev/
Testing:
kitchensink reference processing stress test for many hours with
different values; hs-tier1-3

Thanks,
  Thomas


From stefan.johansson at oracle.com  Fri Apr 13 09:37:02 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Fri, 13 Apr 2018 11:37:02 +0200
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
 current_end
In-Reply-To: <CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
 <fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
 <3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
 <CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
 <CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
 <3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
 <CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
 <5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
 <CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
Message-ID: <ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>

Hi JC,

I don't have a name, but I've looked at bit more at the failures and I 
think they are unrelated and one of the local compiler engineers agree.

I also ran some local testing and was not able to get any error with you 
latest changes, but verified that it doens't work without the graal 
parts. So they seem good. It might still be good to switch this over to 
the general hotspot-dev list to let someone with Graal knowledge to look 
at the change and make sure everything is correct.

Thanks,
Stefan


On 2018-04-12 17:26, JC Beyler wrote:
> Hi Stefan,
> 
> Thanks for testing :). I've renamed the bug title in the JBS and will 
> emit a new webrev shortly. Do you have the name of a compiler engineer 
> in mind or should I perhaps now move this conversation to the general 
> hotspot-dev mailing list and ask there?
> 
> The alternative is to add the compiler-mailing list to this email thread 
> and ask there before sending to the general list. What do you think is best?
> 
> Thanks for all your help,
> Jc
> 
> On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson 
> <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>> wrote:
> 
> 
> 
>     On 2018-04-11 17:48, JC Beyler wrote:
>      > Hi Stefan,
>      >
>      > Sorry about that, I must have missed adding the files or
>     something. Here
>      > is a webrev that added the changes for the SA file:
>      > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
>      >
>     No problem, this looks good. I kicked of a run in our test system to
>     get
>     some more coverage and have tried to include some Graal testing. I'll
>     let you know the results once they are done.
> 
>     Please also update the bug title both in JBS and the changeset.
> 
>     Cheers,
>     Stefan
> 
>      > I changed the method name, which propagated a change to:
>      >
>     src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
>      >
>      > I tried testing your test file. It exists in my branch (if the
>     same) under:
>      > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
>      >
>      > and interestingly (which generally means I did something wrong), it
>      > passed before/after the change so I could not verify that this is
>     a test
>      > showing that all is well in the world on my side. Any ideas of
>     what I
>      > did wrong?
>      >
>      > I did again test it for?hotspot/jtreg/compiler/aot/ and
>      > hotspot/jtreg/serviceability/jvmti and it passes those.
>      >
>      > Thanks for all your help,
>      > Jc
>      >
>      >
>      >
>      > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
>      > <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>
>     <mailto:stefan.johansson at oracle.com
>     <mailto:stefan.johansson at oracle.com>>> wrote:
>      >
>      >? ? ?Hi JC,
>      >
>      >? ? ?On 2018-04-11 00:56, JC Beyler wrote:
>      >? ? ? > Small update:
>      >? ? ? >
>      >? ? ? > Here is the fixed webrev for the '{' that were out of
>     alignment.
>      >? ? ?This
>      >? ? ? > passed release build JTREG
>     for?hotspot/jtreg/compiler/jvmti (just
>      >? ? ?to run
>      >? ? ? > something as a smoke screen)
>     and?hotspot/jtreg/compiler/aot/ (to
>      >? ? ?test
>      >? ? ? > Graal).
>      >? ? ? > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
>      >? ? ? >
>      >? ? ?I think this looks better, I agree that leaving _end is
>     tempting to
>      >? ? ?avoid a lot of change, but I think this will be better in the
>     long run.
>      >
>      >? ? ?I still miss the changes to make the SA work. To see a
>     problem you
>      >? ? ?can run:
>      >? ? ?make CONF=fast run-test
>      >? ? ?TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
>      >
>      >? ? ?Cheers,
>      >? ? ?Stefan
>      >
>      >? ? ? > Let me know what you think,
>      >? ? ? > Jc
>      >? ? ? >
>      >? ? ? > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler
>     <jcbeyler at google.com <mailto:jcbeyler at google.com>
>      >? ? ?<mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>
>      >? ? ? > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>
>     <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>>> wrote:
>      >? ? ? >
>      >? ? ? >? ? ?Hi Karen and Stefan,
>      >? ? ? >
>      >? ? ? >? ? ?@Stefan: Naming is hard :)
>      >? ? ? >? ? ?@Karen: thanks for the Graal comment, I fixed it in
>     the new
>      >? ? ?webrev,
>      >? ? ? >? ? ?let me know what you think :)
>      >? ? ? >
>      >? ? ? >? ? ?I think the naming convention suggested in this webrev
>     came from
>      >? ? ? >? ? ?conversations in for JEP-331 and I am actually relatively
>      >? ? ? >? ? ?indifferent to the final result (as long as we have
>     some form of
>      >? ? ? >? ? ?forward progress :)). To be honest, I'd also be happy
>     to just
>      >? ? ?leave
>      >? ? ? >? ? ?_end as is for all architectures and Graal and have a new
>      >? ? ? >? ? ?_allocation_end. However, during initial reviews of
>     JEP-331
>      >? ? ?it was
>      >? ? ? >? ? ?deemed complicated to understand:
>      >? ? ? >
>      >? ? ? >? ? ?_end -> the _end or sampling end
>      >? ? ? >? ? ?_allocation_end -> end pointer for the last possible
>     allocation
>      >? ? ? >? ? ?hard_end -> allocation end?+ reserved space
>      >? ? ? >
>      >? ? ? >? ? ?That is how this naming came up and why hard_end went to
>      >? ? ?"reserved_end".
>      >? ? ? >
>      >? ? ? >? ? ?I'm really indifferent, so I offer as a perusal:
>      >? ? ? > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
>      >? ? ? >
>      >? ? ? >? ? ?I noticed a few problems of alignement of '{' so I'll
>     go fix
>      >? ? ?that.
>      >? ? ? >? ? ?Basically this webrev does the following:
>      >? ? ? >
>      >? ? ? >? ? ?- Uses fast_path_end instead of end
>      >? ? ? >? ? ?- Reverts hard_end back to where it was
>      >? ? ? >? ? ?- Adds the changes to Graal; there is a bunch of
>     changes in Graal
>      >? ? ? >? ? ?because Graal still contains a bit of code doing
>     fasttlabrefills.
>      >? ? ? >
>      >? ? ? >? ? ?Let me know what you think!
>      >? ? ? >
>      >? ? ? >? ? ?Thanks,
>      >? ? ? >? ? ?Jc
>      >? ? ? >
>      >? ? ? >
>      >? ? ? >? ? ?On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear
>      >? ? ? >? ? ?<karen.kinnear at oracle.com
>     <mailto:karen.kinnear at oracle.com> <mailto:karen.kinnear at oracle.com
>     <mailto:karen.kinnear at oracle.com>>
>      >? ? ?<mailto:karen.kinnear at oracle.com
>     <mailto:karen.kinnear at oracle.com> <mailto:karen.kinnear at oracle.com
>     <mailto:karen.kinnear at oracle.com>>>>
>      >? ? ?wrote:
>      >? ? ? >
>      >? ? ? >? ? ? ? ?Hi JC,
>      >? ? ? >
>      >? ? ? >? ? ? ? ?A comment about Graal. The impact on Graal for this
>      >? ? ?particular
>      >? ? ? >? ? ? ? ?change would be to break it - so you?ll need
>      >? ? ? >? ? ? ? ?to complete the Graal changes for this renaming.
>     That isn?t
>      >? ? ? >? ? ? ? ?optional or something that could be a follow-on. It
>      >? ? ? >? ? ? ? ?is not ok to break a feature, even an experimental
>     one.
>      >? ? ?We will
>      >? ? ? >? ? ? ? ?discuss in the other thread potential phasing of
>     adding
>      >? ? ?sampling.
>      >? ? ? >
>      >? ? ? >? ? ? ? ?I did not do a thorough search -you can do that -
>     I did find
>      >? ? ? >? ? ? ? ?src/jdk.internal.vm.compiler/share/classes/
>      >? ? ? >
>      >     
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? >? ? ? ? ? ? public final int threadTlabOffset =
>      >? ? ? >? ? ? ? ?getFieldOffset("Thread::_tlab", Integer.class,
>      >? ? ? >? ? ? ? ?"ThreadLocalAllocBuffer");
>      >? ? ? >
>      >     
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? >? ? ? ? ? ? private final int
>     threadLocalAllocBufferStartOffset =
>      >? ? ? >? ? ? ? ?getFieldOffset("ThreadLocalAllocBuffer::_start",
>      >? ? ?Integer.class,
>      >? ? ? >? ? ? ? ?"HeapWord*");
>      >? ? ? >
>      >     
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? >? ? ? ? ? ? private final int threadLocalAllocBufferEndOffset =
>      >? ? ? >? ? ? ? ?getFieldOffset("ThreadLocalAllocBuffer::_end",
>     Integer.class,
>      >? ? ? >? ? ? ? ?"HeapWord*");
>      >? ? ? >
>      >     
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? >? ? ? ? ? ? private final int threadLocalAllocBufferTopOffset =
>      >? ? ? >? ? ? ? ?getFieldOffset("ThreadLocalAllocBuffer::_top",
>     Integer.class,
>      >? ? ? >? ? ? ? ?"HeapWord*");
>      >? ? ? >
>      >     
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? >? ? ? ? ? ? private final int
>     threadLocalAllocBufferPfTopOffset =
>      >? ? ? >? ? ? ? ?getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
>      >? ? ?Integer.class,
>      >? ? ? >? ? ? ? ?"HeapWord*");
>      >? ? ? >
>      >     
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? >? ? ? ? ? ? private final int
>      >? ? ?threadLocalAllocBufferSlowAllocationsOffset
>      >? ? ? >? ? ? ? ?=
>     getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
>      >? ? ? >? ? ? ? ?Integer.class, "unsigned");
>      >? ? ? >
>      >     
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? >? ? ? ? ? ? private final int
>      >? ? ?threadLocalAllocBufferFastRefillWasteOffset
>      >? ? ? >? ? ? ? ?=
>      >? ? ?getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
>      >? ? ? >? ? ? ? ?Integer.class, "unsigned");
>      >? ? ? >
>      >     
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? >? ? ? ? ? ? private final int
>      >? ? ?threadLocalAllocBufferNumberOfRefillsOffset
>      >? ? ? >? ? ? ? ?=
>      >? ? ?getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
>      >? ? ? >? ? ? ? ?Integer.class, "unsigned");
>      >? ? ? >
>      >     
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? >? ? ? ? ? ? private final int
>      >? ? ? >? ? ? ? ?threadLocalAllocBufferRefillWasteLimitOffset =
>      >? ? ? >       
>      ?getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
>      >? ? ? >? ? ? ? ?Integer.class, "size_t");
>      >? ? ? >
>      >     
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? >? ? ? ? ? ? private final int
>      >? ? ?threadLocalAllocBufferDesiredSizeOffset =
>      >? ? ? >       
>      ?getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
>      >? ? ? >? ? ? ? ?Integer.class, "size_t");
>      >? ? ? >
>      >     
>      ?org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>      >? ? ? >? ? ? ? ? ? public final int tlabAlignmentReserve =
>      >? ? ? >
>      >     
>      ?getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
>      >? ? ? >? ? ? ? ?Integer.class, "size_t?);
>      >? ? ? >
>      >? ? ? >? ? ? ? ?hope this helps,
>      >? ? ? >? ? ? ? ?Karen
>      >? ? ? >
>      >? ? ? >>? ? ? ? ?On Apr 10, 2018, at 7:04 AM, Stefan Johansson
>      >? ? ? >>? ? ? ? ?<stefan.johansson at oracle.com
>     <mailto:stefan.johansson at oracle.com>
>      >? ? ?<mailto:stefan.johansson at oracle.com
>     <mailto:stefan.johansson at oracle.com>>
>      >? ? ? >>? ? ? ? ?<mailto:stefan.johansson at oracle.com
>     <mailto:stefan.johansson at oracle.com>
>      >? ? ?<mailto:stefan.johansson at oracle.com
>     <mailto:stefan.johansson at oracle.com>>>> wrote:
>      >? ? ? >>
>      >? ? ? >>? ? ? ? ?Hi JC,
>      >? ? ? >>
>      >? ? ? >>? ? ? ? ?I realize that the names have been discussed
>     before but I'm
>      >? ? ? >>? ? ? ? ?leaning towards suggesting something new. We
>     discussed this
>      >? ? ? >>? ? ? ? ?briefly here in the office and others might have
>     different
>      >? ? ? >>? ? ? ? ?opinions. One point that came up is that if we do
>     this
>      >? ? ?change
>      >? ? ? >>? ? ? ? ?and change all usages of
>     JavaThread::tlab_end_offset() it
>      >? ? ? >>? ? ? ? ?would be good to make sure the new name is good.
>     To us
>      >? ? ? >>? ? ? ? ?_current_end is not very descriptive, but naming
>     is hard and
>      >? ? ? >>? ? ? ? ?the best we could come up with is _fast_path_end
>     which would
>      >? ? ? >>? ? ? ? ?give the code:
>      >? ? ? >>? ? ? ? ??cmpptr(end, Address(thread,
>      >? ? ? >>? ? ? ? ?JavaThread::tlab_fast_path_end_offset()));
>      >? ? ? >>? ? ? ? ??jcc(Assembler::above, slow_case);
>      >? ? ? >>
>      >? ? ? >>? ? ? ? ?I think this reads pretty good and is fairly
>     clear. If we do
>      >? ? ? >>? ? ? ? ?this rename I think you can re-use _end in JEP-331
>      >? ? ?instead of
>      >? ? ? >>? ? ? ? ?calling it _allocation_end. But that is a later
>     review :)
>      >? ? ? >>
>      >? ? ? >>? ? ? ? ?Also, is there a good reason for renaming
>     hard_end() to
>      >? ? ? >>? ? ? ? ?reserved_end()?
>      >? ? ? >>
>      >? ? ? >>? ? ? ? ?One additional thing, you need to update the SA
>     to reflect
>      >? ? ? >>? ? ? ? ?this change. I think the only place you need to
>     fix is in:
>      >? ? ? >>
>      >     
>      ?src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
>      >? ? ? >>
>      >? ? ? >>? ? ? ? ?Thanks,
>      >? ? ? >>? ? ? ? ?Stefan
>      >? ? ? >>
>      >? ? ? >>? ? ? ? ?On 2018-04-09 19:24, JC Beyler wrote:
>      >? ? ? >>>? ? ? ? ?Hi all,
>      >? ? ? >>>? ? ? ? ?Small pre-amble to this request:
>      >? ? ? >>>? ? ? ? ?In my work to try to get a heap sampler in
>     OpenJDK (via JEP
>      >? ? ? >>>? ? ? ? ?331
>      >? ? ?<https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm
>      >? ? ? >>>? ? ? ? ?trying to reduce the footprint of my change so
>     that the
>      >? ? ? >>>? ? ? ? ?integration can be easier. I was told that
>     generally a JEP
>      >? ? ? >>>? ? ? ? ?webrev should be feature complete and go in at-once.
>      >? ? ?However,
>      >? ? ? >>>? ? ? ? ?with the change touching quite a bit of various code
>      >? ? ?pieces,
>      >? ? ? >>>? ? ? ? ?I was trying to figure out what could be
>     separated as not
>      >? ? ? >>>? ? ? ? ?"part of the feature".
>      >? ? ? >>>? ? ? ? ?I asked around and said that perhaps a solution
>     would be to
>      >? ? ? >>>? ? ? ? ?cut up the renaming of TLAB's end field that I
>     do in that
>      >? ? ? >>>? ? ? ? ?webrev. Because I'm renaming a field in TLAB used by
>      >? ? ?various
>      >? ? ? >>>? ? ? ? ?backends for that work, I have to update every
>     architecture
>      >? ? ? >>>? ? ? ? ?dependent code to reflect it.
>      >? ? ? >>>? ? ? ? ?I entirely understand that perhaps this is not
>     in the
>      >? ? ?habits
>      >? ? ? >>>? ? ? ? ?and very potentially might not be the way things are
>      >? ? ? >>>? ? ? ? ?generally done. If so, I apologize and let me
>     know if you
>      >? ? ? >>>? ? ? ? ?would not want this to go in separately :)
>      >? ? ? >>>? ? ? ? ?Final note: there is still a chance JEP-331 does
>     not go in.
>      >? ? ? >>>? ? ? ? ?If it does not, we can leave the new name in
>     place or I'll
>      >? ? ? >>>? ? ? ? ?happily revert it. I can even create an issue to
>     track this
>      >? ? ? >>>? ? ? ? ?if that makes it easier for all.
>      >? ? ? >>>? ? ? ? ?End of the pre-amble.
>      >? ? ? >>>? ? ? ? ?The 33-line change webrev in question is here:
>      >? ? ? >>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>      >? ? ? >>>? ? ? ? ?I fixed all the architectures and JVMCI and ran
>     a few
>      >? ? ?sanity
>      >? ? ? >>>? ? ? ? ?tests to ensure I had not missed anything.
>      >? ? ? >>>? ? ? ? ?Thanks for your help and I hope this is not too much
>      >? ? ?trouble,
>      >? ? ? >>>? ? ? ? ?Jc
>      >? ? ? >>>? ? ? ? ?Ps: there is a graal change that needs to happen
>     but I was
>      >? ? ? >>>? ? ? ? ?not sure who/where
>     <https://teams.googleplex.com/u/where>
>      >? ? ?<https://teams.googleplex.com/u/where>
>      >? ? ?<https://teams.googleplex.com/u/where> to
>      >? ? ? >>>? ? ? ? ?ask about it. I was told it could happen in a
>     separate
>      >? ? ? >>>? ? ? ? ?webrev. Can anyone point me to the right direction?
>      >? ? ?Should it
>      >? ? ? >>>? ? ? ? ?just be hotspot-compiler-dev?
>      >? ? ? >
>      >
> 

From stefan.johansson at oracle.com  Fri Apr 13 12:25:52 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Fri, 13 Apr 2018 14:25:52 +0200
Subject: RFR (M): 6672778: G1 should trim task queues more aggressively
 during evacuation pauses
In-Reply-To: <1523608516.2360.10.camel@oracle.com>
References: <1523272805.4326.33.camel@oracle.com>
 <1523447197.9657.6.camel@oracle.com>
 <43f37e0f-74c4-b9f9-bef7-934180518261@oracle.com>
 <1523608516.2360.10.camel@oracle.com>
Message-ID: <b306a75c-51f2-f1e5-b0de-3aa6a5759645@oracle.com>



On 2018-04-13 10:35, Thomas Schatzl wrote:
> Hi Stefan,
> 
>    thanks for your review... :)
> 
> On Thu, 2018-04-12 at 17:15 +0200, Stefan Johansson wrote:
>> Hi Thomas,
>>
>> On 2018-04-11 13:46, Thomas Schatzl wrote:
>>> Hi all,
>>>
>>>     I updated and (hopefully) improved the change a bit after some
>>> more thinking.
> [...]
>>>
>>> Webrevs:
>>> http://cr.openjdk.java.net/~tschatzl/6672778/webrev.0_to_1/ (diff)
>>> http://cr.openjdk.java.net/~tschatzl/6672778/webrev.1/ (full)
>>
>> Thanks for this update, I had a glance at the first version and I
>> think this is indeed simpler. Still have some comments though:
>> src/hotspot/share/gc/g1/g1CollectedHeap.cpp
>> 3129 root_processor->evacuate_roots(pss, pss->closures(), worker_id);
>>
>> Only pass in pss, and get the closures inside evactuate_roots.
>> -----
>> src/hotspot/share/gc/g1/g1SharedClosures.hpp
>> 48 double trim_time_sec() {
>> 49   return TicksToTimeHelper::seconds(_oops.trim_ticks_and_reset())
>> +
>> 50     TicksToTimeHelper::seconds(_oops_in_cld.trim_ticks_and_reset()
>> );
>> 51 }
>>
>> This could be removed now, right?
>> -----
>>
>> Apart from this me and Thomas has also spoken a bit offline so there
>> might be some additional changes.
>>
>> Thanks,
>> Stefan
> 
>    all done.
> 
> http://cr.openjdk.java.net/~tschatzl/6672778/webrev.1_to_2/ (diff)
> http://cr.openjdk.java.net/~tschatzl/6672778/webrev.2/ (full)

I like this :) Some additional small comments:

src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp
  516     _start_time += TicksToTimeHelper::seconds(_trim_time);

Maybe add a comment to explain when we update _start_time, something like:
// The trim_time should be excluded from this phase, do this by updating
// the start time.
-----

src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp
  380 class G1GCParPhaseTimesTracker : public CHeapObj<mtGC> {

Why do you need to change this to be CHeapObj instead of StackObj?
-----

src/hotspot/share/gc/g1/g1ParScanThreadState.hpp

   64   uint const _stack_drain_upper_threshold;
   65   uint const _stack_drain_lower_threshold;

As you know I like "drain" better than "trim" but to be consistent I 
think we should name these _queue_trim_xxxxx_threshold. Or go the other 
way and name everything "drain" =)
------

Thanks,
Stefan

> 
> Thanks,
>    Thomas
> 


From kim.barrett at oracle.com  Fri Apr 13 17:34:04 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 13 Apr 2018 13:34:04 -0400
Subject: RFR (S): 8201490: Improve concurrent mark keep alive closure
 performance
In-Reply-To: <1523607497.2360.9.camel@oracle.com>
References: <1523563031.2265.3.camel@oracle.com>
 <390AF736-8FBB-4985-A8D7-AF41032E1257@oracle.com>
 <1523607497.2360.9.camel@oracle.com>
Message-ID: <6A3B12CE-1BDF-4526-8015-C9F6A5474AC8@oracle.com>

> On Apr 13, 2018, at 4:18 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~tschatzl/8201490/webrev.0_to_1 (diff)
> http://cr.openjdk.java.net/~tschatzl/8201490/webrev.1 (full)
> 
> Thanks,
>  Thomas

Looks good.



From stefan.johansson at oracle.com  Mon Apr 16 08:21:55 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Mon, 16 Apr 2018 10:21:55 +0200
Subject: RFR (S): 8201490: Improve concurrent mark keep alive closure
 performance
In-Reply-To: <6A3B12CE-1BDF-4526-8015-C9F6A5474AC8@oracle.com>
References: <1523563031.2265.3.camel@oracle.com>
 <390AF736-8FBB-4985-A8D7-AF41032E1257@oracle.com>
 <1523607497.2360.9.camel@oracle.com>
 <6A3B12CE-1BDF-4526-8015-C9F6A5474AC8@oracle.com>
Message-ID: <b2ef32ca-26e1-21b4-a66d-58bc0143bbdd@oracle.com>



On 2018-04-13 19:34, Kim Barrett wrote:
>> On Apr 13, 2018, at 4:18 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>>
>> http://cr.openjdk.java.net/~tschatzl/8201490/webrev.0_to_1 (diff)
>> http://cr.openjdk.java.net/~tschatzl/8201490/webrev.1 (full)
>>
>> Thanks,
>>   Thomas
> 
> Looks good.
> 
+1
StefanJ


From stefan.johansson at oracle.com  Mon Apr 16 08:58:56 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Mon, 16 Apr 2018 10:58:56 +0200
Subject: RFR (S): 8201527: Bump default value of G1RefProcDrainInterval
In-Reply-To: <1523610654.2360.20.camel@oracle.com>
References: <1523610654.2360.20.camel@oracle.com>
Message-ID: <431b0bf9-d8cf-ba68-8f23-75e7528ceca4@oracle.com>

Hi Thomas,

Thanks for the details, changing the default value sounds reasonable. 
Reviewed.

Thanks,
Stefan

On 2018-04-13 11:10, Thomas Schatzl wrote:
> Hi all,
> 
>    can I have reviews for this change that bumps the default value of
> G1RefProcDrainInterval to 1000?
> 
> The G1RefProcDrainInterval flag determines the frequency at which new
> marks are actually processed while keeping alive references during
> reference processing.
> 
> The current value is 10, i.e. every ten references we try to drain the
> mark stack. However, due to how expensive setup and teardown of G1
> marking is, this seriously inhibits performance.
> 
> Tests showed that with a significantly higher value, 1000, reference
> processing time can halve.
> 
> There is a graph attached to the CR showing that somewhere between 500
> and 1000 the improvement levels out, so I chose the higher value. Users
> may still try out higher values if they want. Also, we might want to
> change this back if/when somebody fixes marking, but that seems to be a
> much larger effort than changing this default value :)
> 
> There is no issue with filling up the mark stack during reference
> processing, by default it may contains 128k entries. So no worries
> here.
> 
> This improvement is in addition to the other improvements to reference
> processing posted just recently.
> 
> Internal perf runs are on its way, however they typically do not
> exercise reference processing, so there should be no issue.
> 
> I will do the CSR work as soon as I have reviews for this (trivial)
> change.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8201527
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8201527/webrev/
> Testing:
> kitchensink reference processing stress test for many hours with
> different values; hs-tier1-3
> 
> Thanks,
>    Thomas
> 


From thomas.schatzl at oracle.com  Mon Apr 16 11:08:50 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 16 Apr 2018 13:08:50 +0200
Subject: RFR (M): 6672778: G1 should trim task queues more aggressively
 during evacuation pauses
In-Reply-To: <b306a75c-51f2-f1e5-b0de-3aa6a5759645@oracle.com>
References: <1523272805.4326.33.camel@oracle.com>
 <1523447197.9657.6.camel@oracle.com>
 <43f37e0f-74c4-b9f9-bef7-934180518261@oracle.com>
 <1523608516.2360.10.camel@oracle.com>
 <b306a75c-51f2-f1e5-b0de-3aa6a5759645@oracle.com>
Message-ID: <1523876930.12621.6.camel@oracle.com>

Hi all,

On Fri, 2018-04-13 at 14:25 +0200, Stefan Johansson wrote:
> 
> On 2018-04-13 10:35, Thomas Schatzl wrote:
> > Hi Stefan,
> > 
> >    thanks for your review... :)
> > 
> > On Thu, 2018-04-12 at 17:15 +0200, Stefan Johansson wrote:
> > > Hi Thomas,
> > > 
> > > On 2018-04-11 13:46, Thomas Schatzl wrote:
> > > > Hi all,
> > > > 
> > > >     I updated and (hopefully) improved the change a bit after
> > > > some
> > > > more thinking.
> > 
> > [...]
> > > > 
> > > > Webrevs:
> > > > http://cr.openjdk.java.net/~tschatzl/6672778/webrev.0_to_1/
> > > > (diff)
> > > > http://cr.openjdk.java.net/~tschatzl/6672778/webrev.1/ (full)
> > > 
> > > Thanks for this update, I had a glance at the first version and I
> > > think this is indeed simpler. Still have some comments though:
> > > src/hotspot/share/gc/g1/g1CollectedHeap.cpp
> > > 3129 root_processor->evacuate_roots(pss, pss->closures(),
> > > worker_id);
> > > 
> > > Only pass in pss, and get the closures inside evactuate_roots.
> > > -----
> > > src/hotspot/share/gc/g1/g1SharedClosures.hpp
> > > 48 double trim_time_sec() {
> > > 49   return
> > > TicksToTimeHelper::seconds(_oops.trim_ticks_and_reset())
> > > +
> > > 50     TicksToTimeHelper::seconds(_oops_in_cld.trim_ticks_and_res
> > > et()
> > > );
> > > 51 }
> > > 
> > > This could be removed now, right?
> > > -----
> > > 
> > > Apart from this me and Thomas has also spoken a bit offline so
> > > there
> > > might be some additional changes.
> > > 
> > > Thanks,
> > > Stefan
> > 
> >    all done.
> > 
> > http://cr.openjdk.java.net/~tschatzl/6672778/webrev.1_to_2/ (diff)
> > http://cr.openjdk.java.net/~tschatzl/6672778/webrev.2/ (full)
> 
> I like this :) Some additional small comments:
> 
> src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp
>   516     _start_time += TicksToTimeHelper::seconds(_trim_time);
> 
> Maybe add a comment to explain when we update _start_time, something
> like:
> // The trim_time should be excluded from this phase, do this by
> // updating the start time.

Fixed.

> -----
> 
> src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp
>   380 class G1GCParPhaseTimesTracker : public CHeapObj<mtGC> {
> 
> Why do you need to change this to be CHeapObj instead of StackObj?

The compiler complains about virtual methods in a StackObj. I did not
want to risk issues due to that. 

> src/hotspot/share/gc/g1/g1ParScanThreadState.hpp
> 
>    64   uint const _stack_drain_upper_threshold;
>    65   uint const _stack_drain_lower_threshold;
> 
> As you know I like "drain" better than "trim" but to be consistent I 
> think we should name these _queue_trim_xxxxx_threshold. Or go the
> other way and name everything "drain" =)

Fixed.

Also fixed a problem with the "-" operator of Tickspan introduced in
all this refactoring. This caused negative times being reported
sometimes in the logs.

http://cr.openjdk.java.net/~tschatzl/6672778/webrev.2_to_3/ (diff)
http://cr.openjdk.java.net/~tschatzl/6672778/webrev.3/ (full)

The change looks really nice now imho, thanks Stefan!

Thanks,
  Thomas



From thomas.schatzl at oracle.com  Mon Apr 16 11:13:18 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 16 Apr 2018 13:13:18 +0200
Subject: RFR (S): 8154528: Reclaim regions emptied by marking in Remark
 pause
In-Reply-To: <1522334960.2451.24.camel@oracle.com>
References: <1522334960.2451.24.camel@oracle.com>
Message-ID: <1523877198.12621.9.camel@oracle.com>

Hi,

  ping for a second reviewer....

Thomas

On Thu, 2018-03-29 at 16:49 +0200, Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews for this change that moves the space reclamation
> of empty regions into the Remark pause, which makes these regions
> available much sooner than before, with the obvious benefits of doing
> so.
> 
> The Cleanup pause now only contains updating the remembered set
> states
> after rebuilding remembered sets and determining the collection set
> candidates. In the future we might be able to make those concurrent
> and
> drop the Cleanup pause completely.
> 
> There is not much too say here, after all the recent refactorings
> this
> patch is almost trivial :)
> 
> From a timing POV this adds a few ms to the Remark pause in my
> measurements, mostly from the code root purging moved here. I think
> there is enough opportunity in the remark pause to decrease its
> duration in the future that outweighs the mentioned benefits.
> 
> Thanks go to everyone reviewing so far, particularly StefanJ and
> Sangheon!
> 
> Depends on JDK-8178105.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8154528
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8154528/webrev/
> Testing:
> hs-tier 1-5
> 
> Thanks,
>   Thomas
> 
> 
> 



From thomas.schatzl at oracle.com  Mon Apr 16 11:13:51 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 16 Apr 2018 13:13:51 +0200
Subject: RFR (XS): 8200723: Suppress rs_length and predicted_cards
 sampling during mixed gcs
In-Reply-To: <1522838125.2398.13.camel@oracle.com>
References: <1522838125.2398.13.camel@oracle.com>
Message-ID: <1523877231.12621.10.camel@oracle.com>

Hi all,

  ping for any reviewer ;)

Thomas

On Wed, 2018-04-04 at 12:35 +0200, Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews for this small change that fixes a throughput
> problem G1 may show after mixed gc phase?
> 
> The problem is that after mixed gc young gen sizing is heavily
> influenced by mixed gc due to in many cases highly different RS
> lengths
> and number of cards processed. Almost always in a negative way (if
> not
> neutral), i.e. during mixed gc these values are almost always much
> higher than during young gc, meaning that young gen of the first few
> young-only gcs is much smaller than it should be.
> 
> There is another related problem with adaptive IHOP, where due to
> these
> changes to the young gen, the survival rate increases (smaller young
> gen means less time to die), which decreases IHOP, which in turn
> increases the number of mixed phases (e.g. mixed gc's), which in turn
> make young gen stay small.
> 
> JDK-8035557 has a graph showing how eden size over time in relation
> to
> rs_length could look like without this change.
> 
> Contrary to JDK-8035557 this change kind of arbitrarily suppresses
> the
> sampling for rs_length and predicted_cards during mixed gc, so these
> "bad" values never enter the prediction logic. Mixed gc is not
> affected, since we do not use any prediction for sizing young during
> that time.
> 
> The proper fix would be JDK-8035557, completely separating
> predictions
> for young-only and mixed gc.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8200723
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8200723/webrev
> Testing:
> hs-tier 1-5 with many other changes over time; manual inspection of
> eden sizing behavior of several known to be affected benchmarks
> 
> Thanks,
>   Thomas
> 



From thomas.schatzl at oracle.com  Mon Apr 16 11:14:26 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 16 Apr 2018 13:14:26 +0200
Subject: RFR (XS): 8200730: Fix debug=gc+phases time tracking in Remark
 and Cleanup
In-Reply-To: <1522844769.2398.20.camel@oracle.com>
References: <1522844769.2398.20.camel@oracle.com>
Message-ID: <1523877266.12621.11.camel@oracle.com>

Hi all,

  ping for any reviewer...

Thanks,
  Thomas

On Wed, 2018-04-04 at 14:26 +0200, Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews to let the recently introduced timing
> measurements
> in Remark and Cleanup pauses actually show useful numbers?
> 
> The problem is that the GCTraceTime instances were not assigned to a
> variable inside a scope so the compiler immediately destructed it,
> always giving "0.000ms" lengths.
> 
> Also added to use the gc timer to these lines for JFR support.
> 
> I would like to think this is a trivial change.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8200730
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8200730/webrev
> Testing:
> manual verification that the shown numbers are sane
> 
> Thanks,
>   Thomas
> 



From shade at redhat.com  Mon Apr 16 11:29:54 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 16 Apr 2018 13:29:54 +0200
Subject: RFR (S): 8154528: Reclaim regions emptied by marking in Remark
 pause
In-Reply-To: <1523877198.12621.9.camel@oracle.com>
References: <1522334960.2451.24.camel@oracle.com>
 <1523877198.12621.9.camel@oracle.com>
Message-ID: <bd8569af-760c-8934-c656-c3d21ed74a71@redhat.com>

On 04/16/2018 01:13 PM, Thomas Schatzl wrote:
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8154528
>> Webrev:
>> http://cr.openjdk.java.net/~tschatzl/8154528/webrev/

The patch looks good.

We do the similar thing in Shenandoah, it is surprisingly effective on many workloads. Although
Shenandoah does this by marking those regions as "trash" during the pause, and then concurrently
cleaning them up after leaving the pause, which saves a few milliseconds of pause time. It matters
in two non-obvious places: a) if you ZapUnusedHeapArea (enabled by default in fastdebug) during the
pause, many of time-sensitive bugs get hidden; b) test time gets larger, because we would spend much
more time in STW;

Another related idea that we implemented in Shenandoah is immediate-garbage shortcut: when we have
enough of these reclaimable regions (e.g. 95% of total garbage), we shortcut the cycle, wasting no
more cycles for collection. I think it is more beneficial for G1, because you can avoid going to STW
for evacuation.

HTHS,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180416/e956f91e/signature.asc>

From thomas.schatzl at oracle.com  Mon Apr 16 11:58:16 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 16 Apr 2018 13:58:16 +0200
Subject: RFR (S): 8154528: Reclaim regions emptied by marking in Remark
 pause
In-Reply-To: <bd8569af-760c-8934-c656-c3d21ed74a71@redhat.com>
References: <1522334960.2451.24.camel@oracle.com>
 <1523877198.12621.9.camel@oracle.com>
 <bd8569af-760c-8934-c656-c3d21ed74a71@redhat.com>
Message-ID: <1523879896.12621.25.camel@oracle.com>

Hi Aleksey,

On Mon, 2018-04-16 at 13:29 +0200, Aleksey Shipilev wrote:
> On 04/16/2018 01:13 PM, Thomas Schatzl wrote:
> > > CR:
> > > https://bugs.openjdk.java.net/browse/JDK-8154528
> > > Webrev:
> > > http://cr.openjdk.java.net/~tschatzl/8154528/webrev/
> 
> The patch looks good.

  thanks for your review.

> 
> We do the similar thing in Shenandoah, it is surprisingly effective
> on many workloads. Although Shenandoah does this by marking those
> regions as "trash" during the pause, and then concurrently
> cleaning them up after leaving the pause, which saves a few
> milliseconds of pause time. It matters in two non-obvious places: a) 

You mean concurrently cleaning these regions?

G1 did the concurrent cleaning as well, but it has been removed for now
because
- reclaiming these regions is really really fast
- it adds some additional necessary synchronization (lock) in the
region allocation path. This shows up in pause time sometimes
particularly with smaller region sizes.

Now if G1 had lock-free region allocation (and lock free addition to
the free-list), this would not matter at all. At the moment the
additional lock has been considered worse than the additional
millisecond or so (in product code) even for large heaps.

> if you ZapUnusedHeapArea (enabled by default in fastdebug) during the
> pause, many of time-sensitive bugs get hidden; b) test time gets
> larger, because we would spend much more time in STW;
> 
> Another related idea that we implemented in Shenandoah is immediate-
> garbage shortcut: when we have enough of these reclaimable regions
> (e.g. 95% of total garbage), we shortcut the cycle, wasting no
> more cycles for collection. I think it is more beneficial for G1,
> because you can avoid going to STW for evacuation.

If I understand your suggestion, in this case the mixed phase won't be
started already :)

As for frequency of empty regions during remark, there "typically" arenot a lot of empty regions to reclaim any more. G1 reclaims some kind of empty humongous regions all the time (every gc pause), for exactly this reason.

Of course it would be really nice if the remembered set were improved
to be able to reclaim even more empty regions during regular gc
(basically its current implementation prevents efficiently doing that).

Thanks,
  Thomas



From stefan.johansson at oracle.com  Mon Apr 16 12:09:17 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Mon, 16 Apr 2018 14:09:17 +0200
Subject: RFR (XS): 8200730: Fix debug=gc+phases time tracking in Remark
 and Cleanup
In-Reply-To: <1523877266.12621.11.camel@oracle.com>
References: <1522844769.2398.20.camel@oracle.com>
 <1523877266.12621.11.camel@oracle.com>
Message-ID: <c5765497-17ed-e89f-a7af-0670def210c8@oracle.com>

Hi Thomas,

On 2018-04-16 13:14, Thomas Schatzl wrote:
> Hi all,
> 
>    ping for any reviewer...
> 
> Thanks,
>    Thomas
> 
> On Wed, 2018-04-04 at 14:26 +0200, Thomas Schatzl wrote:
>> Hi all,
>>
>>    can I have reviews to let the recently introduced timing
>> measurements
>> in Remark and Cleanup pauses actually show useful numbers?
>>
>> The problem is that the GCTraceTime instances were not assigned to a
>> variable inside a scope so the compiler immediately destructed it,
>> always giving "0.000ms" lengths.
>>
>> Also added to use the gc timer to these lines for JFR support.
>>
>> I would like to think this is a trivial change.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8200730
>> Webrev:
>> http://cr.openjdk.java.net/~tschatzl/8200730/webrev
Sorry for missing this one :)

Thanks for fixing this. Two things:
src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
1994     GCTraceTime(Debug, gc)("Clear Next Bitmap");

This line should to be changed as well.
---

The second thing is a partly pre-existing problem and I suggest you fix 
all occurrences in this file. The name "trace" is a bit misleading when 
the debug-level is "Debug", which is the case for all GCTraceTime in 
this file. I would prefer using "debug", like on this line:
1654     GCTraceTime(Debug, gc, phases) debug("Weak Processing", 
_gc_timer_cm);
-----

Thanks,
Stefan

>> Testing:
>> manual verification that the shown numbers are sane
>>
>> Thanks,
>>    Thomas
>>
> 


From stefan.johansson at oracle.com  Mon Apr 16 12:51:20 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Mon, 16 Apr 2018 14:51:20 +0200
Subject: RFR (XS): 8200723: Suppress rs_length and predicted_cards
 sampling during mixed gcs
In-Reply-To: <1522838125.2398.13.camel@oracle.com>
References: <1522838125.2398.13.camel@oracle.com>
Message-ID: <decce937-7f57-7397-06eb-970b7d4d87e2@oracle.com>

Hi Thomas,

On 2018-04-04 12:35, Thomas Schatzl wrote:
> Hi all,
> 
>    can I have reviews for this small change that fixes a throughput
> problem G1 may show after mixed gc phase?
> 
> The problem is that after mixed gc young gen sizing is heavily
> influenced by mixed gc due to in many cases highly different RS lengths
> and number of cards processed. Almost always in a negative way (if not
> neutral), i.e. during mixed gc these values are almost always much
> higher than during young gc, meaning that young gen of the first few
> young-only gcs is much smaller than it should be.
> 
> There is another related problem with adaptive IHOP, where due to these
> changes to the young gen, the survival rate increases (smaller young
> gen means less time to die), which decreases IHOP, which in turn
> increases the number of mixed phases (e.g. mixed gc's), which in turn
> make young gen stay small.
> 
> JDK-8035557 has a graph showing how eden size over time in relation to
> rs_length could look like without this change.
> 
> Contrary to JDK-8035557 this change kind of arbitrarily suppresses the
> sampling for rs_length and predicted_cards during mixed gc, so these
> "bad" values never enter the prediction logic. Mixed gc is not
> affected, since we do not use any prediction for sizing young during
> that time.
> 
> The proper fix would be JDK-8035557, completely separating predictions
> for young-only and mixed gc.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8200723
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8200723/webrev
Yet another one you slipped past me :)

I think the reasoning around this change is sound and code-wise it looks 
simple and good.

Thanks,
Stefan

> Testing:
> hs-tier 1-5 with many other changes over time; manual inspection of
> eden sizing behavior of several known to be affected benchmarks
> 
> Thanks,
>    Thomas
> 


From stefan.johansson at oracle.com  Mon Apr 16 12:58:34 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Mon, 16 Apr 2018 14:58:34 +0200
Subject: RFR (M): 6672778: G1 should trim task queues more aggressively
 during evacuation pauses
In-Reply-To: <1523876930.12621.6.camel@oracle.com>
References: <1523272805.4326.33.camel@oracle.com>
 <1523447197.9657.6.camel@oracle.com>
 <43f37e0f-74c4-b9f9-bef7-934180518261@oracle.com>
 <1523608516.2360.10.camel@oracle.com>
 <b306a75c-51f2-f1e5-b0de-3aa6a5759645@oracle.com>
 <1523876930.12621.6.camel@oracle.com>
Message-ID: <8fa48c25-6c7a-80af-4445-0f5d416ec4d4@oracle.com>

Hi Thomas,

On 2018-04-16 13:08, Thomas Schatzl wrote:
> Hi all,
> 
> On Fri, 2018-04-13 at 14:25 +0200, Stefan Johansson wrote:
>>
>> On 2018-04-13 10:35, Thomas Schatzl wrote:
>>> Hi Stefan,
>>>
>>>     thanks for your review... :)
>>>
>>> On Thu, 2018-04-12 at 17:15 +0200, Stefan Johansson wrote:
>>>> Hi Thomas,
>>>>
>>>> On 2018-04-11 13:46, Thomas Schatzl wrote:
>>>>> Hi all,
>>>>>
>>>>>      I updated and (hopefully) improved the change a bit after
>>>>> some
>>>>> more thinking.
>>>
>>> [...]
>> 
> Also fixed a problem with the "-" operator of Tickspan introduced in
> all this refactoring. This caused negative times being reported
> sometimes in the logs.
> 
> http://cr.openjdk.java.net/~tschatzl/6672778/webrev.2_to_3/ (diff)
> http://cr.openjdk.java.net/~tschatzl/6672778/webrev.3/ (full)
> 
> The change looks really nice now imho, thanks Stefan!
I agree, ship it :)

Thanks,
Stefan
> 
> Thanks,
>    Thomas
> 


From thomas.schatzl at oracle.com  Mon Apr 16 14:11:00 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 16 Apr 2018 16:11:00 +0200
Subject: RFR (XS): 8200730: Fix debug=gc+phases time tracking in Remark
 and Cleanup
In-Reply-To: <c5765497-17ed-e89f-a7af-0670def210c8@oracle.com>
References: <1522844769.2398.20.camel@oracle.com>
 <1523877266.12621.11.camel@oracle.com>
 <c5765497-17ed-e89f-a7af-0670def210c8@oracle.com>
Message-ID: <1523887860.12621.27.camel@oracle.com>

Hi Stefan,

On Mon, 2018-04-16 at 14:09 +0200, Stefan Johansson wrote:
> Hi Thomas,
> 
> On 2018-04-16 13:14, Thomas Schatzl wrote:
> > Hi all,
> > 
> >    ping for any reviewer...
> > 
> > Thanks,
> >    Thomas
> > 
> > On Wed, 2018-04-04 at 14:26 +0200, Thomas Schatzl wrote:
> > > Hi all,
> > > 
> > >    can I have reviews to let the recently introduced timing
> > > measurements in Remark and Cleanup pauses actually show useful
> > > numbers?
> > > 
> > > The problem is that the GCTraceTime instances were not assigned
> > > to a variable inside a scope so the compiler immediately
> > > destructed it, always giving "0.000ms" lengths.
> > > 
> > > Also added to use the gc timer to these lines for JFR support.
> > > 
> > > I would like to think this is a trivial change.
> > > 
> > > CR:
> > > https://bugs.openjdk.java.net/browse/JDK-8200730
> > > Webrev:
> > > http://cr.openjdk.java.net/~tschatzl/8200730/webrev
> 
> Sorry for missing this one :)
> 
> Thanks for fixing this. Two things:
> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
> 1994     GCTraceTime(Debug, gc)("Clear Next Bitmap");
> 
> This line should to be changed as well.

That's already been wrong for a long time -__-

> ---
> 
> The second thing is a partly pre-existing problem and I suggest you
> fix all occurrences in this file. The name "trace" is a bit
> misleading when the debug-level is "Debug", which is the case for all
> GCTraceTime in this file. I would prefer using "debug", like on this
> line:
> 1654     GCTraceTime(Debug, gc, phases) debug("Weak Processing", 
> _gc_timer_cm);
> -----

Fixed too.

http://cr.openjdk.java.net/~tschatzl/8200730/webrev.0_to_1/ (diff)
http://cr.openjdk.java.net/~tschatzl/8200730/webrev.1/ (full)

Thanks for your review.

Thomas



From thomas.schatzl at oracle.com  Mon Apr 16 15:28:06 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 16 Apr 2018 17:28:06 +0200
Subject: RFR (S): 8201596: java.lang.ref.Reference processing total time
 logging broken
Message-ID: <1523892486.12621.34.camel@oracle.com>

Hi all,

  can I have reviews for this change that fixes the output for
"Reference Processing" and adds "Weak Processing" like the other
collectors have?

For some time now the "Reference Processing" entry showed the time for
"Weak Processing", i.e. processing of VM internal weak references, not
j.l.ref.References processing.

This is really confusing because if you add gc+phase+ref logging you
typically get an overall shorter "Reference Processing" time than the
sub-phases take.

Also the "Other" time is really high sometimes.

I do not think it had other impact than logging though.

CR:
https://bugs.openjdk.java.net/browse/JDK-8201596
Webrev:
http://cr.openjdk.java.net/~tschatzl/8201596/webrev/
Testing:
test case, local testing, local compilation

Thanks,
  Thomas


From kim.barrett at oracle.com  Mon Apr 16 18:43:50 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 16 Apr 2018 14:43:50 -0400
Subject: RFR (S): 8201596: java.lang.ref.Reference processing total time
 logging broken
In-Reply-To: <1523892486.12621.34.camel@oracle.com>
References: <1523892486.12621.34.camel@oracle.com>
Message-ID: <A3D66240-7B83-45C2-A163-71313B932D1C@oracle.com>

> On Apr 16, 2018, at 11:28 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi all,
> 
>  can I have reviews for this change that fixes the output for
> "Reference Processing" and adds "Weak Processing" like the other
> collectors have?
> 
> For some time now the "Reference Processing" entry showed the time for
> "Weak Processing", i.e. processing of VM internal weak references, not
> j.l.ref.References processing.
> 
> This is really confusing because if you add gc+phase+ref logging you
> typically get an overall shorter "Reference Processing" time than the
> sub-phases take.
> 
> Also the "Other" time is really high sometimes.
> 
> I do not think it had other impact than logging though.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8201596
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8201596/webrev/
> Testing:
> test case, local testing, local compilation
> 
> Thanks,
>  Thomas

Looks good.



From sangheon.kim at oracle.com  Mon Apr 16 18:48:06 2018
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Mon, 16 Apr 2018 11:48:06 -0700
Subject: RFR (S): 8201596: java.lang.ref.Reference processing total time
 logging broken
In-Reply-To: <1523892486.12621.34.camel@oracle.com>
References: <1523892486.12621.34.camel@oracle.com>
Message-ID: <a00a8e3e-f288-91f1-9679-cfa712d6872f@oracle.com>

Hi Thomas,

On 04/16/2018 08:28 AM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for this change that fixes the output for
> "Reference Processing" and adds "Weak Processing" like the other
> collectors have?
>
> For some time now the "Reference Processing" entry showed the time for
> "Weak Processing", i.e. processing of VM internal weak references, not
> j.l.ref.References processing.
>
> This is really confusing because if you add gc+phase+ref logging you
> typically get an overall shorter "Reference Processing" time than the
> sub-phases take.
>
> Also the "Other" time is really high sometimes.
>
> I do not think it had other impact than logging though.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8201596
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8201596/webrev/
Looks good.

Thanks,
Sangheon


> Testing:
> test case, local testing, local compilation
>
> Thanks,
>    Thomas



From sangheon.kim at oracle.com  Mon Apr 16 18:51:46 2018
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Mon, 16 Apr 2018 11:51:46 -0700
Subject: RFR (XS): 8200730: Fix debug=gc+phases time tracking in Remark
 and Cleanup
In-Reply-To: <1523887860.12621.27.camel@oracle.com>
References: <1522844769.2398.20.camel@oracle.com>
 <1523877266.12621.11.camel@oracle.com>
 <c5765497-17ed-e89f-a7af-0670def210c8@oracle.com>
 <1523887860.12621.27.camel@oracle.com>
Message-ID: <a3c0f25f-8bab-31a2-82d8-1eeb7206c9c0@oracle.com>

Hi Thomas,

On 04/16/2018 07:11 AM, Thomas Schatzl wrote:
> Hi Stefan,
>
> On Mon, 2018-04-16 at 14:09 +0200, Stefan Johansson wrote:
>> Hi Thomas,
>>
>> On 2018-04-16 13:14, Thomas Schatzl wrote:
>>> Hi all,
>>>
>>>     ping for any reviewer...
>>>
>>> Thanks,
>>>     Thomas
>>>
>>> On Wed, 2018-04-04 at 14:26 +0200, Thomas Schatzl wrote:
>>>> Hi all,
>>>>
>>>>     can I have reviews to let the recently introduced timing
>>>> measurements in Remark and Cleanup pauses actually show useful
>>>> numbers?
>>>>
>>>> The problem is that the GCTraceTime instances were not assigned
>>>> to a variable inside a scope so the compiler immediately
>>>> destructed it, always giving "0.000ms" lengths.
>>>>
>>>> Also added to use the gc timer to these lines for JFR support.
>>>>
>>>> I would like to think this is a trivial change.
>>>>
>>>> CR:
>>>> https://bugs.openjdk.java.net/browse/JDK-8200730
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~tschatzl/8200730/webrev
>> Sorry for missing this one :)
>>
>> Thanks for fixing this. Two things:
>> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
>> 1994     GCTraceTime(Debug, gc)("Clear Next Bitmap");
>>
>> This line should to be changed as well.
> That's already been wrong for a long time -__-
>
>> ---
>>
>> The second thing is a partly pre-existing problem and I suggest you
>> fix all occurrences in this file. The name "trace" is a bit
>> misleading when the debug-level is "Debug", which is the case for all
>> GCTraceTime in this file. I would prefer using "debug", like on this
>> line:
>> 1654     GCTraceTime(Debug, gc, phases) debug("Weak Processing",
>> _gc_timer_cm);
>> -----
> Fixed too.
>
> http://cr.openjdk.java.net/~tschatzl/8200730/webrev.0_to_1/ (diff)
> http://cr.openjdk.java.net/~tschatzl/8200730/webrev.1/ (full)
Webrev.1 looks good.

Thanks,
Sangheon


>
> Thanks for your review.
>
> Thomas
>



From kim.barrett at oracle.com  Tue Apr 17 02:35:34 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 16 Apr 2018 22:35:34 -0400
Subject: RFR (XS): 8200723: Suppress rs_length and predicted_cards
 sampling during mixed gcs
In-Reply-To: <1522838125.2398.13.camel@oracle.com>
References: <1522838125.2398.13.camel@oracle.com>
Message-ID: <6D17BBC8-E838-4C3E-90B5-BC1E2000CEE9@oracle.com>

> On Apr 4, 2018, at 6:35 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi all,
> 
>  can I have reviews for this small change that fixes a throughput
> problem G1 may show after mixed gc phase?
> 
> The problem is that after mixed gc young gen sizing is heavily
> influenced by mixed gc due to in many cases highly different RS lengths
> and number of cards processed. Almost always in a negative way (if not
> neutral), i.e. during mixed gc these values are almost always much
> higher than during young gc, meaning that young gen of the first few
> young-only gcs is much smaller than it should be.
> 
> There is another related problem with adaptive IHOP, where due to these
> changes to the young gen, the survival rate increases (smaller young
> gen means less time to die), which decreases IHOP, which in turn
> increases the number of mixed phases (e.g. mixed gc's), which in turn
> make young gen stay small.
> 
> JDK-8035557 has a graph showing how eden size over time in relation to
> rs_length could look like without this change.
> 
> Contrary to JDK-8035557 this change kind of arbitrarily suppresses the
> sampling for rs_length and predicted_cards during mixed gc, so these
> "bad" values never enter the prediction logic. Mixed gc is not
> affected, since we do not use any prediction for sizing young during
> that time.
> 
> The proper fix would be JDK-8035557, completely separating predictions
> for young-only and mixed gc.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8200723
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8200723/webrev
> Testing:
> hs-tier 1-5 with many other changes over time; manual inspection of
> eden sizing behavior of several known to be affected benchmarks
> 
> Thanks,
>  Thomas

I was going to question whether there might be a problem with the call
to update_rs_lengths_prediction at line 711, which will might be using
stale data.  Except it doesn't update except for young-only collections.

Why do the calls to report_pending_cards and report_rs_lengths at
lines 694-5 cast the arguments to double?  I really dislike casts...

Change looks good.




From per.liden at oracle.com  Tue Apr 17 12:20:12 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 17 Apr 2018 14:20:12 +0200
Subject: RFR: 8201646: Introduce ReferenceDiscoverer interface
Message-ID: <cf59a291-e003-c50d-d257-8f74a3f7910e@oracle.com>

Introduce ReferenceDiscoverer interface to allow for alternative 
ReferenceProcessor implementations. The current ReferenceProcessor 
implementation is built for STW operation, which is undesirable for low 
latency GCs.

Bug: https://bugs.openjdk.java.net/browse/JDK-8201646
Webrev: http://cr.openjdk.java.net/~pliden/8201646/webrev.0

/Per


From stefan.karlsson at oracle.com  Tue Apr 17 12:39:27 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 17 Apr 2018 14:39:27 +0200
Subject: RFR: 8201646: Introduce ReferenceDiscoverer interface
In-Reply-To: <cf59a291-e003-c50d-d257-8f74a3f7910e@oracle.com>
References: <cf59a291-e003-c50d-d257-8f74a3f7910e@oracle.com>
Message-ID: <13b1c848-17a7-ec30-ca3e-a076bf97e113@oracle.com>

Looks good.

StefanK

On 2018-04-17 14:20, Per Liden wrote:
> Introduce ReferenceDiscoverer interface to allow for alternative 
> ReferenceProcessor implementations. The current ReferenceProcessor 
> implementation is built for STW operation, which is undesirable for low 
> latency GCs.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201646
> Webrev: http://cr.openjdk.java.net/~pliden/8201646/webrev.0
> 
> /Per


From per.liden at oracle.com  Tue Apr 17 12:49:29 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 17 Apr 2018 14:49:29 +0200
Subject: RFR: 8201646: Introduce ReferenceDiscoverer interface
In-Reply-To: <13b1c848-17a7-ec30-ca3e-a076bf97e113@oracle.com>
References: <cf59a291-e003-c50d-d257-8f74a3f7910e@oracle.com>
 <13b1c848-17a7-ec30-ca3e-a076bf97e113@oracle.com>
Message-ID: <5ca7b319-5c67-99c5-976f-c772a9d9f2e6@oracle.com>

Thanks Stefan!

/Per

On 04/17/2018 02:39 PM, Stefan Karlsson wrote:
> Looks good.
> 
> StefanK
> 
> On 2018-04-17 14:20, Per Liden wrote:
>> Introduce ReferenceDiscoverer interface to allow for alternative 
>> ReferenceProcessor implementations. The current ReferenceProcessor 
>> implementation is built for STW operation, which is undesirable for 
>> low latency GCs.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201646
>> Webrev: http://cr.openjdk.java.net/~pliden/8201646/webrev.0
>>
>> /Per


From thomas.schatzl at oracle.com  Tue Apr 17 12:54:25 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 17 Apr 2018 14:54:25 +0200
Subject: RFR: 8201646: Introduce ReferenceDiscoverer interface
In-Reply-To: <cf59a291-e003-c50d-d257-8f74a3f7910e@oracle.com>
References: <cf59a291-e003-c50d-d257-8f74a3f7910e@oracle.com>
Message-ID: <1523969665.2369.4.camel@oracle.com>

Hi Per,

On Tue, 2018-04-17 at 14:20 +0200, Per Liden wrote:
> Introduce ReferenceDiscoverer interface to allow for alternative 
> ReferenceProcessor implementations. The current ReferenceProcessor 
> implementation is built for STW operation, which is undesirable for
> low latency GCs.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201646
> Webrev: http://cr.openjdk.java.net/~pliden/8201646/webrev.0
> 

  great, I also thought about introducing such an interface, but
hesitated because of the additional work :)

My question is, did you perform at least some cursory performance
checking because this adds a virtual call?

Looks good otherwise.

Thanks,
  Thomas


From rkennke at redhat.com  Tue Apr 17 13:46:04 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 17 Apr 2018 15:46:04 +0200
Subject: RFR: 8201646: Introduce ReferenceDiscoverer interface
In-Reply-To: <cf59a291-e003-c50d-d257-8f74a3f7910e@oracle.com>
References: <cf59a291-e003-c50d-d257-8f74a3f7910e@oracle.com>
Message-ID: <c31f18a0-e285-52e9-47c3-24b3ca6d7916@redhat.com>

Am 17.04.2018 um 14:20 schrieb Per Liden:
> Introduce ReferenceDiscoverer interface to allow for alternative
> ReferenceProcessor implementations. The current ReferenceProcessor
> implementation is built for STW operation, which is undesirable for low
> latency GCs.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201646
> Webrev: http://cr.openjdk.java.net/~pliden/8201646/webrev.0
> 
> /Per

This seems reasonable and the patch looks good to me.

Thanks, Roman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180417/0cd10522/signature.asc>

From sangheon.kim at oracle.com  Tue Apr 17 20:07:04 2018
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Tue, 17 Apr 2018 13:07:04 -0700
Subject: RFR (S): 8201527: Bump default value of G1RefProcDrainInterval
In-Reply-To: <1523610654.2360.20.camel@oracle.com>
References: <1523610654.2360.20.camel@oracle.com>
Message-ID: <037fda86-0ac7-1964-7dd5-5d46a2fca637@oracle.com>

Hi Thomas,

On 04/13/2018 02:10 AM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for this change that bumps the default value of
> G1RefProcDrainInterval to 1000?
>
> The G1RefProcDrainInterval flag determines the frequency at which new
> marks are actually processed while keeping alive references during
> reference processing.
>
> The current value is 10, i.e. every ten references we try to drain the
> mark stack. However, due to how expensive setup and teardown of G1
> marking is, this seriously inhibits performance.
>
> Tests showed that with a significantly higher value, 1000, reference
> processing time can halve.
>
> There is a graph attached to the CR showing that somewhere between 500
> and 1000 the improvement levels out, so I chose the higher value. Users
> may still try out higher values if they want. Also, we might want to
> change this back if/when somebody fixes marking, but that seems to be a
> much larger effort than changing this default value :)
>
> There is no issue with filling up the mark stack during reference
> processing, by default it may contains 128k entries. So no worries
> here.
>
> This improvement is in addition to the other improvements to reference
> processing posted just recently.
>
> Internal perf runs are on its way, however they typically do not
> exercise reference processing, so there should be no issue.
>
> I will do the CSR work as soon as I have reviews for this (trivial)
> change.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8201527
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8201527/webrev/
> Testing:
> kitchensink reference processing stress test for many hours with
> different values; hs-tier1-3
Looks good.
Also reviewed CSR (JDK-8201531 
<https://bugs.openjdk.java.net/browse/JDK-8201531>).

Thanks,
Sangheon


>
> Thanks,
>    Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180417/50ad139c/attachment.htm>

From sangheon.kim at oracle.com  Tue Apr 17 22:17:06 2018
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Tue, 17 Apr 2018 15:17:06 -0700
Subject: RFR (M): 8201172: Parallelize Remset Tracking Update Before
 Rebuild phase
In-Reply-To: <1523446979.9657.4.camel@oracle.com>
References: <1523272611.4326.30.camel@oracle.com>
 <f0f0d1e2-be9f-e0b7-a8ed-af145464f8f0@oracle.com>
 <1523446979.9657.4.camel@oracle.com>
Message-ID: <aa02ffe4-2571-d72a-4778-a67cc510f284@oracle.com>

Hi Thomas,

On 04/11/2018 04:42 AM, Thomas Schatzl wrote:
> Hi Stefan,
>
> On Tue, 2018-04-10 at 14:29 +0200, Stefan Johansson wrote:
>> Hi Thomas,
>>
>> On 2018-04-09 13:16, Thomas Schatzl wrote:
>>> Hi all,
>>>
>>>     can I have reviews for this straightforward change that improves
>>> the
>>> "Remset Tracking Update Before Rebuild" phase of the Remark pause?
>>>
>>> Performance of this phase has not been a big issue, with ~3000
>>> regions
>>> you get around 1ms of time taken, but now it's even faster and
>>> hopefully if run with 30k regions, there are no nasty suprises (or
>>> not
>>> as nasty at least).
>>>
>>> Determining the number of threads to use has been done by doing a
>>> few
>>> measurements and tests and look at which point there does not seem
>>> to
>>> be any more scaling (i.e. the noise seems higher than the
>>> improvements), and the pause time much smaller than a millisecond.
>>>
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8201172
>>> Webrev:
>>> http://cr.openjdk.java.net/~tschatzl/8201172/webrev/
>> Looks good, just a few minor things:
>> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
>> 1108     G1UpdateRemSetTrackingBeforeRebuild cl(_g1h, _cm, &_cl);
>> 1109     _g1h->heap_region_par_iterate_from_worker_offset(&cl,
>> &_hrclaimer, worker_id);
>> 1110     Atomic::add(cl.num_selected_for_rebuild(),
>> &_num_selected_for_rebuild);
>>
>> Using the same names for all closures and and having
>> num_selected_for_rebuild in both the task and the closure, makes
>> this code a bit hard to follow. I suggest calling the task member
>> _total_selected_for_rebuild and also have the getter name match the
>> member for the closure.
>>
>> For the closures I'm fine with the members being named _cl, but it
>> would help if the instance above were name something else, like
>> rebuild.
> Done.
>
> http://cr.openjdk.java.net/~tschatzl/8201172/webrev.0_to_1 (diff)
> http://cr.openjdk.java.net/~tschatzl/8201172/webrev.1 (full)
Webrev.1 looks good.
I only have minor nits.

src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
1011?? G1ConcurrentMark* _cm;
- _cm member seems not really necessary for 
G1UpdateRemSetTrackingBeforeRebuildTask as it only passes to 
G1UpdateRemSetTrackingBeforeRebuild and we can get it from G1CollectedHeap.

1013?? uint _total_selected_for_rebuild;
- volatile?

Thanks,
Sangheon


>
> This change contains one difference that I actually forgot to fix in
> the last webrev - my notes tell me that the "best" value for
> RegionsPerThread is 384, not 512. I forgot to change this after fixing
> the ceil() operation in line 1174. I.e. originally I had
> align_size_up() there, but it requires a power-of-2 alignment value,
> that of course asserted when using 384. I fixed the align_size_up, but
> did not change the RegionsPerThread value. Sorry.
>
> Thanks,
>    Thomas



From sangheon.kim at oracle.com  Tue Apr 17 22:27:54 2018
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Tue, 17 Apr 2018 15:27:54 -0700
Subject: RFR: 8196071: Change G1 Full GC heap and thread sizing ergonomics
In-Reply-To: <69ab6ed5-372e-a0bd-3e42-76c7ca435796@oracle.com>
References: <7497d3fb-044d-35f2-f02f-70ea79f0e2aa@oracle.com>
 <1522054707.2471.7.camel@oracle.com>
 <217a9dd1-5e01-d46d-7e0e-7ab79e3381fd@oracle.com>
 <1522059162.8723.1.camel@oracle.com>
 <69ab6ed5-372e-a0bd-3e42-76c7ca435796@oracle.com>
Message-ID: <faecc63e-d72b-56be-2b11-c6525b071d21@oracle.com>

Hi Stefan,

Webrev.1 looks good to me.

Thanks,
Sangheon


On 04/05/2018 05:05 AM, Stefan Johansson wrote:
> Change looking for second reviewer.
>
> Cheers,
> Stefan
>
> On 2018-03-26 12:12, Thomas Schatzl wrote:
>> Hi,
>>
>> On Mon, 2018-03-26 at 11:47 +0200, Stefan Johansson wrote:
>>>
>>> On 2018-03-26 10:58, Thomas Schatzl wrote:
>>>> Hi,
>>>>
>>>> On Thu, 2018-03-22 at 16:42 +0100, Stefan Johansson wrote:
>>>>> Hi,
>>>>>
>>>>> Please review or comment on this change to let the G1 Full GC
>>>>> calculate the number of worker threads.
>>>>>
>> [...]
>>>>
>>>> ??? looks good, although I would prefer to separate the
>>>> HeapSizePerGCWorker change into a separate CR.
>>>
>>> Good point. Created JDK-8200228 for this and just realized I
>>> probably
>>> need a CSR for that as well. Here's a new webrev without the flag-
>>> change:
>>> http://cr.openjdk.java.net/~sjohanss/8196071/01/
>>
>> ?? still good.
>>
>> Thomas
>>



From rkennke at redhat.com  Wed Apr 18 06:34:51 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 18 Apr 2018 08:34:51 +0200
Subject: RFR: JDK-8198285: More consistent Access API for arraycopy
In-Reply-To: <e495295b-beb7-908a-f81b-7183e38dd41a@redhat.com>
References: <b57660bf-6c92-f243-6abd-2ea69570389c@redhat.com>
 <e495295b-beb7-908a-f81b-7183e38dd41a@redhat.com>
Message-ID: <fbaa9f9d-26c5-4d47-40cb-60db870f7c28@redhat.com>

Ping? Can I get a review?

Thanks, Roman


> I just realized we use ptrdiff_t for offset in the rest of the API. I am
> not sure that it's really a good fit. ptrdiff_t is meant to be used in
> pointer arithmetic and is relative to the size of the pointer type. We
> use it to give an offset in bytes from object start to the field, which
> is always positive and can be unsigned (ptrdiff_t is signed) and is
> always in bytes. Alas, I changed the API to use ptrdiff_t for now to
> make it consistent. If we want to change this, we shall change them all.
> 
> Please review the updated full webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8198285/webrev.01/
> 
> Thanks, Roman
> 
>>  Currently, the arraycopy API in access.hpp gets the src and dst oops,
>> plus the src and dst addresses. In order to be most useful to garbage
>> collectors, it should receive the src and dst oops together with the src
>> and dst offsets instead, and let the Access API / GC calculate the src
>> and dst addresses.
>>
>> For example, Shenandoah needs to resolve the src and dst objects for
>> arraycopy, and then apply the corresponding offsets. With the current
>> API (obj+ptr) it would calculate the ptr-diff from obj to ptr, then
>> resolve obj, then re-add the calculate ptr-diff. This is fragile because
>> we also may resolve obj in the runtime before calculating ptr (e.g. via
>> arrayOop::base()). If we then pass in the original obj and a ptr
>> calculated from another copy of the same obj, the above resolution logic
>> would not work. This is currently the case for obj-arraycopy.
>>
>> I propose to change the API to accept obj+offset, in addition to ptr for
>> both src and dst. Only one or the other should be used. Heap accesses
>> should use obj+offset and pass NULL for raw-ptr, off-heap accesses (or
>> heap accesses that are already resolved.. use with care) should pass
>> NULL+0 for obj+offset and the raw-ptr. Notice that this also allows the
>> API to be used for Java<->native array bulk transfers.
>>
>> An alternative would be to break the API up into 4 variants:
>>
>> Java->Java transfer:
>> arraycopy(oop src, size_t src_offs, oop dst, size_t dst_offs, size_t len)
>>
>> Java->Native transfer:
>> arraycopy(oop src, size_t src_offs, D* raw_dst, size_t len)
>>
>> Native->Java transfer:
>> arraycopy(S* src_raw, oop dst, size_t dst_offs, size_t len)
>>
>> 'Unsafe' transfer:
>> arraycopy(S* src_raw, D* dst_raw, size_t len)
>>
>>
>> But that seemed to be too much boilerplate copy+pasting for my taste.
>> (See how having this overly complicated template layer hurts us?)
>>
>> Plus, I had a better idea: instead of accepting oop+offset OR T* for
>> almost every Access API, we may want to abstract that and take an
>> Address type argument, which would be either HeapAddress(obj, offset) or
>> RawAddress(T* ptr). GCs may then just call addr->address() to get the
>> actual address, or specialize for HeapAddress variants and resolve the
>> objs and then resolve the address. This would also allow us to get rid
>> of almost half of the API (all the *_at variants would go) and some
>> other simplifications. However, this seemed to explode the scope of this
>> RFE, and would be better handled in another RFE.
>>
>> This changes makes both typeArrayKlass and objArrayKlass use the changed
>> API, plus I identified all (hopefully) places where we do bulk
>> Java<->native array transfers and make them use the API too. Gets us rid
>> of a bunch of memcpy calls :-)
>>
>> Please review the change:
>> http://cr.openjdk.java.net/~rkennke/JDK-8198285/webrev.00/
>>
>> Thanks, Roman
>>
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180418/6f3fc640/signature.asc>

From thomas.schatzl at oracle.com  Wed Apr 18 06:52:53 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 18 Apr 2018 08:52:53 +0200
Subject: RFR (M): 8201492: Properly implement non-contiguous generations for
 reference discovery
Message-ID: <1524034373.3236.7.camel@oracle.com>

Hi all,

  can I have reviews for this change that adapts the reference
discovery for the non-contiguous generations (and non-contiguous
generations in general) of G1 to solve one day-one performance issue?

So reference discovery does not properly support non-contiguous
generations, resorting to an approximation of it. 

This in turn causes G1 to require the "preserve cm referents" phase
during GC during marking, which is very costly in some cases. 

The reason for the preserve cm referents phase is that References
(j.l.ref.References instances) that are discovered by concurrent
discovery, will currently prevent discovery and evacuation of referents
in the STW pauses, as G1 thinks that it already has discovered that
Reference and skips it. Still their referents can be in young gen,
while the Reference is in old gen (young gc may iterate over it during
card scanning), and this may cause crashes later. 

The preserve cm referents phase brute-force simply evacuates any
"leftover" referents and its followers. 

This is because the STW reference discovery currently does not treat
References in old gen as roots (i.e. to be scanned and referents
evacuated always), as the STW reference processor thinks that the g1
heap is a single generation spanning the whole heap. 

By giving the ref processor the correct idea of generations in G1, this
automatically works, and obsoletes the "preserve cm referents" phase.

To get an understanding how serious this issue may be, on theKitchensink reference stress test program, the "Preserve CM referents"
phase may take 105ms out of 115ms.
CR:
https://bugs.openjdk.java.net/browse/JDK-8201492
Webrev:
http://cr.openjdk.java.net/~tschatzl/8201492/webrev/
Testing:
hs-tier1-3, performance verification, lots of Kitchensink reference
stress testing runs

Thanks,
  Thomas



From thomas.schatzl at oracle.com  Wed Apr 18 06:57:03 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 18 Apr 2018 08:57:03 +0200
Subject: RFR (S): 8201640: Use _ref_processor_* member variables directly in
 G1CollectedHeap
Message-ID: <1524034623.3236.11.camel@oracle.com>

Hi all,

  can I have reviews for this minor cleanup that removes the use of
getters to the various ref_processor members in G1CollectedHeap by
direct access?

CR:
https://bugs.openjdk.java.net/browse/JDK-8201640
Webrev:
http://cr.openjdk.java.net/~tschatzl/8201640/
Testing:
hs-tier1-3 with other changes, local compilation

Thanks,
  Thomas



From thomas.schatzl at oracle.com  Wed Apr 18 07:06:56 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 18 Apr 2018 09:06:56 +0200
Subject: RFR (XS): 8200723: Suppress rs_length and predicted_cards
 sampling during mixed gcs
In-Reply-To: <6D17BBC8-E838-4C3E-90B5-BC1E2000CEE9@oracle.com>
References: <1522838125.2398.13.camel@oracle.com>
 <6D17BBC8-E838-4C3E-90B5-BC1E2000CEE9@oracle.com>
Message-ID: <1524035216.3236.13.camel@oracle.com>

Hi Kim, Stefan,

On Mon, 2018-04-16 at 22:35 -0400, Kim Barrett wrote:
> > On Apr 4, 2018, at 6:35 AM, Thomas Schatzl <thomas.schatzl at oracle.c
> > om> wrote:
> > 
> > Hi all,
> > 
> >  can I have reviews for this small change that fixes a throughput
> > problem G1 may show after mixed gc phase?
> > 
> > 
> > [...]
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8200723
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8200723/webrev
> > Testing:
> > hs-tier 1-5 with many other changes over time; manual inspection of
> > eden sizing behavior of several known to be affected benchmarks
> > 
> > Thanks,
> >  Thomas
> 
> I was going to question whether there might be a problem with the
> call to update_rs_lengths_prediction at line 711, which will might be
> using stale data.  Except it doesn't update except for young-only
> collections.
> 
> Why do the calls to report_pending_cards and report_rs_lengths at
> lines 694-5 cast the arguments to double?  I really dislike casts...
> 

Yeah, some code that would need a lot of refactoring...

> Change looks good.
> 

  thanks for your reviews.

Thomas



From thomas.schatzl at oracle.com  Wed Apr 18 07:11:16 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 18 Apr 2018 09:11:16 +0200
Subject: RFR (XS): 8200730: Fix debug=gc+phases time tracking in Remark
 and Cleanup
In-Reply-To: <a3c0f25f-8bab-31a2-82d8-1eeb7206c9c0@oracle.com>
References: <1522844769.2398.20.camel@oracle.com>
 <1523877266.12621.11.camel@oracle.com>
 <c5765497-17ed-e89f-a7af-0670def210c8@oracle.com>
 <1523887860.12621.27.camel@oracle.com>
 <a3c0f25f-8bab-31a2-82d8-1eeb7206c9c0@oracle.com>
Message-ID: <1524035476.3236.14.camel@oracle.com>

Hi Stefan, Sangheon,

On Mon, 2018-04-16 at 11:51 -0700, sangheon.kim wrote:
> Hi Thomas,
> 
> On 04/16/2018 07:11 AM, Thomas Schatzl wrote:
> > Hi Stefan,
> > 
> > [...]
> > Fixed too.
> > 
> > http://cr.openjdk.java.net/~tschatzl/8200730/webrev.0_to_1/ (diff)
> > http://cr.openjdk.java.net/~tschatzl/8200730/webrev.1/ (full)
> 
> Webrev.1 looks good.

   Thanks for your reviews!

Thomas


From thomas.schatzl at oracle.com  Wed Apr 18 07:15:33 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 18 Apr 2018 09:15:33 +0200
Subject: RFR (XS): 8201487: Do not rebalance reference processing queues
 if not doing parallel reference processing
In-Reply-To: <560dc311-9fcd-a6e7-4afd-01aeb8e4fa80@oracle.com>
References: <1523563422.2265.6.camel@oracle.com>
 <560dc311-9fcd-a6e7-4afd-01aeb8e4fa80@oracle.com>
Message-ID: <1524035733.3236.15.camel@oracle.com>

Hi Sangheon, Kim,

On Thu, 2018-04-12 at 14:58 -0700, sangheon.kim wrote:
> Hi Thomas,
> 
> On 04/12/2018 01:03 PM, Thomas Schatzl wrote:
> > Hi all,
> > 
> >    can I have reviews for this small change that removes discovered
> > list
> > rebalancing for better work distribution across threads if running
> > serially.
> > 
> > This can save hundreds of ms in reference processing time.
> > 
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8201487
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8201487/webrev/
> 
> Looks good.

  thanks for your reviews.

Thomas



From thomas.schatzl at oracle.com  Wed Apr 18 07:16:05 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 18 Apr 2018 09:16:05 +0200
Subject: RFR (S): 8201490: Improve concurrent mark keep alive closure
 performance
In-Reply-To: <b2ef32ca-26e1-21b4-a66d-58bc0143bbdd@oracle.com>
References: <1523563031.2265.3.camel@oracle.com>
 <390AF736-8FBB-4985-A8D7-AF41032E1257@oracle.com>
 <1523607497.2360.9.camel@oracle.com>
 <6A3B12CE-1BDF-4526-8015-C9F6A5474AC8@oracle.com>
 <b2ef32ca-26e1-21b4-a66d-58bc0143bbdd@oracle.com>
Message-ID: <1524035765.3236.16.camel@oracle.com>

Hi Stefan, Kim,

On Mon, 2018-04-16 at 10:21 +0200, Stefan Johansson wrote:
> 
> On 2018-04-13 19:34, Kim Barrett wrote:
> > > On Apr 13, 2018, at 4:18 AM, Thomas Schatzl <thomas.schatzl at oracl
> > > e.com> wrote:
> > > 
> > > http://cr.openjdk.java.net/~tschatzl/8201490/webrev.0_to_1 (diff)
> > > http://cr.openjdk.java.net/~tschatzl/8201490/webrev.1 (full)
> > > 
> > > Thanks,
> > >   Thomas
> > 
> > Looks good.
> > 
> 
> +1

  thanks for your reviews.

Thomas



From thomas.schatzl at oracle.com  Wed Apr 18 07:19:50 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 18 Apr 2018 09:19:50 +0200
Subject: RFR (S): 8201596: java.lang.ref.Reference processing total time
 logging broken
In-Reply-To: <a00a8e3e-f288-91f1-9679-cfa712d6872f@oracle.com>
References: <1523892486.12621.34.camel@oracle.com>
 <a00a8e3e-f288-91f1-9679-cfa712d6872f@oracle.com>
Message-ID: <1524035990.3236.17.camel@oracle.com>

Hi Sangheon, Kim,

On Mon, 2018-04-16 at 11:48 -0700, sangheon.kim wrote:
> Hi Thomas,
> 
> On 04/16/2018 08:28 AM, Thomas Schatzl wrote:
> > Hi all,
> > 
> >    can I have reviews for this change that fixes the output for
> > "Reference Processing" and adds "Weak Processing" like the other
> > collectors have?
> > 
> > For some time now the "Reference Processing" entry showed the time
> > for "Weak Processing", i.e. processing of VM internal weak
> > references, not j.l.ref.References processing.
> > 
> > This is really confusing because if you add gc+phase+ref logging
> > you typically get an overall shorter "Reference Processing" time
> > than the sub-phases take.
> > 
> > Also the "Other" time is really high sometimes.
> > 
> > I do not think it had other impact than logging though.
> > 
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8201596
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8201596/webrev/
> 
> Looks good.
> 

  thanks for your reviews.

Thomas



From stefan.johansson at oracle.com  Wed Apr 18 07:25:54 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Wed, 18 Apr 2018 09:25:54 +0200
Subject: RFR (S): 8201640: Use _ref_processor_* member variables directly
 in G1CollectedHeap
In-Reply-To: <1524034623.3236.11.camel@oracle.com>
References: <1524034623.3236.11.camel@oracle.com>
Message-ID: <9fdcab9a-1ff2-b69a-aff3-7696f11298cd@oracle.com>

Hi Thomas,

On 2018-04-18 08:57, Thomas Schatzl wrote:
> Hi all,
> 
>    can I have reviews for this minor cleanup that removes the use of
> getters to the various ref_processor members in G1CollectedHeap by
> direct access?
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8201640
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8201640/
Looks good!

Stefan
> Testing:
> hs-tier1-3 with other changes, local compilation
> 
> Thanks,
>    Thomas
> 


From thomas.schatzl at oracle.com  Wed Apr 18 07:31:12 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 18 Apr 2018 09:31:12 +0200
Subject: RFR (M): 8201172: Parallelize Remset Tracking Update Before
 Rebuild phase
In-Reply-To: <aa02ffe4-2571-d72a-4778-a67cc510f284@oracle.com>
References: <1523272611.4326.30.camel@oracle.com>
 <f0f0d1e2-be9f-e0b7-a8ed-af145464f8f0@oracle.com>
 <1523446979.9657.4.camel@oracle.com>
 <aa02ffe4-2571-d72a-4778-a67cc510f284@oracle.com>
Message-ID: <1524036672.6872.1.camel@oracle.com>

On Tue, 2018-04-17 at 15:17 -0700, sangheon.kim wrote:
> Hi Thomas,
> 
> On 04/11/2018 04:42 AM, Thomas Schatzl wrote:
> > Hi Stefan,
> > 
> > On Tue, 2018-04-10 at 14:29 +0200, Stefan Johansson wrote:
> > > Hi Thomas,
> > > 
> > > On 2018-04-09 13:16, Thomas Schatzl wrote:
> > > > Hi all,
> > > > 
> > > >     can I have reviews for this straightforward change that
> > > > improves
> > > > the
> > > > "Remset Tracking Update Before Rebuild" phase of the Remark
> > > > pause?
> > > > 
> > > > Performance of this phase has not been a big issue, with ~3000
> > > > regions
> > > > you get around 1ms of time taken, but now it's even faster and
> > > > hopefully if run with 30k regions, there are no nasty suprises
> > > > (or
> > > > not
> > > > as nasty at least).
> > > > 
> > > > Determining the number of threads to use has been done by doing
> > > > a
> > > > few
> > > > measurements and tests and look at which point there does not
> > > > seem
> > > > to
> > > > be any more scaling (i.e. the noise seems higher than the
> > > > improvements), and the pause time much smaller than a
> > > > millisecond.
> > > > 
> > > > CR:
> > > > https://bugs.openjdk.java.net/browse/JDK-8201172
> > > > Webrev:
> > > > http://cr.openjdk.java.net/~tschatzl/8201172/webrev/
> > > 
> > > Looks good, just a few minor things:
> > > src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
> > > 1108     G1UpdateRemSetTrackingBeforeRebuild cl(_g1h, _cm, &_cl);
> > > 1109     _g1h->heap_region_par_iterate_from_worker_offset(&cl,
> > > &_hrclaimer, worker_id);
> > > 1110     Atomic::add(cl.num_selected_for_rebuild(),
> > > &_num_selected_for_rebuild);
> > > 
> > > Using the same names for all closures and and having
> > > num_selected_for_rebuild in both the task and the closure, makes
> > > this code a bit hard to follow. I suggest calling the task member
> > > _total_selected_for_rebuild and also have the getter name match
> > > the
> > > member for the closure.
> > > 
> > > For the closures I'm fine with the members being named _cl, but
> > > it
> > > would help if the instance above were name something else, like
> > > rebuild.
> > 
> > Done.
> > 
> > http://cr.openjdk.java.net/~tschatzl/8201172/webrev.0_to_1 (diff)
> > http://cr.openjdk.java.net/~tschatzl/8201172/webrev.1 (full)
> 
> Webrev.1 looks good.
> I only have minor nits.
> 
> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
> 1011   G1ConcurrentMark* _cm;
> - _cm member seems not really necessary for 
> G1UpdateRemSetTrackingBeforeRebuildTask as it only passes to 
> G1UpdateRemSetTrackingBeforeRebuild and we can get it from
> G1CollectedHeap.

There is no guideline on this, I kind of prefer explicitly passing on
what's needed. I will keep that.

> 
> 1013   uint _total_selected_for_rebuild;
> - volatile?

  I will fix this before pushing.

Thanks,
  Thomas



From stefan.johansson at oracle.com  Wed Apr 18 11:55:12 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Wed, 18 Apr 2018 13:55:12 +0200
Subject: RFR: 8196071: Change G1 Full GC heap and thread sizing ergonomics
In-Reply-To: <faecc63e-d72b-56be-2b11-c6525b071d21@oracle.com>
References: <7497d3fb-044d-35f2-f02f-70ea79f0e2aa@oracle.com>
 <1522054707.2471.7.camel@oracle.com>
 <217a9dd1-5e01-d46d-7e0e-7ab79e3381fd@oracle.com>
 <1522059162.8723.1.camel@oracle.com>
 <69ab6ed5-372e-a0bd-3e42-76c7ca435796@oracle.com>
 <faecc63e-d72b-56be-2b11-c6525b071d21@oracle.com>
Message-ID: <bd48b4d6-3408-8c11-98ae-947ba9523e7f@oracle.com>

Thanks for the review.

I will re-run some testing and push this tomorrow.

Thanks,
Stefan

On 2018-04-18 00:27, sangheon.kim wrote:
> Hi Stefan,
> 
> Webrev.1 looks good to me.
> 
> Thanks,
> Sangheon
> 
> 
> On 04/05/2018 05:05 AM, Stefan Johansson wrote:
>> Change looking for second reviewer.
>>
>> Cheers,
>> Stefan
>>
>> On 2018-03-26 12:12, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Mon, 2018-03-26 at 11:47 +0200, Stefan Johansson wrote:
>>>>
>>>> On 2018-03-26 10:58, Thomas Schatzl wrote:
>>>>> Hi,
>>>>>
>>>>> On Thu, 2018-03-22 at 16:42 +0100, Stefan Johansson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review or comment on this change to let the G1 Full GC
>>>>>> calculate the number of worker threads.
>>>>>>
>>> [...]
>>>>>
>>>>> ??? looks good, although I would prefer to separate the
>>>>> HeapSizePerGCWorker change into a separate CR.
>>>>
>>>> Good point. Created JDK-8200228 for this and just realized I
>>>> probably
>>>> need a CSR for that as well. Here's a new webrev without the flag-
>>>> change:
>>>> http://cr.openjdk.java.net/~sjohanss/8196071/01/
>>>
>>> ?? still good.
>>>
>>> Thomas
>>>
> 


From per.liden at oracle.com  Wed Apr 18 12:06:58 2018
From: per.liden at oracle.com (Per Liden)
Date: Wed, 18 Apr 2018 14:06:58 +0200
Subject: RFR: 8201646: Introduce ReferenceDiscoverer interface
In-Reply-To: <1523969665.2369.4.camel@oracle.com>
References: <cf59a291-e003-c50d-d257-8f74a3f7910e@oracle.com>
 <1523969665.2369.4.camel@oracle.com>
Message-ID: <e5825e9f-ad48-07f2-9a79-2009739b5f60@oracle.com>

On 04/17/2018 02:54 PM, Thomas Schatzl wrote:
> Hi Per,
> 
> On Tue, 2018-04-17 at 14:20 +0200, Per Liden wrote:
>> Introduce ReferenceDiscoverer interface to allow for alternative
>> ReferenceProcessor implementations. The current ReferenceProcessor
>> implementation is built for STW operation, which is undesirable for
>> low latency GCs.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201646
>> Webrev: http://cr.openjdk.java.net/~pliden/8201646/webrev.0
>>
> 
>    great, I also thought about introducing such an interface, but
> hesitated because of the additional work :)

Thanks for reviewing!

I noticed one thing in my patch. To get the oop type I'm including 
oop.hpp instead of oopsHierarchy.hpp. I'll fix this before pushing.

--- a/src/hotspot/share/gc/shared/referenceDiscoverer.hpp
+++ b/src/hotspot/share/gc/shared/referenceDiscoverer.hpp
@@ -27,7 +27,7 @@

  #include "memory/allocation.hpp"
  #include "memory/referenceType.hpp"
-#include "oops/oop.hpp"
+#include "oops/oopsHierarchy.hpp"

> 
> My question is, did you perform at least some cursory performance
> checking because this adds a virtual call?

I did run specjbb2015 (which uses SoftRefs fairly heavily), 2 iterations 
with and 2 iterations without my patch. No measurable difference in 
pause times.

cheers,
Per

> 
> Looks good otherwise.
> 
> Thanks,
>    Thomas
> 


From per.liden at oracle.com  Wed Apr 18 12:07:33 2018
From: per.liden at oracle.com (Per Liden)
Date: Wed, 18 Apr 2018 14:07:33 +0200
Subject: RFR: 8201646: Introduce ReferenceDiscoverer interface
In-Reply-To: <c31f18a0-e285-52e9-47c3-24b3ca6d7916@redhat.com>
References: <cf59a291-e003-c50d-d257-8f74a3f7910e@oracle.com>
 <c31f18a0-e285-52e9-47c3-24b3ca6d7916@redhat.com>
Message-ID: <90967350-0048-798a-989f-f52c3e8c970e@oracle.com>

Thanks Roman!

/Per

On 04/17/2018 03:46 PM, Roman Kennke wrote:
> Am 17.04.2018 um 14:20 schrieb Per Liden:
>> Introduce ReferenceDiscoverer interface to allow for alternative
>> ReferenceProcessor implementations. The current ReferenceProcessor
>> implementation is built for STW operation, which is undesirable for low
>> latency GCs.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201646
>> Webrev: http://cr.openjdk.java.net/~pliden/8201646/webrev.0
>>
>> /Per
> 
> This seems reasonable and the patch looks good to me.
> 
> Thanks, Roman
> 
> 


From thomas.schatzl at oracle.com  Wed Apr 18 12:24:24 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 18 Apr 2018 14:24:24 +0200
Subject: RFR: 8201646: Introduce ReferenceDiscoverer interface
In-Reply-To: <e5825e9f-ad48-07f2-9a79-2009739b5f60@oracle.com>
References: <cf59a291-e003-c50d-d257-8f74a3f7910e@oracle.com>
 <1523969665.2369.4.camel@oracle.com>
 <e5825e9f-ad48-07f2-9a79-2009739b5f60@oracle.com>
Message-ID: <1524054264.6872.6.camel@oracle.com>

Hi Per,

On Wed, 2018-04-18 at 14:06 +0200, Per Liden wrote:
> On 04/17/2018 02:54 PM, Thomas Schatzl wrote:
> > Hi Per,
> > 
> > On Tue, 2018-04-17 at 14:20 +0200, Per Liden wrote:
> > > Introduce ReferenceDiscoverer interface to allow for alternative
> > > ReferenceProcessor implementations. The current
> > > ReferenceProcessor
> > > implementation is built for STW operation, which is undesirable
> > > for
> > > low latency GCs.
> > > 
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201646
> > > Webrev: http://cr.openjdk.java.net/~pliden/8201646/webrev.0
> > > 
> > 
> >    great, I also thought about introducing such an interface, but
> > hesitated because of the additional work :)
> 
> Thanks for reviewing!
> 
> I noticed one thing in my patch. To get the oop type I'm including 
> oop.hpp instead of oopsHierarchy.hpp. I'll fix this before pushing.
> 
> --- a/src/hotspot/share/gc/shared/referenceDiscoverer.hpp
> +++ b/src/hotspot/share/gc/shared/referenceDiscoverer.hpp
> @@ -27,7 +27,7 @@
> 
>   #include "memory/allocation.hpp"
>   #include "memory/referenceType.hpp"
> -#include "oops/oop.hpp"
> +#include "oops/oopsHierarchy.hpp"
> 
> > 
> > My question is, did you perform at least some cursory performance
> > checking because this adds a virtual call?
> 
> I did run specjbb2015 (which uses SoftRefs fairly heavily), 2
> iterations 
> with and 2 iterations without my patch. No measurable difference in 
> pause times.

 okay. Ship it.

Thomas


From per.liden at oracle.com  Wed Apr 18 14:05:24 2018
From: per.liden at oracle.com (Per Liden)
Date: Wed, 18 Apr 2018 16:05:24 +0200
Subject: RFR: 8201800: Add support for adjusting heap addresses in a TLAB
Message-ID: <318e8a8d-aedd-c518-b4ae-a291eb0ba624@oracle.com>

This patch adds support for iterating over and adjusting heap addresses 
contained in TLABs. A user of this would be ZGC, which sometimes wants 
to adjust the color of those pointers. This patch adds a new function, 
ThreadLocalAllocBuffer::addresses_do(), which takes a function/functor 
and applies that to all addresses in the TLAB.

Bug: https://bugs.openjdk.java.net/browse/JDK-8201800
Webrev: http://cr.openjdk.java.net/~pliden/8201800/webrev.0

/Per


From shade at redhat.com  Wed Apr 18 14:23:11 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 18 Apr 2018 16:23:11 +0200
Subject: RFR: 8201800: Add support for adjusting heap addresses in a TLAB
In-Reply-To: <318e8a8d-aedd-c518-b4ae-a291eb0ba624@oracle.com>
References: <318e8a8d-aedd-c518-b4ae-a291eb0ba624@oracle.com>
Message-ID: <519a3201-8273-3c56-9a2d-db50f7cee3ed@redhat.com>

On 04/18/2018 04:05 PM, Per Liden wrote:
> This patch adds support for iterating over and adjusting heap addresses contained in TLABs. A user
> of this would be ZGC, which sometimes wants to adjust the color of those pointers. This patch adds a
> new function, ThreadLocalAllocBuffer::addresses_do(), which takes a function/functor and applies
> that to all addresses in the TLAB.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201800
> Webrev: http://cr.openjdk.java.net/~pliden/8201800/webrev.0

Wait, how does this supposed to work? Don't you want to pass four arguments to f(...), not call f()
four times?

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180418/3a39773a/signature.asc>

From shade at redhat.com  Wed Apr 18 14:26:29 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 18 Apr 2018 16:26:29 +0200
Subject: RFR: 8201800: Add support for adjusting heap addresses in a TLAB
In-Reply-To: <519a3201-8273-3c56-9a2d-db50f7cee3ed@redhat.com>
References: <318e8a8d-aedd-c518-b4ae-a291eb0ba624@oracle.com>
 <519a3201-8273-3c56-9a2d-db50f7cee3ed@redhat.com>
Message-ID: <f23e3819-4758-97a5-06be-c438a2129ef4@redhat.com>

On 04/18/2018 04:23 PM, Aleksey Shipilev wrote:
> On 04/18/2018 04:05 PM, Per Liden wrote:
>> This patch adds support for iterating over and adjusting heap addresses contained in TLABs. A user
>> of this would be ZGC, which sometimes wants to adjust the color of those pointers. This patch adds a
>> new function, ThreadLocalAllocBuffer::addresses_do(), which takes a function/functor and applies
>> that to all addresses in the TLAB.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201800
>> Webrev: http://cr.openjdk.java.net/~pliden/8201800/webrev.0
> 
> Wait, how does this supposed to work? Don't you want to pass four arguments to f(...), not call f()
> four times?

I misread. You want to update addresses *of* the TLAB itself, not *in* a memory covered by the TLAB.

This looks fine to me.

-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180418/8066f440/signature.asc>

From per.liden at oracle.com  Wed Apr 18 14:51:23 2018
From: per.liden at oracle.com (Per Liden)
Date: Wed, 18 Apr 2018 16:51:23 +0200
Subject: RFR: 8201800: Add support for adjusting heap addresses in a TLAB
In-Reply-To: <f23e3819-4758-97a5-06be-c438a2129ef4@redhat.com>
References: <318e8a8d-aedd-c518-b4ae-a291eb0ba624@oracle.com>
 <519a3201-8273-3c56-9a2d-db50f7cee3ed@redhat.com>
 <f23e3819-4758-97a5-06be-c438a2129ef4@redhat.com>
Message-ID: <0731cb81-8d4f-08c6-63b5-9d096d785ae4@oracle.com>

On 04/18/2018 04:26 PM, Aleksey Shipilev wrote:
> On 04/18/2018 04:23 PM, Aleksey Shipilev wrote:
>> On 04/18/2018 04:05 PM, Per Liden wrote:
>>> This patch adds support for iterating over and adjusting heap addresses contained in TLABs. A user
>>> of this would be ZGC, which sometimes wants to adjust the color of those pointers. This patch adds a
>>> new function, ThreadLocalAllocBuffer::addresses_do(), which takes a function/functor and applies
>>> that to all addresses in the TLAB.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201800
>>> Webrev: http://cr.openjdk.java.net/~pliden/8201800/webrev.0
>>
>> Wait, how does this supposed to work? Don't you want to pass four arguments to f(...), not call f()
>> four times?
> 
> I misread. You want to update addresses *of* the TLAB itself, not *in* a memory covered by the TLAB.

Yep, that's right.

> 
> This looks fine to me.

Thanks for reviewing!

/Per

> 
> -Aleksey
> 
> 


From stefan.karlsson at oracle.com  Wed Apr 18 14:58:26 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 18 Apr 2018 16:58:26 +0200
Subject: RFR: 8201800: Add support for adjusting heap addresses in a TLAB
In-Reply-To: <318e8a8d-aedd-c518-b4ae-a291eb0ba624@oracle.com>
References: <318e8a8d-aedd-c518-b4ae-a291eb0ba624@oracle.com>
Message-ID: <6da4cfaa-85ee-c192-aa80-dc65a53db1df@oracle.com>

Looks good to me.

StefanK

On 2018-04-18 16:05, Per Liden wrote:
> This patch adds support for iterating over and adjusting heap addresses 
> contained in TLABs. A user of this would be ZGC, which sometimes wants 
> to adjust the color of those pointers. This patch adds a new function, 
> ThreadLocalAllocBuffer::addresses_do(), which takes a function/functor 
> and applies that to all addresses in the TLAB.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201800
> Webrev: http://cr.openjdk.java.net/~pliden/8201800/webrev.0
> 
> /Per


From per.liden at oracle.com  Wed Apr 18 15:08:36 2018
From: per.liden at oracle.com (Per Liden)
Date: Wed, 18 Apr 2018 17:08:36 +0200
Subject: RFR: 8201800: Add support for adjusting heap addresses in a TLAB
In-Reply-To: <6da4cfaa-85ee-c192-aa80-dc65a53db1df@oracle.com>
References: <318e8a8d-aedd-c518-b4ae-a291eb0ba624@oracle.com>
 <6da4cfaa-85ee-c192-aa80-dc65a53db1df@oracle.com>
Message-ID: <8655bda0-0f07-9eec-fef5-2e4f13fa26a9@oracle.com>

Thanks Stefan!

/Per

On 04/18/2018 04:58 PM, Stefan Karlsson wrote:
> Looks good to me.
> 
> StefanK
> 
> On 2018-04-18 16:05, Per Liden wrote:
>> This patch adds support for iterating over and adjusting heap 
>> addresses contained in TLABs. A user of this would be ZGC, which 
>> sometimes wants to adjust the color of those pointers. This patch adds 
>> a new function, ThreadLocalAllocBuffer::addresses_do(), which takes a 
>> function/functor and applies that to all addresses in the TLAB.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201800
>> Webrev: http://cr.openjdk.java.net/~pliden/8201800/webrev.0
>>
>> /Per


From kim.barrett at oracle.com  Thu Apr 19 04:56:14 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 19 Apr 2018 00:56:14 -0400
Subject: RFR: 8201826: G1: Don't invoke WeakProcessor if mark stack has
 overflowed 
Message-ID: <9D6CF88A-D4F7-408C-8AF8-7C724A036559@oracle.com>

Please review this change to G1 concurrent marking to not invoke the
WeakProcessor when the mark stack has overflowed, as the is-alive
closure is not accurate in that situation.

CR:
https://bugs.openjdk.java.net/browse/JDK-8201826

Webrev:
http://cr.openjdk.java.net/~kbarrett/8201826/open.00/

Testing:
{jdk,hs}-tier{1,2,3} on all Oracle supported platforms.




From stefan.karlsson at oracle.com  Thu Apr 19 07:12:14 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 19 Apr 2018 09:12:14 +0200
Subject: RFR: 8201826: G1: Don't invoke WeakProcessor if mark stack has
 overflowed
In-Reply-To: <9D6CF88A-D4F7-408C-8AF8-7C724A036559@oracle.com>
References: <9D6CF88A-D4F7-408C-8AF8-7C724A036559@oracle.com>
Message-ID: <b673deee-cdae-a226-1474-9c44331cc089@oracle.com>

Looks good.

StefanK

On 2018-04-19 06:56, Kim Barrett wrote:
> Please review this change to G1 concurrent marking to not invoke the
> WeakProcessor when the mark stack has overflowed, as the is-alive
> closure is not accurate in that situation.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8201826
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8201826/open.00/
> 
> Testing:
> {jdk,hs}-tier{1,2,3} on all Oracle supported platforms.
> 
> 


From kim.barrett at oracle.com  Thu Apr 19 07:18:26 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 19 Apr 2018 03:18:26 -0400
Subject: RFR: 8201826: G1: Don't invoke WeakProcessor if mark stack has
 overflowed
In-Reply-To: <b673deee-cdae-a226-1474-9c44331cc089@oracle.com>
References: <9D6CF88A-D4F7-408C-8AF8-7C724A036559@oracle.com>
 <b673deee-cdae-a226-1474-9c44331cc089@oracle.com>
Message-ID: <F2542EF5-BDB6-4147-8DA8-BFC37D591573@oracle.com>

> On Apr 19, 2018, at 3:12 AM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
> 
> Looks good.
> 
> StefanK

Thanks.

> On 2018-04-19 06:56, Kim Barrett wrote:
>> Please review this change to G1 concurrent marking to not invoke the
>> WeakProcessor when the mark stack has overflowed, as the is-alive
>> closure is not accurate in that situation.
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8201826
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8201826/open.00/
>> Testing:
>> {jdk,hs}-tier{1,2,3} on all Oracle supported platforms.




From thomas.schatzl at oracle.com  Thu Apr 19 07:21:12 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 19 Apr 2018 09:21:12 +0200
Subject: RFR: 8201826: G1: Don't invoke WeakProcessor if mark stack has
 overflowed
In-Reply-To: <9D6CF88A-D4F7-408C-8AF8-7C724A036559@oracle.com>
References: <9D6CF88A-D4F7-408C-8AF8-7C724A036559@oracle.com>
Message-ID: <1524122472.2376.0.camel@oracle.com>

Hi Kim,

On Thu, 2018-04-19 at 00:56 -0400, Kim Barrett wrote:
> Please review this change to G1 concurrent marking to not invoke the
> WeakProcessor when the mark stack has overflowed, as the is-alive
> closure is not accurate in that situation.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8201826
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8201826/open.00/
> 
> Testing:
> {jdk,hs}-tier{1,2,3} on all Oracle supported platforms.
> 

  looks good.

Thomas


From thomas.schatzl at oracle.com  Thu Apr 19 08:09:09 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 19 Apr 2018 10:09:09 +0200
Subject: RFR (M): 6672778: G1 should trim task queues more aggressively
 during evacuation pauses
In-Reply-To: <8fa48c25-6c7a-80af-4445-0f5d416ec4d4@oracle.com>
References: <1523272805.4326.33.camel@oracle.com>
 <1523447197.9657.6.camel@oracle.com>
 <43f37e0f-74c4-b9f9-bef7-934180518261@oracle.com>
 <1523608516.2360.10.camel@oracle.com>
 <b306a75c-51f2-f1e5-b0de-3aa6a5759645@oracle.com>
 <1523876930.12621.6.camel@oracle.com>
 <8fa48c25-6c7a-80af-4445-0f5d416ec4d4@oracle.com>
Message-ID: <1524125349.2376.3.camel@oracle.com>

Hi all,

  I unfortunately found another issue with timing:

when calculating the "Other" time, we add the SATBFiltering phase to
the known worker time - however that time is already included in the
ext root scan time, so it is double-counted, and you occasionally get
slightly negative "Other" times.

This problem had been introduced in the refactoring too :(

This change fixes that.

Webrev:
http://cr.openjdk.java.net/~tschatzl/6672778/webrev.3_to_4/ (diff)
http://cr.openjdk.java.net/~tschatzl/6672778/webrev.4/ (full)

Thanks,
  Thomas

On Mon, 2018-04-16 at 14:58 +0200, Stefan Johansson wrote:
> Hi Thomas,
> 
> On 2018-04-16 13:08, Thomas Schatzl wrote:
> > Hi all,
> > 
> > On Fri, 2018-04-13 at 14:25 +0200, Stefan Johansson wrote:
> > > 
> > > On 2018-04-13 10:35, Thomas Schatzl wrote:
> > > > Hi Stefan,
> > > > 
> > > >     thanks for your review... :)
> > > > 
> > > > On Thu, 2018-04-12 at 17:15 +0200, Stefan Johansson wrote:
> > > > > Hi Thomas,
> > > > > 
> > > > > On 2018-04-11 13:46, Thomas Schatzl wrote:
> > > > > > Hi all,
> > > > > > 
> > > > > >      I updated and (hopefully) improved the change a bit
> > > > > > after
> > > > > > some
> > > > > > more thinking.
> > > > 
> > > > [...]
> > 
> > Also fixed a problem with the "-" operator of Tickspan introduced
> > in
> > all this refactoring. This caused negative times being reported
> > sometimes in the logs.
> > 
> > http://cr.openjdk.java.net/~tschatzl/6672778/webrev.2_to_3/ (diff)
> > http://cr.openjdk.java.net/~tschatzl/6672778/webrev.3/ (full)
> > 
> > The change looks really nice now imho, thanks Stefan!
> 
> I agree, ship it :)
> 
> Thanks,
> Stefan
> > 
> > Thanks,
> >    Thomas
> > 



From kim.barrett at oracle.com  Thu Apr 19 08:13:03 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 19 Apr 2018 04:13:03 -0400
Subject: RFR: 8201826: G1: Don't invoke WeakProcessor if mark stack has
 overflowed
In-Reply-To: <1524122472.2376.0.camel@oracle.com>
References: <9D6CF88A-D4F7-408C-8AF8-7C724A036559@oracle.com>
 <1524122472.2376.0.camel@oracle.com>
Message-ID: <A34E6C28-60CD-4F05-AC24-3796B732EAD0@oracle.com>

> On Apr 19, 2018, at 3:21 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi Kim,
> 
> On Thu, 2018-04-19 at 00:56 -0400, Kim Barrett wrote:
>> Please review this change to G1 concurrent marking to not invoke the
>> WeakProcessor when the mark stack has overflowed, as the is-alive
>> closure is not accurate in that situation.
>> 
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8201826
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8201826/open.00/
>> 
>> Testing:
>> {jdk,hs}-tier{1,2,3} on all Oracle supported platforms.
>> 
> 
>  looks good.
> 
> Thomas

Thanks.



From stefan.johansson at oracle.com  Thu Apr 19 09:27:42 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 19 Apr 2018 11:27:42 +0200
Subject: RFR (M): 6672778: G1 should trim task queues more aggressively
 during evacuation pauses
In-Reply-To: <1524125349.2376.3.camel@oracle.com>
References: <1523272805.4326.33.camel@oracle.com>
 <1523447197.9657.6.camel@oracle.com>
 <43f37e0f-74c4-b9f9-bef7-934180518261@oracle.com>
 <1523608516.2360.10.camel@oracle.com>
 <b306a75c-51f2-f1e5-b0de-3aa6a5759645@oracle.com>
 <1523876930.12621.6.camel@oracle.com>
 <8fa48c25-6c7a-80af-4445-0f5d416ec4d4@oracle.com>
 <1524125349.2376.3.camel@oracle.com>
Message-ID: <9423fa30-d986-0070-4561-ebfb3b0623a3@oracle.com>



On 2018-04-19 10:09, Thomas Schatzl wrote:
> Hi all,
> 
>    I unfortunately found another issue with timing:
> 
> when calculating the "Other" time, we add the SATBFiltering phase to
> the known worker time - however that time is already included in the
> ext root scan time, so it is double-counted, and you occasionally get
> slightly negative "Other" times.
> 
> This problem had been introduced in the refactoring too :(
> 
> This change fixes that.
> 
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/6672778/webrev.3_to_4/ (diff)
> http://cr.openjdk.java.net/~tschatzl/6672778/webrev.4/ (full)
Good that you caught that! Still good.

Thanks,
Stefan

> 
> Thanks,
>    Thomas
> 
> On Mon, 2018-04-16 at 14:58 +0200, Stefan Johansson wrote:
>> Hi Thomas,
>>
>> On 2018-04-16 13:08, Thomas Schatzl wrote:
>>> Hi all,
>>>
>>> On Fri, 2018-04-13 at 14:25 +0200, Stefan Johansson wrote:
>>>>
>>>> On 2018-04-13 10:35, Thomas Schatzl wrote:
>>>>> Hi Stefan,
>>>>>
>>>>>      thanks for your review... :)
>>>>>
>>>>> On Thu, 2018-04-12 at 17:15 +0200, Stefan Johansson wrote:
>>>>>> Hi Thomas,
>>>>>>
>>>>>> On 2018-04-11 13:46, Thomas Schatzl wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>>       I updated and (hopefully) improved the change a bit
>>>>>>> after
>>>>>>> some
>>>>>>> more thinking.
>>>>>
>>>>> [...]
>>>
>>> Also fixed a problem with the "-" operator of Tickspan introduced
>>> in
>>> all this refactoring. This caused negative times being reported
>>> sometimes in the logs.
>>>
>>> http://cr.openjdk.java.net/~tschatzl/6672778/webrev.2_to_3/ (diff)
>>> http://cr.openjdk.java.net/~tschatzl/6672778/webrev.3/ (full)
>>>
>>> The change looks really nice now imho, thanks Stefan!
>>
>> I agree, ship it :)
>>
>> Thanks,
>> Stefan
>>>
>>> Thanks,
>>>     Thomas
>>>
> 


From thomas.schatzl at oracle.com  Thu Apr 19 18:48:06 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 19 Apr 2018 20:48:06 +0200
Subject: RFR (S): 8202018: Move card table clear before enqueuing pending
 references
Message-ID: <1524163686.2765.3.camel@oracle.com>

Hi all,

  can I have reviews for this small change in preparation of "JDK-
8202017: Merge Reference Enqueuing phase with phase 3 of Reference
processing"?

So to be able to merge reference enqueuing with reference processing,
we need to make sure that the card marks of reference enqueuing are not
overwritten by card table clearing.

Card table clearing wipes data that the previous scan rs and update rs
phases have written to the card table to do duplicate card in
remembered sets detection.
Investigation of the code shows that since both scan rs and update rs
have already finished at the point of reference processing, we can
simply do the card table clearing before reference processing too -
otherwise it would at worst hide an existing bug as only scan rs and
update rs actually add to the list of regions' card tables to clear.

Looking at the code, doing the change, and testing all showed that this
seems fine.

CR:
https://bugs.openjdk.java.net/browse/JDK-8202018
Webrev:
http://cr.openjdk.java.net/~tschatzl/8202018/webrev/
Testing:
hs-tier1-4 with and without VerifyCTCleanup enabled (as it is a develop
flag and would give issues with the product, I temporarily
unconditionally enabled it via code)

Thanks,
  Thomas



From thomas.schatzl at oracle.com  Thu Apr 19 19:01:04 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 19 Apr 2018 21:01:04 +0200
Subject: RFR (S): 8202021: Improve variable naming in ReferenceProcessor
Message-ID: <1524164464.2765.9.camel@oracle.com>

Hi all,

  can I have reviews for this cleanup change that improves variable
naming in ReferenceProcessor code.

The main change is about renaming some member variables from something
really confusing to me to something useful (to me again :)) in the
DiscoveredListIterator class.

The other change is related to changing ReferenceProcessor::num_q to
num_queues, i.e. spelling out what the "q" is supposed to mean.

That imho improves readability quite a bit.

CR:
https://bugs.openjdk.java.net/browse/JDK-8202021
Webrev:
http://cr.openjdk.java.net/~tschatzl/8202021/webrev/
Testing:
local compilation, hs-tier1-4 with 8202017

based on JDK-8202018, but I do not think there is overlap.

Thanks,
  Thomas



From thomas.schatzl at oracle.com  Thu Apr 19 19:14:06 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 19 Apr 2018 21:14:06 +0200
Subject: RFR (S/M): 8202017: Merge Reference Enqueuing phase with phase 3 of
 Reference processing
Message-ID: <1524165246.2765.14.camel@oracle.com>

Hi all,

  can I have reviews for this change that merges the Reference
Enqueuing phase of reference processing with the respective phase 3 of
actual Reference Processing?

This is enabled by JDK-8202018 where we moved some work that cleared
card tables from inbetween Reference Processing and Reference Enqueuing
because we could (and likely always could), so the issue that cards
dirtied by Reference Processing are not cleared any more.

This saves one time spinning up and synchronizing worker threads at
least, if not more due to locality (i.e. completely saving one linked
list traversal).

This change affects all collectors using the reference processing
framework - I assume that Shenandoah, if it is using it, does not need
a split reference enqueuing phase either. Afaik Z does not use this
framework... :)

CR:
https://bugs.openjdk.java.net/browse/JDK-8202017
Webrev:
http://cr.openjdk.java.net/~tschatzl/8202017/webrev/
Testing:
hs-tier1-4

Thanks,
  Thomas



From sangheon.kim at oracle.com  Thu Apr 19 19:29:46 2018
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Thu, 19 Apr 2018 12:29:46 -0700
Subject: RFR (S): 8202018: Move card table clear before enqueuing pending
 references
In-Reply-To: <1524163686.2765.3.camel@oracle.com>
References: <1524163686.2765.3.camel@oracle.com>
Message-ID: <c4ec81a9-ab4e-c9fa-65d5-864f7ec2c950@oracle.com>

Hi Thomas,

On 04/19/2018 11:48 AM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for this small change in preparation of "JDK-
> 8202017: Merge Reference Enqueuing phase with phase 3 of Reference
> processing"?
>
> So to be able to merge reference enqueuing with reference processing,
> we need to make sure that the card marks of reference enqueuing are not
> overwritten by card table clearing.
>
> Card table clearing wipes data that the previous scan rs and update rs
> phases have written to the card table to do duplicate card in
> remembered sets detection.
> Investigation of the code shows that since both scan rs and update rs
> have already finished at the point of reference processing, we can
> simply do the card table clearing before reference processing too -
> otherwise it would at worst hide an existing bug as only scan rs and
> update rs actually add to the list of regions' card tables to clear.
>
> Looking at the code, doing the change, and testing all showed that this
> seems fine.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8202018
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8202018/webrev/
Looks good.

Thanks,
Sangheon


> Testing:
> hs-tier1-4 with and without VerifyCTCleanup enabled (as it is a develop
> flag and would give issues with the product, I temporarily
> unconditionally enabled it via code)
>
> Thanks,
>    Thomas
>



From sangheon.kim at oracle.com  Thu Apr 19 19:38:00 2018
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Thu, 19 Apr 2018 12:38:00 -0700
Subject: RFR (S): 8202021: Improve variable naming in ReferenceProcessor
In-Reply-To: <1524164464.2765.9.camel@oracle.com>
References: <1524164464.2765.9.camel@oracle.com>
Message-ID: <e881566b-d438-add2-360b-04d475b9bcab@oracle.com>

Hi Thomas,

On 04/19/2018 12:01 PM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for this cleanup change that improves variable
> naming in ReferenceProcessor code.
>
> The main change is about renaming some member variables from something
> really confusing to me to something useful (to me again :)) in the
> DiscoveredListIterator class.
>
> The other change is related to changing ReferenceProcessor::num_q to
> num_queues, i.e. spelling out what the "q" is supposed to mean.
>
> That imho improves readability quite a bit.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8202021
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8202021/webrev/
> Testing:
> local compilation, hs-tier1-4 with 8202017
>
> based on JDK-8202018, but I do not think there is overlap.
>
> Thanks,
>    Thomas
>
Looks good.
Just minor nits, so don't need extra webrev for these.

/src/hotspot/share/gc/shared/referenceProcessor.cpp
112?? _discovery_is_mt???? = mt_discovery;
113?? _num_queues?????????????? = MAX2(1U, mt_processing_degree);
114?? _max_num_queues?????????? = MAX2(_num_queues, mt_discovery_degree);
- Align with line 112?

312???? log_develop_trace(gc, ref)("??????? obj " INTPTR_FORMAT "/next_d 
" INTPTR_FORMAT, p2i(obj), p2i(next_discovered));
- next_d -> next_discovered

src/hotspot/share/gc/shared/referenceProcessor.hpp
- Copyright year update

src/hotspot/share/gc/shared/referenceProcessor.inline.hpp
- Copyright year update

Thanks,
Sangheon






From thomas.schatzl at oracle.com  Thu Apr 19 20:08:09 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 19 Apr 2018 22:08:09 +0200
Subject: RFR (S): 8202021: Improve variable naming in ReferenceProcessor
In-Reply-To: <e881566b-d438-add2-360b-04d475b9bcab@oracle.com>
References: <1524164464.2765.9.camel@oracle.com>
 <e881566b-d438-add2-360b-04d475b9bcab@oracle.com>
Message-ID: <1524168489.2765.15.camel@oracle.com>

Hi Sangheon,

  thanks for your review. I updated the change in-place.

Thomas

On Thu, 2018-04-19 at 12:38 -0700, sangheon.kim wrote:
> Hi Thomas,
> 
> On 04/19/2018 12:01 PM, Thomas Schatzl wrote:
> > Hi all,
> > 
> >    can I have reviews for this cleanup change that improves
> > variable
> > naming in ReferenceProcessor code.
> > 
> > The main change is about renaming some member variables from
> > something
> > really confusing to me to something useful (to me again :)) in the
> > DiscoveredListIterator class.
> > 
> > The other change is related to changing ReferenceProcessor::num_q
> > to
> > num_queues, i.e. spelling out what the "q" is supposed to mean.
> > 
> > That imho improves readability quite a bit.
> > 
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8202021
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8202021/webrev/
> > Testing:
> > local compilation, hs-tier1-4 with 8202017
> > 
> > based on JDK-8202018, but I do not think there is overlap.
> > 
> > Thanks,
> >    Thomas
> > 
> 
> Looks good.
> Just minor nits, so don't need extra webrev for these.
> 
> /src/hotspot/share/gc/shared/referenceProcessor.cpp
> 112   _discovery_is_mt     = mt_discovery;
> 113   _num_queues               = MAX2(1U, mt_processing_degree);
> 114   _max_num_queues           = MAX2(_num_queues,
> mt_discovery_degree);
> - Align with line 112?
> 
> 312     log_develop_trace(gc, ref)("        obj " INTPTR_FORMAT
> "/next_d 
> " INTPTR_FORMAT, p2i(obj), p2i(next_discovered));
> - next_d -> next_discovered
> 
> src/hotspot/share/gc/shared/referenceProcessor.hpp
> - Copyright year update
> 
> src/hotspot/share/gc/shared/referenceProcessor.inline.hpp
> - Copyright year update
> 
> Thanks,
> Sangheon
> 
> 
> 
> 



From thomas.schatzl at oracle.com  Thu Apr 19 20:10:04 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 19 Apr 2018 22:10:04 +0200
Subject: RFR (S): 8202018: Move card table clear before enqueuing
 pending references
In-Reply-To: <c4ec81a9-ab4e-c9fa-65d5-864f7ec2c950@oracle.com>
References: <1524163686.2765.3.camel@oracle.com>
 <c4ec81a9-ab4e-c9fa-65d5-864f7ec2c950@oracle.com>
Message-ID: <1524168604.2765.16.camel@oracle.com>

Hi,

On Thu, 2018-04-19 at 12:29 -0700, sangheon.kim wrote:
> Hi Thomas,
> 
> On 04/19/2018 11:48 AM, Thomas Schatzl wrote:
> > Hi all,
> > 
> >    can I have reviews for this small change in preparation of "JDK-
> > 8202017: Merge Reference Enqueuing phase with phase 3 of Reference
> > processing"?
> > 
> > 
> > [...]
> > Looking at the code, doing the change, and testing all showed that
> > this seems fine.
> > 
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8202018
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8202018/webrev/
> 
> Looks good.

  thanks for your review.

Thomas



From lutz.schmidt at sap.com  Fri Apr 20 11:04:01 2018
From: lutz.schmidt at sap.com (Schmidt, Lutz)
Date: Fri, 20 Apr 2018 11:04:01 +0000
Subject: RFR(XXS) 8202079: [s390]: Build failure w/o precompiled headers
Message-ID: <C5F577EA-8E49-496D-AE94-A2D1BA8DEAD3@sap.com>

Hi,

may I please request reviews for this tiny change, adding just a missing include? 

Bug:    https://bugs.openjdk.java.net/browse/JDK-8202079
Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8202079.00/ 

With this fix, the no_pch build completes OK. Due to the simplicity of the fix, I did not run extensive tests. SPECjvm98 was the most elaborate one. 

Thank you!
Lutz


From thomas.stuefe at gmail.com  Fri Apr 20 11:07:12 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 20 Apr 2018 11:07:12 +0000
Subject: RFR(XXS) 8202079: [s390]: Build failure w/o precompiled headers
In-Reply-To: <C5F577EA-8E49-496D-AE94-A2D1BA8DEAD3@sap.com>
References: <C5F577EA-8E49-496D-AE94-A2D1BA8DEAD3@sap.com>
Message-ID: <CAA-vtUyi=6TaguvMKtMCBALbbr3cyuT5uy0_5+uQu5EN+cvCNA@mail.gmail.com>

Looks good.

:)

On Fri, Apr 20, 2018, 13:04 Schmidt, Lutz <lutz.schmidt at sap.com> wrote:

> Hi,
>
> may I please request reviews for this tiny change, adding just a missing
> include?
>
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8202079
> Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8202079.00/
>
> With this fix, the no_pch build completes OK. Due to the simplicity of the
> fix, I did not run extensive tests. SPECjvm98 was the most elaborate one.
>
> Thank you!
> Lutz
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180420/e5ba2750/attachment.htm>

From shade at redhat.com  Fri Apr 20 11:09:59 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 20 Apr 2018 13:09:59 +0200
Subject: RFR(XXS) 8202079: [s390]: Build failure w/o precompiled headers
In-Reply-To: <C5F577EA-8E49-496D-AE94-A2D1BA8DEAD3@sap.com>
References: <C5F577EA-8E49-496D-AE94-A2D1BA8DEAD3@sap.com>
Message-ID: <3533c9b5-b98e-db99-be17-96d6b0b16aff@redhat.com>

On 04/20/2018 01:04 PM, Schmidt, Lutz wrote:
> Hi,
> 
> may I please request reviews for this tiny change, adding just a missing include?
> 
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8202079 Webrev:
> http://cr.openjdk.java.net/~lucy/webrevs/8202079.00/

Looks good!

Aside: I am currently teaching my CI to cross-compile linux/s390x, and that was one of the things
that breaks it.

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180420/eeb706b5/signature.asc>

From lutz.schmidt at sap.com  Fri Apr 20 12:10:24 2018
From: lutz.schmidt at sap.com (Schmidt, Lutz)
Date: Fri, 20 Apr 2018 12:10:24 +0000
Subject: RFR(XXS) 8202079: [s390]: Build failure w/o precompiled headers
In-Reply-To: <3533c9b5-b98e-db99-be17-96d6b0b16aff@redhat.com>
References: <C5F577EA-8E49-496D-AE94-A2D1BA8DEAD3@sap.com>
 <3533c9b5-b98e-db99-be17-96d6b0b16aff@redhat.com>
Message-ID: <5DC0E2C3-2244-4E3F-A68F-572004F81F3C@sap.com>

Thank you, Thomas & Aleksey!

Have a great weekend!
Lutz

?On 20.04.18, 13:09, "Aleksey Shipilev" <shade at redhat.com> wrote:

    On 04/20/2018 01:04 PM, Schmidt, Lutz wrote:
    > Hi,
    > 
    > may I please request reviews for this tiny change, adding just a missing include?
    > 
    > Bug:    https://bugs.openjdk.java.net/browse/JDK-8202079 Webrev:
    > http://cr.openjdk.java.net/~lucy/webrevs/8202079.00/
    
    Looks good!
    
    Aside: I am currently teaching my CI to cross-compile linux/s390x, and that was one of the things
    that breaks it.
    
    -Aleksey
    
    


From stefan.karlsson at oracle.com  Fri Apr 20 12:27:10 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 20 Apr 2018 14:27:10 +0200
Subject: RFR: 8202081: Introduce CollectedHeap::is_oop()
Message-ID: <fb4daf82-647d-1e1e-02bf-655975e2d085@oracle.com>

Hi all,

I'd like to propose that we add a virtual CollectedHeap::is_oop() 
function, so that GCs can add GC specific checks when verifying oops.

We've been running with this patch in the ZGC repository for a while, 
but the patch is ZGC agnostic:
http://hg.openjdk.java.net/zgc/zgc/rev/66eb1ad3de72
https://bugs.openjdk.java.net/browse/JDK-8202081

(I can create a webrev if needed)

Thanks,
StefanK


From erik.osterlund at oracle.com  Fri Apr 20 13:08:25 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Fri, 20 Apr 2018 15:08:25 +0200
Subject: RFR: 8202081: Introduce CollectedHeap::is_oop()
In-Reply-To: <fb4daf82-647d-1e1e-02bf-655975e2d085@oracle.com>
References: <fb4daf82-647d-1e1e-02bf-655975e2d085@oracle.com>
Message-ID: <5AD9E649.2040804@oracle.com>

Hi Stefan,

Looks great.

Thanks,
/Erik

On 2018-04-20 14:27, Stefan Karlsson wrote:
> Hi all,
>
> I'd like to propose that we add a virtual CollectedHeap::is_oop() 
> function, so that GCs can add GC specific checks when verifying oops.
>
> We've been running with this patch in the ZGC repository for a while, 
> but the patch is ZGC agnostic:
> http://hg.openjdk.java.net/zgc/zgc/rev/66eb1ad3de72
> https://bugs.openjdk.java.net/browse/JDK-8202081
>
> (I can create a webrev if needed)
>
> Thanks,
> StefanK



From rkennke at redhat.com  Fri Apr 20 13:11:59 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 20 Apr 2018 15:11:59 +0200
Subject: RFR: 8202081: Introduce CollectedHeap::is_oop()
In-Reply-To: <fb4daf82-647d-1e1e-02bf-655975e2d085@oracle.com>
References: <fb4daf82-647d-1e1e-02bf-655975e2d085@oracle.com>
Message-ID: <76714141-82c3-d4c6-cc1d-5dceac05a062@redhat.com>

I think it makes sense and patch looks good too.

Roman

> I'd like to propose that we add a virtual CollectedHeap::is_oop()
> function, so that GCs can add GC specific checks when verifying oops.
> 
> We've been running with this patch in the ZGC repository for a while,
> but the patch is ZGC agnostic:
> http://hg.openjdk.java.net/zgc/zgc/rev/66eb1ad3de72
> https://bugs.openjdk.java.net/browse/JDK-8202081
> 
> (I can create a webrev if needed)
> 
> Thanks,
> StefanK


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180420/c3bb304c/signature.asc>

From stefan.karlsson at oracle.com  Fri Apr 20 13:59:03 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 20 Apr 2018 15:59:03 +0200
Subject: RFR: 8202081: Introduce CollectedHeap::is_oop()
In-Reply-To: <fb4daf82-647d-1e1e-02bf-655975e2d085@oracle.com>
References: <fb4daf82-647d-1e1e-02bf-655975e2d085@oracle.com>
Message-ID: <feaa079b-e035-c318-8778-5eff2a41a727@oracle.com>

Thanks for the reviews, Erik and Roman.

StefanK

On 2018-04-20 14:27, Stefan Karlsson wrote:
> Hi all,
>
> I'd like to propose that we add a virtual CollectedHeap::is_oop() 
> function, so that GCs can add GC specific checks when verifying oops.
>
> We've been running with this patch in the ZGC repository for a while, 
> but the patch is ZGC agnostic:
> http://hg.openjdk.java.net/zgc/zgc/rev/66eb1ad3de72
> https://bugs.openjdk.java.net/browse/JDK-8202081
>
> (I can create a webrev if needed)
>
> Thanks,
> StefanK



From erik.osterlund at oracle.com  Fri Apr 20 14:50:07 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Fri, 20 Apr 2018 16:50:07 +0200
Subject: RFR: 8202083: Remove explicit CMS checks in CardTableBarrierSet
Message-ID: <5AD9FE1F.3050702@oracle.com>

Hi,

In CardTableBarrierSet, we sometimes need fencing due to the card table 
being scanned concurrently when using CMS with pre-cleaning. Rather than 
explicitly checking for those CMS flags in the generic 
CardTableBarrierSet class, it is preferrable to check the CardTable 
scanned_concurrently() property which reflects that better

Webrev:
http://cr.openjdk.java.net/~eosterlund/8202083/webrev.00/

Bug:
https://bugs.openjdk.java.net/browse/JDK-8202083

Thanks,
/Erik


From HORIE at jp.ibm.com  Mon Apr 23 10:33:59 2018
From: HORIE at jp.ibm.com (Michihiro Horie)
Date: Mon, 23 Apr 2018 19:33:59 +0900
Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64
Message-ID: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>



Dear all,

I would like to ask reviews on 8154736 ?enhancement of cmpxchg and
copy_to_survivor?. The change adds options to avoid expensive syncs with
compare-and-exchange. An experiment by using SPECjbb2015 showed 6%
improvement in critical-jOPS. This change focuses on ppc64 but would be
potentially beneficial for aarch64.

Although discussions stopped at
http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002718.html
, I would like to restart the review by taking over Hiroshi's work if the
discussion is still open.

Bug: https://bugs.openjdk.java.net/browse/JDK-8154736
Webrev: http://cr.openjdk.java.net/~mhorie/8154736/webrev.08/

Previous review had discussions on improper log output (
http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-September/002672.html
). Logs can be generated properly with this change, but I would like to ask
if we should use ?if(log) OrderAccess:acquire()? as is in webrev or more
general approach with a call to OrderAccess:consume() with empty
implementation on all supported platforms.

Also, there were discussions on the problem of unawareness of copied obj (
http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002696.html
). This change adds ?release? in cmpxchg_pre_membar. This was discussed in
http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002698.html
.

I measured SPECjbb2015 with its multi JVMs mode on a POWER8 node (for JDK11
, I modified MANIFEST in specjbb2015.jar to specify locations of JAXB
related libraries). As a result, critical-jOPS improved by 6% due to this
change.

Best regards,
--
Michihiro,
IBM Research - Tokyo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180423/6a4d8f1e/attachment.htm>

From stefan.johansson at oracle.com  Mon Apr 23 12:57:24 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Mon, 23 Apr 2018 14:57:24 +0200
Subject: RFR: 8191471: Elastic TLABs for G1
Message-ID: <f3758636-0e83-27d6-a9cc-bf16f82d03bb@oracle.com>

Hi,

Please review these changes to lower the waste in G1 mutator regions.

JBS: https://bugs.openjdk.java.net/browse/JDK-8191471
Webrev: http://cr.openjdk.java.net/~sjohanss/8191471/00/

Summary
G1 might waste excessive amount of memory due to allocations that would 
span region boundaries. To lower this waste this patch addresses this 
problem in two ways. TLAB allocations are now more flexible allowing the 
size to be less then the desired amount as long as the allocation will 
fit in the TLAB (defined by min_word_size in the call).

The G1 allocation code also tries to minimize the waste by keeping two 
active allocation regions so that a single large allocation won't cause 
waste that could have been used for other allocations.

Testing
Functional testing through mach5 with hs-tier 1-3 and jdk-tier 1-3. 
Performance testing locally and through aurora without seeing any 
regressions.

Thanks,
Stefan



From stefan.johansson at oracle.com  Mon Apr 23 12:57:45 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Mon, 23 Apr 2018 14:57:45 +0200
Subject: RFR: 8202140: TLAB logging is not correct for G1
Message-ID: <66684a37-2b85-ad90-3dea-d53028f76485@oracle.com>

Hi,

Please review this small change to make TLAB logging more correct, 
especially for collectors using regions.

JBS: https://bugs.openjdk.java.net/browse/JDK-8202140
Webrev: http://cr.openjdk.java.net/~sjohanss/8202140/00/

Summary
The current TLAB logging is not completely correct for G1 and other 
collectors using regions. The logging in 
ThreadLocalAllocBuffer::print_stats() expects that the allocated size is:
size_t alloc = _number_of_refills * _desired_size;

For each region in G1 the last TLAB might be smaller then _desired_size 
and therefor we need to add a separate value to account the actual 
allocated size.

Testing
Verified output to include reasonable values and ran through basic mach5 
testing.

Cheers,
Stefan


From thomas.schatzl at oracle.com  Mon Apr 23 13:42:12 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 23 Apr 2018 15:42:12 +0200
Subject: RFR: 8202140: TLAB logging is not correct for G1
In-Reply-To: <66684a37-2b85-ad90-3dea-d53028f76485@oracle.com>
References: <66684a37-2b85-ad90-3dea-d53028f76485@oracle.com>
Message-ID: <1524490932.2450.1.camel@oracle.com>

Hi,

On Mon, 2018-04-23 at 14:57 +0200, Stefan Johansson wrote:
> Hi,
> 
> Please review this small change to make TLAB logging more correct, 
> especially for collectors using regions.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8202140
> Webrev: http://cr.openjdk.java.net/~sjohanss/8202140/00/
> 
> Summary
> The current TLAB logging is not completely correct for G1 and other 
> collectors using regions. The logging in 
> ThreadLocalAllocBuffer::print_stats() expects that the allocated size
> is: size_t alloc = _number_of_refills * _desired_size;
> 
> For each region in G1 the last TLAB might be smaller then
> _desired_size and therefor we need to add a separate value to account
> the actual allocated size.

  looks good to me.

Maybe please fix the indentation of
ThreadLocalAllocBuffer::initialize_statistics().

Thanks,
  Thomas


From stefan.johansson at oracle.com  Mon Apr 23 14:02:15 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Mon, 23 Apr 2018 16:02:15 +0200
Subject: RFR (S): 8202021: Improve variable naming in ReferenceProcessor
In-Reply-To: <1524168489.2765.15.camel@oracle.com>
References: <1524164464.2765.9.camel@oracle.com>
 <e881566b-d438-add2-360b-04d475b9bcab@oracle.com>
 <1524168489.2765.15.camel@oracle.com>
Message-ID: <f802b27d-ae1f-9ae1-9e74-408f7202bf24@oracle.com>

Hi Thomas,

On 2018-04-19 22:08, Thomas Schatzl wrote:
> Hi Sangheon,
> 
>    thanks for your review. I updated the change in-place.
> 
> Thomas
> 
> On Thu, 2018-04-19 at 12:38 -0700, sangheon.kim wrote:
>> Hi Thomas,
>>
>> On 04/19/2018 12:01 PM, Thomas Schatzl wrote:
>>> Hi all,
>>>
>>>     can I have reviews for this cleanup change that improves
>>> variable
>>> naming in ReferenceProcessor code.
>>>
>>> The main change is about renaming some member variables from
>>> something
>>> really confusing to me to something useful (to me again :)) in the
>>> DiscoveredListIterator class.
>>>
>>> The other change is related to changing ReferenceProcessor::num_q
>>> to
>>> num_queues, i.e. spelling out what the "q" is supposed to mean.
>>>
>>> That imho improves readability quite a bit.
>>>
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8202021
>>> Webrev:
>>> http://cr.openjdk.java.net/~tschatzl/8202021/webrev/

Thanks for doing this, having better names really help when working with 
this code. The change looks ok, but I still struggle a bit with what all 
members are. I think my problem is seeing that _ref and _discovered_addr 
go together. What do you think about renaming:
_ref -> _current
_discovered_addr -> _current_discovered_addr
Potentially also:
_referent -> _current_referent
_referent_addr -> _current_referent_addr

Cheers,
Stefan

>>> Testing:
>>> local compilation, hs-tier1-4 with 8202017
>>>
>>> based on JDK-8202018, but I do not think there is overlap.
>>>
>>> Thanks,
>>>     Thomas
>>>
>>
>> Looks good.
>> Just minor nits, so don't need extra webrev for these.
>>
>> /src/hotspot/share/gc/shared/referenceProcessor.cpp
>> 112   _discovery_is_mt     = mt_discovery;
>> 113   _num_queues               = MAX2(1U, mt_processing_degree);
>> 114   _max_num_queues           = MAX2(_num_queues,
>> mt_discovery_degree);
>> - Align with line 112?
>>
>> 312     log_develop_trace(gc, ref)("        obj " INTPTR_FORMAT
>> "/next_d
>> " INTPTR_FORMAT, p2i(obj), p2i(next_discovered));
>> - next_d -> next_discovered
>>
>> src/hotspot/share/gc/shared/referenceProcessor.hpp
>> - Copyright year update
>>
>> src/hotspot/share/gc/shared/referenceProcessor.inline.hpp
>> - Copyright year update
>>
>> Thanks,
>> Sangheon
>>
>>
>>
>>
> 


From stefan.johansson at oracle.com  Mon Apr 23 14:05:43 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Mon, 23 Apr 2018 16:05:43 +0200
Subject: RFR (S): 8202018: Move card table clear before enqueuing pending
 references
In-Reply-To: <1524163686.2765.3.camel@oracle.com>
References: <1524163686.2765.3.camel@oracle.com>
Message-ID: <80303c8d-1b31-10c7-8d0e-9ed41320c820@oracle.com>

Looks good,
StefanJ

On 2018-04-19 20:48, Thomas Schatzl wrote:
> Hi all,
> 
>    can I have reviews for this small change in preparation of "JDK-
> 8202017: Merge Reference Enqueuing phase with phase 3 of Reference
> processing"?
> 
> So to be able to merge reference enqueuing with reference processing,
> we need to make sure that the card marks of reference enqueuing are not
> overwritten by card table clearing.
> 
> Card table clearing wipes data that the previous scan rs and update rs
> phases have written to the card table to do duplicate card in
> remembered sets detection.
> Investigation of the code shows that since both scan rs and update rs
> have already finished at the point of reference processing, we can
> simply do the card table clearing before reference processing too -
> otherwise it would at worst hide an existing bug as only scan rs and
> update rs actually add to the list of regions' card tables to clear.
> 
> Looking at the code, doing the change, and testing all showed that this
> seems fine.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8202018
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8202018/webrev/
> Testing:
> hs-tier1-4 with and without VerifyCTCleanup enabled (as it is a develop
> flag and would give issues with the product, I temporarily
> unconditionally enabled it via code)
> 
> Thanks,
>    Thomas
> 


From thomas.schatzl at oracle.com  Mon Apr 23 14:08:40 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 23 Apr 2018 16:08:40 +0200
Subject: RFR: 8191471: Elastic TLABs for G1
In-Reply-To: <f3758636-0e83-27d6-a9cc-bf16f82d03bb@oracle.com>
References: <f3758636-0e83-27d6-a9cc-bf16f82d03bb@oracle.com>
Message-ID: <1524492520.2450.8.camel@oracle.com>

On Mon, 2018-04-23 at 14:57 +0200, Stefan Johansson wrote:
> Hi,
> 
> Please review these changes to lower the waste in G1 mutator regions.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8191471
> Webrev: http://cr.openjdk.java.net/~sjohanss/8191471/00/
> 
> Summary
> G1 might waste excessive amount of memory due to allocations that
> would span region boundaries. To lower this waste this patch
> addresses this problem in two ways. TLAB allocations are now more
> flexible allowing the size to be less then the desired amount as long
> as the allocation will fit in the TLAB (defined by min_word_size in
> the call).
> 
> The G1 allocation code also tries to minimize the waste by keeping
> two active allocation regions so that a single large allocation won't
> cause waste that could have been used for other allocations.

  some minor nits:

- I would prefer that allocate_new_tlab() returned zero in
actual_word_size if the allocation failed. It does not in any
implementation.

- g1CollectedHeap.hpp:444: superfluous newline

- collectedHeap.hpp:132: "filled out" -> "returned"

Seems good otherwise.

Thanks,
  Thomas



From thomas.schatzl at oracle.com  Mon Apr 23 14:33:05 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 23 Apr 2018 16:33:05 +0200
Subject: RFR (S): 8202021: Improve variable naming in ReferenceProcessor
In-Reply-To: <f802b27d-ae1f-9ae1-9e74-408f7202bf24@oracle.com>
References: <1524164464.2765.9.camel@oracle.com>
 <e881566b-d438-add2-360b-04d475b9bcab@oracle.com>
 <1524168489.2765.15.camel@oracle.com>
 <f802b27d-ae1f-9ae1-9e74-408f7202bf24@oracle.com>
Message-ID: <1524493985.2450.11.camel@oracle.com>

On Mon, 2018-04-23 at 16:02 +0200, Stefan Johansson wrote:
> Hi Thomas,
> 
> On 2018-04-19 22:08, Thomas Schatzl wrote:
> > Hi Sangheon,
> > 
> >    thanks for your review. I updated the change in-place.
> > 
> > Thomas
> > 
> > On Thu, 2018-04-19 at 12:38 -0700, sangheon.kim wrote:
> > > Hi Thomas,
> > > 
> > > On 04/19/2018 12:01 PM, Thomas Schatzl wrote:
> > > > Hi all,
> > > > 
> > > >     can I have reviews for this cleanup change that improves
> > > > variable
> > > > naming in ReferenceProcessor code.
> > > > 
> > > > The main change is about renaming some member variables from
> > > > something
> > > > really confusing to me to something useful (to me again :)) in
> > > > the
> > > > DiscoveredListIterator class.
> > > > 
> > > > The other change is related to changing
> > > > ReferenceProcessor::num_q
> > > > to
> > > > num_queues, i.e. spelling out what the "q" is supposed to mean.
> > > > 
> > > > That imho improves readability quite a bit.
> > > > 
> > > > CR:
> > > > https://bugs.openjdk.java.net/browse/JDK-8202021
> > > > Webrev:
> > > > http://cr.openjdk.java.net/~tschatzl/8202021/webrev/
> 
> Thanks for doing this, having better names really help when working
> with this code. The change looks ok, but I still struggle a bit with
> what all members are. I think my problem is seeing that _ref and
> _discovered_addr go together. What do you think about renaming:
> _ref -> _current
> _discovered_addr -> _current_discovered_addr

Done.

> Potentially also:
> _referent -> _current_referent
> _referent_addr -> _current_referent_addr
> 

I think the latter renaming is unnecessary as there is no
prev/current/next distinction.

http://cr.openjdk.java.net/~tschatzl/8202021/webrev.1/ (full)
http://cr.openjdk.java.net/~tschatzl/8202021/webrev.0_to_1/ (diff)

Thanks,
  Thomas


From xiaofeng.wu at mavs.uta.edu  Mon Apr 23 15:42:50 2018
From: xiaofeng.wu at mavs.uta.edu (Xiaofeng Wu)
Date: Mon, 23 Apr 2018 10:42:50 -0500
Subject: A Side-channel Attack on HotSpot Heap Management
Message-ID: <9DB7BF3E-0184-473F-803D-89F0DAA81124@mavs.uta.edu>

We publish a paper ?A Side-channel Attack on HotSpot Heap Management?, and it is 
to appear in The 10th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud), 2018 
The paper link and details can be found in this link: http://ranger.uta.edu/~jrao/papers/HotCloud18.pdf 

In a nutshell, the problem is due to the usage of wall-clock timer in Parallel Scavenge GC. 
When JVM shares wall-clock timer with other applications in a multi-tenant environment, the time 
measurement opens up a side-channel for us to trick PS GC algorithm.
we can dilate time of minor GC or major GC to make GC dysfunctional: 
1. consume more heap size, or 2. invoke more GCs.

Currently, we only use eBPF to trace JVM debug symbols and launch attack like 
_ZN18AdaptiveSizePolicy22minor collection beginEv. However, profiler tools usually need 
root privilege. Still, we believe that it is an important issue and hope to see that the community 
can provide a safety net to avoid this kind of attack.

Best regards,
Xiaofeng Wu





From sangheon.kim at oracle.com  Mon Apr 23 20:19:07 2018
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Mon, 23 Apr 2018 13:19:07 -0700
Subject: RFR: 8202140: TLAB logging is not correct for G1
In-Reply-To: <66684a37-2b85-ad90-3dea-d53028f76485@oracle.com>
References: <66684a37-2b85-ad90-3dea-d53028f76485@oracle.com>
Message-ID: <fd24a3f8-a7f1-e38e-e1c5-6de8d95c87ac@oracle.com>

Hi Stefan,

On 04/23/2018 05:57 AM, Stefan Johansson wrote:
> Hi,
>
> Please review this small change to make TLAB logging more correct, 
> especially for collectors using regions.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8202140
> Webrev: http://cr.openjdk.java.net/~sjohanss/8202140/00/
>
> Summary
> The current TLAB logging is not completely correct for G1 and other 
> collectors using regions. The logging in 
> ThreadLocalAllocBuffer::print_stats() expects that the allocated size is:
> size_t alloc = _number_of_refills * _desired_size;
>
> For each region in G1 the last TLAB might be smaller then 
> _desired_size and therefor we need to add a separate value to account 
> the actual allocated size.
>
> Testing
> Verified output to include reasonable values and ran through basic 
> mach5 testing.
Looks good.

Thanks,
Sangheon


>
> Cheers,
> Stefan



From sangheon.kim at oracle.com  Mon Apr 23 20:23:03 2018
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Mon, 23 Apr 2018 13:23:03 -0700
Subject: RFR (S): 8202021: Improve variable naming in ReferenceProcessor
In-Reply-To: <1524493985.2450.11.camel@oracle.com>
References: <1524164464.2765.9.camel@oracle.com>
 <e881566b-d438-add2-360b-04d475b9bcab@oracle.com>
 <1524168489.2765.15.camel@oracle.com>
 <f802b27d-ae1f-9ae1-9e74-408f7202bf24@oracle.com>
 <1524493985.2450.11.camel@oracle.com>
Message-ID: <88aca18f-32f5-4190-371f-9a5655602be7@oracle.com>

Hi Thomas,

On 04/23/2018 07:33 AM, Thomas Schatzl wrote:
> On Mon, 2018-04-23 at 16:02 +0200, Stefan Johansson wrote:
>> Hi Thomas,
>>
>> On 2018-04-19 22:08, Thomas Schatzl wrote:
>>> Hi Sangheon,
>>>
>>>     thanks for your review. I updated the change in-place.
>>>
>>> Thomas
>>>
>>> On Thu, 2018-04-19 at 12:38 -0700, sangheon.kim wrote:
>>>> Hi Thomas,
>>>>
>>>> On 04/19/2018 12:01 PM, Thomas Schatzl wrote:
>>>>> Hi all,
>>>>>
>>>>>      can I have reviews for this cleanup change that improves
>>>>> variable
>>>>> naming in ReferenceProcessor code.
>>>>>
>>>>> The main change is about renaming some member variables from
>>>>> something
>>>>> really confusing to me to something useful (to me again :)) in
>>>>> the
>>>>> DiscoveredListIterator class.
>>>>>
>>>>> The other change is related to changing
>>>>> ReferenceProcessor::num_q
>>>>> to
>>>>> num_queues, i.e. spelling out what the "q" is supposed to mean.
>>>>>
>>>>> That imho improves readability quite a bit.
>>>>>
>>>>> CR:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8202021
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~tschatzl/8202021/webrev/
>> Thanks for doing this, having better names really help when working
>> with this code. The change looks ok, but I still struggle a bit with
>> what all members are. I think my problem is seeing that _ref and
>> _discovered_addr go together. What do you think about renaming:
>> _ref -> _current
>> _discovered_addr -> _current_discovered_addr
> Done.
>
>> Potentially also:
>> _referent -> _current_referent
>> _referent_addr -> _current_referent_addr
>>
> I think the latter renaming is unnecessary as there is no
> prev/current/next distinction.
>
> http://cr.openjdk.java.net/~tschatzl/8202021/webrev.1/ (full)
> http://cr.openjdk.java.net/~tschatzl/8202021/webrev.0_to_1/ (diff)
webrev.1 still looks good.

Thanks,
Sangheon


>
> Thanks,
>    Thomas



From kim.barrett at oracle.com  Mon Apr 23 21:29:31 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 23 Apr 2018 17:29:31 -0400
Subject: RFR: 8202083: Remove explicit CMS checks in CardTableBarrierSet
In-Reply-To: <5AD9FE1F.3050702@oracle.com>
References: <5AD9FE1F.3050702@oracle.com>
Message-ID: <BD69A740-6C08-4F55-9B6E-97331EEEAB5E@oracle.com>

> On Apr 20, 2018, at 10:50 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
> 
> Hi,
> 
> In CardTableBarrierSet, we sometimes need fencing due to the card table being scanned concurrently when using CMS with pre-cleaning. Rather than explicitly checking for those CMS flags in the generic CardTableBarrierSet class, it is preferrable to check the CardTable scanned_concurrently() property which reflects that better
> 
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8202083/webrev.00/
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8202083
> 
> Thanks,
> /Erik

Isn't the correct predicate here
CardTableBarrierSet::card_mark_must_follow_store?

Also, the comment probably ought to be "generalized".

Also, CardTable::scanned_concurrently() seems misplaced. CardTable is
a data structure, scanned_concurrently is a usage policy. And the only
use of scanned_concurrently seems to be the implementation of
card_mark_must_follow_store. It seems like CardTableBarrierSet would
be a better place for that bit of information.



From kim.barrett at oracle.com  Mon Apr 23 23:10:35 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 23 Apr 2018 19:10:35 -0400
Subject: RFR (S/M): 8202017: Merge Reference Enqueuing phase with phase 3
 of Reference processing
In-Reply-To: <1524165246.2765.14.camel@oracle.com>
References: <1524165246.2765.14.camel@oracle.com>
Message-ID: <9C1F6CAC-02DC-44F6-A24F-81814118748A@oracle.com>

> On Apr 19, 2018, at 3:14 PM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi all,
> 
>  can I have reviews for this change that merges the Reference
> Enqueuing phase of reference processing with the respective phase 3 of
> actual Reference Processing?
> 
> This is enabled by JDK-8202018 where we moved some work that cleared
> card tables from inbetween Reference Processing and Reference Enqueuing
> because we could (and likely always could), so the issue that cards
> dirtied by Reference Processing are not cleared any more.
> 
> This saves one time spinning up and synchronizing worker threads at
> least, if not more due to locality (i.e. completely saving one linked
> list traversal).
> 
> This change affects all collectors using the reference processing
> framework - I assume that Shenandoah, if it is using it, does not need
> a split reference enqueuing phase either. Afaik Z does not use this
> framework... :)
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8202017
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8202017/webrev/
> Testing:
> hs-tier1-4
> 
> Thanks,
>  Thomas

Looks good.  Just a couple very minor things.

------------------------------------------------------------------------------ 
src/hotspot/share/gc/shared/referenceProcessor.cpp
 607     _refs_lists[i].set_head(NULL);
 608     _refs_lists[i].set_length(0);

 790        refs_lists[i].set_head(NULL);
 791        refs_lists[i].set_length(0);

Maybe move these into process_phase3?

------------------------------------------------------------------------------ 
src/hotspot/share/gc/g1/g1CollectedHeap.hpp
 515   // If during an initial mark pause we install a pending list head which is not otherwise reachable

Perhaps s/install/may install/

------------------------------------------------------------------------------ 
src/hotspot/share/gc/shared/genCollectedHeap.cpp
 518       rp->disable_discovery();

Ick!  This whole little dance around discovery_is_atomic,
enqueueing_is_done, &etc looks like it is related to CMS and the
distinction between CMS and Serial.  See also the TODO-ish block
comment at line 489.

This looks ripe for refactoring as part of the cleanup of CMS-specific
intrusions.  Probably should have a followup RFE for this.

------------------------------------------------------------------------------



From stefan.johansson at oracle.com  Tue Apr 24 06:59:43 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 24 Apr 2018 08:59:43 +0200
Subject: RFR (S): 8202021: Improve variable naming in ReferenceProcessor
In-Reply-To: <88aca18f-32f5-4190-371f-9a5655602be7@oracle.com>
References: <1524164464.2765.9.camel@oracle.com>
 <e881566b-d438-add2-360b-04d475b9bcab@oracle.com>
 <1524168489.2765.15.camel@oracle.com>
 <f802b27d-ae1f-9ae1-9e74-408f7202bf24@oracle.com>
 <1524493985.2450.11.camel@oracle.com>
 <88aca18f-32f5-4190-371f-9a5655602be7@oracle.com>
Message-ID: <2edb67c4-5534-463a-3050-efcc4bce65a4@oracle.com>



On 2018-04-23 22:23, sangheon.kim wrote:
> Hi Thomas,
> 
> On 04/23/2018 07:33 AM, Thomas Schatzl wrote:
>> On Mon, 2018-04-23 at 16:02 +0200, Stefan Johansson wrote:
>>> Hi Thomas,
>>>
>>> On 2018-04-19 22:08, Thomas Schatzl wrote:
>>>> Hi Sangheon,
>>>>
>>>> ??? thanks for your review. I updated the change in-place.
>>>>
>>>> Thomas
>>>>
>>>> On Thu, 2018-04-19 at 12:38 -0700, sangheon.kim wrote:
>>>>> Hi Thomas,
>>>>>
>>>>> On 04/19/2018 12:01 PM, Thomas Schatzl wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> ???? can I have reviews for this cleanup change that improves
>>>>>> variable
>>>>>> naming in ReferenceProcessor code.
>>>>>>
>>>>>> The main change is about renaming some member variables from
>>>>>> something
>>>>>> really confusing to me to something useful (to me again :)) in
>>>>>> the
>>>>>> DiscoveredListIterator class.
>>>>>>
>>>>>> The other change is related to changing
>>>>>> ReferenceProcessor::num_q
>>>>>> to
>>>>>> num_queues, i.e. spelling out what the "q" is supposed to mean.
>>>>>>
>>>>>> That imho improves readability quite a bit.
>>>>>>
>>>>>> CR:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202021
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~tschatzl/8202021/webrev/
>>> Thanks for doing this, having better names really help when working
>>> with this code. The change looks ok, but I still struggle a bit with
>>> what all members are. I think my problem is seeing that _ref and
>>> _discovered_addr go together. What do you think about renaming:
>>> _ref -> _current
>>> _discovered_addr -> _current_discovered_addr
>> Done.
>>
>>> Potentially also:
>>> _referent -> _current_referent
>>> _referent_addr -> _current_referent_addr
>>>
>> I think the latter renaming is unnecessary as there is no
>> prev/current/next distinction.
>>
>> http://cr.openjdk.java.net/~tschatzl/8202021/webrev.1/ (full)
>> http://cr.openjdk.java.net/~tschatzl/8202021/webrev.0_to_1/ (diff)
> webrev.1 still looks good.
Thanks for doing the additional changes, looks good!

Cheers,
Stefan

> 
> Thanks,
> Sangheon
> 
> 
>>
>> Thanks,
>> ?? Thomas
> 


From stefan.johansson at oracle.com  Tue Apr 24 08:26:55 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 24 Apr 2018 10:26:55 +0200
Subject: RFR: 8191471: Elastic TLABs for G1
In-Reply-To: <1524492520.2450.8.camel@oracle.com>
References: <f3758636-0e83-27d6-a9cc-bf16f82d03bb@oracle.com>
 <1524492520.2450.8.camel@oracle.com>
Message-ID: <d7b05478-0c30-0dc6-2567-9e30f0ab7b0f@oracle.com>

Thanks for reviewing Thomas,

On 2018-04-23 16:08, Thomas Schatzl wrote:
> On Mon, 2018-04-23 at 14:57 +0200, Stefan Johansson wrote:
>> Hi,
>>
>> Please review these changes to lower the waste in G1 mutator regions.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8191471
>> Webrev: http://cr.openjdk.java.net/~sjohanss/8191471/00/
>>
>> Summary
>> G1 might waste excessive amount of memory due to allocations that
>> would span region boundaries. To lower this waste this patch
>> addresses this problem in two ways. TLAB allocations are now more
>> flexible allowing the size to be less then the desired amount as long
>> as the allocation will fit in the TLAB (defined by min_word_size in
>> the call).
>>
>> The G1 allocation code also tries to minimize the waste by keeping
>> two active allocation regions so that a single large allocation won't
>> cause waste that could have been used for other allocations.
> 
>    some minor nits:
> 
> - I would prefer that allocate_new_tlab() returned zero in
> actual_word_size if the allocation failed. It does not in any
> implementation.
> 
> - g1CollectedHeap.hpp:444: superfluous newline
> 
> - collectedHeap.hpp:132: "filled out" -> "returned"
> 
All fixed, new webrevs:
Full: http://cr.openjdk.java.net/~sjohanss/8191471/01/
Inc: http://cr.openjdk.java.net/~sjohanss/8191471/00-01/

Thanks,
Stefan

> Seems good otherwise.
> 
> Thanks,
>    Thomas
> 


From stefan.johansson at oracle.com  Tue Apr 24 08:32:07 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 24 Apr 2018 10:32:07 +0200
Subject: RFR: 8202140: TLAB logging is not correct for G1
In-Reply-To: <1524490932.2450.1.camel@oracle.com>
References: <66684a37-2b85-ad90-3dea-d53028f76485@oracle.com>
 <1524490932.2450.1.camel@oracle.com>
Message-ID: <ebc9a2d5-18ac-16c5-4464-b57b19ff4e47@oracle.com>

Hi Thomas,

On 2018-04-23 15:42, Thomas Schatzl wrote:
> Hi,
> 
> On Mon, 2018-04-23 at 14:57 +0200, Stefan Johansson wrote:
>> Hi,
>>
>> Please review this small change to make TLAB logging more correct,
>> especially for collectors using regions.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8202140
>> Webrev: http://cr.openjdk.java.net/~sjohanss/8202140/00/
>>
>> Summary
>> The current TLAB logging is not completely correct for G1 and other
>> collectors using regions. The logging in
>> ThreadLocalAllocBuffer::print_stats() expects that the allocated size
>> is: size_t alloc = _number_of_refills * _desired_size;
>>
>> For each region in G1 the last TLAB might be smaller then
>> _desired_size and therefor we need to add a separate value to account
>> the actual allocated size.
> 
>    looks good to me.
> 
> Maybe please fix the indentation of
> ThreadLocalAllocBuffer::initialize_statistics().
> 
Thanks for the review, I will add this before pushing:
===
diff --git a/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp 
b/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp
--- a/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp
+++ b/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp
@@ -157,12 +157,12 @@
  }

  void ThreadLocalAllocBuffer::initialize_statistics() {
-    _number_of_refills = 0;
-    _fast_refill_waste = 0;
-    _slow_refill_waste = 0;
-    _gc_waste          = 0;
-    _slow_allocations  = 0;
-    _allocated_size    = 0;
+  _number_of_refills = 0;
+  _fast_refill_waste = 0;
+  _slow_refill_waste = 0;
+  _gc_waste          = 0;
+  _slow_allocations  = 0;
+  _allocated_size    = 0;
  }

  void ThreadLocalAllocBuffer::fill(HeapWord* start,
===

Cheers,
Stefan

> Thanks,
>    Thomas
> 


From per.liden at oracle.com  Tue Apr 24 09:19:40 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 24 Apr 2018 11:19:40 +0200
Subject: RFR: 8191471: Elastic TLABs for G1
In-Reply-To: <f3758636-0e83-27d6-a9cc-bf16f82d03bb@oracle.com>
References: <f3758636-0e83-27d6-a9cc-bf16f82d03bb@oracle.com>
Message-ID: <b670bcde-6a9f-33cf-316f-7b8bddc8aa46@oracle.com>

Hi Stefan,

On 04/23/2018 02:57 PM, Stefan Johansson wrote:
> Hi,
> 
> Please review these changes to lower the waste in G1 mutator regions.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8191471
> Webrev: http://cr.openjdk.java.net/~sjohanss/8191471/00/

Looks good overall, just two comments:

src/hotspot/share/gc/shared/collectedHeap.cpp
---------------------------------------------

  374   size_t minimal_tlab_size = 
MAX2(ThreadLocalAllocBuffer::compute_min_size(size), MinTLABSize);

Can we move the MAX2-logic into compute_min_size()? It seems to belong 
in there, rather than here?


src/hotspot/share/gc/shared/collectedHeap.hpp
---------------------------------------------
  133   virtual HeapWord* allocate_new_tlab(size_t min_word_size,
  134                                       size_t desired_word_size,
  135                                       size_t* actual_word_size);

The argument names now vary between the collectors. I suggest we use the 
same names in all places and skip the "word" part. Something like: 
min_size, requested_size, actual_size?

cheers,
Per

> 
> Summary
> G1 might waste excessive amount of memory due to allocations that would 
> span region boundaries. To lower this waste this patch addresses this 
> problem in two ways. TLAB allocations are now more flexible allowing the 
> size to be less then the desired amount as long as the allocation will 
> fit in the TLAB (defined by min_word_size in the call).
> 
> The G1 allocation code also tries to minimize the waste by keeping two 
> active allocation regions so that a single large allocation won't cause 
> waste that could have been used for other allocations.
> 
> Testing
> Functional testing through mach5 with hs-tier 1-3 and jdk-tier 1-3. 
> Performance testing locally and through aurora without seeing any 
> regressions.
> 
> Thanks,
> Stefan
> 


From thomas.schatzl at oracle.com  Tue Apr 24 09:26:24 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 24 Apr 2018 11:26:24 +0200
Subject: RFR (S/M): 8202017: Merge Reference Enqueuing phase with phase
 3 of Reference processing
In-Reply-To: <9C1F6CAC-02DC-44F6-A24F-81814118748A@oracle.com>
References: <1524165246.2765.14.camel@oracle.com>
 <9C1F6CAC-02DC-44F6-A24F-81814118748A@oracle.com>
Message-ID: <1524561984.2367.3.camel@oracle.com>

Hi Kim,

On Mon, 2018-04-23 at 19:10 -0400, Kim Barrett wrote:
> > On Apr 19, 2018, at 3:14 PM, Thomas Schatzl <thomas.schatzl at oracle.
> > com> wrote:
> > 
> > Hi all,
> > 
> >  can I have reviews for this change that merges the Reference
> > Enqueuing phase of reference processing with the respective phase 3
> > of actual Reference Processing?
> > 
[...]
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8202017
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8202017/webrev/
> > Testing:
> > hs-tier1-4
> > 
> > Thanks,
> >  Thomas
> 
> Looks good.  Just a couple very minor things.
> 
> -------------------------------------------------------------------
> ----------- 
> src/hotspot/share/gc/shared/referenceProcessor.cpp
>  607     _refs_lists[i].set_head(NULL);
>  608     _refs_lists[i].set_length(0);
> 
>  790        refs_lists[i].set_head(NULL);
>  791        refs_lists[i].set_length(0);
> 
> Maybe move these into process_phase3?

Done.

> 
> -------------------------------------------------------------------
> ----------- 
> src/hotspot/share/gc/g1/g1CollectedHeap.hpp
>  515   // If during an initial mark pause we install a pending list
> head which is not otherwise reachable
> 
> Perhaps s/install/may install/
> 

Done.

> src/hotspot/share/gc/shared/genCollectedHeap.cpp
>  518       rp->disable_discovery();
> 
> Ick!  This whole little dance around discovery_is_atomic,
> enqueueing_is_done, &etc looks like it is related to CMS and the
> distinction between CMS and Serial.  See also the TODO-ish block
> comment at line 489.
> 
> This looks ripe for refactoring as part of the cleanup of CMS-
> specific intrusions.  Probably should have a followup RFE for this.

I will file an RFE for this.

New webrevs:
http://cr.openjdk.java.net/~tschatzl/8202017/webrev.0_to_1 (diff)
http://cr.openjdk.java.net/~tschatzl/8202017/webrev.1/ (full)

Thomas



From thomas.schatzl at oracle.com  Tue Apr 24 09:32:08 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 24 Apr 2018 11:32:08 +0200
Subject: RFR: 8202140: TLAB logging is not correct for G1
In-Reply-To: <ebc9a2d5-18ac-16c5-4464-b57b19ff4e47@oracle.com>
References: <66684a37-2b85-ad90-3dea-d53028f76485@oracle.com>
 <1524490932.2450.1.camel@oracle.com>
 <ebc9a2d5-18ac-16c5-4464-b57b19ff4e47@oracle.com>
Message-ID: <1524562328.2367.4.camel@oracle.com>

Hi Stefan,

On Tue, 2018-04-24 at 10:32 +0200, Stefan Johansson wrote:
> Hi Thomas,
> 
> On 2018-04-23 15:42, Thomas Schatzl wrote:
> > Hi,
> > 
> > On Mon, 2018-04-23 at 14:57 +0200, Stefan Johansson wrote:
> > > Hi,
> > > 
> > > Please review this small change to make TLAB logging more
> > > correct,
> > > especially for collectors using regions.
> > > 
> > > JBS: https://bugs.openjdk.java.net/browse/JDK-8202140
> > > Webrev: http://cr.openjdk.java.net/~sjohanss/8202140/00/
> > > 
> > > Summary
> > > The current TLAB logging is not completely correct for G1 and
> > > other
> > > collectors using regions. The logging in
> > > ThreadLocalAllocBuffer::print_stats() expects that the allocated
> > > size
> > > is: size_t alloc = _number_of_refills * _desired_size;
> > > 
> > > For each region in G1 the last TLAB might be smaller then
> > > _desired_size and therefor we need to add a separate value to
> > > account
> > > the actual allocated size.
> > 
> >    looks good to me.
> > 
> > Maybe please fix the indentation of
> > ThreadLocalAllocBuffer::initialize_statistics().
> > 
> 
> Thanks for the review, I will add this before pushing:
> ===
> diff --git a/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp 
> b/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp
> --- a/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp
> +++ b/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp
> @@ -157,12 +157,12 @@
>   }
> 
>   void ThreadLocalAllocBuffer::initialize_statistics() {
> -    _number_of_refills = 0;
> -    _fast_refill_waste = 0;
> -    _slow_refill_waste = 0;
> -    _gc_waste          = 0;
> -    _slow_allocations  = 0;
> -    _allocated_size    = 0;
> +  _number_of_refills = 0;
> +  _fast_refill_waste = 0;
> +  _slow_refill_waste = 0;
> +  _gc_waste          = 0;
> +  _slow_allocations  = 0;
> +  _allocated_size    = 0;
>   }
> 
>   void ThreadLocalAllocBuffer::fill(HeapWord* start,
> ===

  thanks, looks good.

Thomas



From thomas.schatzl at oracle.com  Tue Apr 24 09:32:51 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 24 Apr 2018 11:32:51 +0200
Subject: RFR (S): 8202021: Improve variable naming in ReferenceProcessor
In-Reply-To: <2edb67c4-5534-463a-3050-efcc4bce65a4@oracle.com>
References: <1524164464.2765.9.camel@oracle.com>
 <e881566b-d438-add2-360b-04d475b9bcab@oracle.com>
 <1524168489.2765.15.camel@oracle.com>
 <f802b27d-ae1f-9ae1-9e74-408f7202bf24@oracle.com>
 <1524493985.2450.11.camel@oracle.com>
 <88aca18f-32f5-4190-371f-9a5655602be7@oracle.com>
 <2edb67c4-5534-463a-3050-efcc4bce65a4@oracle.com>
Message-ID: <1524562371.2367.5.camel@oracle.com>

Hi Stefan, Sangheon,

On Tue, 2018-04-24 at 08:59 +0200, Stefan Johansson wrote:
> 
> On 2018-04-23 22:23, sangheon.kim wrote:
> > Hi Thomas,
> > 
> > 
[...]
> > webrev.1 still looks good.
> 
> Thanks for doing the additional changes, looks good!
> 

  thanks for your reviews.

Thomas


From martin.doerr at sap.com  Tue Apr 24 14:20:06 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 24 Apr 2018 14:20:06 +0000
Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for
 ppc64
In-Reply-To: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>
References: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>
Message-ID: <63793e9f7b0e4989a9716cf87be3c7fe@sap.com>

Hi Michihiro,

thanks for posting the new webrev. I think this looks much better, now.

I don't like the "if log_is_enabled() acquire()" code so much, but it looks correct to me. I'd prefer your OrderAccess:consume() proposal, but I can live with it if other reviewers prefer it.

I couldn't find any store-load pattern which may miss ordering, but I'd highly appreciate if another reviewer double-checked that the barriers are right this time.

If needed, we could use memory_order_acq_rel which I'm planning to add with JDK-8202080. I guess this wouldn't really impact performance.

I think 6% performance gain is really worth doing this change.

Best regards,
Martin


From: Michihiro Horie [mailto:HORIE at jp.ibm.com]
Sent: Montag, 23. April 2018 12:34
To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
Cc: Hiroshi H Horii <HORII at jp.ibm.com>; Gustavo Romero <gromero at linux.vnet.ibm.com>; Kazunori Ogata <OGATAK at jp.ibm.com>; shade at redhat.com; aph at redhat.com; Doerr, Martin <martin.doerr at sap.com>
Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64


Dear all,

I would like to ask reviews on 8154736 "enhancement of cmpxchg and copy_to_survivor". The change adds options to avoid expensive syncs with compare-and-exchange. An experiment by using SPECjbb2015 showed 6% improvement in critical-jOPS. This change focuses on ppc64 but would be potentially beneficial for aarch64.

Although discussions stopped at http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002718.html, I would like to restart the review by taking over Hiroshi's work if the discussion is still open.

Bug: https://bugs.openjdk.java.net/browse/JDK-8154736
Webrev: http://cr.openjdk.java.net/~mhorie/8154736/webrev.08/

Previous review had discussions on improper log output (http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-September/002672.html). Logs can be generated properly with this change, but I would like to ask if we should use "if(log) OrderAccess:acquire()" as is in webrev or more general approach with a call to OrderAccess:consume() with empty implementation on all supported platforms.

Also, there were discussions on the problem of unawareness of copied obj (http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002696.html). This change adds "release" in cmpxchg_pre_membar. This was discussed in http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002698.html.

I measured SPECjbb2015 with its multi JVMs mode on a POWER8 node (for JDK11, I modified MANIFEST in specjbb2015.jar to specify locations of JAXB related libraries). As a result, critical-jOPS improved by 6% due to this change.

Best regards,
--
Michihiro,
IBM Research - Tokyo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180424/a818d4b0/attachment.htm>

From glaubitz at physik.fu-berlin.de  Tue Apr 24 14:42:26 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 24 Apr 2018 16:42:26 +0200
Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for
 ppc64
In-Reply-To: <63793e9f7b0e4989a9716cf87be3c7fe@sap.com>
References: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>
 <63793e9f7b0e4989a9716cf87be3c7fe@sap.com>
Message-ID: <e1718644-9a70-2636-bdfc-a9508e4cda78@physik.fu-berlin.de>

Hi!

On 04/24/2018 04:20 PM, Doerr, Martin wrote:
> I think 6% performance gain is really worth doing this change.

Quick question: Does this pose any assumptions on the instruction set baseline
on ppc64? I haven't build-tested this yet, but I want to avoid it doesn't break
on POWER5, for example, which is used in Debian's big-endian ppc64 port.

Thanks,
Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From gromero at linux.vnet.ibm.com  Tue Apr 24 15:54:29 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Tue, 24 Apr 2018 12:54:29 -0300
Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for
 ppc64
In-Reply-To: <e1718644-9a70-2636-bdfc-a9508e4cda78@physik.fu-berlin.de>
References: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>
 <63793e9f7b0e4989a9716cf87be3c7fe@sap.com>
 <e1718644-9a70-2636-bdfc-a9508e4cda78@physik.fu-berlin.de>
Message-ID: <cbc8950b-4f42-a550-4550-5dcb9ac29fd4@linux.vnet.ibm.com>

Hi John,

On 04/24/2018 11:42 AM, John Paul Adrian Glaubitz wrote:
> On 04/24/2018 04:20 PM, Doerr, Martin wrote:
>> I think 6% performance gain is really worth doing this change.
> 
> Quick question: Does this pose any assumptions on the instruction set baseline
> on ppc64? I haven't build-tested this yet, but I want to avoid it doesn't break
> on POWER5, for example, which is used in Debian's big-endian ppc64 port.

Yes, it does. But POWER5 and above are ok. Lightweight sync (lwsync) was
introduced with Power ISA v2.03 which, by its turn, maps to POWER5.

Thanks for taking care of Power + Debian :-)


Regards,
Gustavo



From thomas.schatzl at oracle.com  Wed Apr 25 11:13:30 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 25 Apr 2018 13:13:30 +0200
Subject: RFR (M): 6672778: G1 should trim task queues more aggressively
 during evacuation pauses
In-Reply-To: <9423fa30-d986-0070-4561-ebfb3b0623a3@oracle.com>
References: <1523272805.4326.33.camel@oracle.com>
 <1523447197.9657.6.camel@oracle.com>
 <43f37e0f-74c4-b9f9-bef7-934180518261@oracle.com>
 <1523608516.2360.10.camel@oracle.com>
 <b306a75c-51f2-f1e5-b0de-3aa6a5759645@oracle.com>
 <1523876930.12621.6.camel@oracle.com>
 <8fa48c25-6c7a-80af-4445-0f5d416ec4d4@oracle.com>
 <1524125349.2376.3.camel@oracle.com>
 <9423fa30-d986-0070-4561-ebfb3b0623a3@oracle.com>
Message-ID: <1524654810.2487.1.camel@oracle.com>

Hi,

  thanks for your review, Stefan.

Could I have another reviewer for this change?

Thanks,
  Thomas

On Thu, 2018-04-19 at 11:27 +0200, Stefan Johansson wrote:
> 
> On 2018-04-19 10:09, Thomas Schatzl wrote:
> > Hi all,
> > 
> >    I unfortunately found another issue with timing:
> > 
> > when calculating the "Other" time, we add the SATBFiltering phase
> > to the known worker time - however that time is already included in
> > the ext root scan time, so it is double-counted, and you
> > occasionally get slightly negative "Other" times.
> > 
> > This problem had been introduced in the refactoring too :(
> > 
> > This change fixes that.
> > 
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/6672778/webrev.3_to_4/ (diff)
> > http://cr.openjdk.java.net/~tschatzl/6672778/webrev.4/ (full)
> 
> Good that you caught that! Still good.
> 
> Thanks,
> Stefan
> 
> > 
> > Thanks,
> >    Thomas
> > 
> > On Mon, 2018-04-16 at 14:58 +0200, Stefan Johansson wrote:
> > > Hi Thomas,
> > > 
> > > On 2018-04-16 13:08, Thomas Schatzl wrote:
> > > > Hi all,
> > > > 
> > > > On Fri, 2018-04-13 at 14:25 +0200, Stefan Johansson wrote:
> > > > > 
> > > > > On 2018-04-13 10:35, Thomas Schatzl wrote:
> > > > > > Hi Stefan,
> > > > > > 
> > > > > >      thanks for your review... :)
> > > > > > 
> > > > > > On Thu, 2018-04-12 at 17:15 +0200, Stefan Johansson wrote:
> > > > > > > Hi Thomas,
> > > > > > > 
> > > > > > > On 2018-04-11 13:46, Thomas Schatzl wrote:
> > > > > > > > Hi all,
> > > > > > > > 
> > > > > > > >       I updated and (hopefully) improved the change a
> > > > > > > > bit
> > > > > > > > after
> > > > > > > > some
> > > > > > > > more thinking.
> > > > > > 
> > > > > > [...]
> > > > 
> > > > Also fixed a problem with the "-" operator of Tickspan
> > > > introduced
> > > > in
> > > > all this refactoring. This caused negative times being reported
> > > > sometimes in the logs.
> > > > 
> > > > http://cr.openjdk.java.net/~tschatzl/6672778/webrev.2_to_3/
> > > > (diff)
> > > > http://cr.openjdk.java.net/~tschatzl/6672778/webrev.3/ (full)
> > > > 
> > > > The change looks really nice now imho, thanks Stefan!
> > > 
> > > I agree, ship it :)
> > > 
> > > Thanks,
> > > Stefan
> > > > 
> > > > Thanks,
> > > >     Thomas
> > > > 



From david.holmes at oracle.com  Wed Apr 25 12:45:15 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Apr 2018 22:45:15 +1000
Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for
 ppc64
In-Reply-To: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>
References: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>
Message-ID: <5625a595-1165-8d48-afbd-8229cdc4ac07@oracle.com>

Hi Michihiro,

On 23/04/2018 8:33 PM, Michihiro Horie wrote:
> 
> 
> Dear all,
> 
> I would like to ask reviews on 8154736 ?enhancement of cmpxchg and
> copy_to_survivor?. The change adds options to avoid expensive syncs with
> compare-and-exchange. An experiment by using SPECjbb2015 showed 6%
> improvement in critical-jOPS. This change focuses on ppc64 but would be
> potentially beneficial for aarch64.
> 
> Although discussions stopped at
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002718.html
> , I would like to restart the review by taking over Hiroshi's work if the
> discussion is still open.

So the very last comment there was about not implicitly assuming  
memory_order_consume, yet that has not been addressed in the proposal.

Further the discussion on hotspot-runtime-dev through September and  
October was far more illuminating. I think my post here:

http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-October/021617.html

and the closely following one from Thomas Schatzl summed up the concerns  
about the proposed changes.

AFAICS the restarted proposal addresses none of those concerns but  
simply takes up where the previous implementation suggestion left off.

This is a proposal to change the memory ordering semantics of part of  
the shared GC code _not_ just the PPC64 implementation, but I have seen  
no analysis to demonstrate the correctness of such a proposal.

David
-----


> Bug: https://bugs.openjdk.java.net/browse/JDK-8154736
> Webrev: http://cr.openjdk.java.net/~mhorie/8154736/webrev.08/
> 
> Previous review had discussions on improper log output (
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-September/002672.html
> ). Logs can be generated properly with this change, but I would like to ask
> if we should use ?if(log) OrderAccess:acquire()? as is in webrev or more
> general approach with a call to OrderAccess:consume() with empty
> implementation on all supported platforms.
> 
> Also, there were discussions on the problem of unawareness of copied obj (
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002696.html
> ). This change adds ?release? in cmpxchg_pre_membar. This was discussed in
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002698.html
> .
> 
> I measured SPECjbb2015 with its multi JVMs mode on a POWER8 node (for JDK11
> , I modified MANIFEST in specjbb2015.jar to specify locations of JAXB
> related libraries). As a result, critical-jOPS improved by 6% due to this
> change.
> 
> Best regards,
> --
> Michihiro,
> IBM Research - Tokyo
> 


From erik.osterlund at oracle.com  Wed Apr 25 15:32:04 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 25 Apr 2018 17:32:04 +0200
Subject: RFR: JDK-8198285: More consistent Access API for arraycopy
In-Reply-To: <b57660bf-6c92-f243-6abd-2ea69570389c@redhat.com>
References: <b57660bf-6c92-f243-6abd-2ea69570389c@redhat.com>
Message-ID: <5AE09F74.7050005@oracle.com>

Hi Roman,

So the options for this API were:

1) Resolve the addresses as we do today, but you think you get better 
Shenandoah performance if we either
2) Have 3 different access calls, (from heap to native, from native to 
heap, from heap to heap) for copying, or
3) Have 1 access call that can encode the above 3 variants, but looks 
ugly at the call sites.

You clearly went for 3, which leaves the callsites looking rather hard 
to read. It is for example not obvious for me what is going on here 
(javaClasses.cpp line 313):

HeapAccess<>::arraycopy<jbyte>(NULL, 0, reinterpret_cast<const 
jbyte*>(utf8_str), value(h_obj()), 
typeArrayOopDesc::element_offset<jbyte>(0), NULL, length);

...without looking very carefully at the long list of arguments encoding 
what is actually going on (copy from native to the heap). What is worse 
is that this will probably not compile without adding the template 
keyword to the call (since you have a qualified template member function 
behind a template class), like this:
HeapAccess<>::template arraycopy<jbyte>(NULL, 0, reinterpret_cast<const 
jbyte*>(utf8_str), value(h_obj()), 
typeArrayOopDesc::element_offset<jbyte>(0), NULL, length);

...which as a public API leaves me feeling a bit like this:     :C

May I suggest adding an array access helper. The idea is to keep a 
single call through Access, and a single backend point for array copy, 
but let the helper provide the three different types of copying as 
different functions, so that the call sites still look pretty and easy 
to read and follow.

This helper could additionally have load_at, and store_at use array 
indices as opposed to offsets, and hence hide the offset calculations we 
perform today (typically involving checking if we are using compressed 
oops or not).

I am thinking something along the lines of 
ArrayAccess<>::arraycopy_to_native(readable_arguments), 
ArrayAccess<>::arraycopy_from_native(readable_arguments), 
ArrayAccess<>::arraycopy(readable_arguments), which translates to some 
form of Access<>::arraycopy(unreadable_arguments). And for example 
ArrayAccess<>::load_at(obj, index) would translate to some kind of 
HeapAccess<IN_HEAP_ARRAY>::load_at(obj, offset_for_index(index)) as a 
bonus, making everyone using the API jump with happiness.

What do you think about this idea? Good or bad? I guess the question is 
whether this helper should be in access.hpp, or somewhere else (like in 
arrayOop). Thoughts are welcome.

Thanks,
/Erik

On 2018-04-11 19:54, Roman Kennke wrote:
>   Currently, the arraycopy API in access.hpp gets the src and dst oops,
> plus the src and dst addresses. In order to be most useful to garbage
> collectors, it should receive the src and dst oops together with the src
> and dst offsets instead, and let the Access API / GC calculate the src
> and dst addresses.
>
> For example, Shenandoah needs to resolve the src and dst objects for
> arraycopy, and then apply the corresponding offsets. With the current
> API (obj+ptr) it would calculate the ptr-diff from obj to ptr, then
> resolve obj, then re-add the calculate ptr-diff. This is fragile because
> we also may resolve obj in the runtime before calculating ptr (e.g. via
> arrayOop::base()). If we then pass in the original obj and a ptr
> calculated from another copy of the same obj, the above resolution logic
> would not work. This is currently the case for obj-arraycopy.
>
> I propose to change the API to accept obj+offset, in addition to ptr for
> both src and dst. Only one or the other should be used. Heap accesses
> should use obj+offset and pass NULL for raw-ptr, off-heap accesses (or
> heap accesses that are already resolved.. use with care) should pass
> NULL+0 for obj+offset and the raw-ptr. Notice that this also allows the
> API to be used for Java<->native array bulk transfers.
>
> An alternative would be to break the API up into 4 variants:
>
> Java->Java transfer:
> arraycopy(oop src, size_t src_offs, oop dst, size_t dst_offs, size_t len)
>
> Java->Native transfer:
> arraycopy(oop src, size_t src_offs, D* raw_dst, size_t len)
>
> Native->Java transfer:
> arraycopy(S* src_raw, oop dst, size_t dst_offs, size_t len)
>
> 'Unsafe' transfer:
> arraycopy(S* src_raw, D* dst_raw, size_t len)
>
>
> But that seemed to be too much boilerplate copy+pasting for my taste.
> (See how having this overly complicated template layer hurts us?)
>
> Plus, I had a better idea: instead of accepting oop+offset OR T* for
> almost every Access API, we may want to abstract that and take an
> Address type argument, which would be either HeapAddress(obj, offset) or
> RawAddress(T* ptr). GCs may then just call addr->address() to get the
> actual address, or specialize for HeapAddress variants and resolve the
> objs and then resolve the address. This would also allow us to get rid
> of almost half of the API (all the *_at variants would go) and some
> other simplifications. However, this seemed to explode the scope of this
> RFE, and would be better handled in another RFE.
>
> This changes makes both typeArrayKlass and objArrayKlass use the changed
> API, plus I identified all (hopefully) places where we do bulk
> Java<->native array transfers and make them use the API too. Gets us rid
> of a bunch of memcpy calls :-)
>
> Please review the change:
> http://cr.openjdk.java.net/~rkennke/JDK-8198285/webrev.00/
>
> Thanks, Roman
>



From rkennke at redhat.com  Wed Apr 25 15:59:10 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 25 Apr 2018 17:59:10 +0200
Subject: RFR: JDK-8198285: More consistent Access API for arraycopy
In-Reply-To: <5AE09F74.7050005@oracle.com>
References: <b57660bf-6c92-f243-6abd-2ea69570389c@redhat.com>
 <5AE09F74.7050005@oracle.com>
Message-ID: <f0a526e2-d6f5-4c5f-558c-52096e395c3e@redhat.com>

> 
> 1) Resolve the addresses as we do today, but you think you get better
> Shenandoah performance if we either
> 2) Have 3 different access calls, (from heap to native, from native to
> heap, from heap to heap) for copying, or
> 3) Have 1 access call that can encode the above 3 variants, but looks
> ugly at the call sites.

There's also the idea to pass Address arguments to arraycopy, one for
src, one for dst, and have 2 different subclasses: one for obj+offset
(heap access) and one with direct pointer (raw). Your comment gave me
the idea to also provide arrayOop+idx. This would look clean on the
caller side I think.

It would also be useful on the GC side: BarrierSets would specialize
only in the variants that they are interested in, for example, in case
of Shenandoah:
1. arraycopy(HeapAddress,HeapAddress) Java->Java
2. arraycopy(HeapAddress,RawAddress)  Java->native
3. arraycopy(RawAddress,HeapAddress)  native->Java

other barriersets can ignore the exact type and only call the args
address->resolve() or so to get the actual raw address.

This would *also* be beneficial for the other APIs: instead of having
all the X() and X_at() variants, we can just use one X variant that
either takes RawAddress or HeapAddress.

I made a little (not yet compiling/working) prototype of this a while ago:

http://cr.openjdk.java.net/~rkennke/JDK-8199801-2.patch


What do you think? Would it make sense to go further down that road?

Roman

> You clearly went for 3, which leaves the callsites looking rather hard
> to read. It is for example not obvious for me what is going on here
> (javaClasses.cpp line 313):
> 
> HeapAccess<>::arraycopy<jbyte>(NULL, 0, reinterpret_cast<const
> jbyte*>(utf8_str), value(h_obj()),
> typeArrayOopDesc::element_offset<jbyte>(0), NULL, length);
> 
> ...without looking very carefully at the long list of arguments encoding
> what is actually going on (copy from native to the heap). What is worse
> is that this will probably not compile without adding the template
> keyword to the call (since you have a qualified template member function
> behind a template class), like this:
> HeapAccess<>::template arraycopy<jbyte>(NULL, 0, reinterpret_cast<const
> jbyte*>(utf8_str), value(h_obj()),
> typeArrayOopDesc::element_offset<jbyte>(0), NULL, length);
> 
> ...which as a public API leaves me feeling a bit like this:???? :C
> 
> May I suggest adding an array access helper. The idea is to keep a
> single call through Access, and a single backend point for array copy,
> but let the helper provide the three different types of copying as
> different functions, so that the call sites still look pretty and easy
> to read and follow.
> 
> This helper could additionally have load_at, and store_at use array
> indices as opposed to offsets, and hence hide the offset calculations we
> perform today (typically involving checking if we are using compressed
> oops or not).
> 
> I am thinking something along the lines of
> ArrayAccess<>::arraycopy_to_native(readable_arguments),
> ArrayAccess<>::arraycopy_from_native(readable_arguments),
> ArrayAccess<>::arraycopy(readable_arguments), which translates to some
> form of Access<>::arraycopy(unreadable_arguments). And for example
> ArrayAccess<>::load_at(obj, index) would translate to some kind of
> HeapAccess<IN_HEAP_ARRAY>::load_at(obj, offset_for_index(index)) as a
> bonus, making everyone using the API jump with happiness.
> 
> What do you think about this idea? Good or bad? I guess the question is
> whether this helper should be in access.hpp, or somewhere else (like in
> arrayOop). Thoughts are welcome.
> 
> Thanks,
> /Erik
> 
> On 2018-04-11 19:54, Roman Kennke wrote:
>> ? Currently, the arraycopy API in access.hpp gets the src and dst oops,
>> plus the src and dst addresses. In order to be most useful to garbage
>> collectors, it should receive the src and dst oops together with the src
>> and dst offsets instead, and let the Access API / GC calculate the src
>> and dst addresses.
>>
>> For example, Shenandoah needs to resolve the src and dst objects for
>> arraycopy, and then apply the corresponding offsets. With the current
>> API (obj+ptr) it would calculate the ptr-diff from obj to ptr, then
>> resolve obj, then re-add the calculate ptr-diff. This is fragile because
>> we also may resolve obj in the runtime before calculating ptr (e.g. via
>> arrayOop::base()). If we then pass in the original obj and a ptr
>> calculated from another copy of the same obj, the above resolution logic
>> would not work. This is currently the case for obj-arraycopy.
>>
>> I propose to change the API to accept obj+offset, in addition to ptr for
>> both src and dst. Only one or the other should be used. Heap accesses
>> should use obj+offset and pass NULL for raw-ptr, off-heap accesses (or
>> heap accesses that are already resolved.. use with care) should pass
>> NULL+0 for obj+offset and the raw-ptr. Notice that this also allows the
>> API to be used for Java<->native array bulk transfers.
>>
>> An alternative would be to break the API up into 4 variants:
>>
>> Java->Java transfer:
>> arraycopy(oop src, size_t src_offs, oop dst, size_t dst_offs, size_t len)
>>
>> Java->Native transfer:
>> arraycopy(oop src, size_t src_offs, D* raw_dst, size_t len)
>>
>> Native->Java transfer:
>> arraycopy(S* src_raw, oop dst, size_t dst_offs, size_t len)
>>
>> 'Unsafe' transfer:
>> arraycopy(S* src_raw, D* dst_raw, size_t len)
>>
>>
>> But that seemed to be too much boilerplate copy+pasting for my taste.
>> (See how having this overly complicated template layer hurts us?)
>>
>> Plus, I had a better idea: instead of accepting oop+offset OR T* for
>> almost every Access API, we may want to abstract that and take an
>> Address type argument, which would be either HeapAddress(obj, offset) or
>> RawAddress(T* ptr). GCs may then just call addr->address() to get the
>> actual address, or specialize for HeapAddress variants and resolve the
>> objs and then resolve the address. This would also allow us to get rid
>> of almost half of the API (all the *_at variants would go) and some
>> other simplifications. However, this seemed to explode the scope of this
>> RFE, and would be better handled in another RFE.
>>
>> This changes makes both typeArrayKlass and objArrayKlass use the changed
>> API, plus I identified all (hopefully) places where we do bulk
>> Java<->native array transfers and make them use the API too. Gets us rid
>> of a bunch of memcpy calls :-)
>>
>> Please review the change:
>> http://cr.openjdk.java.net/~rkennke/JDK-8198285/webrev.00/
>>
>> Thanks, Roman
>>
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180425/3e15afe7/signature.asc>

From david.holmes at oracle.com  Thu Apr 26 02:30:04 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Apr 2018 12:30:04 +1000
Subject: Potential optimization to the GC termination protocol in JDK8
In-Reply-To: <CAG2GYXGrAJPX7Wp=5mJLypnGKdpnL=vZFLKAW6fdodxuk5XeYA@mail.gmail.com>
References: <CAG2GYXGrAJPX7Wp=5mJLypnGKdpnL=vZFLKAW6fdodxuk5XeYA@mail.gmail.com>
Message-ID: <9b20437c-86e5-f413-e5e4-7f2089fc4182@oracle.com>

Re-directing to the hotspot GC mailing list from jdk8u-dev mailing list

Please do not reply-all with jdk8u-dev included.

David

On 26/04/2018 12:24 PM, T S wrote:
> [Problem]
> The work stealing during the GC takes lots of time to terminate. The
> Parallel Scavenge in JDK 8 uses a distributed termination protocol to
> synchronize GC threads. After 2 ? N consecutive unsuccessful steal attempts
> (steal_best_of_2 function), a GC thread enters the termination procedure,
> where N is the number of GC threads.
> 
> Suppose there are N GC threads, it takes 2 * N * N failed attempts before a
> GC stops. It is inefficient and takes too much time, especially when there
> are very few GC threads alive. If there are hundreds or thousands of GC
> happen during the app execution, that is a big waste of time.
> 
> 
> 
> [Solution]
> Is that possible to reduce the number of steal attempt during the end of
> GC? My idea is to record the number of active GC threads (i.e., N_live)
> that are not yet in the termination protocol. A thread only steals from the
> pool of active GC threads because the inactive GC threads have no task to
> be stolen. Accordingly, the criteria for thread termination becomes 2 ?
> N_live consecutive failed steal attempts. It can reduce the steal attempts
> to half.
> 
> 
> 
> Good forward for others' feedbacks.
> Thanks.
> Tony
> 
> 


From rkennke at redhat.com  Thu Apr 26 06:53:01 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 26 Apr 2018 08:53:01 +0200
Subject: Potential optimization to the GC termination protocol in JDK8
In-Reply-To: <9b20437c-86e5-f413-e5e4-7f2089fc4182@oracle.com>
References: <CAG2GYXGrAJPX7Wp=5mJLypnGKdpnL=vZFLKAW6fdodxuk5XeYA@mail.gmail.com>
 <9b20437c-86e5-f413-e5e4-7f2089fc4182@oracle.com>
Message-ID: <4aa5e12a-94b9-6ac8-f0e0-e2d48f6593f7@redhat.com>

>> [Problem]
>> The work stealing during the GC takes lots of time to terminate. The
>> Parallel Scavenge in JDK 8 uses a distributed termination protocol to
>> synchronize GC threads. After 2 ? N consecutive unsuccessful steal
>> attempts
>> (steal_best_of_2 function), a GC thread enters the termination procedure,
>> where N is the number of GC threads.
>>
>> Suppose there are N GC threads, it takes 2 * N * N failed attempts
>> before a
>> GC stops. It is inefficient and takes too much time, especially when
>> there
>> are very few GC threads alive. If there are hundreds or thousands of GC
>> happen during the app execution, that is a big waste of time.
>>
>>
>>
>> [Solution]
>> Is that possible to reduce the number of steal attempt during the end of
>> GC? My idea is to record the number of active GC threads (i.e., N_live)
>> that are not yet in the termination protocol. A thread only steals
>> from the
>> pool of active GC threads because the inactive GC threads have no task to
>> be stolen. Accordingly, the criteria for thread termination becomes 2 ?
>> N_live consecutive failed steal attempts. It can reduce the steal
>> attempts
>> to half.
>>
>>
>>
>> Good forward for others' feedbacks.
>> Thanks.
>> Tony

Hi Tony,
in Shenandoah we have implemented an improved termination protocol. See
the comment here:

http://hg.openjdk.java.net/shenandoah/jdk/file/b4a3595f7c56/src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp#l93

We intend to upstream this stuff very soon, at which point it can be
used by all other GCs if they wish. It's a drop-in replacement for the
existing task queue code.

It sounds like it's similar to what you have in mind. Right?

Thanks, Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180426/31dcccae/signature.asc>

From thomas.schatzl at oracle.com  Thu Apr 26 09:36:35 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 26 Apr 2018 11:36:35 +0200
Subject: RFR (M): 8201491: G1 support for java.lang.ref.Reference precleaning
Message-ID: <1524735395.2350.15.camel@oracle.com>

Hi all,

  can I have reviews for this change that implements reference
precleaning like CMS for G1?

In absence of fully concurrent reference processing this seems to be a
very good tradeoff between effort and improvement in some cases.

Since it is planned to be obsoleted in the future, and I do not expect
other new collectors to implement it (Shenandoah will likely go to
fully concurrent as well, Z afaik already has concurrent Reference
processing, and CMS is on its way out), I added a G1 specific
experimental option called "G1UseReferencePrecleaning" defaulting to
true (enabled).

It is also single-threaded, although it could be extended to MT
processing fairly easily. Again, a compromise between effort and
expected gain.

Contrary to CMS, the yield check interval is very high (after every
Reference), so it won't hold up pause requests, which may be a frequent
reason to disable it.

I spent like two days trying to find and convince myselves about a
fast-to-check and 100% reliable condition that would allow fine-grained 
yield checks with CMS too, however there was none I could find.
At least I am currently almost confident that this was the exact
problem why CMS implements yielding as is. I defer fixing this for CMS
to the community if they want it, i.e. implementing
CMSPrecleanRefsYieldClosure::should_return_fine_grain(), and
potentially replacing ::should_return() in the code.

Precleaning may lengthen the concurrent cycle time once more in case of
millions of References around as it is single threaded, however
typically this also decreases the Remark pause by magnitudes then.

I do not expect that to be an issue with almost all workloads as if you
have many References, the (Remark) pause time problem is typically more
 of an issue.

CR:
https://bugs.openjdk.java.net/browse/JDK-8201491
Webrev:
http://cr.openjdk.java.net/~tschatzl/8201491/webrev/
Testing:
hs-tier1-5, *many* times Kitchensink reference stress test

Thanks,
  Thomas



From shade at redhat.com  Thu Apr 26 09:46:03 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 26 Apr 2018 11:46:03 +0200
Subject: RFR (M): 8201491: G1 support for java.lang.ref.Reference
 precleaning
In-Reply-To: <1524735395.2350.15.camel@oracle.com>
References: <1524735395.2350.15.camel@oracle.com>
Message-ID: <475b6476-ead7-a3a8-281e-4f749ffa1f15@redhat.com>

On 04/26/2018 11:36 AM, Thomas Schatzl wrote:
> In absence of fully concurrent reference processing this seems to be a
> very good tradeoff between effort and improvement in some cases.
> 
> Since it is planned to be obsoleted in the future, and I do not expect
> other new collectors to implement it (Shenandoah will likely go to
> fully concurrent as well,

Current Shenandoah actually implements Precleaning too, because it uses the same STW RP available in
all JDKs where we backport Shenandoah. It is indeed a good tradeoff between prolonging the
concurrent phase, and dodging long pause processing provably alive references.

> I added a G1 specific experimental option called "G1UseReferencePrecleaning" defaulting to true
> (enabled).

Shenandoah uses the shorter "ShenandoahPreclean", maybe you want to do it shorter too.

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180426/95f8f113/signature.asc>

From HORIE at jp.ibm.com  Thu Apr 26 12:04:48 2018
From: HORIE at jp.ibm.com (Michihiro Horie)
Date: Thu, 26 Apr 2018 21:04:48 +0900
Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for
 ppc64
In-Reply-To: <5625a595-1165-8d48-afbd-8229cdc4ac07@oracle.com>
References: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>
 <5625a595-1165-8d48-afbd-8229cdc4ac07@oracle.com>
Message-ID: <OFCDA3DCF8.3EABE52D-ON0025827B.0040714C-4925827B.00425BD3@notes.na.collabserv.com>


Hi David,

>So the very last comment there was about not implicitly assuming
>memory_order_consume, yet that has not been addressed in the proposal.
>
>Further the discussion on hotspot-runtime-dev through September and
>October was far more illuminating. I think my post here:
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_hotspot-2Druntime-2Ddev_2016-2DOctober_021617.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=4DMMn8KoNrvfjd9HS_nXI5hLeagvDCcmeB6oFd-mcPk&e=

>and the closely following one from Thomas Schatzl summed up the concerns
>about the proposed changes.
Thank you very much for pointing out the missing items I need to take into
account.

>This is a proposal to change the memory ordering semantics of part of
>the shared GC code _not_ just the PPC64 implementation, but I have seen
>no analysis to demonstrate the correctness of such a proposal.
I do agree the necessity of demonstrating the correctness. I would try my
best for this.


Best regards,
--
Michihiro,
IBM Research - Tokyo



From:	David Holmes <david.holmes at oracle.com>
To:	Michihiro Horie <HORIE at jp.ibm.com>,
            ppc-aix-port-dev at openjdk.java.net,
            hotspot-dev at openjdk.java.net, hotspot-gc-dev at openjdk.java.net
Cc:	Hiroshi H Horii <HORII at jp.ibm.com>
Date:	2018/04/25 21:45
Subject:	Re: RFR(M): 8154736: enhancement of cmpxchg and
            copy_to_survivor for ppc64



Hi Michihiro,

On 23/04/2018 8:33 PM, Michihiro Horie wrote:
>
>
> Dear all,
>
> I would like to ask reviews on 8154736 ?enhancement of cmpxchg and
> copy_to_survivor?. The change adds options to avoid expensive syncs with
> compare-and-exchange. An experiment by using SPECjbb2015 showed 6%
> improvement in critical-jOPS. This change focuses on ppc64 but would be
> potentially beneficial for aarch64.
>
> Although discussions stopped at
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_ppc-2Daix-2Dport-2Ddev_2016-2DOctober_002718.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=C2p8l68JKbOLCTpy4Zu5280A84QXht0U4_3Ha7QBaRc&e=

> , I would like to restart the review by taking over Hiroshi's work if the
> discussion is still open.

So the very last comment there was about not implicitly assuming
memory_order_consume, yet that has not been addressed in the proposal.

Further the discussion on hotspot-runtime-dev through September and
October was far more illuminating. I think my post here:

https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_hotspot-2Druntime-2Ddev_2016-2DOctober_021617.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=4DMMn8KoNrvfjd9HS_nXI5hLeagvDCcmeB6oFd-mcPk&e=


and the closely following one from Thomas Schatzl summed up the concerns
about the proposed changes.

AFAICS the restarted proposal addresses none of those concerns but
simply takes up where the previous implementation suggestion left off.

This is a proposal to change the memory ordering semantics of part of
the shared GC code _not_ just the PPC64 implementation, but I have seen
no analysis to demonstrate the correctness of such a proposal.

David
-----


> Bug:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8154736&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=4hpwVPathLPraOYinkDMNu4gAgivm62zURDtKyMKPe8&e=

> Webrev:
https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8154736_webrev.08_&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=DMMm7IWjNJSRB69AbPfo-zPkhDNK8EbhxWEdT6z46k8&e=

>
> Previous review had discussions on improper log output (
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_ppc-2Daix-2Dport-2Ddev_2016-2DSeptember_002672.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=s0YwAXbLaVr-SrmfU4DdH87Kd4baoN7bkGA1y-fBSrQ&e=

> ). Logs can be generated properly with this change, but I would like to
ask
> if we should use ?if(log) OrderAccess:acquire()? as is in webrev or more
> general approach with a call to OrderAccess:consume() with empty
> implementation on all supported platforms.
>
> Also, there were discussions on the problem of unawareness of copied obj
(
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_ppc-2Daix-2Dport-2Ddev_2016-2DOctober_002696.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=HmMGF6U-OQ33yEAAUBjhhdBSVzw7m9ec0oiXn8y7eS8&e=

> ). This change adds ?release? in cmpxchg_pre_membar. This was discussed
in
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_ppc-2Daix-2Dport-2Ddev_2016-2DOctober_002698.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=mZWJvHc1jKeJlaDa1nu_vDz5FfB0WlCCnRmAOJYHLgA&e=

> .
>
> I measured SPECjbb2015 with its multi JVMs mode on a POWER8 node (for
JDK11
> , I modified MANIFEST in specjbb2015.jar to specify locations of JAXB
> related libraries). As a result, critical-jOPS improved by 6% due to this
> change.
>
> Best regards,
> --
> Michihiro,
> IBM Research - Tokyo
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180426/4bbf48fe/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180426/4bbf48fe/graycol.gif>

From thomas.schatzl at oracle.com  Thu Apr 26 14:12:54 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 26 Apr 2018 16:12:54 +0200
Subject: RFR (M): 8201492: Properly implement non-contiguous generations
 for reference discovery
In-Reply-To: <1524034373.3236.7.camel@oracle.com>
References: <1524034373.3236.7.camel@oracle.com>
Message-ID: <1524751974.11105.0.camel@oracle.com>

Hi all,

  could someone please have a look at this?

Thanks,
  Thomas

On Wed, 2018-04-18 at 08:52 +0200, Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews for this change that adapts the reference
> discovery for the non-contiguous generations (and non-contiguous
> generations in general) of G1 to solve one day-one performance issue?
> 
> So reference discovery does not properly support non-contiguous
> generations, resorting to an approximation of it. 
> 
> This in turn causes G1 to require the "preserve cm referents" phase
> during GC during marking, which is very costly in some cases. 
> 
> The reason for the preserve cm referents phase is that References
> (j.l.ref.References instances) that are discovered by concurrent
> discovery, will currently prevent discovery and evacuation of
> referents
> in the STW pauses, as G1 thinks that it already has discovered that
> Reference and skips it. Still their referents can be in young gen,
> while the Reference is in old gen (young gc may iterate over it
> during
> card scanning), and this may cause crashes later. 
> 
> The preserve cm referents phase brute-force simply evacuates any
> "leftover" referents and its followers. 
> 
> This is because the STW reference discovery currently does not treat
> References in old gen as roots (i.e. to be scanned and referents
> evacuated always), as the STW reference processor thinks that the g1
> heap is a single generation spanning the whole heap. 
> 
> By giving the ref processor the correct idea of generations in G1,
> this
> automatically works, and obsoletes the "preserve cm referents" phase.
> 
> To get an understanding how serious this issue may be, on
> theKitchensink reference stress test program, the "Preserve CM
> referents"
> phase may take 105ms out of 115ms.
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8201492
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8201492/webrev/
> Testing:
> hs-tier1-3, performance verification, lots of Kitchensink reference
> stress testing runs
> 
> Thanks,
>   Thomas
> 



From erik.osterlund at oracle.com  Thu Apr 26 15:29:38 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Thu, 26 Apr 2018 17:29:38 +0200
Subject: RFR: JDK-8198285: More consistent Access API for arraycopy
In-Reply-To: <f0a526e2-d6f5-4c5f-558c-52096e395c3e@redhat.com>
References: <b57660bf-6c92-f243-6abd-2ea69570389c@redhat.com>
 <5AE09F74.7050005@oracle.com>
 <f0a526e2-d6f5-4c5f-558c-52096e395c3e@redhat.com>
Message-ID: <5AE1F062.3020303@oracle.com>

Hi Roman,

Sure. That is another option. I wonder what the callsites will look like 
though? Will users of the API have to create their address wrapper 
objects explicitly at the callsite and pass them in to the Access call? 
I am also worried that wrapping the addresses in these wrapper objects 
type erases the element type, which might come in handy when we perform 
atomic arraycopy, so that we know what granularity the atomicity needs 
to be on. And either that goes in as explicit template parameters on the 
array type (ugh), or explicitly on the arraycopy function, making it a 
template type qualified template method, which requires the template 
keyword, like this:

length_in_bytes = ...
HeapAccess<ARRAYCOPY_ATOMIC>::template 
arraycopy<jshort>(NativeAddress(ptr), HeapArray(obj, index), 
length_in_bytes)?

I tend to think it would be easier and more clear to write:

ArrayAccess<ARRAYCOPY_ATOMIC>::arraycopy_from_native(ptr, obj, index, 
length);

Each required parameter is clear when you read the API.

But I am open to suggestions of course.

Thanks,
/Erik

On 2018-04-25 17:59, Roman Kennke wrote:
>> 1) Resolve the addresses as we do today, but you think you get better
>> Shenandoah performance if we either
>> 2) Have 3 different access calls, (from heap to native, from native to
>> heap, from heap to heap) for copying, or
>> 3) Have 1 access call that can encode the above 3 variants, but looks
>> ugly at the call sites.
> There's also the idea to pass Address arguments to arraycopy, one for
> src, one for dst, and have 2 different subclasses: one for obj+offset
> (heap access) and one with direct pointer (raw). Your comment gave me
> the idea to also provide arrayOop+idx. This would look clean on the
> caller side I think.
>
> It would also be useful on the GC side: BarrierSets would specialize
> only in the variants that they are interested in, for example, in case
> of Shenandoah:
> 1. arraycopy(HeapAddress,HeapAddress) Java->Java
> 2. arraycopy(HeapAddress,RawAddress)  Java->native
> 3. arraycopy(RawAddress,HeapAddress)  native->Java
>
> other barriersets can ignore the exact type and only call the args
> address->resolve() or so to get the actual raw address.
>
> This would *also* be beneficial for the other APIs: instead of having
> all the X() and X_at() variants, we can just use one X variant that
> either takes RawAddress or HeapAddress.
>
> I made a little (not yet compiling/working) prototype of this a while ago:
>
> http://cr.openjdk.java.net/~rkennke/JDK-8199801-2.patch
>
>
> What do you think? Would it make sense to go further down that road?
>
> Roman
>
>> You clearly went for 3, which leaves the callsites looking rather hard
>> to read. It is for example not obvious for me what is going on here
>> (javaClasses.cpp line 313):
>>
>> HeapAccess<>::arraycopy<jbyte>(NULL, 0, reinterpret_cast<const
>> jbyte*>(utf8_str), value(h_obj()),
>> typeArrayOopDesc::element_offset<jbyte>(0), NULL, length);
>>
>> ...without looking very carefully at the long list of arguments encoding
>> what is actually going on (copy from native to the heap). What is worse
>> is that this will probably not compile without adding the template
>> keyword to the call (since you have a qualified template member function
>> behind a template class), like this:
>> HeapAccess<>::template arraycopy<jbyte>(NULL, 0, reinterpret_cast<const
>> jbyte*>(utf8_str), value(h_obj()),
>> typeArrayOopDesc::element_offset<jbyte>(0), NULL, length);
>>
>> ...which as a public API leaves me feeling a bit like this:     :C
>>
>> May I suggest adding an array access helper. The idea is to keep a
>> single call through Access, and a single backend point for array copy,
>> but let the helper provide the three different types of copying as
>> different functions, so that the call sites still look pretty and easy
>> to read and follow.
>>
>> This helper could additionally have load_at, and store_at use array
>> indices as opposed to offsets, and hence hide the offset calculations we
>> perform today (typically involving checking if we are using compressed
>> oops or not).
>>
>> I am thinking something along the lines of
>> ArrayAccess<>::arraycopy_to_native(readable_arguments),
>> ArrayAccess<>::arraycopy_from_native(readable_arguments),
>> ArrayAccess<>::arraycopy(readable_arguments), which translates to some
>> form of Access<>::arraycopy(unreadable_arguments). And for example
>> ArrayAccess<>::load_at(obj, index) would translate to some kind of
>> HeapAccess<IN_HEAP_ARRAY>::load_at(obj, offset_for_index(index)) as a
>> bonus, making everyone using the API jump with happiness.
>>
>> What do you think about this idea? Good or bad? I guess the question is
>> whether this helper should be in access.hpp, or somewhere else (like in
>> arrayOop). Thoughts are welcome.
>>
>> Thanks,
>> /Erik
>>
>> On 2018-04-11 19:54, Roman Kennke wrote:
>>>    Currently, the arraycopy API in access.hpp gets the src and dst oops,
>>> plus the src and dst addresses. In order to be most useful to garbage
>>> collectors, it should receive the src and dst oops together with the src
>>> and dst offsets instead, and let the Access API / GC calculate the src
>>> and dst addresses.
>>>
>>> For example, Shenandoah needs to resolve the src and dst objects for
>>> arraycopy, and then apply the corresponding offsets. With the current
>>> API (obj+ptr) it would calculate the ptr-diff from obj to ptr, then
>>> resolve obj, then re-add the calculate ptr-diff. This is fragile because
>>> we also may resolve obj in the runtime before calculating ptr (e.g. via
>>> arrayOop::base()). If we then pass in the original obj and a ptr
>>> calculated from another copy of the same obj, the above resolution logic
>>> would not work. This is currently the case for obj-arraycopy.
>>>
>>> I propose to change the API to accept obj+offset, in addition to ptr for
>>> both src and dst. Only one or the other should be used. Heap accesses
>>> should use obj+offset and pass NULL for raw-ptr, off-heap accesses (or
>>> heap accesses that are already resolved.. use with care) should pass
>>> NULL+0 for obj+offset and the raw-ptr. Notice that this also allows the
>>> API to be used for Java<->native array bulk transfers.
>>>
>>> An alternative would be to break the API up into 4 variants:
>>>
>>> Java->Java transfer:
>>> arraycopy(oop src, size_t src_offs, oop dst, size_t dst_offs, size_t len)
>>>
>>> Java->Native transfer:
>>> arraycopy(oop src, size_t src_offs, D* raw_dst, size_t len)
>>>
>>> Native->Java transfer:
>>> arraycopy(S* src_raw, oop dst, size_t dst_offs, size_t len)
>>>
>>> 'Unsafe' transfer:
>>> arraycopy(S* src_raw, D* dst_raw, size_t len)
>>>
>>>
>>> But that seemed to be too much boilerplate copy+pasting for my taste.
>>> (See how having this overly complicated template layer hurts us?)
>>>
>>> Plus, I had a better idea: instead of accepting oop+offset OR T* for
>>> almost every Access API, we may want to abstract that and take an
>>> Address type argument, which would be either HeapAddress(obj, offset) or
>>> RawAddress(T* ptr). GCs may then just call addr->address() to get the
>>> actual address, or specialize for HeapAddress variants and resolve the
>>> objs and then resolve the address. This would also allow us to get rid
>>> of almost half of the API (all the *_at variants would go) and some
>>> other simplifications. However, this seemed to explode the scope of this
>>> RFE, and would be better handled in another RFE.
>>>
>>> This changes makes both typeArrayKlass and objArrayKlass use the changed
>>> API, plus I identified all (hopefully) places where we do bulk
>>> Java<->native array transfers and make them use the API too. Gets us rid
>>> of a bunch of memcpy calls :-)
>>>
>>> Please review the change:
>>> http://cr.openjdk.java.net/~rkennke/JDK-8198285/webrev.00/
>>>
>>> Thanks, Roman
>>>
>



From shade at redhat.com  Thu Apr 26 17:37:54 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 26 Apr 2018 19:37:54 +0200
Subject: RFR: Epsilon GC
Message-ID: <7353b73f-c563-d91c-d0e2-22b4548ca010@redhat.com>

Hi,

This is the review thread for Epsilon GC changes.

JEP, targeted to 11:
  http://openjdk.java.net/jeps/318
  (you can find links to binary builds and sandbox locations there)

Webrev:
  http://cr.openjdk.java.net/~shade/epsilon/webrev.05/

Notes:

  *) See how the whole things is _almost_ drop-in to hotspot/share/gc, without having arch-specific
mess -- thanks to GC interface work done over last years;

  *) There are some leftovers due to GC barriers work in progress: templateTable_arm.cpp addition
goes away after JDK-8201786 [1], c1_LIRGenerator.cpp change should go away after C1 barriers
modularization is complete, graphKit.cpp change should go away after C2 barriers modularization is
complete;

  *) Half of the webrev are Epsilon-specific tests. They take ~30s in release and ~60s in fastdebug
on my desktop. They are not in tier1, so smoke testing time is not affected;

  *) UseEpsilonGC is experimental. This should be fine after conditional GC compilation [2], so
vendors who are unwilling to extend whatever small notion [3] of support comes with experimental VM
option, may choose not to build it.

Testing: all platform builds, gc/epsilon on x86_64

Thanks,
-Aleksey

[1] https://bugs.openjdk.java.net/browse/JDK-8201786
[2] https://bugs.openjdk.java.net/browse/JDK-8200729
[3] http://hg.openjdk.java.net/jdk/jdk/file/3661f31c6df4/src/hotspot/share/runtime/globals.hpp#l150

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180426/fc0c9c6b/signature.asc>

From rkennke at redhat.com  Thu Apr 26 18:32:55 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 26 Apr 2018 20:32:55 +0200
Subject: RFR: Epsilon GC
In-Reply-To: <7353b73f-c563-d91c-d0e2-22b4548ca010@redhat.com>
References: <7353b73f-c563-d91c-d0e2-22b4548ca010@redhat.com>
Message-ID: <f2a8ec06-81ad-4704-fc12-677b04317868@redhat.com>

Hi Aleksey,

I like it! It is a nice testament to the GC interface work indeed :-)

I have nothing to complain about in the changeset, but I am not a
Reviewer either ;-)

Cheers, Roman

> Hi,
> 
> This is the review thread for Epsilon GC changes.
> 
> JEP, targeted to 11:
>   http://openjdk.java.net/jeps/318
>   (you can find links to binary builds and sandbox locations there)
> 
> Webrev:
>   http://cr.openjdk.java.net/~shade/epsilon/webrev.05/
> 
> Notes:
> 
>   *) See how the whole things is _almost_ drop-in to hotspot/share/gc, without having arch-specific
> mess -- thanks to GC interface work done over last years;
> 
>   *) There are some leftovers due to GC barriers work in progress: templateTable_arm.cpp addition
> goes away after JDK-8201786 [1], c1_LIRGenerator.cpp change should go away after C1 barriers
> modularization is complete, graphKit.cpp change should go away after C2 barriers modularization is
> complete;
> 
>   *) Half of the webrev are Epsilon-specific tests. They take ~30s in release and ~60s in fastdebug
> on my desktop. They are not in tier1, so smoke testing time is not affected;
> 
>   *) UseEpsilonGC is experimental. This should be fine after conditional GC compilation [2], so
> vendors who are unwilling to extend whatever small notion [3] of support comes with experimental VM
> option, may choose not to build it.
> 
> Testing: all platform builds, gc/epsilon on x86_64
> 
> Thanks,
> -Aleksey
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8201786
> [2] https://bugs.openjdk.java.net/browse/JDK-8200729
> [3] http://hg.openjdk.java.net/jdk/jdk/file/3661f31c6df4/src/hotspot/share/runtime/globals.hpp#l150
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180426/152b5a96/signature.asc>

From sangheon.kim at oracle.com  Thu Apr 26 19:01:30 2018
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Thu, 26 Apr 2018 12:01:30 -0700
Subject: RFR (M): 6672778: G1 should trim task queues more aggressively
 during evacuation pauses
In-Reply-To: <1524654810.2487.1.camel@oracle.com>
References: <1523272805.4326.33.camel@oracle.com>
 <1523447197.9657.6.camel@oracle.com>
 <43f37e0f-74c4-b9f9-bef7-934180518261@oracle.com>
 <1523608516.2360.10.camel@oracle.com>
 <b306a75c-51f2-f1e5-b0de-3aa6a5759645@oracle.com>
 <1523876930.12621.6.camel@oracle.com>
 <8fa48c25-6c7a-80af-4445-0f5d416ec4d4@oracle.com>
 <1524125349.2376.3.camel@oracle.com>
 <9423fa30-d986-0070-4561-ebfb3b0623a3@oracle.com>
 <1524654810.2487.1.camel@oracle.com>
Message-ID: <cd5e7d9f-7a13-fc6c-429a-f987ec63c88e@oracle.com>

Hi Thomas,

This is nice improvement, thank you for doing this.

On 04/25/2018 04:13 AM, Thomas Schatzl wrote:
> Hi,
>
>    thanks for your review, Stefan.
>
> Could I have another reviewer for this change?
>
> Thanks,
>    Thomas
>
> On Thu, 2018-04-19 at 11:27 +0200, Stefan Johansson wrote:
>> On 2018-04-19 10:09, Thomas Schatzl wrote:
>>> Hi all,
>>>
>>>     I unfortunately found another issue with timing:
>>>
>>> when calculating the "Other" time, we add the SATBFiltering phase
>>> to the known worker time - however that time is already included in
>>> the ext root scan time, so it is double-counted, and you
>>> occasionally get slightly negative "Other" times.
>>>
>>> This problem had been introduced in the refactoring too :(
>>>
>>> This change fixes that.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~tschatzl/6672778/webrev.3_to_4/ (diff)
>>> http://cr.openjdk.java.net/~tschatzl/6672778/webrev.4/ (full)
webrev.4 looks good to me.

If you are interested, please add 'const' before pushing this.

src/hotspot/share/gc/g1/g1ParScanThreadState.hpp
 ?204?? Tickspan trim_ticks();

src/hotspot/share/gc/g1/g1RemSet.hpp
 ?174?? Tickspan strong_code_root_scan_time() { return 
_strong_code_root_scan_time;? }
 ?175?? Tickspan strong_code_root_trim_partially_time() { return 
_strong_code_trim_partially_time; }

Thanks,
Sangheon


>> Good that you caught that! Still good.
>>
>> Thanks,
>> Stefan
>>
>>> Thanks,
>>>     Thomas
>>>
>>> On Mon, 2018-04-16 at 14:58 +0200, Stefan Johansson wrote:
>>>> Hi Thomas,
>>>>
>>>> On 2018-04-16 13:08, Thomas Schatzl wrote:
>>>>> Hi all,
>>>>>
>>>>> On Fri, 2018-04-13 at 14:25 +0200, Stefan Johansson wrote:
>>>>>> On 2018-04-13 10:35, Thomas Schatzl wrote:
>>>>>>> Hi Stefan,
>>>>>>>
>>>>>>>       thanks for your review... :)
>>>>>>>
>>>>>>> On Thu, 2018-04-12 at 17:15 +0200, Stefan Johansson wrote:
>>>>>>>> Hi Thomas,
>>>>>>>>
>>>>>>>> On 2018-04-11 13:46, Thomas Schatzl wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>>        I updated and (hopefully) improved the change a
>>>>>>>>> bit
>>>>>>>>> after
>>>>>>>>> some
>>>>>>>>> more thinking.
>>>>>>> [...]
>>>>> Also fixed a problem with the "-" operator of Tickspan
>>>>> introduced
>>>>> in
>>>>> all this refactoring. This caused negative times being reported
>>>>> sometimes in the logs.
>>>>>
>>>>> http://cr.openjdk.java.net/~tschatzl/6672778/webrev.2_to_3/
>>>>> (diff)
>>>>> http://cr.openjdk.java.net/~tschatzl/6672778/webrev.3/ (full)
>>>>>
>>>>> The change looks really nice now imho, thanks Stefan!
>>>> I agree, ship it :)
>>>>
>>>> Thanks,
>>>> Stefan
>>>>> Thanks,
>>>>>      Thomas
>>>>>



From kim.barrett at oracle.com  Thu Apr 26 21:03:16 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 26 Apr 2018 17:03:16 -0400
Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for
 ppc64
In-Reply-To: <5625a595-1165-8d48-afbd-8229cdc4ac07@oracle.com>
References: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>
 <5625a595-1165-8d48-afbd-8229cdc4ac07@oracle.com>
Message-ID: <F8C75A5A-404E-45CA-89CE-C97E582AF2D7@oracle.com>

> On Apr 25, 2018, at 8:45 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Michihiro,
> 
> On 23/04/2018 8:33 PM, Michihiro Horie wrote:
>> Dear all,
>> I would like to ask reviews on 8154736 ?enhancement of cmpxchg and
>> copy_to_survivor?. The change adds options to avoid expensive syncs with
>> compare-and-exchange. An experiment by using SPECjbb2015 showed 6%
>> improvement in critical-jOPS. This change focuses on ppc64 but would be
>> potentially beneficial for aarch64.
>> Although discussions stopped at
>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002718.html
>> , I would like to restart the review by taking over Hiroshi's work if the
>> discussion is still open.
> 
> So the very last comment there was about not implicitly assuming memory_order_consume, yet that has not been addressed in the proposal.
> 
> Further the discussion on hotspot-runtime-dev through September and October was far more illuminating. I think my post here:
> 
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-October/021617.html
> 
> and the closely following one from Thomas Schatzl summed up the concerns about the proposed changes.
> 
> AFAICS the restarted proposal addresses none of those concerns but simply takes up where the previous implementation suggestion left off.
> 
> This is a proposal to change the memory ordering semantics of part of the shared GC code _not_ just the PPC64 implementation, but I have seen no analysis to demonstrate the correctness of such a proposal.

I agree with David here. So far we've seen no such analysis. All we
have seen is a series of proposed changes and non-failing test
results, all of which have then been shown to have holes. (Among other
things, this suggests the set of tests being applied is inadequate.)
Part of the author's job is to convince reviewers that the proposed
change is correct. I'm not expecting a formal proof, but I am
expecting a lot more than has been provided so far.

In this latest proposal, the conditional acquire doesn't look right to
me. If the logging is disabled so there is no acquire, the object is
then returned to the callers, who might do what with it? Is that safe?
For all callers? And is it stable through future maintenance? This is
not to say that I think making those acquires unconditional is
sufficient.



From kim.barrett at oracle.com  Thu Apr 26 23:03:47 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 26 Apr 2018 19:03:47 -0400
Subject: RFR (S/M): 8202017: Merge Reference Enqueuing phase with phase 3
 of Reference processing
In-Reply-To: <1524561984.2367.3.camel@oracle.com>
References: <1524165246.2765.14.camel@oracle.com>
 <9C1F6CAC-02DC-44F6-A24F-81814118748A@oracle.com>
 <1524561984.2367.3.camel@oracle.com>
Message-ID: <C986DB3F-B76B-4DCF-AD98-54D27187E749@oracle.com>

> On Apr 24, 2018, at 5:26 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi Kim,
> 
> On Mon, 2018-04-23 at 19:10 -0400, Kim Barrett wrote:
>>> On Apr 19, 2018, at 3:14 PM, Thomas Schatzl <thomas.schatzl at oracle.
>>> com> wrote:
>>> 
>>> Hi all,
>>> 
>>> can I have reviews for this change that merges the Reference
>>> Enqueuing phase of reference processing with the respective phase 3
>>> of actual Reference Processing?
>>> 
> [...]
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8202017
>>> Webrev:
>>> http://cr.openjdk.java.net/~tschatzl/8202017/webrev/
>>> Testing:
>>> hs-tier1-4
>>> 
>>> Thanks,
>>> Thomas
>> 
>> Looks good.  Just a couple very minor things.
>> 
>> -------------------------------------------------------------------
>> ----------- 
>> src/hotspot/share/gc/shared/referenceProcessor.cpp
>> 607     _refs_lists[i].set_head(NULL);
>> 608     _refs_lists[i].set_length(0);
>> 
>> 790        refs_lists[i].set_head(NULL);
>> 791        refs_lists[i].set_length(0);
>> 
>> Maybe move these into process_phase3?
> 
> Done.
> 
>> 
>> -------------------------------------------------------------------
>> ----------- 
>> src/hotspot/share/gc/g1/g1CollectedHeap.hpp
>> 515   // If during an initial mark pause we install a pending list
>> head which is not otherwise reachable
>> 
>> Perhaps s/install/may install/
>> 
> 
> Done.
> 
>> src/hotspot/share/gc/shared/genCollectedHeap.cpp
>> 518       rp->disable_discovery();
>> 
>> Ick!  This whole little dance around discovery_is_atomic,
>> enqueueing_is_done, &etc looks like it is related to CMS and the
>> distinction between CMS and Serial.  See also the TODO-ish block
>> comment at line 489.
>> 
>> This looks ripe for refactoring as part of the cleanup of CMS-
>> specific intrusions.  Probably should have a followup RFE for this.
> 
> I will file an RFE for this.
> 
> New webrevs:
> http://cr.openjdk.java.net/~tschatzl/8202017/webrev.0_to_1 (diff)
> http://cr.openjdk.java.net/~tschatzl/8202017/webrev.1/ (full)
> 
> Thomas

In the comment for G1CollectedHeap::make_pending_list_reachable():
 516   // otherwise reachable ensure that it is marked in the bitmap for concurrent marking

s/reachable ensure/reachable. Ensure/

Otherwise looks good.  No need for a new webrev for that comment change.



From erik.osterlund at oracle.com  Fri Apr 27 08:41:57 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Fri, 27 Apr 2018 10:41:57 +0200
Subject: RFR: 8202083: Remove explicit CMS checks in CardTableBarrierSet
In-Reply-To: <BD69A740-6C08-4F55-9B6E-97331EEEAB5E@oracle.com>
References: <5AD9FE1F.3050702@oracle.com>
 <BD69A740-6C08-4F55-9B6E-97331EEEAB5E@oracle.com>
Message-ID: <5AE2E255.90609@oracle.com>

Hi Kim,

Now that we reached an agreement on 8202082, may I assume we have 
reached an agreement here too?

Thanks,
/Erik

On 2018-04-23 23:29, Kim Barrett wrote:
>> On Apr 20, 2018, at 10:50 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>
>> Hi,
>>
>> In CardTableBarrierSet, we sometimes need fencing due to the card table being scanned concurrently when using CMS with pre-cleaning. Rather than explicitly checking for those CMS flags in the generic CardTableBarrierSet class, it is preferrable to check the CardTable scanned_concurrently() property which reflects that better
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8202083/webrev.00/
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8202083
>>
>> Thanks,
>> /Erik
> Isn't the correct predicate here
> CardTableBarrierSet::card_mark_must_follow_store?
>
> Also, the comment probably ought to be "generalized".
>
> Also, CardTable::scanned_concurrently() seems misplaced. CardTable is
> a data structure, scanned_concurrently is a usage policy. And the only
> use of scanned_concurrently seems to be the implementation of
> card_mark_must_follow_store. It seems like CardTableBarrierSet would
> be a better place for that bit of information.
>



From thomas.schatzl at oracle.com  Fri Apr 27 09:11:56 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 27 Apr 2018 11:11:56 +0200
Subject: RFR (S/M): 8202017: Merge Reference Enqueuing phase with phase
 3 of Reference processing
In-Reply-To: <C986DB3F-B76B-4DCF-AD98-54D27187E749@oracle.com>
References: <1524165246.2765.14.camel@oracle.com>
 <9C1F6CAC-02DC-44F6-A24F-81814118748A@oracle.com>
 <1524561984.2367.3.camel@oracle.com>
 <C986DB3F-B76B-4DCF-AD98-54D27187E749@oracle.com>
Message-ID: <1524820316.2555.1.camel@oracle.com>

Hi Kim,

On Thu, 2018-04-26 at 19:03 -0400, Kim Barrett wrote:
> > On Apr 24, 2018, at 5:26 AM, Thomas Schatzl <thomas.schatzl at oracle.
> > com> wrote:
> > 
> > Hi Kim,
> > 
> > On Mon, 2018-04-23 at 19:10 -0400, Kim Barrett wrote:
> > > > 
> > > [...]
> > > This looks ripe for refactoring as part of the cleanup of CMS-
> > > specific intrusions.  Probably should have a followup RFE for
> > > this.
> > 
> > I will file an RFE for this.

Filed JDK-8202185 btw.

> > 
> > New webrevs:
> > http://cr.openjdk.java.net/~tschatzl/8202017/webrev.0_to_1 (diff)
> > http://cr.openjdk.java.net/~tschatzl/8202017/webrev.1/ (full)
> > 
> > Thomas
> 
> In the comment for G1CollectedHeap::make_pending_list_reachable():
>  516   // otherwise reachable ensure that it is marked in the bitmap
> for concurrent marking
> 
> s/reachable ensure/reachable. Ensure/
> 
> Otherwise looks good.  No need for a new webrev for that comment
> change.

I updated the webrev in place for the second reviewer.

Thanks for your review.

Thanks,
  Thomas


From per.liden at oracle.com  Fri Apr 27 09:33:02 2018
From: per.liden at oracle.com (Per Liden)
Date: Fri, 27 Apr 2018 11:33:02 +0200
Subject: RFR: 8202364: Add GCConfig::hs_err_name() to avoid GC-specific code
 in error reporting
Message-ID: <eff1d971-6314-fa0d-67b9-a97cc4ea3d58@oracle.com>

The gc_mode() function in vmErrror.cpp currently tests which Use*GC flag 
is set and translates that into a name. We should instead call into 
GCConfig to get the name. This patch adds a new function 
(GCConfig::hs_err_name) for this purpose. This is not placed on 
CollectedHeap, since we might need this name before a CollectedHeap 
instance has been created, e.g. if we crash during VM startup.

Bug: https://bugs.openjdk.java.net/browse/JDK-8202364
Webrev: http://cr.openjdk.java.net/~pliden/8202364/webrev.0

/Per



From erik.osterlund at oracle.com  Fri Apr 27 09:40:42 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Fri, 27 Apr 2018 11:40:42 +0200
Subject: RFR: 8202364: Add GCConfig::hs_err_name() to avoid GC-specific
 code in error reporting
In-Reply-To: <eff1d971-6314-fa0d-67b9-a97cc4ea3d58@oracle.com>
References: <eff1d971-6314-fa0d-67b9-a97cc4ea3d58@oracle.com>
Message-ID: <5AE2F01A.7010508@oracle.com>

Hi Per,

Looks good.

Thanks,
/Erik

On 2018-04-27 11:33, Per Liden wrote:
> The gc_mode() function in vmErrror.cpp currently tests which Use*GC 
> flag is set and translates that into a name. We should instead call 
> into GCConfig to get the name. This patch adds a new function 
> (GCConfig::hs_err_name) for this purpose. This is not placed on 
> CollectedHeap, since we might need this name before a CollectedHeap 
> instance has been created, e.g. if we crash during VM startup.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202364
> Webrev: http://cr.openjdk.java.net/~pliden/8202364/webrev.0
>
> /Per
>



From shade at redhat.com  Fri Apr 27 09:39:17 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 27 Apr 2018 11:39:17 +0200
Subject: RFR: 8202364: Add GCConfig::hs_err_name() to avoid GC-specific
 code in error reporting
In-Reply-To: <eff1d971-6314-fa0d-67b9-a97cc4ea3d58@oracle.com>
References: <eff1d971-6314-fa0d-67b9-a97cc4ea3d58@oracle.com>
Message-ID: <e07528fd-f828-c51c-555f-ba050e58c5b2@redhat.com>

On 04/27/2018 11:33 AM, Per Liden wrote:
> The gc_mode() function in vmErrror.cpp currently tests which Use*GC flag is set and translates that
> into a name. We should instead call into GCConfig to get the name. This patch adds a new function
> (GCConfig::hs_err_name) for this purpose. This is not placed on CollectedHeap, since we might need
> this name before a CollectedHeap instance has been created, e.g. if we crash during VM startup.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202364
> Webrev: http://cr.openjdk.java.net/~pliden/8202364/webrev.0

Looks good.

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180427/68dbcdbf/signature.asc>

From shade at redhat.com  Fri Apr 27 09:40:34 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 27 Apr 2018 11:40:34 +0200
Subject: RFR: 8202364: Add GCConfig::hs_err_name() to avoid GC-specific
 code in error reporting
In-Reply-To: <e07528fd-f828-c51c-555f-ba050e58c5b2@redhat.com>
References: <eff1d971-6314-fa0d-67b9-a97cc4ea3d58@oracle.com>
 <e07528fd-f828-c51c-555f-ba050e58c5b2@redhat.com>
Message-ID: <ff00a3d3-c500-b1a7-f30e-e19d6d029b8b@redhat.com>

On 04/27/2018 11:39 AM, Aleksey Shipilev wrote:
> On 04/27/2018 11:33 AM, Per Liden wrote:
>> The gc_mode() function in vmErrror.cpp currently tests which Use*GC flag is set and translates that
>> into a name. We should instead call into GCConfig to get the name. This patch adds a new function
>> (GCConfig::hs_err_name) for this purpose. This is not placed on CollectedHeap, since we might need
>> this name before a CollectedHeap instance has been created, e.g. if we crash during VM startup.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202364
>> Webrev: http://cr.openjdk.java.net/~pliden/8202364/webrev.0
> 
> Looks good.

Wait, except you want to keep the human-readable?

Was:

 308   if (UseG1GC)            return "g1 gc";
 309   if (UseParallelGC)      return "parallel gc";
 310   if (UseConcMarkSweepGC) return "concurrent mark sweep gc";
 311   if (UseSerialGC)        return "serial gc";

Now:

  57   SupportedGC(UseSerialGC,        CollectedHeap::Serial,   serialArguments,   "serialgc"  ),
  59   SupportedGC(UseParallelGC,      CollectedHeap::Parallel, parallelArguments, "parallelgc"),
  60   SupportedGC(UseParallelOldGC,   CollectedHeap::Parallel, parallelArguments, "parallelgc"),
  61   SupportedGC(UseConcMarkSweepGC, CollectedHeap::CMS,      cmsArguments,      "cmsgc"     ),
  62   SupportedGC(UseG1GC,            CollectedHeap::G1,       g1Arguments,       "g1gc"      ),

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180427/90bae853/signature.asc>

From per.liden at oracle.com  Fri Apr 27 09:42:00 2018
From: per.liden at oracle.com (Per Liden)
Date: Fri, 27 Apr 2018 11:42:00 +0200
Subject: RFR: 8202366,,Add macro for common loop in GCConfig
Message-ID: <a2da923a-e9fa-9352-ce8c-1701158d2757@oracle.com>

In GCConfig, we loop over the list of supported GCs in many places. We 
could simplify the code a bit by adding a FOR_EACH_SUPPORTED_GC macro.

Bug: https://bugs.openjdk.java.net/browse/JDK-8202366
Webrev: http://cr.openjdk.java.net/~pliden/8202366/webrev.0

/Per


From per.liden at oracle.com  Fri Apr 27 09:48:11 2018
From: per.liden at oracle.com (Per Liden)
Date: Fri, 27 Apr 2018 11:48:11 +0200
Subject: RFR: 8202364: Add GCConfig::hs_err_name() to avoid GC-specific
 code in error reporting
In-Reply-To: <ff00a3d3-c500-b1a7-f30e-e19d6d029b8b@redhat.com>
References: <eff1d971-6314-fa0d-67b9-a97cc4ea3d58@oracle.com>
 <e07528fd-f828-c51c-555f-ba050e58c5b2@redhat.com>
 <ff00a3d3-c500-b1a7-f30e-e19d6d029b8b@redhat.com>
Message-ID: <d6ff4962-76ed-e03c-8f22-43edd9014f7d@oracle.com>

On 04/27/2018 11:40 AM, Aleksey Shipilev wrote:
> On 04/27/2018 11:39 AM, Aleksey Shipilev wrote:
>> On 04/27/2018 11:33 AM, Per Liden wrote:
>>> The gc_mode() function in vmErrror.cpp currently tests which Use*GC flag is set and translates that
>>> into a name. We should instead call into GCConfig to get the name. This patch adds a new function
>>> (GCConfig::hs_err_name) for this purpose. This is not placed on CollectedHeap, since we might need
>>> this name before a CollectedHeap instance has been created, e.g. if we crash during VM startup.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202364
>>> Webrev: http://cr.openjdk.java.net/~pliden/8202364/webrev.0
>>
>> Looks good.
> 
> Wait, except you want to keep the human-readable?

I though it looked ugly with the space so I removed it. I don't think it 
makes it less readable.

/Per


From per.liden at oracle.com  Fri Apr 27 09:50:18 2018
From: per.liden at oracle.com (Per Liden)
Date: Fri, 27 Apr 2018 11:50:18 +0200
Subject: RFR: 8202364: Add GCConfig::hs_err_name() to avoid GC-specific
 code in error reporting
In-Reply-To: <5AE2F01A.7010508@oracle.com>
References: <eff1d971-6314-fa0d-67b9-a97cc4ea3d58@oracle.com>
 <5AE2F01A.7010508@oracle.com>
Message-ID: <b3c43481-1fa3-9cec-50a8-71656c444751@oracle.com>

Thanks Erik!

/Per

On 04/27/2018 11:40 AM, Erik ?sterlund wrote:
> Hi Per,
> 
> Looks good.
> 
> Thanks,
> /Erik
> 
> On 2018-04-27 11:33, Per Liden wrote:
>> The gc_mode() function in vmErrror.cpp currently tests which Use*GC 
>> flag is set and translates that into a name. We should instead call 
>> into GCConfig to get the name. This patch adds a new function 
>> (GCConfig::hs_err_name) for this purpose. This is not placed on 
>> CollectedHeap, since we might need this name before a CollectedHeap 
>> instance has been created, e.g. if we crash during VM startup.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202364
>> Webrev: http://cr.openjdk.java.net/~pliden/8202364/webrev.0
>>
>> /Per
>>
> 


From shade at redhat.com  Fri Apr 27 09:50:19 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 27 Apr 2018 11:50:19 +0200
Subject: RFR: 8202364: Add GCConfig::hs_err_name() to avoid GC-specific
 code in error reporting
In-Reply-To: <d6ff4962-76ed-e03c-8f22-43edd9014f7d@oracle.com>
References: <eff1d971-6314-fa0d-67b9-a97cc4ea3d58@oracle.com>
 <e07528fd-f828-c51c-555f-ba050e58c5b2@redhat.com>
 <ff00a3d3-c500-b1a7-f30e-e19d6d029b8b@redhat.com>
 <d6ff4962-76ed-e03c-8f22-43edd9014f7d@oracle.com>
Message-ID: <06d8ff9c-ee44-2d7e-08fa-4f31b2da06d2@redhat.com>

On 04/27/2018 11:48 AM, Per Liden wrote:
> On 04/27/2018 11:40 AM, Aleksey Shipilev wrote:
>> On 04/27/2018 11:39 AM, Aleksey Shipilev wrote:
>>> On 04/27/2018 11:33 AM, Per Liden wrote:
>>>> The gc_mode() function in vmErrror.cpp currently tests which Use*GC flag is set and translates that
>>>> into a name. We should instead call into GCConfig to get the name. This patch adds a new function
>>>> (GCConfig::hs_err_name) for this purpose. This is not placed on CollectedHeap, since we might need
>>>> this name before a CollectedHeap instance has been created, e.g. if we crash during VM startup.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202364
>>>> Webrev: http://cr.openjdk.java.net/~pliden/8202364/webrev.0
>>>
>>> Looks good.
>>
>> Wait, except you want to keep the human-readable?
> 
> I though it looked ugly with the space so I removed it. I don't think it makes it less readable.

The line where GC name is injected already have spaces:

Java VM: OpenJDK Server VM (slowdebug 10-internal+0-adhoc.user.shenandoah-jdk10, mixed mode, tiered,
g1 gc, linux-x86)

I prefer not to change formatting unless there is very compelling reason to do so.

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180427/5026b4da/signature.asc>

From per.liden at oracle.com  Fri Apr 27 09:58:45 2018
From: per.liden at oracle.com (Per Liden)
Date: Fri, 27 Apr 2018 11:58:45 +0200
Subject: RFR: 8202364: Add GCConfig::hs_err_name() to avoid GC-specific
 code in error reporting
In-Reply-To: <06d8ff9c-ee44-2d7e-08fa-4f31b2da06d2@redhat.com>
References: <eff1d971-6314-fa0d-67b9-a97cc4ea3d58@oracle.com>
 <e07528fd-f828-c51c-555f-ba050e58c5b2@redhat.com>
 <ff00a3d3-c500-b1a7-f30e-e19d6d029b8b@redhat.com>
 <d6ff4962-76ed-e03c-8f22-43edd9014f7d@oracle.com>
 <06d8ff9c-ee44-2d7e-08fa-4f31b2da06d2@redhat.com>
Message-ID: <32fb0cc1-fdc8-3b42-dab6-9701318b47b9@oracle.com>

On 04/27/2018 11:50 AM, Aleksey Shipilev wrote:
> On 04/27/2018 11:48 AM, Per Liden wrote:
>> On 04/27/2018 11:40 AM, Aleksey Shipilev wrote:
>>> On 04/27/2018 11:39 AM, Aleksey Shipilev wrote:
>>>> On 04/27/2018 11:33 AM, Per Liden wrote:
>>>>> The gc_mode() function in vmErrror.cpp currently tests which Use*GC flag is set and translates that
>>>>> into a name. We should instead call into GCConfig to get the name. This patch adds a new function
>>>>> (GCConfig::hs_err_name) for this purpose. This is not placed on CollectedHeap, since we might need
>>>>> this name before a CollectedHeap instance has been created, e.g. if we crash during VM startup.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202364
>>>>> Webrev: http://cr.openjdk.java.net/~pliden/8202364/webrev.0
>>>>
>>>> Looks good.
>>>
>>> Wait, except you want to keep the human-readable?
>>
>> I though it looked ugly with the space so I removed it. I don't think it makes it less readable.
> 
> The line where GC name is injected already have spaces:
> 
> Java VM: OpenJDK Server VM (slowdebug 10-internal+0-adhoc.user.shenandoah-jdk10, mixed mode, tiered,
> g1 gc, linux-x86)
> 
> I prefer not to change formatting unless there is very compelling reason to do so.

Sure, keeping the original names.

http://cr.openjdk.java.net/~pliden/8202364/webrev.1

cheers,
Per


From shade at redhat.com  Fri Apr 27 09:59:35 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 27 Apr 2018 11:59:35 +0200
Subject: RFR: 8202364: Add GCConfig::hs_err_name() to avoid GC-specific
 code in error reporting
In-Reply-To: <32fb0cc1-fdc8-3b42-dab6-9701318b47b9@oracle.com>
References: <eff1d971-6314-fa0d-67b9-a97cc4ea3d58@oracle.com>
 <e07528fd-f828-c51c-555f-ba050e58c5b2@redhat.com>
 <ff00a3d3-c500-b1a7-f30e-e19d6d029b8b@redhat.com>
 <d6ff4962-76ed-e03c-8f22-43edd9014f7d@oracle.com>
 <06d8ff9c-ee44-2d7e-08fa-4f31b2da06d2@redhat.com>
 <32fb0cc1-fdc8-3b42-dab6-9701318b47b9@oracle.com>
Message-ID: <50880e75-4a68-a96c-c63a-e0008891d2a1@redhat.com>

On 04/27/2018 11:58 AM, Per Liden wrote:
> On 04/27/2018 11:50 AM, Aleksey Shipilev wrote:
>> On 04/27/2018 11:48 AM, Per Liden wrote:
>>> On 04/27/2018 11:40 AM, Aleksey Shipilev wrote:
>>>> On 04/27/2018 11:39 AM, Aleksey Shipilev wrote:
>>>>> On 04/27/2018 11:33 AM, Per Liden wrote:
>>>>>> The gc_mode() function in vmErrror.cpp currently tests which Use*GC flag is set and translates
>>>>>> that
>>>>>> into a name. We should instead call into GCConfig to get the name. This patch adds a new function
>>>>>> (GCConfig::hs_err_name) for this purpose. This is not placed on CollectedHeap, since we might
>>>>>> need
>>>>>> this name before a CollectedHeap instance has been created, e.g. if we crash during VM startup.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202364
>>>>>> Webrev: http://cr.openjdk.java.net/~pliden/8202364/webrev.0
>>>>>
>>>>> Looks good.
>>>>
>>>> Wait, except you want to keep the human-readable?
>>>
>>> I though it looked ugly with the space so I removed it. I don't think it makes it less readable.
>>
>> The line where GC name is injected already have spaces:
>>
>> Java VM: OpenJDK Server VM (slowdebug 10-internal+0-adhoc.user.shenandoah-jdk10, mixed mode, tiered,
>> g1 gc, linux-x86)
>>
>> I prefer not to change formatting unless there is very compelling reason to do so.
> 
> Sure, keeping the original names.
> 
> http://cr.openjdk.java.net/~pliden/8202364/webrev.1

Excellent, go!

-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180427/df2eab93/signature.asc>

From per.liden at oracle.com  Fri Apr 27 10:05:04 2018
From: per.liden at oracle.com (Per Liden)
Date: Fri, 27 Apr 2018 12:05:04 +0200
Subject: RFR: 8202364: Add GCConfig::hs_err_name() to avoid GC-specific
 code in error reporting
In-Reply-To: <50880e75-4a68-a96c-c63a-e0008891d2a1@redhat.com>
References: <eff1d971-6314-fa0d-67b9-a97cc4ea3d58@oracle.com>
 <e07528fd-f828-c51c-555f-ba050e58c5b2@redhat.com>
 <ff00a3d3-c500-b1a7-f30e-e19d6d029b8b@redhat.com>
 <d6ff4962-76ed-e03c-8f22-43edd9014f7d@oracle.com>
 <06d8ff9c-ee44-2d7e-08fa-4f31b2da06d2@redhat.com>
 <32fb0cc1-fdc8-3b42-dab6-9701318b47b9@oracle.com>
 <50880e75-4a68-a96c-c63a-e0008891d2a1@redhat.com>
Message-ID: <0abff4f8-2293-5055-d6d7-29343edb2bc7@oracle.com>

On 04/27/2018 11:59 AM, Aleksey Shipilev wrote:
> On 04/27/2018 11:58 AM, Per Liden wrote:
>> On 04/27/2018 11:50 AM, Aleksey Shipilev wrote:
>>> On 04/27/2018 11:48 AM, Per Liden wrote:
>>>> On 04/27/2018 11:40 AM, Aleksey Shipilev wrote:
>>>>> On 04/27/2018 11:39 AM, Aleksey Shipilev wrote:
>>>>>> On 04/27/2018 11:33 AM, Per Liden wrote:
>>>>>>> The gc_mode() function in vmErrror.cpp currently tests which Use*GC flag is set and translates
>>>>>>> that
>>>>>>> into a name. We should instead call into GCConfig to get the name. This patch adds a new function
>>>>>>> (GCConfig::hs_err_name) for this purpose. This is not placed on CollectedHeap, since we might
>>>>>>> need
>>>>>>> this name before a CollectedHeap instance has been created, e.g. if we crash during VM startup.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202364
>>>>>>> Webrev: http://cr.openjdk.java.net/~pliden/8202364/webrev.0
>>>>>>
>>>>>> Looks good.
>>>>>
>>>>> Wait, except you want to keep the human-readable?
>>>>
>>>> I though it looked ugly with the space so I removed it. I don't think it makes it less readable.
>>>
>>> The line where GC name is injected already have spaces:
>>>
>>> Java VM: OpenJDK Server VM (slowdebug 10-internal+0-adhoc.user.shenandoah-jdk10, mixed mode, tiered,
>>> g1 gc, linux-x86)
>>>
>>> I prefer not to change formatting unless there is very compelling reason to do so.
>>
>> Sure, keeping the original names.
>>
>> http://cr.openjdk.java.net/~pliden/8202364/webrev.1
> 
> Excellent, go!
> 

Thanks for reviewing!

/Per


From erik.osterlund at oracle.com  Fri Apr 27 10:10:49 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Fri, 27 Apr 2018 12:10:49 +0200
Subject: RFR: 8202366,,Add macro for common loop in GCConfig
In-Reply-To: <a2da923a-e9fa-9352-ce8c-1701158d2757@oracle.com>
References: <a2da923a-e9fa-9352-ce8c-1701158d2757@oracle.com>
Message-ID: <5AE2F729.2050603@oracle.com>

Hi Per,

Looks good.

Thanks,
/Erik

On 2018-04-27 11:42, Per Liden wrote:
> In GCConfig, we loop over the list of supported GCs in many places. We 
> could simplify the code a bit by adding a FOR_EACH_SUPPORTED_GC macro.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202366
> Webrev: http://cr.openjdk.java.net/~pliden/8202366/webrev.0
>
> /Per



From shade at redhat.com  Fri Apr 27 10:09:11 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 27 Apr 2018 12:09:11 +0200
Subject: RFR: 8202366,,Add macro for common loop in GCConfig
In-Reply-To: <a2da923a-e9fa-9352-ce8c-1701158d2757@oracle.com>
References: <a2da923a-e9fa-9352-ce8c-1701158d2757@oracle.com>
Message-ID: <0d8e6ffe-17d6-f962-2a91-072cb4733878@redhat.com>

On 04/27/2018 11:42 AM, Per Liden wrote:
> In GCConfig, we loop over the list of supported GCs in many places. We could simplify the code a bit
> by adding a FOR_EACH_SUPPORTED_GC macro.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202366
> Webrev: http://cr.openjdk.java.net/~pliden/8202366/webrev.0

Looks good (well, as good as control-flow-bearing macros look).

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180427/df00af7f/signature.asc>

From thomas.schatzl at oracle.com  Fri Apr 27 10:14:33 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 27 Apr 2018 12:14:33 +0200
Subject: RFR (M): 6672778: G1 should trim task queues more aggressively
 during evacuation pauses
In-Reply-To: <cd5e7d9f-7a13-fc6c-429a-f987ec63c88e@oracle.com>
References: <1523272805.4326.33.camel@oracle.com>
 <1523447197.9657.6.camel@oracle.com>
 <43f37e0f-74c4-b9f9-bef7-934180518261@oracle.com>
 <1523608516.2360.10.camel@oracle.com>
 <b306a75c-51f2-f1e5-b0de-3aa6a5759645@oracle.com>
 <1523876930.12621.6.camel@oracle.com>
 <8fa48c25-6c7a-80af-4445-0f5d416ec4d4@oracle.com>
 <1524125349.2376.3.camel@oracle.com>
 <9423fa30-d986-0070-4561-ebfb3b0623a3@oracle.com>
 <1524654810.2487.1.camel@oracle.com>
 <cd5e7d9f-7a13-fc6c-429a-f987ec63c88e@oracle.com>
Message-ID: <1524824073.2555.2.camel@oracle.com>

Hi Kim,

On Thu, 2018-04-26 at 12:01 -0700, sangheon.kim wrote:
> Hi Thomas,
> 
> This is nice improvement, thank you for doing this.

  thank you for your review. I added the suggested "const"s before
pushing.

Thomas



From per.liden at oracle.com  Fri Apr 27 11:25:03 2018
From: per.liden at oracle.com (Per Liden)
Date: Fri, 27 Apr 2018 13:25:03 +0200
Subject: RFR: 8202366,,Add macro for common loop in GCConfig
In-Reply-To: <5AE2F729.2050603@oracle.com>
References: <a2da923a-e9fa-9352-ce8c-1701158d2757@oracle.com>
 <5AE2F729.2050603@oracle.com>
Message-ID: <2cecae04-12d4-e820-7b10-001dcd9c8391@oracle.com>

Thanks Erik!

/Per

On 04/27/2018 12:10 PM, Erik ?sterlund wrote:
> Hi Per,
> 
> Looks good.
> 
> Thanks,
> /Erik
> 
> On 2018-04-27 11:42, Per Liden wrote:
>> In GCConfig, we loop over the list of supported GCs in many places. We 
>> could simplify the code a bit by adding a FOR_EACH_SUPPORTED_GC macro.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202366
>> Webrev: http://cr.openjdk.java.net/~pliden/8202366/webrev.0
>>
>> /Per
> 


From per.liden at oracle.com  Fri Apr 27 11:26:24 2018
From: per.liden at oracle.com (Per Liden)
Date: Fri, 27 Apr 2018 13:26:24 +0200
Subject: RFR: 8202366,,Add macro for common loop in GCConfig
In-Reply-To: <0d8e6ffe-17d6-f962-2a91-072cb4733878@redhat.com>
References: <a2da923a-e9fa-9352-ce8c-1701158d2757@oracle.com>
 <0d8e6ffe-17d6-f962-2a91-072cb4733878@redhat.com>
Message-ID: <ba576b5c-4ec6-2cdc-59e5-0112789f770c@oracle.com>

On 04/27/2018 12:09 PM, Aleksey Shipilev wrote:
> On 04/27/2018 11:42 AM, Per Liden wrote:
>> In GCConfig, we loop over the list of supported GCs in many places. We could simplify the code a bit
>> by adding a FOR_EACH_SUPPORTED_GC macro.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202366
>> Webrev: http://cr.openjdk.java.net/~pliden/8202366/webrev.0
> 
> Looks good (well, as good as control-flow-bearing macros look).

Thanks Aleksey (yes, I dream of c++11 daily...)

/Per


From stefan.johansson at oracle.com  Fri Apr 27 13:38:55 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Fri, 27 Apr 2018 15:38:55 +0200
Subject: RFR (M): 8201492: Properly implement non-contiguous generations
 for reference discovery
In-Reply-To: <1524751974.11105.0.camel@oracle.com>
References: <1524034373.3236.7.camel@oracle.com>
 <1524751974.11105.0.camel@oracle.com>
Message-ID: <87f49dd3-cabb-ae05-c804-ae359711c102@oracle.com>

Hi Thomas,

On 2018-04-26 16:12, Thomas Schatzl wrote:
> Hi all,
> 
>    could someone please have a look at this?
> 
> Thanks,
>    Thomas
> 
> On Wed, 2018-04-18 at 08:52 +0200, Thomas Schatzl wrote:
>> Hi all,
>>
>>    can I have reviews for this change that adapts the reference
>> discovery for the non-contiguous generations (and non-contiguous
>> generations in general) of G1 to solve one day-one performance issue?
>>
>> So reference discovery does not properly support non-contiguous
>> generations, resorting to an approximation of it.
>>
>> This in turn causes G1 to require the "preserve cm referents" phase
>> during GC during marking, which is very costly in some cases.
>>
>> The reason for the preserve cm referents phase is that References
>> (j.l.ref.References instances) that are discovered by concurrent
>> discovery, will currently prevent discovery and evacuation of
>> referents
>> in the STW pauses, as G1 thinks that it already has discovered that
>> Reference and skips it. Still their referents can be in young gen,
>> while the Reference is in old gen (young gc may iterate over it
>> during
>> card scanning), and this may cause crashes later.
>>
>> The preserve cm referents phase brute-force simply evacuates any
>> "leftover" referents and its followers.
>>
>> This is because the STW reference discovery currently does not treat
>> References in old gen as roots (i.e. to be scanned and referents
>> evacuated always), as the STW reference processor thinks that the g1
>> heap is a single generation spanning the whole heap.
>>
>> By giving the ref processor the correct idea of generations in G1,
>> this
>> automatically works, and obsoletes the "preserve cm referents" phase.
>>
>> To get an understanding how serious this issue may be, on
>> theKitchensink reference stress test program, the "Preserve CM
>> referents"
>> phase may take 105ms out of 115ms.
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8201492
>> Webrev:
>> http://cr.openjdk.java.net/~tschatzl/8201492/webrev/
The change looks good, really nice improvement.

The only thing I can comment on is the introduction of 
SpanReferenceProcessor. I think it would be nicer to just have a single 
ReferenceProcessor that always take a closure for deciding if discovery 
should be done, ie. let the other GCs explicitly create their 
SpanBasedDiscoverer and pass it in.

Cheers,
Stefan

>> Testing:
>> hs-tier1-3, performance verification, lots of Kitchensink reference
>> stress testing runs
>>
>> Thanks,
>>    Thomas
>>
> 


From stefan.karlsson at oracle.com  Fri Apr 27 14:18:06 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 27 Apr 2018 16:18:06 +0200
Subject: RFR: Epsilon GC
In-Reply-To: <7353b73f-c563-d91c-d0e2-22b4548ca010@redhat.com>
References: <7353b73f-c563-d91c-d0e2-22b4548ca010@redhat.com>
Message-ID: <326d0707-6299-a7c2-b217-a68b43a03259@oracle.com>

Hi Aleksey,

On 2018-04-26 19:37, Aleksey Shipilev wrote:
> Hi,
> 
> This is the review thread for Epsilon GC changes.
> 
> JEP, targeted to 11:
>    http://openjdk.java.net/jeps/318
>    (you can find links to binary builds and sandbox locations there)
> 
> Webrev:
>    http://cr.openjdk.java.net/~shade/epsilon/webrev.05/
> 
> Notes:
> 
>    *) See how the whole things is _almost_ drop-in to hotspot/share/gc, without having arch-specific
> mess -- thanks to GC interface work done over last years;

I'm glad to see that we've come so far, and that this gets so well 
contained in the GC directory.

> 
>    *) There are some leftovers due to GC barriers work in progress: templateTable_arm.cpp addition
> goes away after JDK-8201786 [1], c1_LIRGenerator.cpp change should go away after C1 barriers
> modularization is complete, graphKit.cpp change should go away after C2 barriers modularization is
> complete;
> 
>    *) Half of the webrev are Epsilon-specific tests. They take ~30s in release and ~60s in fastdebug
> on my desktop. They are not in tier1, so smoke testing time is not affected;
> 
>    *) UseEpsilonGC is experimental. This should be fine after conditional GC compilation [2], so
> vendors who are unwilling to extend whatever small notion [3] of support comes with experimental VM
> option, may choose not to build it.

I spent the day cleaning up and testing the patches for [2], and will 
send out an RFR on Wednesday (when I'm back to the office). In the mean 
time, I'm dropping the patches here so that you can take a look and 
hopefully adopt your patch. It should be almost trivial to add the 
appropriate INCLUDE_EPSILONGC and EPSILONGC_ONLY macros.

The squashed patch queue for [2]:
http://cr.openjdk.java.net/~stefank/8200729/prototype/webrev.03/all/

Preparation patch to get rid of some unneeded INCLUDE_ALL_GCS:
http://cr.openjdk.java.net/~stefank/8200729/prototype/webrev.03/00.removeUnneededIncludeAllGCs/

Fix some includes required when GCs are conditionally compiled out:
http://cr.openjdk.java.net/~stefank/8200729/prototype/webrev.03/01.fixIncludes/

This is the main patch that adds (and uses) INCLUDE_CMSGC, INCLUDE_G1GC, 
INCLUDE_PARALLELGC, and INCLUDE_SERIALGC:
http://cr.openjdk.java.net/~stefank/8200729/prototype/webrev.03/02.mainPatch/

This is the patch to add the possibility to turn on and off the 
different gc when configuring the build (partly contributed by Ihse):
http://cr.openjdk.java.net/~stefank/8200729/prototype/webrev.03/03.selectIndivudualGCsMakePatch/

Thanks,
StefanK

> 
> Testing: all platform builds, gc/epsilon on x86_64
> 
> Thanks,
> -Aleksey
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8201786
> [2] https://bugs.openjdk.java.net/browse/JDK-8200729
> [3] http://hg.openjdk.java.net/jdk/jdk/file/3661f31c6df4/src/hotspot/share/runtime/globals.hpp#l150
> 


From shade at redhat.com  Fri Apr 27 14:26:24 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 27 Apr 2018 16:26:24 +0200
Subject: RFR: Epsilon GC
In-Reply-To: <326d0707-6299-a7c2-b217-a68b43a03259@oracle.com>
References: <7353b73f-c563-d91c-d0e2-22b4548ca010@redhat.com>
 <326d0707-6299-a7c2-b217-a68b43a03259@oracle.com>
Message-ID: <a79e7b74-5cb7-37f4-71db-bdb18d7a5abd@redhat.com>

On 04/27/2018 04:18 PM, Stefan Karlsson wrote:
>> ?? *) See how the whole things is _almost_ drop-in to hotspot/share/gc, without having arch-specific
>> mess -- thanks to GC interface work done over last years;
> 
> I'm glad to see that we've come so far, and that this gets so well contained in the GC directory.

Yup! Unfortunately there is no early+complete Epsilon patch to compare with. The injection in
arch-specific places was very ugly.


>> ?? *) UseEpsilonGC is experimental. This should be fine after conditional GC compilation [2], so
>> vendors who are unwilling to extend whatever small notion [3] of support comes with experimental VM
>> option, may choose not to build it.
> 
> I spent the day cleaning up and testing the patches for [2], and will send out an RFR on Wednesday
> (when I'm back to the office). In the mean time, I'm dropping the patches here so that you can take
> a look and hopefully adopt your patch. It should be almost trivial to add the appropriate
> INCLUDE_EPSILONGC and EPSILONGC_ONLY macros.

Oh, no rush. I would rebase Epsilon sandbox branch next week anyway, once the remaining bits of GC
interface and various other infra bits like gcConfig land into jdk/jdk. It is easier to work in the
Sandbox, rather than adopting patches ahead of time. Looking forward to adopt these!

I started this first-round RFR to have feedback on the Epsilon code itself.

Thanks,
-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180427/d97f8e04/signature.asc>

From kim.barrett at oracle.com  Fri Apr 27 16:53:51 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 27 Apr 2018 12:53:51 -0400
Subject: RFR: 8202083: Remove explicit CMS checks in CardTableBarrierSet
In-Reply-To: <5AE2E255.90609@oracle.com>
References: <5AD9FE1F.3050702@oracle.com>
 <BD69A740-6C08-4F55-9B6E-97331EEEAB5E@oracle.com> <5AE2E255.90609@oracle.com>
Message-ID: <A8E0BA21-F0FE-4CA4-9E33-544DD348F287@oracle.com>

> On Apr 27, 2018, at 4:41 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
> 
> Hi Kim,
> 
> Now that we reached an agreement on 8202082, may I assume we have reached an agreement here too?

Oh, right.  Yes.  Just needs the comment fix.

> 
> Thanks,
> /Erik
> 
> On 2018-04-23 23:29, Kim Barrett wrote:
>>> On Apr 20, 2018, at 10:50 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> In CardTableBarrierSet, we sometimes need fencing due to the card table being scanned concurrently when using CMS with pre-cleaning. Rather than explicitly checking for those CMS flags in the generic CardTableBarrierSet class, it is preferrable to check the CardTable scanned_concurrently() property which reflects that better
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~eosterlund/8202083/webrev.00/
>>> 
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8202083
>>> 
>>> Thanks,
>>> /Erik
>> Isn't the correct predicate here
>> CardTableBarrierSet::card_mark_must_follow_store?
>> 
>> Also, the comment probably ought to be "generalized".
>> 
>> Also, CardTable::scanned_concurrently() seems misplaced. CardTable is
>> a data structure, scanned_concurrently is a usage policy. And the only
>> use of scanned_concurrently seems to be the implementation of
>> card_mark_must_follow_store. It seems like CardTableBarrierSet would
>> be a better place for that bit of information.




From erik.osterlund at oracle.com  Fri Apr 27 16:57:19 2018
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Fri, 27 Apr 2018 18:57:19 +0200
Subject: RFR: 8202083: Remove explicit CMS checks in CardTableBarrierSet
In-Reply-To: <A8E0BA21-F0FE-4CA4-9E33-544DD348F287@oracle.com>
References: <5AD9FE1F.3050702@oracle.com>
 <BD69A740-6C08-4F55-9B6E-97331EEEAB5E@oracle.com> <5AE2E255.90609@oracle.com>
 <A8E0BA21-F0FE-4CA4-9E33-544DD348F287@oracle.com>
Message-ID: <314253D3-8B04-4E43-9901-37244EC52D93@oracle.com>

Hi Kim,

Thanks for the review.

/Erik

On 27 Apr 2018, at 18:53, Kim Barrett <kim.barrett at oracle.com> wrote:

>> On Apr 27, 2018, at 4:41 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>> 
>> Hi Kim,
>> 
>> Now that we reached an agreement on 8202082, may I assume we have reached an agreement here too?
> 
> Oh, right.  Yes.  Just needs the comment fix.
> 
>> 
>> Thanks,
>> /Erik
>> 
>> On 2018-04-23 23:29, Kim Barrett wrote:
>>>> On Apr 20, 2018, at 10:50 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> In CardTableBarrierSet, we sometimes need fencing due to the card table being scanned concurrently when using CMS with pre-cleaning. Rather than explicitly checking for those CMS flags in the generic CardTableBarrierSet class, it is preferrable to check the CardTable scanned_concurrently() property which reflects that better
>>>> 
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~eosterlund/8202083/webrev.00/
>>>> 
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8202083
>>>> 
>>>> Thanks,
>>>> /Erik
>>> Isn't the correct predicate here
>>> CardTableBarrierSet::card_mark_must_follow_store?
>>> 
>>> Also, the comment probably ought to be "generalized".
>>> 
>>> Also, CardTable::scanned_concurrently() seems misplaced. CardTable is
>>> a data structure, scanned_concurrently is a usage policy. And the only
>>> use of scanned_concurrently seems to be the implementation of
>>> card_mark_must_follow_store. It seems like CardTableBarrierSet would
>>> be a better place for that bit of information.
> 
> 



From kim.barrett at oracle.com  Sat Apr 28 01:23:41 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 27 Apr 2018 21:23:41 -0400
Subject: RFR (M): 8201492: Properly implement non-contiguous generations
 for reference discovery
In-Reply-To: <1524034373.3236.7.camel@oracle.com>
References: <1524034373.3236.7.camel@oracle.com>
Message-ID: <C928B37A-A73C-448A-B8F9-ACAD8F2107CC@oracle.com>

> On Apr 18, 2018, at 2:52 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8201492
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8201492/webrev/
> Testing:
> hs-tier1-3, performance verification, lots of Kitchensink reference
> stress testing runs
> 

StefanJ said:
  The only thing I can comment on is the introduction of
  SpanReferenceProcessor. I think it would be nicer to just have a
  single ReferenceProcessor that always take a closure for deciding if
  discovery should be done, ie. let the other GCs explicitly create
  their SpanBasedDiscoverer and pass it in.

I had the same reaction.  It does provide [set_]span(); is that enough
to make it worthwhile?  Maybe?

If that were changed, it may impact other comments below.

------------------------------------------------------------------------------ 
src/hotspot/share/gc/shared/referenceProcessor.cpp 
 135 SpanReferenceProcessor::SpanReferenceProcessor(MemRegion span,
...
 142   ReferenceProcessor(&_span_based_discoverer,
...
 149   _span_based_discoverer(span) {

Passing a pointer to a member before the member has been constructed
can lead to problems, though I didn't find any issues here.  However,
I've seen compiler warnings at some warning levels for something like
this.  (Obviously not with the levels we're testing with.)

Obviously, this isn't a problem if there isn't a SpanReferenceProcessor.

------------------------------------------------------------------------------ 
src/hotspot/share/gc/shared/referenceProcessor.cpp 
 977 template <class T>
 978 bool ReferenceProcessor::is_subject_to_discovery(T const obj) const {
 979   return _is_subject_to_discovery->do_object_b(obj);
 980 }

I don't understand why this is a template.  T *must* be oop (or at
least convertible to oop), since do_object_b takes an oop argument.

------------------------------------------------------------------------------ 
src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp
  41 inline bool G1CMIsAliveClosure::do_object_b(oop obj) {
  42   if (obj == NULL) {
  43     return false;
  44   }
  45   assert(_g1h->is_in_reserved(obj), "Asked for liveness of oop " PTR_FORMAT " outside of reserved heap.", p2i(obj));
  46   // Young regions have nTAMS == bottom(), i.e. all objects there are implicitly live,
  47   // so we do not need to explicitly check for region type.
  48   bool result = !_g1h->is_obj_ill(obj, _g1h->heap_region_containing(obj));

I think the code in lines 42-48 is equivalent to

  bool result = !_g1h->is_obj_ill(obj);

That is, the one-arg form of is_obj_ill performs the null check, the
is_in_reserved assert (though using is_in_g1_reserved), and the heap
region lookup.

------------------------------------------------------------------------------ 
src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp
  55 inline bool G1CMSubjectToDiscoveryClosure::do_object_b(oop obj) {
  56   if (obj == NULL) {
  57     return false;
  58   }

I haven't checked carefully, but it seems wrong to check for
discoverability of NULL; I would have expected NULL to already have
been filtered out before getting to such a check.  In which case the
check here ought to be an assert != NULL.

Oh, but when the policy is ReferentBasedDiscovery we apply this
closure to the referent, and for a concurrent collector the referent
could have been cleared between the time the referent was determined
to be (potentially) not alive and when this check is made.  That's
pretty subtle, and seems worth a comment.

------------------------------------------------------------------------------




From thomas.schatzl at oracle.com  Sun Apr 29 18:45:06 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Sun, 29 Apr 2018 20:45:06 +0200
Subject: RFR (M): 8201492: Properly implement non-contiguous generations
 for reference discovery
In-Reply-To: <C928B37A-A73C-448A-B8F9-ACAD8F2107CC@oracle.com>
References: <1524034373.3236.7.camel@oracle.com>
 <C928B37A-A73C-448A-B8F9-ACAD8F2107CC@oracle.com>
Message-ID: <1525027506.8231.4.camel@oracle.com>

Hi,

On Fri, 2018-04-27 at 21:23 -0400, Kim Barrett wrote:
> > On Apr 18, 2018, at 2:52 AM, Thomas Schatzl <thomas.schatzl at oracle.
> > com> wrote:
> > 
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8201492
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8201492/webrev/
> > Testing:
> > hs-tier1-3, performance verification, lots of Kitchensink reference
> > stress testing runs
> > 
> 
> StefanJ said:
>   The only thing I can comment on is the introduction of
>   SpanReferenceProcessor. I think it would be nicer to just have a
>   single ReferenceProcessor that always take a closure for deciding
> if
>   discovery should be done, ie. let the other GCs explicitly create
>   their SpanBasedDiscoverer and pass it in.
> 
> I had the same reaction.  It does provide [set_]span(); is that
> enough
> to make it worthwhile?  Maybe?
> 
> If that were changed, it may impact other comments below.

Done.

> 
> -------------------------------------------------------------------
> ----------- 
> src/hotspot/share/gc/shared/referenceProcessor.cpp 
>  135 SpanReferenceProcessor::SpanReferenceProcessor(MemRegion span,
> ...
>  142   ReferenceProcessor(&_span_based_discoverer,
> ...
>  149   _span_based_discoverer(span) {
> 
> Passing a pointer to a member before the member has been constructed
> can lead to problems, though I didn't find any issues here.  However,
> I've seen compiler warnings at some warning levels for something like
> this.  (Obviously not with the levels we're testing with.)
> 
> Obviously, this isn't a problem if there isn't a
> SpanReferenceProcessor.
> 
> -------------------------------------------------------------------
> ----------- 
> src/hotspot/share/gc/shared/referenceProcessor.cpp 
>  977 template <class T>
>  978 bool ReferenceProcessor::is_subject_to_discovery(T const obj)
> const {
>  979   return _is_subject_to_discovery->do_object_b(obj);
>  980 }
> 
> I don't understand why this is a template.  T *must* be oop (or at
> least convertible to oop), since do_object_b takes an oop argument.

Fixed.

> 
> -------------------------------------------------------------------
> ----------- 
> src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp
>   41 inline bool G1CMIsAliveClosure::do_object_b(oop obj) {
>   42   if (obj == NULL) {
>   43     return false;
>   44   }
>   45   assert(_g1h->is_in_reserved(obj), "Asked for liveness of oop "
> PTR_FORMAT " outside of reserved heap.", p2i(obj));
>   46   // Young regions have nTAMS == bottom(), i.e. all objects
> there are implicitly live,
>   47   // so we do not need to explicitly check for region type.
>   48   bool result = !_g1h->is_obj_ill(obj, _g1h-
> >heap_region_containing(obj));
> 
> I think the code in lines 42-48 is equivalent to
> 
>   bool result = !_g1h->is_obj_ill(obj);
> 

It is. However the assert error message would not be that descriptive
(imho). I changed it to the suggested 

  42   return !_g1h->is_obj_ill(obj);

though.

> -------------------------------------------------------------------
> ----------- 
> src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp
>   55 inline bool G1CMSubjectToDiscoveryClosure::do_object_b(oop obj)
> {
>   56   if (obj == NULL) {
>   57     return false;
>   58   }
> 
> I haven't checked carefully, but it seems wrong to check for
> discoverability of NULL; I would have expected NULL to already have
> been filtered out before getting to such a check.  In which case the
> check here ought to be an assert != NULL.
> 
> Oh, but when the policy is ReferentBasedDiscovery we apply this
> closure to the referent, and for a concurrent collector the referent
> could have been cleared between the time the referent was determined
> to be (potentially) not alive and when this check is made.  That's
> pretty subtle, and seems worth a comment.

Added.

Webrevs
http://cr.openjdk.java.net/~tschatzl/8201492/webrev.1 (full)
http://cr.openjdk.java.net/~tschatzl/8201492/webrev.0_to_1 (diff)

I pushed the changes through hs-tier1-3 again.

Note that the diff webrev is not very helpful in this case.

Thanks,
  Thomas



From thomas.schatzl at oracle.com  Sun Apr 29 19:39:54 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Sun, 29 Apr 2018 21:39:54 +0200
Subject: RFR (M): 8201492: Properly implement non-contiguous generations
 for reference discovery
In-Reply-To: <1525027506.8231.4.camel@oracle.com>
References: <1524034373.3236.7.camel@oracle.com>
 <C928B37A-A73C-448A-B8F9-ACAD8F2107CC@oracle.com>
 <1525027506.8231.4.camel@oracle.com>
Message-ID: <1525030794.8231.9.camel@oracle.com>

On Sun, 2018-04-29 at 20:45 +0200, Thomas Schatzl wrote:
> Hi,
> 
> On Fri, 2018-04-27 at 21:23 -0400, Kim Barrett wrote:
> > > On Apr 18, 2018, at 2:52 AM, Thomas Schatzl <thomas.schatzl at oracl
> > > e.
> > > com> wrote:
> > > 
> > > 
[...]
> Webrevs
> http://cr.openjdk.java.net/~tschatzl/8201492/webrev.1 (full)
> http://cr.openjdk.java.net/~tschatzl/8201492/webrev.0_to_1 (diff)
> 
> I pushed the changes through hs-tier1-3 again.

  for clarification, I already removed the "SpanReferenceProcessor" on
Friday after Stefan's comments, and this is what has been tested in
that run.

The other changes seem to be trivial enough - I did some 30min
kitchensink reference stress run just to check.

Thanks,
  Thomas



From per.liden at oracle.com  Mon Apr 30 05:45:23 2018
From: per.liden at oracle.com (Per Liden)
Date: Mon, 30 Apr 2018 07:45:23 +0200
Subject: RFC: JEP - ZGC: A Scalable Low-Latency Garbage Gollector
Message-ID: <1e8bc4fc-a963-020c-bf1f-da17533990c1@oracle.com>

Hi,

We're looking at submitting the ZGC JEP to become Candidate. But first 
we'd like to solicit feedback.

http://openjdk.java.net/jeps/8197831

thanks,
Per


From stefan.johansson at oracle.com  Mon Apr 30 08:44:01 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Mon, 30 Apr 2018 10:44:01 +0200
Subject: RFR (M): 8201492: Properly implement non-contiguous generations
 for reference discovery
In-Reply-To: <1525030794.8231.9.camel@oracle.com>
References: <1524034373.3236.7.camel@oracle.com>
 <C928B37A-A73C-448A-B8F9-ACAD8F2107CC@oracle.com>
 <1525027506.8231.4.camel@oracle.com> <1525030794.8231.9.camel@oracle.com>
Message-ID: <cd8784d2-4325-7511-2333-7ca5df3c83a2@oracle.com>



On 2018-04-29 21:39, Thomas Schatzl wrote:
> On Sun, 2018-04-29 at 20:45 +0200, Thomas Schatzl wrote:
>> Hi,
>>
>> On Fri, 2018-04-27 at 21:23 -0400, Kim Barrett wrote:
>>>> On Apr 18, 2018, at 2:52 AM, Thomas Schatzl <thomas.schatzl at oracl
>>>> e.
>>>> com> wrote:
>>>>
>>>>
> [...]
>> Webrevs
>> http://cr.openjdk.java.net/~tschatzl/8201492/webrev.1 (full)
>> http://cr.openjdk.java.net/~tschatzl/8201492/webrev.0_to_1 (diff)
Looks good,
StefanJ

>>
>> I pushed the changes through hs-tier1-3 again.
> 
>    for clarification, I already removed the "SpanReferenceProcessor" on
> Friday after Stefan's comments, and this is what has been tested in
> that run.
> 
> The other changes seem to be trivial enough - I did some 30min
> kitchensink reference stress run just to check.
> 
> Thanks,
>    Thomas
> 


From kim.barrett at oracle.com  Mon Apr 30 14:12:14 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 30 Apr 2018 10:12:14 -0400
Subject: RFR (M): 8201492: Properly implement non-contiguous generations
 for reference discovery
In-Reply-To: <1525027506.8231.4.camel@oracle.com>
References: <1524034373.3236.7.camel@oracle.com>
 <C928B37A-A73C-448A-B8F9-ACAD8F2107CC@oracle.com>
 <1525027506.8231.4.camel@oracle.com>
Message-ID: <024C3D6A-C0B3-4B01-862F-59D391380EAC@oracle.com>

> On Apr 29, 2018, at 2:45 PM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> Webrevs
> http://cr.openjdk.java.net/~tschatzl/8201492/webrev.1 (full)
> http://cr.openjdk.java.net/~tschatzl/8201492/webrev.0_to_1 (diff)
> 
> I pushed the changes through hs-tier1-3 again.
> 
> Note that the diff webrev is not very helpful in this case.
> 
> Thanks,
>  Thomas

------------------------------------------------------------------------------
The member name _span_discoverer, used by several of the collectors,
might be confusing; it's not discovering spans.  I'm not sure what a
better name might be though.  _span_based_discoverer?

------------------------------------------------------------------------------ 
src/hotspot/share/gc/g1/g1FullCollector.hpp
  47 class G1FullGCSubjectToDiscoveryClosure: public BoolObjectClosure {
  48 public:
  49   bool do_object_b(oop p) {
  50     return (p != NULL);
  51   }
  52 };

I think no null check is needed here, and that p could instead be
asserted to be non-NULL, because Full-GC is discovery_is_atomic.  This
is similar to the young/mixed gc case
(G!STWSubjectToDiscoveryClosure), and different from the cm case.
That would better match the _always_subject_to_discovery name too.

------------------------------------------------------------------------------ 
src/hotspot/share/gc/shared/referenceProcessor.hpp
 489   ReferenceProcessorSpanMutator(ReferenceProcessor* rp,
 490                                 MemRegion span):
 491     _rp(rp), _discoverer(span) {
 492     _old_discoverer = rp->is_subject_to_discovery_closure();
 493     rp->set_is_subject_to_discovery_closure(&_discoverer);
 494   }

Why is _old_discoverer initialized in the body rather than the
initializer list.

Also, formatting makes it hard to spot where the initializer list ends
and the body begins.

------------------------------------------------------------------------------



From serguei.spitsyn at oracle.com  Mon Apr 30 18:28:04 2018
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 30 Apr 2018 11:28:04 -0700
Subject: JDK-8171119: Low-Overhead Heap Profiling
In-Reply-To: <CAF9BGBzveRjutxXEq72g5XnP9FOx35JZ_UOQ0XhTwxD-vk+EXw@mail.gmail.com>
References: <CAF9BGByAVNOPrvm7bWVp7pT859+zyfL7ogjzwoPT+7w5AVxD8A@mail.gmail.com>
 <CAF9BGBxmYDOgECEqTNOzpOsnrfrsEO2Ja1YNZJhVdDZb2YP=kA@mail.gmail.com>
 <E090AED1-DBBD-45C4-A8C9-74AAFF996CCA@oracle.com>
 <CAF9BGBzJU=+tDhexvqXm2zdis5jT_j1qTtDegs_WLsshwCug8Q@mail.gmail.com>
 <CAF9BGBy7Ak8R4aimOT+DboMTpCnQOzXJrRGTiQx_ri-80qT+yQ@mail.gmail.com>
 <0A5AD1F8-EBDD-47EA-9741-1AE6B1B3971A@oracle.com>
 <CAF9BGBweUg21jXk88Rs-kNpuuqkNggAUZ69jddi2mFvbQ_Lv3Q@mail.gmail.com>
 <B625BFFA-62EF-4105-AE50-4C4C364A26DA@oracle.com>
 <CAF9BGBxF7fsScHq8vK2iW10TP39JTE=4DnyJjw=uTW5qwPZ1yQ@mail.gmail.com>
 <CAPYFHW1833a7QkQmXbaf5L7Pk5E0Cr9VPbR=JUOQiZTW246K6w@mail.gmail.com>
 <38fabdf2-2627-fbff-d3c1-561799e0e795@oracle.com>
 <CAPYFHW1gzj4OtPHFE1Sh3V0H1o41=p77f1dN1HHkj0cQ0mH=Ng@mail.gmail.com>
 <CAF9BGByuULxk8hyoxGjduiCV6Cc_MjYXY_RQ6Zxy3dXhbMWkQg@mail.gmail.com>
 <CAF9BGBw=-xXT_HdCOtZF33paCL+N3GcrYpNwvjDSV+PO=1voJg@mail.gmail.com>
 <CAF9BGBzveRjutxXEq72g5XnP9FOx35JZ_UOQ0XhTwxD-vk+EXw@mail.gmail.com>
Message-ID: <7d66cf99-a213-c587-4082-361e370137b4@oracle.com>

Added gc-hotspot-dev.

Are there any memory allocation benchmarks that we could run to make 
sure performance is Okay?

Thanks,
Serguei


On 4/30/18 11:19, JC Beyler wrote:
> Hi all,
>
> Did anybody have some time to look at this? Any insight would be
> appreciated!
>
> Thanks!
> Jc
>
> On Thu, Apr 26, 2018 at 3:40 PM JC Beyler <jcbeyler at google.com> wrote:
>
>> Hi all,
>>
>> Sorry for the double post but I was suggested to send this to the
>> runtime-dev mailing list but force of habit made me send it to
>> serviceability first.
>>
>> If anyone on the runtime-dev could look at this, it would be
>> greatly appreciated.
>>
>> Background:
>>    - I am trying to add a sampling system that samples allocations and some
>> allocation points need to protect oops that are on the stack
>>    - What would be the best way and not risk adding any overhead?
>>    - One way was adding Handles like what is done below, what is the
>> runtime-dev mailing list's opinion on this?
>>
>> Thanks for your help!
>> Jc
>>
>> On Thu, Apr 26, 2018 at 11:02 AM JC Beyler <jcbeyler at google.com> wrote:
>>
>>> Hi all,
>>>
>>> A question came up between myself and Serguei about how to protect the
>>> newly allocated oop when the collector does the callback. We decided it
>>> might be best to ask the mailing list for help/guidance/opinion?
>>>
>>>   Consider the changes done in this file for example:
>>>
>>> http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.16/src/hotspot/share/gc/shared/collectedHeap.inline.hpp.udiff.html
>>>
>>> For example, for obj_allocate, the change becomes:
>>>   oop CollectedHeap::obj_allocate(Klass* klass, int size, TRAPS) {
>>>     debug_only(check_for_valid_allocation_state());
>>>     assert(!Universe::heap()->is_gc_active(), "Allocation during gc not
>>> allowed");
>>>     assert(size >= 0, "int won't convert to size_t");
>>> +
>>> +  HandleMark hm(THREAD);
>>> +  Handle result;
>>> +  {
>>> +    JvmtiSampledObjectAllocEventCollector collector;
>>>     HeapWord* obj = common_mem_allocate_init(klass, size, CHECK_NULL);
>>>     post_allocation_setup_obj(klass, obj, size);
>>>     NOT_PRODUCT(Universe::heap()->check_for_bad_heap_word_value(obj,
>>> size));
>>> -  return (oop)obj;
>>> +    result = Handle(THREAD, (oop) obj);
>>> +  }
>>> +  return result();
>>>   }
>>>
>>> The question is: does anyone see an issue here in terms of performance or
>>> something we missed? When I measured it via the Dacapo run, I saw no
>>> performance degradation but I wanted to double check with you all if this
>>> would become a big no no for the final webrev?
>>>
>>> Were other benchmarks show that there is no overhead incurred, would this
>>> be ok?
>>>
>>> Thanks for your help,
>>> Jc
>>>
>>
>>
>>
>>