From kirk at kodewerk.com  Fri Aug  1 11:32:36 2014
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Fri, 1 Aug 2014 13:32:36 +0200
Subject: interesting log entries
Message-ID: <24EF0F15-44D6-4D2A-A8EF-5BE0333C8AA1@kodewerk.com>

Hi,

I?ve run into this in a 1.7.0_40 with G1GC, with -XX:+PrintGCDetails, -XX:+PrintApplicationStoppedTime -XX:+PrintTenuringDistribution and it?s using the rolling logs feature.

The log is riddled with all kinds of different variants of date going backwards and time stamp going forward for backwards. My guess is NTP is involved here but there must also be some bug in the logging to allow things to travel in different directions and/or at different rates.

Regards,
Kirk

2014-06-16T01:41:02.478+0200: 7324.015: Total time for which application threads were stopped: 0.0009980 seconds
2014-06-16T01:41:02.479+0200: 7324.016: Application time: 0.0008090 seconds
2014-06-16T01:41:02.479+0200: 7324.016: Total time for which a1:40:22.957+0200: 7407.019: Application time: 0.0001020 seconds
2014-06-16T01:40:22.958+0200: 7407.020: Total time for which application threads were stopped: 0.0012800 seconds


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

From ysr1729 at gmail.com  Fri Aug  1 17:03:09 2014
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Fri, 1 Aug 2014 10:03:09 -0700
Subject: interesting log entries
In-Reply-To: <24EF0F15-44D6-4D2A-A8EF-5BE0333C8AA1@kodewerk.com>
References: <24EF0F15-44D6-4D2A-A8EF-5BE0333C8AA1@kodewerk.com>
Message-ID: <CABzyjynrsGgJts+CE+6Zdsd=+=XOQyO5ASQ3K=5jyNqqe8WfNQ@mail.gmail.com>

Hi Kirk,

Use the "jvm age" timestamp. That seems to be monotonically increasing, and
doesn't present the issues with the date-stamp on account of NTP etc.

-- ramki


On Fri, Aug 1, 2014 at 4:32 AM, Kirk Pepperdine <kirk at kodewerk.com> wrote:

> Hi,
>
> I?ve run into this in a 1.7.0_40 with G1GC, with -XX:+PrintGCDetails,
> -XX:+PrintApplicationStoppedTime -XX:+PrintTenuringDistribution and it?s
> using the rolling logs feature.
>
> The log is riddled with all kinds of different variants of date going
> backwards and time stamp going forward for backwards. My guess is NTP is
> involved here but there must also be some bug in the logging to allow
> things to travel in different directions and/or at different rates.
>
> Regards,
> Kirk
>
> 2014-06-16T01:41:02.478+0200: 7324.015: Total time for which application
> threads were stopped: 0.0009980 seconds
> 2014-06-16T01:41:02.479+0200: 7324.016: Application time: 0.0008090 seconds
> 2014-06-16T01:41:02.479+0200: 7324.016: Total time for which
> a1:40:22.957+0200: 7407.019: Application time: 0.0001020 seconds
> 2014-06-16T01:40:22.958+0200: 7407.020: Total time for which application
> threads were stopped: 0.0012800 seconds
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140801/25fa874b/attachment.htm>

From kirk at kodewerk.com  Fri Aug  1 18:12:24 2014
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Fri, 1 Aug 2014 20:12:24 +0200
Subject: interesting log entries
In-Reply-To: <CABzyjynrsGgJts+CE+6Zdsd=+=XOQyO5ASQ3K=5jyNqqe8WfNQ@mail.gmail.com>
References: <24EF0F15-44D6-4D2A-A8EF-5BE0333C8AA1@kodewerk.com>
	<CABzyjynrsGgJts+CE+6Zdsd=+=XOQyO5ASQ3K=5jyNqqe8WfNQ@mail.gmail.com>
Message-ID: <6E666261-37D3-4294-8499-0BA3E8E3B54B@kodewerk.com>

Hi Ramki,

I can send you examples of the age timestamp going backwards also ;-).

Regards,
Kirk

On Aug 1, 2014, at 7:03 PM, Srinivas Ramakrishna <ysr1729 at gmail.com> wrote:

> Hi Kirk,
> 
> Use the "jvm age" timestamp. That seems to be monotonically increasing, and doesn't present the issues with the date-stamp on account of NTP etc.
> 
> -- ramki
> 
> 
> On Fri, Aug 1, 2014 at 4:32 AM, Kirk Pepperdine <kirk at kodewerk.com> wrote:
> Hi,
> 
> I?ve run into this in a 1.7.0_40 with G1GC, with -XX:+PrintGCDetails, -XX:+PrintApplicationStoppedTime -XX:+PrintTenuringDistribution and it?s using the rolling logs feature.
> 
> The log is riddled with all kinds of different variants of date going backwards and time stamp going forward for backwards. My guess is NTP is involved here but there must also be some bug in the logging to allow things to travel in different directions and/or at different rates.
> 
> Regards,
> Kirk
> 
> 2014-06-16T01:41:02.478+0200: 7324.015: Total time for which application threads were stopped: 0.0009980 seconds
> 2014-06-16T01:41:02.479+0200: 7324.016: Application time: 0.0008090 seconds
> 2014-06-16T01:41:02.479+0200: 7324.016: Total time for which a1:40:22.957+0200: 7407.019: Application time: 0.0001020 seconds
> 2014-06-16T01:40:22.958+0200: 7407.020: Total time for which application threads were stopped: 0.0012800 seconds
> 
> 
> 

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

From ysr1729 at gmail.com  Fri Aug  1 19:07:53 2014
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Fri, 1 Aug 2014 12:07:53 -0700
Subject: interesting log entries
In-Reply-To: <6E666261-37D3-4294-8499-0BA3E8E3B54B@kodewerk.com>
References: <24EF0F15-44D6-4D2A-A8EF-5BE0333C8AA1@kodewerk.com>
	<CABzyjynrsGgJts+CE+6Zdsd=+=XOQyO5ASQ3K=5jyNqqe8WfNQ@mail.gmail.com>
	<6E666261-37D3-4294-8499-0BA3E8E3B54B@kodewerk.com>
Message-ID: <CABzyjyn5btKqhQx2yzhHQ5wiDQK1CD8DPd4qnUFy7B_WiQ6QDg@mail.gmail.com>

ok. Please make sure to include platform info.

thanks.
-- ramki


On Fri, Aug 1, 2014 at 11:12 AM, Kirk Pepperdine <kirk at kodewerk.com> wrote:

> Hi Ramki,
>
> I can send you examples of the age timestamp going backwards also ;-).
>
> Regards,
> Kirk
>
> On Aug 1, 2014, at 7:03 PM, Srinivas Ramakrishna <ysr1729 at gmail.com>
> wrote:
>
> Hi Kirk,
>
> Use the "jvm age" timestamp. That seems to be monotonically increasing,
> and doesn't present the issues with the date-stamp on account of NTP etc.
>
> -- ramki
>
>
> On Fri, Aug 1, 2014 at 4:32 AM, Kirk Pepperdine <kirk at kodewerk.com> wrote:
>
>> Hi,
>>
>> I?ve run into this in a 1.7.0_40 with G1GC, with -XX:+PrintGCDetails,
>> -XX:+PrintApplicationStoppedTime -XX:+PrintTenuringDistribution and it?s
>> using the rolling logs feature.
>>
>> The log is riddled with all kinds of different variants of date going
>> backwards and time stamp going forward for backwards. My guess is NTP is
>> involved here but there must also be some bug in the logging to allow
>> things to travel in different directions and/or at different rates.
>>
>> Regards,
>> Kirk
>>
>> 2014-06-16T01:41:02.478+0200: 7324.015: Total time for which application
>> threads were stopped: 0.0009980 seconds
>> 2014-06-16T01:41:02.479+0200: 7324.016: Application time: 0.0008090
>> seconds
>> 2014-06-16T01:41:02.479+0200: 7324.016: Total time for which
>> a1:40:22.957+0200: 7407.019: Application time: 0.0001020 seconds
>> 2014-06-16T01:40:22.958+0200: 7407.020: Total time for which application
>> threads were stopped: 0.0012800 seconds
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140801/a78866db/attachment.htm>

From bengt.rutisson at oracle.com  Mon Aug  4 08:02:59 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 04 Aug 2014 10:02:59 +0200
Subject: RFR (S): 8051973: Eager reclaim leaves marks of marked but
	reclaimed objects on the next bitmap
In-Reply-To: <1406719767.2707.2.camel@cirrus>
References: <1406630412.2620.22.camel@cirrus> <53D80918.7070904@oracle.com>
	<1406719767.2707.2.camel@cirrus>
Message-ID: <53DF3E33.8000001@oracle.com>


Hi Thomas,

Looks good.

One minor question about this code:


6609     // Need to clear mark bit of the humongous object if already set.
6610     if (next_bitmap->isMarked(r->bottom())) {
6611       next_bitmap->clear(r->bottom());
6612     }

Is it worth checking if the bit is marked or should we just 
unconditionally clear it?

Thanks,
Bengt


On 2014-07-30 13:29, Thomas Schatzl wrote:
> Hi Jon,
>
>    thanks for the review.
>
> On Tue, 2014-07-29 at 13:50 -0700, Jon Masamitsu wrote:
>> On 7/29/2014 3:40 AM, Thomas Schatzl wrote:
>>> Hi all,
>>>
>>>     can I have reviews for the following small change?
>>>
>>> JDK-8027959 implemented eager reclaim of humongous objects, which
>>> potentially left stray set marks on the mark bitmap after reclaiming a
>>> region.
>>>
>>> This change fixes this.
>>>
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8051973
>>> Webrev:
>>> http://cr.openjdk.java.net/~tschatzl/8051973/webrev/
>> The changes look good.
>>
>> You left the uses  r->bottom() so you would not
>> have to cast obj to HeapWord*?
> Yes. If you have objections to that I can change that back. The code is
> easier to read for me if there is not that much casting.
>
>> Do you want to specify a region size in the test?  Current
>> policy would have  regions sizes such that
>>
>>     48     public static final int M = 1024*1024;
>>
>> gives you humongous allocations but policy could change, yes?
> Done.
>
> See
> http://cr.openjdk.java.net/~tschatzl/8051973/webrev.0_to_1
> Full webrev:
> http://cr.openjdk.java.net/~tschatzl/8051973/webrev.1
>
> Thomas
>
>



From bengt.rutisson at oracle.com  Mon Aug  4 08:42:11 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 04 Aug 2014 10:42:11 +0200
Subject: Request for review (s) - 8031323: Optionally align objects copied
	to survivor spaces
In-Reply-To: <53D87415.1040902@oracle.com>
References: <53267CBB.9020804@oracle.com>	<53284A7E.9060106@oracle.com>	<5363D517.80200@oracle.com>	<53677B60.6030709@oracle.com>
	<53737A80.8070704@oracle.com>	<53738DFA.6090603@oracle.com>
	<53D87415.1040902@oracle.com>
Message-ID: <53DF4763.6010104@oracle.com>


Hi Jon,

Looks good to me.

Bengt


On 2014-07-30 06:27, Jon Masamitsu wrote:
> Bengt and Thomas,
>
> I updated with the latest hs-gc and had to do some merging by
> hand.  The part of the change that merged cleanly is here.
>
> http://cr.openjdk.java.net/~jmasa/8031323/webrev_merge.03/
>
> The changes I merged by hand are
>
> http://cr.openjdk.java.net/~jmasa/8031323/webrev_delta.03/
>
> The complete change is
>
> http://cr.openjdk.java.net/~jmasa/8031323/webrev.03/
>
> I moved the file parGCAllocBuffer.inline.hpp to
>
> src/share/vm/gc_implementation/shared/parGCAllocBuffer.inline.hpp
>
> from  src/share/vm/memory
>
> I compared the webrev.02 with these and believe these are
> consistent with the webrev.02.  I re-tested and there were no
> surprises.
>
> Jon
>
> On 5/14/2014 8:38 AM, Bengt Rutisson wrote:
>>
>> Hi Jon,
>>
>> Thanks for fixing all of this!
>>
>> Looks good. Reviewed.
>>
>> Bengt
>>
>> On 5/14/14 4:15 PM, Jon Masamitsu wrote:
>>> Bengt,
>>>
>>> Thanks for looking at this.  Responses in-line.
>>>
>>> On 5/5/2014 4:52 AM, Bengt Rutisson wrote:
>>>>
>>>> Hi Jon,
>>>>
>>>> On 2014-05-02 19:25, Jon Masamitsu wrote:
>>>>> New webrev with problems addressed except as noted below.
>>>>>
>>>>> http://cr.openjdk.java.net/~jmasa/8031323/webrev.01/
>>>>
>>>>
>>>> To make it compile I had to remove the inline keyword from the 
>>>> declaration of CollectedHeap::align_allocation_or_fail():
>>>>
>>>> diff --git a/src/share/vm/gc_interface/collectedHeap.hpp 
>>>> b/src/share/vm/gc_interface/collectedHeap.hpp
>>>> --- a/src/share/vm/gc_interface/collectedHeap.hpp
>>>> +++ b/src/share/vm/gc_interface/collectedHeap.hpp
>>>> @@ -353,7 +353,7 @@
>>>>
>>>>    // Return the address "addr" aligned by "alignment_in_bytes" if 
>>>> such
>>>>    // an address is below "end".  Return NULL otherwise.
>>>> -  inline static HeapWord* align_allocation_or_fail(HeapWord* addr,
>>>> +  static HeapWord* align_allocation_or_fail(HeapWord* addr,
>>>> HeapWord* end,
>>>>                                                     unsigned short 
>>>> alignment_in_bytes);
>>>>
>>>>
>>>> The includes for the usages of 
>>>> CollectedHeap::align_allocation_or_fail() need to be updated.
>>>>
>>>> space.cpp should include collectedHeap.inline.hpp.
>>>>
>>>> psPromotionLAB.hpp is using 
>>>> CollectedHeap::align_allocation_or_fail() and thus would need the 
>>>> include too, but we should not include inline files from hpp files, 
>>>> so you need to move PSYoungPromotionLAB::allocate() into 
>>>> psPromotionLAB.inline.hpp and have that include 
>>>> collectedHeap.inline.hpp.
>>>>
>>>> Similarly parGCAllocBuffer.hpp would need the include too since 
>>>> ParGCAllocBuffer::allocate_aligned() uses 
>>>> CollectedHeap::align_allocation_or_fail(). But again we should not 
>>>> include inline files in hpp files so 
>>>> ParGCAllocBuffer::allocate_aligned() should probably be moved in to 
>>>> the cpp file. Or, if we are worried about performance regressions 
>>>> we need to introduce a parGCAllocBuffer.inline.hpp file and move it 
>>>> there.
>>>>
>>> Now compiles with and without USE_PRECOMPILED_HEADER=0.  I left the
>>> inline methods as inline.
>>>
>>>>
>>>>
>>>> In CollectedHeap::align_allocation_or_fail(), I think we can 
>>>> replace this:
>>>>
>>>>   if(new_addr > addr && new_addr < end) {
>>>>
>>>> with:
>>>>
>>>>   assert(new_addr > addr, "some good err_msg");
>>>>   if(new_addr < end) {
>>>>
>>>>
>>>
>>> Fixed.
>>>
>>>>
>>>> In ContiguousSpace::allocate_aligned() I think we can make the 
>>>> assert for the alignment of obj a bit stronger. Now we do:
>>>>
>>>> assert(is_aligned(obj) && is_aligned(new_top), "checking alignment");
>>>>
>>>> But we have just gone through some trouble to make sure that obj is 
>>>> aligned to SurvivorAlignmentInBytes, so I think we should assert 
>>>> that rather than just the 8 byte alignment that Space::is_aligned() 
>>>> gives us.
>>>>
>>>
>>> Fixed.
>>>
>>>>
>>>> PSYoungPromotionLAB::allocate() and 
>>>> ContiguousSpace::allocate_aligned() is part of the code duplication 
>>>> that you plan on fixing with JDK-8042321. I'm fine with fixing that 
>>>> in a separate change, but it would be nice if we can make these 
>>>> methods look more similar. Right now they use different return 
>>>> patterns.
>>>>
>>>> PSYoungPromotionLAB::allocate() uses:
>>>>
>>>> if (allocation worked) {
>>>>   return obj;
>>>> }
>>>> ...
>>>> return NULL;
>>>>
>>>> But ContiguousSpace::allocate_aligned() uses an else statement:
>>>>
>>>> if (allocation worked) {
>>>>   return obj;
>>>> } else {
>>>>   ...
>>>>   return NULL;
>>>> }
>>>>
>>> Fixed.  Both have an else clause.
>>>
>>>> Similarly to the comment about the assert in 
>>>> ContiguousSpace::allocate_aligned() I think the assert in 
>>>> PSYoungPromotionLAB::allocate() can be strengthened to assert that 
>>>> obj is SurvivorAlignmentInBytes aligned.
>>>>
>>>
>>> Fixed.
>>>
>>>>
>>>> A minor thing about oop.pcgc.inline.hpp
>>>>
>>>> -// Used by parallel old GC.
>>>> +// forward_to_atomic() is used by parallel old and G1 GCs.
>>>>
>>>> You updated this comment to include G1, but the method is actually 
>>>> also used by ParNew (see 
>>>> ParNewGeneration::copy_to_survivor_space_avoiding_promotion_undo()) 
>>>> and I don't find any usages in ParallelOld. I would suggest to just 
>>>> get rid of the comment. It is not important to have a comment 
>>>> saying who uses it.
>>>>
>>>>
>>> Deleted comment.
>>>
>>>>
>>>> Another very minor thing. The extra line feed added around line 
>>>> 1200 in parNewGeneration.cpp does not seem related to this change:
>>>
>>> I think the extra blank line was in the original.  I added it back.
>>>
>>>>
>>>> http://cr.openjdk.java.net/~jmasa/8031323/webrev.01/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp.cdiff.html 
>>>>
>>>>
>>>>
>>>> Testing. There are tests for this feature coming, right? What kind 
>>>> of testing have you done so far on the current patch?
>>>
>>> I added diagnostics to count the number of allocations that were 
>>> aligned
>>> to 64 bytes.  Then ran with different values of 
>>> SurvivorAlignmentInBytes.
>>> In particular 8 bytes and 64 bytes.   I printed the fraction of 
>>> survivor allocations
>>> and promoted allocations that were aligned and not aligned after 
>>> each collection.
>>> I looked at the output such as (for 8byte alignment)
>>>
>>> Promoted addresses aligned 462 missed 3178 p_fraction 0.126923
>>> Survivor addresses aligned 933 missed 6050 ss_fraction 0.133610
>>>
>>> and (for 64 byte alignment)
>>>
>>> Promoted addresses aligned 471 missed 3168 p_fraction 0.129431
>>> Survivor addresses aligned 7107 missed 0 ss_fraction  1.000000
>>>
>>> to see if it was as I expected it to be.
>>>
>>> The webrev with the changes are at
>>>
>>> http://cr.openjdk.java.net/~jmasa/8031323/webrev_delta.02/
>>>
>>> The webrev shows the changes but also contains (if you look at other
>>> than just the changes), the diagnostic printing code I described above.
>>> You can ignore that since it is not in the complete webrev.
>>>
>>> The complete webrev is at
>>>
>>> http://cr.openjdk.java.net/~jmasa/8031323/webrev.02/
>>>
>>> Thanks again.
>>>
>>> Jon
>>>
>>>
>>>
>>>>
>>>> Thanks,
>>>> Bengt
>>>>
>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>> On 03/18/2014 06:30 AM, Bengt Rutisson wrote:
>>>>>>
>>>>>> Hi Jon,
>>>>>>
>>>>>> On 2014-03-17 05:40, Jon Masamitsu wrote:
>>>>>>> 8031323: Optionally align objects copied to survivor spaces
>>>>>>>
>>>>>>> Add the option to specify an alignment for allocations into the
>>>>>>> survivor spaces.  Survivor space allocations will overflow if the
>>>>>>> survivor spaces have not been increased.   The expected use
>>>>>>> is to align survivor space allocations to cache line sizes.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jmasa/8031323/webrev.00/
>>>>>>
>>>>>> For G1 it looks to me like we are aligning objects in the old 
>>>>>> regions as well. I thought the intent was to only align in the 
>>>>>> survivor regions. Am I missing something?
>>>>>
>>>>> Yes, that was an error.   Fixed in the new webrev.
>>>>>
>>>>>>
>>>>>> Note that it is not enough to check the alloc purpose for G1 
>>>>>> since G1CollectedHeap::par_allocate_during_gc() only takes the 
>>>>>> purpose as a hint and may still return buffers from other regions 
>>>>>> than expected for a purpose. But I guess that in this case it is 
>>>>>> not too important to get it exactly right, so it may be enough to 
>>>>>> check the alloc purpose value.
>>>>>
>>>>> I did use the purpose and there are cases where alignments in the 
>>>>> survivor spaces
>>>>> can be missed.   I think the number missed is a very small 
>>>>> percentage of the total
>>>>> so I'm going to let those slip by.  I thought that preferable to 
>>>>> the more extensive
>>>>> coding changes it would take to catch them.
>>>>>>
>>>>>>
>>>>>> The code in PSYoungPromotionLAB::allcoate(), 
>>>>>> ParGCAllocBuffer::allocate_aligned() and 
>>>>>> ContiguousSpace::allocate_aligned() is very similar. Is there a 
>>>>>> way to consolidate these methods?
>>>>>>
>>>>> I looked at this but did not come up with a suitable way to fix 
>>>>> it. I've opened
>>>>> CR to track the issue.
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8042321
>>>>>
>>>>>
>>>>>>
>>>>>> The code in CollectedHeap::align_allocation_or_fail() looks quite 
>>>>>> different from other places in the code base where we do padding. 
>>>>>> What do you think about doing something like this instead?
>>>>>>
>>>>>> inline HeapWord* 
>>>>>> CollectedHeap::align_allocation_or_fail(HeapWord* addr, HeapWord* 
>>>>>> end, unsigned short alignment_in_bytes) {
>>>>>>   if (alignment_in_bytes <= ObjectAlignmentInBytes) {
>>>>>>     return addr;
>>>>>>   }
>>>>>>
>>>>>>   assert(is_ptr_aligned(addr, HeapWordSize), "");
>>>>>>   assert(is_size_aligned(alignment_in_bytes, HeapWordSize), "");
>>>>>>
>>>>>>   HeapWord* new_addr = (HeapWord*) align_pointer_up(addr, 
>>>>>> alignment_in_bytes);
>>>>>>   size_t padding = pointer_delta(new_addr, addr);
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8042321
>>>>>>   if (padding == 0) {
>>>>>>     return addr;
>>>>>>   }
>>>>>>
>>>>>>   if (padding < CollectedHeap::min_fill_size()) {
>>>>>>     padding += alignment_in_bytes / HeapWordSize;
>>>>>>     assert(padding >= CollectedHeap::min_fill_size(), "");
>>>>>>     new_addr = addr + padding;
>>>>>>   }
>>>>>>
>>>>>>   if(new_addr > addr && new_addr < end) {
>>>>>>     CollectedHeap::fill_with_object(addr, padding);
>>>>>>     return new_addr;
>>>>>>   } else {
>>>>>>     return NULL;
>>>>>>   }
>>>>>> }
>>>>>
>>>>> Fixed that as suggested.
>>>>>
>>>>> Jon
>>>>>>
>>>>>> Thanks,
>>>>>> Bengt
>>>>>>
>>>>>>>
>>>>>>> Jon
>>>>>>
>>>>>
>>>>
>>>
>>
>



From stefan.karlsson at oracle.com  Mon Aug  4 13:01:23 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 04 Aug 2014 15:01:23 +0200
Subject: RFR: 8049831: Metadata Full GCs are not triggered when
	CMSClassUnloadingEnabled is turned off
In-Reply-To: <53BE5F21.7040001@oracle.com>
References: <53BE4D5E.2010908@oracle.com> <53BE5F21.7040001@oracle.com>
Message-ID: <53DF8423.5060907@oracle.com>

Hi again,

I missed running hg add on the test so I'll have to push it as a 
separate changeset.

It wil be pushed as:
http://cr.openjdk.java.net/~stefank/8051883/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8051883

thanks,
StefanK

On 2014-07-10 11:38, Stefan Karlsson wrote:
> Hi all,
>
> I decided to convert my adhoc test into a jtreg test that could be 
> checked in:
> http://cr.openjdk.java.net/~stefank/8049831/webrev.01
>
> StefanK
>
> On 2014-07-10 10:22, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please, review this fix to honor -XX:-CMSClassUnloadingEnabled 
>> correctly in the metadata allocation failure path.
>>
>> http://cr.openjdk.java.net/~stefank/8049831/webrev.00
>> https://bugs.openjdk.java.net/browse/JDK-8049831
>>
>> By default, CMS does class unloading after a concurrent marking 
>> cycle. When the amount of metadata hits the high water mark 
>> (capacity_until_GC), a concurrent cycle is initiated, the high water 
>> mark is increased and the thread can proceed with the allocation. If 
>> CMSClassUnloadingEnabled is turned off we don't unload classes after 
>> a concurrent cycle, but instead relies on Full GCs to reclaim 
>> metadata memory. The current code skips triggering a concurrent cycle 
>> if CMSClassUnloadingEnabled is turned off, but it still allows the 
>> high water mark to be increased and the thread can proceed with the 
>> allocation without triggering a Full GC first. This defeats the 
>> entire purpose of the high water mark.
>>
>> The suggested fix is to not allow the increase of the high water mark 
>> and the allocation if CMSClassUnloadingEnabled is turned off.
>>
>> thanks,
>> StefanK
>



From stefan.karlsson at oracle.com  Mon Aug  4 14:07:06 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 04 Aug 2014 16:07:06 +0200
Subject: RFR: 8048269: Add flag to turn off class unloading after G1
	concurrent mark
In-Reply-To: <53C84AAB.6020305@oracle.com>
References: <53BEAEF4.1010106@oracle.com>
	<53BF1DBD.9080901@oracle.com>		<53BF79A0.9090103@oracle.com>
	<53BF97CB.205@oracle.com>		<53C71021.2060003@oracle.com>		<E09F618D-3047-4069-8C00-7F1473BABFDE@kodewerk.com>		<53C76F5F.1050002@oracle.com>
	<1405581946.2684.5.camel@cirrus> <53C84AAB.6020305@oracle.com>
Message-ID: <53DF938A.9080307@oracle.com>

Hi all,

On 2014-07-18 00:14, Jon Masamitsu wrote:
>
> On 07/17/2014 12:25 AM, Thomas Schatzl wrote:
>> Hi,
>>
>> On Thu, 2014-07-17 at 08:38 +0200, Bengt Rutisson wrote:
>>> On 2014-07-17 07:02, Kirk Pepperdine wrote:
>>>>> I don't care for ClassUnloadingAfterConcurrentMark because turning it
>>>>> off makes me think that class unloading is going to occur "Before"
>>>>> concurrent mark.  How about
>>>>>
>>>>> ClassUnloadingWithConcurrentMark
>>>> +1
>>> I'm fine with this one too.
>> I would suggest ClassUnloadingAtConcurrentMark, because it seems more
>> concise, but either is okay.
>>
>> That would be similar to PrintHeapAtGC and so on. :)
>
> The flag sounds more concise but is it that correct?   With CMS
> at least (which we hope to make use this same flag) some
> of the reduction in work would be during marking but the
> freeing of the metaspace and the cleaning of the system
> dictionary come later (after the sweep).  I still like
> ClassUnloadingWithConcurrentMark - not as precise but
> maybe more correct?

I'm fine with this flag name.

Does anyone strongly oppose the flag name: ClassUnloadingWithConcurrentMark?

thanks,
StefanK

>
> Jon
>
>>
>> Thomas
>>
>>
>



From thomas.schatzl at oracle.com  Mon Aug  4 14:39:59 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 04 Aug 2014 16:39:59 +0200
Subject: RFR (S): 8051973: Eager reclaim leaves marks of marked but
	reclaimed objects on the next bitmap
In-Reply-To: <53DF3E33.8000001@oracle.com>
References: <1406630412.2620.22.camel@cirrus> <53D80918.7070904@oracle.com>
	<1406719767.2707.2.camel@cirrus> <53DF3E33.8000001@oracle.com>
Message-ID: <1407163199.2694.8.camel@cirrus>

Hi Bengt,

On Mon, 2014-08-04 at 10:02 +0200, Bengt Rutisson wrote:
> Hi Thomas,
> 
> Looks good.
> 
> One minor question about this code:
> 
> 
> 6609     // Need to clear mark bit of the humongous object if already set.
> 6610     if (next_bitmap->isMarked(r->bottom())) {
> 6611       next_bitmap->clear(r->bottom());
> 6612     }
> 
> Is it worth checking if the bit is marked or should we just 
> unconditionally clear it?

  it does not really matter I think.

Unfortunately I already pushed the change. I can create a cr to fix
that.

Thanks,
Thomas



From xerox.time.tech at gmail.com  Mon Aug  4 15:45:22 2014
From: xerox.time.tech at gmail.com (Xin Tong)
Date: Mon, 4 Aug 2014 10:45:22 -0500
Subject: synonyms and homonyms on java heaps
Message-ID: <CALKntY0x1AOPo0CFk03w1NzzyY7JxXi9x13KYA2RgyJFHmGHWg@mail.gmail.com>

I would like to know whether synonyms and homonyms  can happen on the
OpenJDK java heaps ? Synonyms are mainly used among multiple processes
and homonyms occur when a single virtual address is associated with
multiple address spaces. are there any use cases for synonyms and
homonyms on the java heap ?

Xin


From bengt.rutisson at oracle.com  Tue Aug  5 07:41:25 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 05 Aug 2014 09:41:25 +0200
Subject: RFR (S): 8051973: Eager reclaim leaves marks of marked but
	reclaimed objects on the next bitmap
In-Reply-To: <1407163199.2694.8.camel@cirrus>
References: <1406630412.2620.22.camel@cirrus> <53D80918.7070904@oracle.com>	
	<1406719767.2707.2.camel@cirrus> <53DF3E33.8000001@oracle.com>
	<1407163199.2694.8.camel@cirrus>
Message-ID: <53E08AA5.3000208@oracle.com>


Hi Thomas,

On 2014-08-04 16:39, Thomas Schatzl wrote:
> Hi Bengt,
>
> On Mon, 2014-08-04 at 10:02 +0200, Bengt Rutisson wrote:
>> Hi Thomas,
>>
>> Looks good.
>>
>> One minor question about this code:
>>
>>
>> 6609     // Need to clear mark bit of the humongous object if already set.
>> 6610     if (next_bitmap->isMarked(r->bottom())) {
>> 6611       next_bitmap->clear(r->bottom());
>> 6612     }
>>
>> Is it worth checking if the bit is marked or should we just
>> unconditionally clear it?
>    it does not really matter I think.
>
> Unfortunately I already pushed the change. I can create a cr to fix
> that.

Sorry, I missed that you had already pushed. No need to fix this.

Sorry for the noise.

Bengt


>
> Thanks,
> Thomas
>



From bengt.rutisson at oracle.com  Tue Aug  5 07:43:18 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 05 Aug 2014 09:43:18 +0200
Subject: RFR: 8048269: Add flag to turn off class unloading after G1
	concurrent mark
In-Reply-To: <53DF938A.9080307@oracle.com>
References: <53BEAEF4.1010106@oracle.com>
	<53BF1DBD.9080901@oracle.com>		<53BF79A0.9090103@oracle.com>
	<53BF97CB.205@oracle.com>		<53C71021.2060003@oracle.com>		<E09F618D-3047-4069-8C00-7F1473BABFDE@kodewerk.com>		<53C76F5F.1050002@oracle.com>
	<1405581946.2684.5.camel@cirrus> <53C84AAB.6020305@oracle.com>
	<53DF938A.9080307@oracle.com>
Message-ID: <53E08B16.9050005@oracle.com>


On 2014-08-04 16:07, Stefan Karlsson wrote:
> Hi all,
>
> On 2014-07-18 00:14, Jon Masamitsu wrote:
>>
>> On 07/17/2014 12:25 AM, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Thu, 2014-07-17 at 08:38 +0200, Bengt Rutisson wrote:
>>>> On 2014-07-17 07:02, Kirk Pepperdine wrote:
>>>>>> I don't care for ClassUnloadingAfterConcurrentMark because 
>>>>>> turning it
>>>>>> off makes me think that class unloading is going to occur "Before"
>>>>>> concurrent mark.  How about
>>>>>>
>>>>>> ClassUnloadingWithConcurrentMark
>>>>> +1
>>>> I'm fine with this one too.
>>> I would suggest ClassUnloadingAtConcurrentMark, because it seems more
>>> concise, but either is okay.
>>>
>>> That would be similar to PrintHeapAtGC and so on. :)
>>
>> The flag sounds more concise but is it that correct?   With CMS
>> at least (which we hope to make use this same flag) some
>> of the reduction in work would be during marking but the
>> freeing of the metaspace and the cleaning of the system
>> dictionary come later (after the sweep).  I still like
>> ClassUnloadingWithConcurrentMark - not as precise but
>> maybe more correct?
>
> I'm fine with this flag name.
>
> Does anyone strongly oppose the flag name: 
> ClassUnloadingWithConcurrentMark?

No objections from me.

Bengt

>
> thanks,
> StefanK
>
>>
>> Jon
>>
>>>
>>> Thomas
>>>
>>>
>>
>



From thomas.schatzl at oracle.com  Tue Aug  5 07:49:34 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 05 Aug 2014 09:49:34 +0200
Subject: RFR: 8048269: Add flag to turn off class unloading after G1
	concurrent mark
In-Reply-To: <53E08B16.9050005@oracle.com>
References: <53BEAEF4.1010106@oracle.com> <53BF1DBD.9080901@oracle.com>
	<53BF79A0.9090103@oracle.com> <53BF97CB.205@oracle.com>
	<53C71021.2060003@oracle.com>
	<E09F618D-3047-4069-8C00-7F1473BABFDE@kodewerk.com>
	<53C76F5F.1050002@oracle.com> <1405581946.2684.5.camel@cirrus>
	<53C84AAB.6020305@oracle.com> <53DF938A.9080307@oracle.com>
	<53E08B16.9050005@oracle.com>
Message-ID: <1407224974.2706.0.camel@cirrus>

Hi,

On Tue, 2014-08-05 at 09:43 +0200, Bengt Rutisson wrote:
> On 2014-08-04 16:07, Stefan Karlsson wrote:
> > Hi all,
> >
> > On 2014-07-18 00:14, Jon Masamitsu wrote:
[...]
> >> The flag sounds more concise but is it that correct?   With CMS
> >> at least (which we hope to make use this same flag) some
> >> of the reduction in work would be during marking but the
> >> freeing of the metaspace and the cleaning of the system
> >> dictionary come later (after the sweep).  I still like
> >> ClassUnloadingWithConcurrentMark - not as precise but
> >> maybe more correct?
> >
> > I'm fine with this flag name.
> >
> > Does anyone strongly oppose the flag name: 
> > ClassUnloadingWithConcurrentMark?
> 
> No objections from me.

Neither from me.

Thomas



From stefan.karlsson at oracle.com  Tue Aug  5 08:09:56 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 05 Aug 2014 10:09:56 +0200
Subject: RFR: 8048269: Add flag to turn off class unloading after G1
	concurrent mark
In-Reply-To: <1407224974.2706.0.camel@cirrus>
References: <53BEAEF4.1010106@oracle.com>
	<53BF1DBD.9080901@oracle.com>			<53BF79A0.9090103@oracle.com>
	<53BF97CB.205@oracle.com>			<53C71021.2060003@oracle.com>			<E09F618D-3047-4069-8C00-7F1473BABFDE@kodewerk.com>			<53C76F5F.1050002@oracle.com>
	<1405581946.2684.5.camel@cirrus>	 <53C84AAB.6020305@oracle.com>
	<53DF938A.9080307@oracle.com>	 <53E08B16.9050005@oracle.com>
	<1407224974.2706.0.camel@cirrus>
Message-ID: <53E09154.3090006@oracle.com>


On 2014-08-05 09:49, Thomas Schatzl wrote:
> Hi,
>
> On Tue, 2014-08-05 at 09:43 +0200, Bengt Rutisson wrote:
>> On 2014-08-04 16:07, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> On 2014-07-18 00:14, Jon Masamitsu wrote:
> [...]
>>>> The flag sounds more concise but is it that correct?   With CMS
>>>> at least (which we hope to make use this same flag) some
>>>> of the reduction in work would be during marking but the
>>>> freeing of the metaspace and the cleaning of the system
>>>> dictionary come later (after the sweep).  I still like
>>>> ClassUnloadingWithConcurrentMark - not as precise but
>>>> maybe more correct?
>>> I'm fine with this flag name.
>>>
>>> Does anyone strongly oppose the flag name:
>>> ClassUnloadingWithConcurrentMark?
>> No objections from me.
> Neither from me.

Good.

Here is the updated patch with the new name:
  http://cr.openjdk.java.net/~stefank/8048269/webrev.01/
  http://cr.openjdk.java.net/~stefank/8048269/webrev.01.delta/

thanks,
StefanK

>
> Thomas
>



From thomas.schatzl at oracle.com  Tue Aug  5 11:14:56 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 05 Aug 2014 13:14:56 +0200
Subject: RFR (XS): 8054341: Remove some obsolete code in G1CollectedHeap class
Message-ID: <1407237296.2706.19.camel@cirrus>

Hi all,

  can I have reviews for this small change that removes some dead code
in the G1CollectedHeap files?

CR:
https://bugs.openjdk.java.net/browse/JDK-8054341
Webrev:
http://cr.openjdk.java.net/~tschatzl/8054341/webrev/
Testing:
jprt

Thanks,
  Thomas



From stefan.karlsson at oracle.com  Tue Aug  5 11:28:11 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 05 Aug 2014 13:28:11 +0200
Subject: RFR (XS): 8054341: Remove some obsolete code in G1CollectedHeap
	class
In-Reply-To: <1407237296.2706.19.camel@cirrus>
References: <1407237296.2706.19.camel@cirrus>
Message-ID: <53E0BFCB.3090804@oracle.com>

On 2014-08-05 13:14, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for this small change that removes some dead code
> in the G1CollectedHeap files?
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8054341
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8054341/webrev/

Looks good to me.

StefanK

> Testing:
> jprt
>
> Thanks,
>    Thomas
>



From bengt.rutisson at oracle.com  Tue Aug  5 12:19:52 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 05 Aug 2014 14:19:52 +0200
Subject: RFR (XS): 8054341: Remove some obsolete code in G1CollectedHeap
	class
In-Reply-To: <53E0BFCB.3090804@oracle.com>
References: <1407237296.2706.19.camel@cirrus> <53E0BFCB.3090804@oracle.com>
Message-ID: <53E0CBE8.4040301@oracle.com>


On 2014-08-05 13:28, Stefan Karlsson wrote:
> On 2014-08-05 13:14, Thomas Schatzl wrote:
>> Hi all,
>>
>>    can I have reviews for this small change that removes some dead code
>> in the G1CollectedHeap files?
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8054341
>> Webrev:
>> http://cr.openjdk.java.net/~tschatzl/8054341/webrev/
>
> Looks good to me.

Looks good to me too.

Bengt

>
> StefanK
>
>> Testing:
>> jprt
>>
>> Thanks,
>>    Thomas
>>
>



From thomas.schatzl at oracle.com  Tue Aug  5 12:39:55 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 05 Aug 2014 14:39:55 +0200
Subject: RFR (XS): 8054341: Remove some obsolete code in G1CollectedHeap
	class
In-Reply-To: <53E0CBE8.4040301@oracle.com>
References: <1407237296.2706.19.camel@cirrus> <53E0BFCB.3090804@oracle.com>
	<53E0CBE8.4040301@oracle.com>
Message-ID: <1407242395.2706.52.camel@cirrus>

Hi Bengt, Stefan,

  thanks for the reviews.

On Tue, 2014-08-05 at 14:19 +0200, Bengt Rutisson wrote:
> On 2014-08-05 13:28, Stefan Karlsson wrote:
> > On 2014-08-05 13:14, Thomas Schatzl wrote:
> >> Hi all,
> >>
> >>    can I have reviews for this small change that removes some dead code
> >> in the G1CollectedHeap files?
> >>
> >> CR:
> >> https://bugs.openjdk.java.net/browse/JDK-8054341
> >> Webrev:
> >> http://cr.openjdk.java.net/~tschatzl/8054341/webrev/
> >
> > Looks good to me.
> 
> Looks good to me too.

Thanks,
  Thomas




From thomas.schatzl at oracle.com  Tue Aug  5 14:07:17 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 05 Aug 2014 16:07:17 +0200
Subject: RFR (XS): 8052170: G1 asserts at collection exit with
	-XX:-G1DeferredRSUpdate
Message-ID: <1407247637.2706.59.camel@cirrus>

Hi all,

  can I have reviews for this small change? It fixes an assertion that
triggers when -XX:-G1DeferredRSUpdate and -XX:+PrintGCDetails is set. In
particular in this case the timing measurements introduced in
JDK-8019342 are not updated during GC, causing this issue.

The existing test case introduced in 8040977 does not trigger either,
because it does not enable PrintGCDetails.

The fix is to initialize these timing metrics also in case
G1DeferredRSUpdate is disabled.

I also moved the checking whether G1DeferredRSUpdate is enabled into
G1CollectedHeap::redirty_logged_cards() as similar code style has been
suggested for the eager reclaim change.

I updated the existing test case too.

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

Webrev:
http://cr.openjdk.java.net/~tschatzl/8052170/webrev

Testing:
jprt, jtreg test case

Thanks,
  Thomas




From jon.masamitsu at oracle.com  Tue Aug  5 21:07:49 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 05 Aug 2014 14:07:49 -0700
Subject: [hdk8u40] Request for review (s) - 8031323: Optionally align objects
	copied to survivor spaces
In-Reply-To: <53267CBB.9020804@oracle.com>
References: <53267CBB.9020804@oracle.com>
Message-ID: <53E147A5.2070501@oracle.com>

This is a backport from jdk9.  The patch applied cleanly.

8031323: Optionally align objects copied to survivor spaces

Add the option to specify an alignment for allocations into the
survivor spaces.  Survivor space allocations will overflow if the
survivor spaces have not been increased.   The expected use
is to align survivor space allocations to cache line sizes.

This is the webrev for the patch from jdk9.

http://cr.openjdk.java.net/~jmasa/8031323/webrev.00/

I made a change to the error message in arguments.cpp
here.  This change was based on a review comment I received
after the push to jdk9

http://cr.openjdk.java.net/~jmasa/8031323/webrev_delta.00/


      if (SurvivorAlignmentInBytes < ObjectAlignmentInBytes) {
        jio_fprintf(defaultStream::error_stream(),
-          "error: SurvivorAlignmentInBytes=%d must be greater than ObjectAlignmentInBytes=%d \n",
+          "error: SurvivorAlignmentInBytes=%d must be greater than or equal to ObjectAlignmentInBytes=%d \n",
            (int)SurvivorAlignmentInBytes, (int)ObjectAlignmentInBytes);
        return false;
      }

Thanks.

Jon



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

From jon.masamitsu at oracle.com  Tue Aug  5 21:16:38 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 05 Aug 2014 14:16:38 -0700
Subject: RFR: 8048269: Add flag to turn off class unloading after G1
	concurrent mark
In-Reply-To: <53E09154.3090006@oracle.com>
References: <53BEAEF4.1010106@oracle.com>
	<53BF1DBD.9080901@oracle.com>			<53BF79A0.9090103@oracle.com>
	<53BF97CB.205@oracle.com>			<53C71021.2060003@oracle.com>			<E09F618D-3047-4069-8C00-7F1473BABFDE@kodewerk.com>			<53C76F5F.1050002@oracle.com>
	<1405581946.2684.5.camel@cirrus>	 <53C84AAB.6020305@oracle.com>
	<53DF938A.9080307@oracle.com>	 <53E08B16.9050005@oracle.com>
	<1407224974.2706.0.camel@cirrus> <53E09154.3090006@oracle.com>
Message-ID: <53E149B6.7050603@oracle.com>


On 08/05/2014 01:09 AM, Stefan Karlsson wrote:
>
> On 2014-08-05 09:49, Thomas Schatzl wrote:
>> Hi,
>>
>> On Tue, 2014-08-05 at 09:43 +0200, Bengt Rutisson wrote:
>>> On 2014-08-04 16:07, Stefan Karlsson wrote:
>>>> Hi all,
>>>>
>>>> On 2014-07-18 00:14, Jon Masamitsu wrote:
>> [...]
>>>>> The flag sounds more concise but is it that correct?   With CMS
>>>>> at least (which we hope to make use this same flag) some
>>>>> of the reduction in work would be during marking but the
>>>>> freeing of the metaspace and the cleaning of the system
>>>>> dictionary come later (after the sweep).  I still like
>>>>> ClassUnloadingWithConcurrentMark - not as precise but
>>>>> maybe more correct?
>>>> I'm fine with this flag name.
>>>>
>>>> Does anyone strongly oppose the flag name:
>>>> ClassUnloadingWithConcurrentMark?
>>> No objections from me.
>> Neither from me.
>
> Good.
>
> Here is the updated patch with the new name:
>  http://cr.openjdk.java.net/~stefank/8048269/webrev.01/
>  http://cr.openjdk.java.net/~stefank/8048269/webrev.01.delta/

Looks good.  Thanks.

Jon

>
> thanks,
> StefanK
>
>>
>> Thomas
>>
>



From jon.masamitsu at oracle.com  Tue Aug  5 21:46:17 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 05 Aug 2014 14:46:17 -0700
Subject: RFR (XS): 8052170: G1 asserts at collection exit with
	-XX:-G1DeferredRSUpdate
In-Reply-To: <1407247637.2706.59.camel@cirrus>
References: <1407247637.2706.59.camel@cirrus>
Message-ID: <53E150A9.8070202@oracle.com>

Changes look good.

Reviewed.

Jon

On 08/05/2014 07:07 AM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for this small change? It fixes an assertion that
> triggers when -XX:-G1DeferredRSUpdate and -XX:+PrintGCDetails is set. In
> particular in this case the timing measurements introduced in
> JDK-8019342 are not updated during GC, causing this issue.
>
> The existing test case introduced in 8040977 does not trigger either,
> because it does not enable PrintGCDetails.
>
> The fix is to initialize these timing metrics also in case
> G1DeferredRSUpdate is disabled.
>
> I also moved the checking whether G1DeferredRSUpdate is enabled into
> G1CollectedHeap::redirty_logged_cards() as similar code style has been
> suggested for the eager reclaim change.
>
> I updated the existing test case too.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8052170
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8052170/webrev
>
> Testing:
> jprt, jtreg test case
>
> Thanks,
>    Thomas
>
>



From bengt.rutisson at oracle.com  Wed Aug  6 08:00:15 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 06 Aug 2014 10:00:15 +0200
Subject: RFR: 8048269: Add flag to turn off class unloading after G1
	concurrent mark
In-Reply-To: <53E09154.3090006@oracle.com>
References: <53BEAEF4.1010106@oracle.com>
	<53BF1DBD.9080901@oracle.com>			<53BF79A0.9090103@oracle.com>
	<53BF97CB.205@oracle.com>			<53C71021.2060003@oracle.com>			<E09F618D-3047-4069-8C00-7F1473BABFDE@kodewerk.com>			<53C76F5F.1050002@oracle.com>
	<1405581946.2684.5.camel@cirrus>	 <53C84AAB.6020305@oracle.com>
	<53DF938A.9080307@oracle.com>	 <53E08B16.9050005@oracle.com>
	<1407224974.2706.0.camel@cirrus> <53E09154.3090006@oracle.com>
Message-ID: <53E1E08F.8030702@oracle.com>


Hi Stefan,

Looks good.

Three minor things:
- g1CollectedHeap.cpp - there is a fixme comment that can be removed
- sharedHeap.cpp - the INCLUDE_ALL_GCS guards are not needed
- we should file a bug to make sure that we don't forget to change CMS 
to use the new flag too

No need for a new webrev for these changes.

Reviewed.
Bengt


On 2014-08-05 10:09, Stefan Karlsson wrote:
>
> On 2014-08-05 09:49, Thomas Schatzl wrote:
>> Hi,
>>
>> On Tue, 2014-08-05 at 09:43 +0200, Bengt Rutisson wrote:
>>> On 2014-08-04 16:07, Stefan Karlsson wrote:
>>>> Hi all,
>>>>
>>>> On 2014-07-18 00:14, Jon Masamitsu wrote:
>> [...]
>>>>> The flag sounds more concise but is it that correct?   With CMS
>>>>> at least (which we hope to make use this same flag) some
>>>>> of the reduction in work would be during marking but the
>>>>> freeing of the metaspace and the cleaning of the system
>>>>> dictionary come later (after the sweep).  I still like
>>>>> ClassUnloadingWithConcurrentMark - not as precise but
>>>>> maybe more correct?
>>>> I'm fine with this flag name.
>>>>
>>>> Does anyone strongly oppose the flag name:
>>>> ClassUnloadingWithConcurrentMark?
>>> No objections from me.
>> Neither from me.
>
> Good.
>
> Here is the updated patch with the new name:
>  http://cr.openjdk.java.net/~stefank/8048269/webrev.01/
>  http://cr.openjdk.java.net/~stefank/8048269/webrev.01.delta/
>
> thanks,
> StefanK
>
>>
>> Thomas
>>
>



From marcus.larsson at oracle.com  Wed Aug  6 08:28:14 2014
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Wed, 06 Aug 2014 10:28:14 +0200
Subject: RFR (XS): 80357290: Code using assert(is_oop_or_null) needs better
	error messages
Message-ID: <53E1E71E.5010408@oracle.com>

Hi,

Can I have reviews for this small change adding oop information to 
is_oop_or_null assert fail messages?

CR:
http://cr.openjdk.java.net/~brutisso/webrev-8035729/

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

Thanks,
Marcus


From marcus.larsson at oracle.com  Wed Aug  6 08:34:04 2014
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Wed, 06 Aug 2014 10:34:04 +0200
Subject: RFR (XS): 8051837: Remove temporary G1UseParallelRSetUpdating and
	G1UseParallelRSetScanning flags
Message-ID: <53E1E87C.3060301@oracle.com>

Hi,

Can I have reviews for this small change removing the two temporary 
flags G1UseParallelRSetUpdating and G1UseParallelRSetScanning?

Testing: jprt

CR:
http://cr.openjdk.java.net/~brutisso/webrev-8051837/

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

Thanks,
Marcus


From stefan.karlsson at oracle.com  Wed Aug  6 08:59:07 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 06 Aug 2014 10:59:07 +0200
Subject: RFR (XS): 80357290: Code using assert(is_oop_or_null) needs better
	error messages
In-Reply-To: <53E1E71E.5010408@oracle.com>
References: <53E1E71E.5010408@oracle.com>
Message-ID: <53E1EE5B.20703@oracle.com>


On 2014-08-06 10:28, Marcus Larsson wrote:
> Hi,
>
> Can I have reviews for this small change adding oop information to 
> is_oop_or_null assert fail messages?
>
> CR:
> http://cr.openjdk.java.net/~brutisso/webrev-8035729/

Looks good to me.

thanks,
StefanK

>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8035729/
>
> Thanks,
> Marcus



From stefan.karlsson at oracle.com  Wed Aug  6 09:03:43 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 06 Aug 2014 11:03:43 +0200
Subject: RFR (XS): 8051837: Remove temporary G1UseParallelRSetUpdating
	and G1UseParallelRSetScanning flags
In-Reply-To: <53E1E87C.3060301@oracle.com>
References: <53E1E87C.3060301@oracle.com>
Message-ID: <53E1EF6F.1070909@oracle.com>


On 2014-08-06 10:34, Marcus Larsson wrote:
> Hi,
>
> Can I have reviews for this small change removing the two temporary 
> flags G1UseParallelRSetUpdating and G1UseParallelRSetScanning?
>
> Testing: jprt
>
> CR:
> http://cr.openjdk.java.net/~brutisso/webrev-8051837/

Looks good.

thanks,
StefanK

>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8051837
>
> Thanks,
> Marcus



From thomas.schatzl at oracle.com  Wed Aug  6 09:14:31 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 06 Aug 2014 11:14:31 +0200
Subject: RFR (XS): 8051837: Remove temporary G1UseParallelRSetUpdating
	and G1UseParallelRSetScanning flags
In-Reply-To: <53E1E87C.3060301@oracle.com>
References: <53E1E87C.3060301@oracle.com>
Message-ID: <1407316471.2656.4.camel@cirrus>

Hi Marcus,

On Wed, 2014-08-06 at 10:34 +0200, Marcus Larsson wrote:
> Hi,
> 
> Can I have reviews for this small change removing the two temporary 
> flags G1UseParallelRSetUpdating and G1UseParallelRSetScanning?
> 
> Testing: jprt
> 
> CR:
> http://cr.openjdk.java.net/~brutisso/webrev-8051837/
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8051837

Looks good, thanks.

Thomas	



From thomas.schatzl at oracle.com  Wed Aug  6 09:24:23 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 06 Aug 2014 11:24:23 +0200
Subject: RFR (XS): 80357290: Code using assert(is_oop_or_null) needs
	better error messages
In-Reply-To: <53E1E71E.5010408@oracle.com>
References: <53E1E71E.5010408@oracle.com>
Message-ID: <1407317063.2656.13.camel@cirrus>

Hi,

On Wed, 2014-08-06 at 10:28 +0200, Marcus Larsson wrote:
> Hi,
> 
> Can I have reviews for this small change adding oop information to 
> is_oop_or_null assert fail messages?
> 
> CR:
> http://cr.openjdk.java.net/~brutisso/webrev-8035729/
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8035729/

  not sure what the other think, but is it worth to try to make the
error messages themselves be more uniform?
While I do not want to be all the same, we have:

1) expected an oop or NULL
2) expected an oop or NULL:
3) Not an oop? (
4) check for header:
5) should be an oop now:
6) Object should be whole at this point:
7) Not an oop:
8) discovered field is bad: 
9) bad referent:
10) bad next field: 
11) bad discovered field: 
12) should always be an oop: 

Some suggestions:

- Capitalize the first letter of the sentences
- change 1 to "Expected an oop or NULL at "
- replace 2,3,5,6,7,12 by 1
- change 4,9-11 to "Expected an oop for <type> field at "

Otherwise the change is good.

Thanks,
  Thomas





From thomas.schatzl at oracle.com  Wed Aug  6 09:26:34 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 06 Aug 2014 11:26:34 +0200
Subject: [hdk8u40] Request for review (s) - 8031323: Optionally align
	objects copied to survivor spaces
In-Reply-To: <53E147A5.2070501@oracle.com>
References: <53267CBB.9020804@oracle.com> <53E147A5.2070501@oracle.com>
Message-ID: <1407317194.2656.15.camel@cirrus>

Hi Jon,

On Tue, 2014-08-05 at 14:07 -0700, Jon Masamitsu wrote:
> This is a backport from jdk9.  The patch applied cleanly.
> 
> 8031323: Optionally align objects copied to survivor spaces
> 
> Add the option to specify an alignment for allocations into the
> survivor spaces.  Survivor space allocations will overflow if the
> survivor spaces have not been increased.   The expected use
> is to align survivor space allocations to cache line sizes.
> 
> This is the webrev for the patch from jdk9.
> 
> http://cr.openjdk.java.net/~jmasa/8031323/webrev.00/
> 
> I made a change to the error message in arguments.cpp
> here.  This change was based on a review comment I received
> after the push to jdk9

I would prefer if the change to the message were made to jdk9 first, and
then both changes backported to 8u.

Otherwise it is hard to see what has already been backported and what
not. (Say, by diffing the the summary lines of both branches).

Thanks,
  Thomas





From thomas.schatzl at oracle.com  Wed Aug  6 10:27:12 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 06 Aug 2014 12:27:12 +0200
Subject: RFR (XS): 8052170: G1 asserts at collection exit with
	-XX:-G1DeferredRSUpdate
In-Reply-To: <53E150A9.8070202@oracle.com>
References: <1407247637.2706.59.camel@cirrus> <53E150A9.8070202@oracle.com>
Message-ID: <1407320832.2656.16.camel@cirrus>

Hi Jon,

On Tue, 2014-08-05 at 14:46 -0700, Jon Masamitsu wrote:
> Changes look good.
> 
> Reviewed.
> 

  thanks for the review.

Thomas




From marcus.larsson at oracle.com  Wed Aug  6 13:42:45 2014
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Wed, 06 Aug 2014 15:42:45 +0200
Subject: RFR (XS): 80357290: Code using assert(is_oop_or_null) needs better
	error messages
In-Reply-To: <1407317063.2656.13.camel@cirrus>
References: <53E1E71E.5010408@oracle.com> <1407317063.2656.13.camel@cirrus>
Message-ID: <53E230D5.1020401@oracle.com>

Hi Thomas,

I like your suggestion and updated the changeset.

New CR:
http://cr.openjdk.java.net/~brutisso/webrev-8035729v2/

Thanks,
Marcus

On 08/06/2014 11:24 AM, Thomas Schatzl wrote:
> Hi,
>
> On Wed, 2014-08-06 at 10:28 +0200, Marcus Larsson wrote:
>> Hi,
>>
>> Can I have reviews for this small change adding oop information to
>> is_oop_or_null assert fail messages?
>>
>> CR:
>> http://cr.openjdk.java.net/~brutisso/webrev-8035729/
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8035729/
>    not sure what the other think, but is it worth to try to make the
> error messages themselves be more uniform?
> While I do not want to be all the same, we have:
>
> 1) expected an oop or NULL
> 2) expected an oop or NULL:
> 3) Not an oop? (
> 4) check for header:
> 5) should be an oop now:
> 6) Object should be whole at this point:
> 7) Not an oop:
> 8) discovered field is bad:
> 9) bad referent:
> 10) bad next field:
> 11) bad discovered field:
> 12) should always be an oop:
>
> Some suggestions:
>
> - Capitalize the first letter of the sentences
> - change 1 to "Expected an oop or NULL at "
> - replace 2,3,5,6,7,12 by 1
> - change 4,9-11 to "Expected an oop for <type> field at "
>
> Otherwise the change is good.
>
> Thanks,
>    Thomas
>
>
>



From thomas.schatzl at oracle.com  Wed Aug  6 14:15:35 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 06 Aug 2014 16:15:35 +0200
Subject: RFR (XS): 8052170: G1 asserts at collection exit with
	-XX:-G1DeferredRSUpdate
In-Reply-To: <1407247637.2706.59.camel@cirrus>
References: <1407247637.2706.59.camel@cirrus>
Message-ID: <1407334535.2656.41.camel@cirrus>

Hi all,

  Bengt had some suggestions to simplify the change: just skip
verification for the values that we do not print anyway.

As this makes the change a lot simpler, I changed it as suggested. New
webrev is at
http://cr.openjdk.java.net/~tschatzl/8052170/webrev.1/

Thanks,
  Thomas

On Tue, 2014-08-05 at 16:07 +0200, Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews for this small change? It fixes an assertion that
> triggers when -XX:-G1DeferredRSUpdate and -XX:+PrintGCDetails is set. In
> particular in this case the timing measurements introduced in
> JDK-8019342 are not updated during GC, causing this issue.
> 
> The existing test case introduced in 8040977 does not trigger either,
> because it does not enable PrintGCDetails.
> 
> The fix is to initialize these timing metrics also in case
> G1DeferredRSUpdate is disabled.
> 
> I also moved the checking whether G1DeferredRSUpdate is enabled into
> G1CollectedHeap::redirty_logged_cards() as similar code style has been
> suggested for the eager reclaim change.
> 
> I updated the existing test case too.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8052170
> 
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8052170/webrev
> 
> Testing:
> jprt, jtreg test case
> 
> Thanks,
>   Thomas
> 
> 




From thomas.schatzl at oracle.com  Wed Aug  6 14:23:50 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 06 Aug 2014 16:23:50 +0200
Subject: RFR (XS): 80357290: Code using assert(is_oop_or_null) needs
	better error messages
In-Reply-To: <53E230D5.1020401@oracle.com>
References: <53E1E71E.5010408@oracle.com> <1407317063.2656.13.camel@cirrus>
	<53E230D5.1020401@oracle.com>
Message-ID: <1407335030.2656.45.camel@cirrus>

Hi Marcus,

On Wed, 2014-08-06 at 15:42 +0200, Marcus Larsson wrote:
> Hi Thomas,
> 
> I like your suggestion and updated the changeset.
> 
> New CR:
> http://cr.openjdk.java.net/~brutisso/webrev-8035729v2/
> 

  looks okay to me. Maybe for completeness the text "Expected an oop for
<type> field at " should be changed to "Expected an oop or NULL
for ...". I forgot that in my listing, sorry.

But it's probably already a big step up from "Not an oop?" :)  If you
want to change these minor issues anyway, consider it reviewed as well.

Thanks,
  Thomas


> On 08/06/2014 11:24 AM, Thomas Schatzl wrote:
> > Hi,
> >
> > On Wed, 2014-08-06 at 10:28 +0200, Marcus Larsson wrote:
> >> Hi,
> >>
> >> Can I have reviews for this small change adding oop information to
> >> is_oop_or_null assert fail messages?
> >>
> >> CR:
> >> http://cr.openjdk.java.net/~brutisso/webrev-8035729/
> >>
> >> Bug:
> >> https://bugs.openjdk.java.net/browse/JDK-8035729/
> >    not sure what the other think, but is it worth to try to make the
> > error messages themselves be more uniform?
> > While I do not want to be all the same, we have:
> >
> > 1) expected an oop or NULL
> > 2) expected an oop or NULL:
> > 3) Not an oop? (
> > 4) check for header:
> > 5) should be an oop now:
> > 6) Object should be whole at this point:
> > 7) Not an oop:
> > 8) discovered field is bad:
> > 9) bad referent:
> > 10) bad next field:
> > 11) bad discovered field:
> > 12) should always be an oop:
> >
> > Some suggestions:
> >
> > - Capitalize the first letter of the sentences
> > - change 1 to "Expected an oop or NULL at "
> > - replace 2,3,5,6,7,12 by 1
> > - change 4,9-11 to "Expected an oop for <type> field at "
> >
> > Otherwise the change is good.
> >
> > Thanks,
> >    Thomas
> >
> >
> >
> 




From bengt.rutisson at oracle.com  Wed Aug  6 15:01:16 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 06 Aug 2014 17:01:16 +0200
Subject: RFR (XS): 8052170: G1 asserts at collection exit with
	-XX:-G1DeferredRSUpdate
In-Reply-To: <1407334535.2656.41.camel@cirrus>
References: <1407247637.2706.59.camel@cirrus> <1407334535.2656.41.camel@cirrus>
Message-ID: <53E2433C.7020003@oracle.com>


Hi Thomas,

On 2014-08-06 16:15, Thomas Schatzl wrote:
> Hi all,
>
>    Bengt had some suggestions to simplify the change: just skip
> verification for the values that we do not print anyway.
>
> As this makes the change a lot simpler, I changed it as suggested. New
> webrev is at
> http://cr.openjdk.java.net/~tschatzl/8052170/webrev.1/

Looks good!

Thanks,
Bengt

>
> Thanks,
>    Thomas
>
> On Tue, 2014-08-05 at 16:07 +0200, Thomas Schatzl wrote:
>> Hi all,
>>
>>    can I have reviews for this small change? It fixes an assertion that
>> triggers when -XX:-G1DeferredRSUpdate and -XX:+PrintGCDetails is set. In
>> particular in this case the timing measurements introduced in
>> JDK-8019342 are not updated during GC, causing this issue.
>>
>> The existing test case introduced in 8040977 does not trigger either,
>> because it does not enable PrintGCDetails.
>>
>> The fix is to initialize these timing metrics also in case
>> G1DeferredRSUpdate is disabled.
>>
>> I also moved the checking whether G1DeferredRSUpdate is enabled into
>> G1CollectedHeap::redirty_logged_cards() as similar code style has been
>> suggested for the eager reclaim change.
>>
>> I updated the existing test case too.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8052170
>>
>> Webrev:
>> http://cr.openjdk.java.net/~tschatzl/8052170/webrev
>>
>> Testing:
>> jprt, jtreg test case
>>
>> Thanks,
>>    Thomas
>>
>>
>



From dmitry.fazunenko at oracle.com  Wed Aug  6 15:53:19 2014
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko)
Date: Wed, 06 Aug 2014 19:53:19 +0400
Subject: RFR: (S) 8050464: G1 string deduplication tests hang/timeout and
	leave running processes consuming all resources
In-Reply-To: <53737D83.2050205@oracle.com>
References: <53737D83.2050205@oracle.com>
Message-ID: <53E24F6F.5000704@oracle.com>

Hi,

Would you please look at the simple fix of String Deduplication tests.

Description:

When string deduplication has happened /s1.equals(s2)/  will be 
equivalent to /s1 == s2/
Deduplication is performed in a separate thread so it could be delayed a 
bit.
Tests are away about possible delay and give another chance if 
deduplication hasn't
happened by the moment of check.
But tests wait for deduplication in infinitive loop, so if deduplication 
doesn't work the tests
will timeout, leaving hanging VM after. Which is not very elegant.

The fix is simple: replace infinitive loops with limited ones and report 
failure.
The logic of the tests hasn't changed.

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

Any comments are welcome.

Thanks,
Dima



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

From jon.masamitsu at oracle.com  Wed Aug  6 17:43:23 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 06 Aug 2014 10:43:23 -0700
Subject: RFR (XS): 80357290: Code using assert(is_oop_or_null) needs better
	error messages
In-Reply-To: <53E230D5.1020401@oracle.com>
References: <53E1E71E.5010408@oracle.com> <1407317063.2656.13.camel@cirrus>
	<53E230D5.1020401@oracle.com>
Message-ID: <53E2693B.4010403@oracle.com>

Marcus,

There are debug functions that just do assertion checking.
For example, assert_locked_or_safepoint() in mutexLocker.cpp.
Would it make it easier to create an

void assert_is_oop_or_null(oop obj) {
   assert(obj->is_oop_or_null(), err_msg())"Expected an oop or NULL at " 
PTR_FORMAT, p2i(obj);
}

and use that where you can?  Some of the uses have more specific messages
so this won't work everywhere.

Jon



On 8/6/2014 6:42 AM, Marcus Larsson wrote:
> Hi Thomas,
>
> I like your suggestion and updated the changeset.
>
> New CR:
> http://cr.openjdk.java.net/~brutisso/webrev-8035729v2/
>
> Thanks,
> Marcus
>
> On 08/06/2014 11:24 AM, Thomas Schatzl wrote:
>> Hi,
>>
>> On Wed, 2014-08-06 at 10:28 +0200, Marcus Larsson wrote:
>>> Hi,
>>>
>>> Can I have reviews for this small change adding oop information to
>>> is_oop_or_null assert fail messages?
>>>
>>> CR:
>>> http://cr.openjdk.java.net/~brutisso/webrev-8035729/
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8035729/
>>    not sure what the other think, but is it worth to try to make the
>> error messages themselves be more uniform?
>> While I do not want to be all the same, we have:
>>
>> 1) expected an oop or NULL
>> 2) expected an oop or NULL:
>> 3) Not an oop? (
>> 4) check for header:
>> 5) should be an oop now:
>> 6) Object should be whole at this point:
>> 7) Not an oop:
>> 8) discovered field is bad:
>> 9) bad referent:
>> 10) bad next field:
>> 11) bad discovered field:
>> 12) should always be an oop:
>>
>> Some suggestions:
>>
>> - Capitalize the first letter of the sentences
>> - change 1 to "Expected an oop or NULL at "
>> - replace 2,3,5,6,7,12 by 1
>> - change 4,9-11 to "Expected an oop for <type> field at "
>>
>> Otherwise the change is good.
>>
>> Thanks,
>>    Thomas
>>
>>
>>
>



From jon.masamitsu at oracle.com  Wed Aug  6 17:52:42 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 06 Aug 2014 10:52:42 -0700
Subject: [hdk8u40] Request for review (s) - 8031323: Optionally align
	objects copied to survivor spaces
In-Reply-To: <1407317194.2656.15.camel@cirrus>
References: <53267CBB.9020804@oracle.com> <53E147A5.2070501@oracle.com>
	<1407317194.2656.15.camel@cirrus>
Message-ID: <53E26B6A.2070905@oracle.com>


On 8/6/2014 2:26 AM, Thomas Schatzl wrote:
> Hi Jon,
>
> On Tue, 2014-08-05 at 14:07 -0700, Jon Masamitsu wrote:
>> This is a backport from jdk9.  The patch applied cleanly.
>>
>> 8031323: Optionally align objects copied to survivor spaces
>>
>> Add the option to specify an alignment for allocations into the
>> survivor spaces.  Survivor space allocations will overflow if the
>> survivor spaces have not been increased.   The expected use
>> is to align survivor space allocations to cache line sizes.
>>
>> This is the webrev for the patch from jdk9.
>>
>> http://cr.openjdk.java.net/~jmasa/8031323/webrev.00/
>>
>> I made a change to the error message in arguments.cpp
>> here.  This change was based on a review comment I received
>> after the push to jdk9
> I would prefer if the change to the message were made to jdk9 first, and
> then both changes backported to 8u.
Thomas,

I will do that.  All your work to keep the jdk9 and the jdk8u sources
in sync (and backports easier) is very much appreciated by me.

All,

I'm removing the webrev_delta.00 from the code review request.

jon

>
> Otherwise it is hard to see what has already been backported and what
> not. (Say, by diffing the the summary lines of both branches).
>
> Thanks,
>    Thomas
>
>
>



From jon.masamitsu at oracle.com  Wed Aug  6 18:43:21 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 06 Aug 2014 11:43:21 -0700
Subject: RFR (XS): 8052170: G1 asserts at collection exit with
	-XX:-G1DeferredRSUpdate
In-Reply-To: <1407334535.2656.41.camel@cirrus>
References: <1407247637.2706.59.camel@cirrus> <1407334535.2656.41.camel@cirrus>
Message-ID: <53E27749.3060704@oracle.com>


On 8/6/2014 7:15 AM, Thomas Schatzl wrote:
> Hi all,
>
>    Bengt had some suggestions to simplify the change: just skip
> verification for the values that we do not print anyway.
>
> As this makes the change a lot simpler, I changed it as suggested. New
> webrev is at
> http://cr.openjdk.java.net/~tschatzl/8052170/webrev.1/

Yes, this is nicer.

Reviewed.

Jon

>
> Thanks,
>    Thomas
>
> On Tue, 2014-08-05 at 16:07 +0200, Thomas Schatzl wrote:
>> Hi all,
>>
>>    can I have reviews for this small change? It fixes an assertion that
>> triggers when -XX:-G1DeferredRSUpdate and -XX:+PrintGCDetails is set. In
>> particular in this case the timing measurements introduced in
>> JDK-8019342 are not updated during GC, causing this issue.
>>
>> The existing test case introduced in 8040977 does not trigger either,
>> because it does not enable PrintGCDetails.
>>
>> The fix is to initialize these timing metrics also in case
>> G1DeferredRSUpdate is disabled.
>>
>> I also moved the checking whether G1DeferredRSUpdate is enabled into
>> G1CollectedHeap::redirty_logged_cards() as similar code style has been
>> suggested for the eager reclaim change.
>>
>> I updated the existing test case too.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8052170
>>
>> Webrev:
>> http://cr.openjdk.java.net/~tschatzl/8052170/webrev
>>
>> Testing:
>> jprt, jtreg test case
>>
>> Thanks,
>>    Thomas
>>
>>
>



From jon.masamitsu at oracle.com  Wed Aug  6 19:56:11 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 06 Aug 2014 12:56:11 -0700
Subject: RFR: (S) 8050464: G1 string deduplication tests hang/timeout
	and leave running processes consuming all resources
In-Reply-To: <53E24F6F.5000704@oracle.com>
References: <53737D83.2050205@oracle.com> <53E24F6F.5000704@oracle.com>
Message-ID: <53E2885B.6040609@oracle.com>

Dima,

If the test fails, can you print the strings with System.out.println() or
System.err.println()?  Any information about the strings might be
useful to understand why deduplication didn't work or why the
test thinks the deduplication didn't work (in case something
happens that the test doesn't expect)?

Jon

On 8/6/2014 8:53 AM, Dmitry Fazunenko wrote:
> Hi,
>
> Would you please look at the simple fix of String Deduplication tests.
>
> Description:
>
> When string deduplication has happened /s1.equals(s2)/ will be 
> equivalent to /s1 == s2/
> Deduplication is performed in a separate thread so it could be delayed 
> a bit.
> Tests are away about possible delay and give another chance if 
> deduplication hasn't
> happened by the moment of check.
> But tests wait for deduplication in infinitive loop, so if 
> deduplication doesn't work the tests
> will timeout, leaving hanging VM after. Which is not very elegant.
>
> The fix is simple: replace infinitive loops with limited ones and 
> report failure.
> The logic of the tests hasn't changed.
>
> http://cr.openjdk.java.net/~dfazunen/8050464/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8050464
>
> Any comments are welcome.
>
> Thanks,
> Dima
>
>
>

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

From bengt.rutisson at oracle.com  Thu Aug  7 07:08:08 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 07 Aug 2014 09:08:08 +0200
Subject: [hdk8u40] Request for review (s) - 8031323: Optionally align
	objects copied to survivor spaces
In-Reply-To: <53E26B6A.2070905@oracle.com>
References: <53267CBB.9020804@oracle.com>
	<53E147A5.2070501@oracle.com>	<1407317194.2656.15.camel@cirrus>
	<53E26B6A.2070905@oracle.com>
Message-ID: <53E325D8.6050903@oracle.com>


Jon,

On 2014-08-06 19:52, Jon Masamitsu wrote:
>
> On 8/6/2014 2:26 AM, Thomas Schatzl wrote:
>> Hi Jon,
>>
>> On Tue, 2014-08-05 at 14:07 -0700, Jon Masamitsu wrote:
>>> This is a backport from jdk9.  The patch applied cleanly.
>>>
>>> 8031323: Optionally align objects copied to survivor spaces
>>>
>>> Add the option to specify an alignment for allocations into the
>>> survivor spaces.  Survivor space allocations will overflow if the
>>> survivor spaces have not been increased.   The expected use
>>> is to align survivor space allocations to cache line sizes.
>>>
>>> This is the webrev for the patch from jdk9.
>>>
>>> http://cr.openjdk.java.net/~jmasa/8031323/webrev.00/
>>>
>>> I made a change to the error message in arguments.cpp
>>> here.  This change was based on a review comment I received
>>> after the push to jdk9
>> I would prefer if the change to the message were made to jdk9 first, and
>> then both changes backported to 8u.
> Thomas,
>
> I will do that.  All your work to keep the jdk9 and the jdk8u sources
> in sync (and backports easier) is very much appreciated by me.
>
> All,
>
> I'm removing the webrev_delta.00 from the code review request.

That means that the backport applied cleanly, right? In that case I 
guess you don't need any reviews to push to the 8u repo. Let me know if 
I'm misunderstanding. If so, I will take a look at the webrev.00 webrev.

Thanks,
Bengt

>
> jon
>
>>
>> Otherwise it is hard to see what has already been backported and what
>> not. (Say, by diffing the the summary lines of both branches).
>>
>> Thanks,
>>    Thomas
>>
>>
>>
>



From marcus.larsson at oracle.com  Thu Aug  7 08:08:23 2014
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Thu, 07 Aug 2014 10:08:23 +0200
Subject: RFR (XS): 80357290: Code using assert(is_oop_or_null) needs better
	error messages
In-Reply-To: <53E2693B.4010403@oracle.com>
References: <53E1E71E.5010408@oracle.com>
	<1407317063.2656.13.camel@cirrus>	<53E230D5.1020401@oracle.com>
	<53E2693B.4010403@oracle.com>
Message-ID: <53E333F7.3020301@oracle.com>

Hi Jon,

Putting the assert in a function would remove the information about file 
and line number for triggered asserts.
Perhaps we could make a macro for this, but I think it might just be 
simpler to keep them as regular asserts in this case.

Thanks,
Marcus


On 08/06/2014 07:43 PM, Jon Masamitsu wrote:
> Marcus,
>
> There are debug functions that just do assertion checking.
> For example, assert_locked_or_safepoint() in mutexLocker.cpp.
> Would it make it easier to create an
>
> void assert_is_oop_or_null(oop obj) {
>   assert(obj->is_oop_or_null(), err_msg())"Expected an oop or NULL at 
> " PTR_FORMAT, p2i(obj);
> }
>
> and use that where you can?  Some of the uses have more specific messages
> so this won't work everywhere.
>
> Jon
>
>
>
> On 8/6/2014 6:42 AM, Marcus Larsson wrote:
>> Hi Thomas,
>>
>> I like your suggestion and updated the changeset.
>>
>> New CR:
>> http://cr.openjdk.java.net/~brutisso/webrev-8035729v2/
>>
>> Thanks,
>> Marcus
>>
>> On 08/06/2014 11:24 AM, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Wed, 2014-08-06 at 10:28 +0200, Marcus Larsson wrote:
>>>> Hi,
>>>>
>>>> Can I have reviews for this small change adding oop information to
>>>> is_oop_or_null assert fail messages?
>>>>
>>>> CR:
>>>> http://cr.openjdk.java.net/~brutisso/webrev-8035729/
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8035729/
>>>    not sure what the other think, but is it worth to try to make the
>>> error messages themselves be more uniform?
>>> While I do not want to be all the same, we have:
>>>
>>> 1) expected an oop or NULL
>>> 2) expected an oop or NULL:
>>> 3) Not an oop? (
>>> 4) check for header:
>>> 5) should be an oop now:
>>> 6) Object should be whole at this point:
>>> 7) Not an oop:
>>> 8) discovered field is bad:
>>> 9) bad referent:
>>> 10) bad next field:
>>> 11) bad discovered field:
>>> 12) should always be an oop:
>>>
>>> Some suggestions:
>>>
>>> - Capitalize the first letter of the sentences
>>> - change 1 to "Expected an oop or NULL at "
>>> - replace 2,3,5,6,7,12 by 1
>>> - change 4,9-11 to "Expected an oop for <type> field at "
>>>
>>> Otherwise the change is good.
>>>
>>> Thanks,
>>>    Thomas
>>>
>>>
>>>
>>
>



From dmitry.fazunenko at oracle.com  Thu Aug  7 10:01:11 2014
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko)
Date: Thu, 07 Aug 2014 14:01:11 +0400
Subject: RFR: (S) 8050464: G1 string deduplication tests hang/timeout
	and leave running processes consuming all resources
In-Reply-To: <53E2885B.6040609@oracle.com>
References: <53737D83.2050205@oracle.com> <53E24F6F.5000704@oracle.com>
	<53E2885B.6040609@oracle.com>
Message-ID: <53E34E67.5060809@oracle.com>

Jon,

Thanks for looking!
I love printing as much debug info as possible. But in this case I have 
nothing to add.
BTW, the deduplication tests are full of various System.out.prinltn(), 
so I think the it will be enough information in case of failure.

I modified a little the code to make test fail. The jtr is attached. 
Please let me know if you believe that more data need to be printed.

Thanks,
Dima

On 06.08.2014 23:56, Jon Masamitsu wrote:
> Dima,
>
> If the test fails, can you print the strings with System.out.println() or
> System.err.println()?  Any information about the strings might be
> useful to understand why deduplication didn't work or why the
> test thinks the deduplication didn't work (in case something
> happens that the test doesn't expect)?
>
> Jon
>
> On 8/6/2014 8:53 AM, Dmitry Fazunenko wrote:
>> Hi,
>>
>> Would you please look at the simple fix of String Deduplication tests.
>>
>> Description:
>>
>> When string deduplication has happened /s1.equals(s2)/ will be 
>> equivalent to /s1 == s2/
>> Deduplication is performed in a separate thread so it could be 
>> delayed a bit.
>> Tests are away about possible delay and give another chance if 
>> deduplication hasn't
>> happened by the moment of check.
>> But tests wait for deduplication in infinitive loop, so if 
>> deduplication doesn't work the tests
>> will timeout, leaving hanging VM after. Which is not very elegant.
>>
>> The fix is simple: replace infinitive loops with limited ones and 
>> report failure.
>> The logic of the tests hasn't changed.
>>
>> http://cr.openjdk.java.net/~dfazunen/8050464/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8050464
>>
>> Any comments are welcome.
>>
>> Thanks,
>> Dima
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140807/a3b5a083/attachment.htm>
-------------- next part --------------
#Test Results (version 2)
#Thu Aug 07 13:51:17 MSK 2014
#-----testdescription-----
$file=/home/dfazunen/ws/hs-gc/test/gc/g1/TestStringDeduplicationFullGC.java
$root=/home/dfazunen/ws/hs-gc/test
keywords=bug8029075 gc
library=/testlibrary
run=ASSUMED_ACTION main TestStringDeduplicationFullGC\n
source=TestStringDeduplicationFullGC.java
title=Test string deduplication during full GC

#-----environment-----

#-----testresult-----
description=file\:/home/dfazunen/ws/hs-gc/test/gc/g1/TestStringDeduplicationFullGC.java
elapsed=17794 0\:00\:17.794
end=Thu Aug 07 13\:51\:17 MSK 2014
environment=regtest
execStatus=Failed. Execution failed\: `main' threw exception\: java.lang.RuntimeException\: Expected to get exit value of [0]
harnessLoaderMode=Classpath Loader
harnessVariety=Full Bundle
hostname=localhost
javatestOS=SunOS 5.11 (amd64)
javatestVersion=4.5
jtregVersion=jtreg 4.0 dev b00
script=com.sun.javatest.regtest.RegressionScript 
sections=script_messages build compile main
start=Thu Aug 07 13\:50\:59 MSK 2014
test=gc/g1/TestStringDeduplicationFullGC.java
totalTime=17801
user.name=dfazunen
work=/home/dfazunen/ws/hs-gc/test/JTwork/gc/g1

#section:script_messages
----------messages:(5/219)----------
JDK under test: (/set/java/re/jdk/9/promoted/ea/b24/binaries/solaris-x64)
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b24)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b24, mixed mode)


#section:build
----------messages:(3/114)----------
command: build TestStringDeduplicationFullGC
reason: Named class compiled on demand
elapsed time (seconds): 3.402
result: Passed. Build successful

#section:compile
----------messages:(3/194)----------
command: compile -XDignore.symbol.file=true /home/dfazunen/ws/hs-gc/test/gc/g1/TestStringDeduplicationFullGC.java
reason: .class file out of date or does not exist
elapsed time (seconds): 3.383
----------rerun:(20/1458)*----------
DISPLAY=fa:0.0 \\
GNOME_DESKTOP_SESSION_ID=this-is-deprecated \\
HOME=/home/dfazunen \\
LANG=ru_RU.UTF-8 \\
LC_ALL=C \\
PATH=/bin:/usr/bin \\
PRINTER=spb04p14 \\
    /set/java/re/jdk/9/promoted/ea/b24/binaries/solaris-x64/bin/javac \\
        -J-Dtest.vm.opts= \\
        -J-Dtest.jdk=/set/java/re/jdk/9/promoted/ea/b24/binaries/solaris-x64 \\
        -J-Dtest.timeout.factor=1.0 \\
        -J-Dtest.src.path=/home/dfazunen/ws/hs-gc/test/gc/g1:/home/dfazunen/ws/hs-gc/test/testlibrary \\
        -J-Dtest.compiler.opts= \\
        -J-Dcompile.jdk=/set/java/re/jdk/9/promoted/ea/b24/binaries/solaris-x64 \\
        -J-Dtest.classes=/home/dfazunen/ws/hs-gc/test/JTwork/classes/gc/g1 \\
        -J-Dtest.class.path=/home/dfazunen/ws/hs-gc/test/JTwork/classes/gc/g1:/home/dfazunen/ws/hs-gc/test/JTwork/classes/testlibrary \\
        -J-Dtest.java.opts= \\
        -J-Dtest.src=/home/dfazunen/ws/hs-gc/test/gc/g1 \\
        -J-Dtest.tool.vm.opts= \\
        -d /home/dfazunen/ws/hs-gc/test/JTwork/classes/gc/g1 -classpath /home/dfazunen/ws/jtreg/dist/jtreg/lib/javatest.jar:/home/dfazunen/ws/jtreg/dist/jtreg/lib/jtreg.jar:/home/dfazunen/ws/hs-gc/test/JTwork/classes/gc/g1:/home/dfazunen/ws/hs-gc/test/gc/g1:/set/java/re/jdk/9/promoted/ea/b24/binaries/solaris-x64/lib/tools.jar -sourcepath /home/dfazunen/ws/hs-gc/test/gc/g1:/home/dfazunen/ws/hs-gc/test/testlibrary -XDignore.symbol.file=true /home/dfazunen/ws/hs-gc/test/gc/g1/TestStringDeduplicationFullGC.java
----------System.out:(0/0)----------
----------System.err:(0/0)----------
result: Passed. Compilation successful

#section:main
----------messages:(3/158)----------
command: main TestStringDeduplicationFullGC
reason: Assumed action based on file name: run main TestStringDeduplicationFullGC 
elapsed time (seconds): 11.505
----------System.out:(64/3695)----------
Command line: [/set/java/re/jdk/9/promoted/ea/b24/binaries/solaris-x64/bin/java -d64 -Xmn50m -Xms100m -Xmx100m -XX:+UseG1GC -XX:+UnlockDiagnosticVMOptions -XX:+VerifyAfterGC -XX:+PrintGC -XX:+PrintStringDeduplicationStatistics -XX:+UseStringDeduplication -XX:StringDeduplicationAgeThreshold=3 TestStringDeduplicationTools$DeduplicationTest 10000 5000 3 FullGC ]
Begin: DeduplicationTest
Creating strings: total=10000, unique=5000
Begin: Full GC 1/3
#0: [Full GC (System.gc())  VerifyAfterGC:[Verifying threads heap Roots HeapRegionSets HeapRegions RemSet StrDedup syms strs zone dict metaspace chunks hand C-heap code cache ]
 4609K->1916K(100M), 0.0202693 secs]
[GC concurrent-string-deduplication, 1230.9K->633.2K(597.7K), avg 48.6%, 0.0040028 secs]
   [Last Exec: 0.0040028 secs, Idle: 0.0000005 secs, Blocked: 0/0.0000000 secs]
      [Inspected:           11835]
         [Skipped:              0(  0.0%)]
         [Hashed:           10607( 89.6%)]
         [Known:              946(  8.0%)]
         [New:              10889( 92.0%)   1230.9K]
      [Deduplicated:         5126( 47.1%)    597.7K( 48.6%)]
         [Young:                0(  0.0%)      0.0B(  0.0%)]
         [Old:               5126(100.0%)    597.7K(100.0%)]
   [Total Exec: 1/0.0040028 secs, Idle: 1/0.0000005 secs, Blocked: 0/0.0000000 secs]
      [Inspected:           11835]
         [Skipped:              0(  0.0%)]
         [Hashed:           10607( 89.6%)]
         [Known:              946(  8.0%)]
         [New:              10889( 92.0%)   1230.9K]
      [Deduplicated:         5126( 47.1%)    597.7K( 48.6%)]
         [Young:                0(  0.0%)      0.0B(  0.0%)]
         [Old:               5126(100.0%)    597.7K(100.0%)]
   [Table]
      [Memory Usage: 165.2K]
      [Size: 1024, Min: 1024, Max: 16777216]
      [Entries: 6709, Load: 655.2%, Cached: 0, Added: 6726, Removed: 17]
      [Resize Count: 0, Shrink Threshold: 682(66.7%), Grow Threshold: 2048(200.0%)]
      [Rehash Count: 0, Rehash Threshold: 120, Hash Seed: 0x0]
      [Age Threshold: 3]
   [Queue]
      [Dropped: 0]
End: Full GC 1/3
Begin: Full GC 2/3
#1: [Full GC (System.gc())  VerifyAfterGC:[Verifying threads heap Roots HeapRegionSets HeapRegions RemSet StrDedup syms strs zone dict metaspace chunks hand C-heap code cache ]
 2428K->1309K(100M), 0.0150873 secs]
End: Full GC 2/3
Begin: Full GC 3/3
#2: [Full GC (System.gc())  VerifyAfterGC:[Verifying threads heap Roots HeapRegionSets HeapRegions RemSet StrDedup syms strs zone dict metaspace chunks hand C-heap code cache ]
 1821K->1309K(100M), 0.0136155 secs]
End: Full GC 3/3
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...

----------System.err:(92/5030)----------
Exception in thread "main" java.lang.RuntimeException: String verification failed
	at TestStringDeduplicationTools.verifyStrings(TestStringDeduplicationTools.java:181)
	at TestStringDeduplicationTools.access$200(TestStringDeduplicationTools.java:35)
	at TestStringDeduplicationTools$DeduplicationTest.main(TestStringDeduplicationTools.java:217)

 stdout: [Begin: DeduplicationTest
Creating strings: total=10000, unique=5000
Begin: Full GC 1/3
#0: [Full GC (System.gc())  VerifyAfterGC:[Verifying threads heap Roots HeapRegionSets HeapRegions RemSet StrDedup syms strs zone dict metaspace chunks hand C-heap code cache ]
 4609K->1916K(100M), 0.0202693 secs]
[GC concurrent-string-deduplication, 1230.9K->633.2K(597.7K), avg 48.6%, 0.0040028 secs]
   [Last Exec: 0.0040028 secs, Idle: 0.0000005 secs, Blocked: 0/0.0000000 secs]
      [Inspected:           11835]
         [Skipped:              0(  0.0%)]
         [Hashed:           10607( 89.6%)]
         [Known:              946(  8.0%)]
         [New:              10889( 92.0%)   1230.9K]
      [Deduplicated:         5126( 47.1%)    597.7K( 48.6%)]
         [Young:                0(  0.0%)      0.0B(  0.0%)]
         [Old:               5126(100.0%)    597.7K(100.0%)]
   [Total Exec: 1/0.0040028 secs, Idle: 1/0.0000005 secs, Blocked: 0/0.0000000 secs]
      [Inspected:           11835]
         [Skipped:              0(  0.0%)]
         [Hashed:           10607( 89.6%)]
         [Known:              946(  8.0%)]
         [New:              10889( 92.0%)   1230.9K]
      [Deduplicated:         5126( 47.1%)    597.7K( 48.6%)]
         [Young:                0(  0.0%)      0.0B(  0.0%)]
         [Old:               5126(100.0%)    597.7K(100.0%)]
   [Table]
      [Memory Usage: 165.2K]
      [Size: 1024, Min: 1024, Max: 16777216]
      [Entries: 6709, Load: 655.2%, Cached: 0, Added: 6726, Removed: 17]
      [Resize Count: 0, Shrink Threshold: 682(66.7%), Grow Threshold: 2048(200.0%)]
      [Rehash Count: 0, Rehash Threshold: 120, Hash Seed: 0x0]
      [Age Threshold: 3]
   [Queue]
      [Dropped: 0]
End: Full GC 1/3
Begin: Full GC 2/3
#1: [Full GC (System.gc())  VerifyAfterGC:[Verifying threads heap Roots HeapRegionSets HeapRegions RemSet StrDedup syms strs zone dict metaspace chunks hand C-heap code cache ]
 2428K->1309K(100M), 0.0150873 secs]
End: Full GC 2/3
Begin: Full GC 3/3
#2: [Full GC (System.gc())  VerifyAfterGC:[Verifying threads heap Roots HeapRegionSets HeapRegions RemSet StrDedup syms strs zone dict metaspace chunks hand C-heap code cache ]
 1821K->1309K(100M), 0.0136155 secs]
End: Full GC 3/3
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
Verifying strings: total=10000, uniqueFound=5000, uniqueExpected=5000
Deduplication not completed, waiting...
];
 stderr: [Exception in thread "main" java.lang.RuntimeException: String verification failed
	at TestStringDeduplicationTools.verifyStrings(TestStringDeduplicationTools.java:181)
	at TestStringDeduplicationTools.access$200(TestStringDeduplicationTools.java:35)
	at TestStringDeduplicationTools$DeduplicationTest.main(TestStringDeduplicationTools.java:217)
]
 exitValue = 1

java.lang.RuntimeException: Expected to get exit value of [0]

	at com.oracle.java.testlibrary.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:296)
	at TestStringDeduplicationTools.testFullGC(TestStringDeduplicationTools.java:356)
	at TestStringDeduplicationFullGC.main(TestStringDeduplicationFullGC.java:34)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:484)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:745)

JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected to get exit value of [0]

JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0]
----------rerun:(21/1320)*----------
DISPLAY=fa:0.0 \\
GNOME_DESKTOP_SESSION_ID=this-is-deprecated \\
HOME=/home/dfazunen \\
LANG=ru_RU.UTF-8 \\
LC_ALL=C \\
PATH=/bin:/usr/bin \\
PRINTER=spb04p14 \\
CLASSPATH=/home/dfazunen/ws/jtreg/dist/jtreg/lib/javatest.jar:/home/dfazunen/ws/jtreg/dist/jtreg/lib/jtreg.jar:/home/dfazunen/ws/hs-gc/test/JTwork/classes/gc/g1:/home/dfazunen/ws/hs-gc/test/gc/g1:/set/java/re/jdk/9/promoted/ea/b24/binaries/solaris-x64/lib/tools.jar \\
    /set/java/re/jdk/9/promoted/ea/b24/binaries/solaris-x64/bin/java \\
        -Dtest.vm.opts= \\
        -Dtest.jdk=/set/java/re/jdk/9/promoted/ea/b24/binaries/solaris-x64 \\
        -Dtest.timeout.factor=1.0 \\
        -Dtest.src.path=/home/dfazunen/ws/hs-gc/test/gc/g1:/home/dfazunen/ws/hs-gc/test/testlibrary \\
        -Dtest.compiler.opts= \\
        -Dcompile.jdk=/set/java/re/jdk/9/promoted/ea/b24/binaries/solaris-x64 \\
        -Dtest.classes=/home/dfazunen/ws/hs-gc/test/JTwork/classes/gc/g1 \\
        -Dtest.class.path=/home/dfazunen/ws/hs-gc/test/JTwork/classes/gc/g1:/home/dfazunen/ws/hs-gc/test/JTwork/classes/testlibrary \\
        -Dtest.java.opts= \\
        -Dtest.src=/home/dfazunen/ws/hs-gc/test/gc/g1 \\
        -Dtest.tool.vm.opts= \\
        com.sun.javatest.regtest.MainWrapper /home/dfazunen/ws/hs-gc/test/JTwork/classes/gc/g1/TestStringDeduplicationFullGC.jta
result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0]


test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0]

From thomas.schatzl at oracle.com  Thu Aug  7 15:43:22 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 07 Aug 2014 17:43:22 +0200
Subject: RFR (XXS): 8054362: gc/g1/TestEagerReclaimHumongousRegions2.java
	timeout
Message-ID: <1407426202.2631.27.camel@cirrus>

Hi all,

  can I have reviews for this following tiny change? The test mentioned
in the subject times out on very slow machines (Atom N-270) on aurora.

This is fixed by decreasing the number of internal runs of the test.

The given value (2) has been determined to take ~1min on that machine,
while preserving the crash reproducability without the fix on large
machines. Going lower makes the test not fail sometimes.

CR:
https://bugs.openjdk.java.net/browse/JDK-8054362
Webrev:
http://cr.openjdk.java.net/~tschatzl/8054362/webrev/
Testing:
test case, jprt

Thanks,
Thomas



From dmitry.fazunenko at oracle.com  Thu Aug  7 16:35:30 2014
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko)
Date: Thu, 07 Aug 2014 20:35:30 +0400
Subject: RFR (XXS): 8054362: gc/g1/TestEagerReclaimHumongousRegions2.java
	timeout
In-Reply-To: <1407426202.2631.27.camel@cirrus>
References: <1407426202.2631.27.camel@cirrus>
Message-ID: <53E3AAD2.4080306@oracle.com>

Hi Thomas,

The fix you made is certainly safe but it makes the test weaker.

As I see from your explanation the timeout happens only on very slow 
machines.
What if test tries to detect if the machine is slow or not and set the 
iteration number accordingly.
I mean something like:

int iterations = 20;

if (|Runtime.getRuntime().availableProcessors()|  < 2 ||

          |Runtime.getRuntime().||maxMemory() < 1G)|  {

   // perhaps the machine is slow, reducing iterations to avoid timeout

   iterations = 2;

}

|
Another suggestion (not related to that bug). What if update the test to check with various region sizes?
Not only with 1M?

Thanks,
Dima
|


On 07.08.2014 19:43, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for this following tiny change? The test mentioned
> in the subject times out on very slow machines (Atom N-270) on aurora.
>
> This is fixed by decreasing the number of internal runs of the test.
>
> The given value (2) has been determined to take ~1min on that machine,
> while preserving the crash reproducability without the fix on large
> machines. Going lower makes the test not fail sometimes.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8054362
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8054362/webrev/
> Testing:
> test case, jprt
>
> Thanks,
> Thomas
>

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

From jon.masamitsu at oracle.com  Thu Aug  7 18:03:15 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 07 Aug 2014 11:03:15 -0700
Subject: [hdk8u40] Request for review (s) - 8031323: Optionally align
	objects copied to survivor spaces
In-Reply-To: <53E325D8.6050903@oracle.com>
References: <53267CBB.9020804@oracle.com>
	<53E147A5.2070501@oracle.com>	<1407317194.2656.15.camel@cirrus>
	<53E26B6A.2070905@oracle.com> <53E325D8.6050903@oracle.com>
Message-ID: <53E3BF63.6010409@oracle.com>


On 08/07/2014 12:08 AM, Bengt Rutisson wrote:
>
> Jon,
>
> On 2014-08-06 19:52, Jon Masamitsu wrote:
>>
>> On 8/6/2014 2:26 AM, Thomas Schatzl wrote:
>>> Hi Jon,
>>>
>>> On Tue, 2014-08-05 at 14:07 -0700, Jon Masamitsu wrote:
>>>> This is a backport from jdk9.  The patch applied cleanly.
>>>>
>>>> 8031323: Optionally align objects copied to survivor spaces
>>>>
>>>> Add the option to specify an alignment for allocations into the
>>>> survivor spaces.  Survivor space allocations will overflow if the
>>>> survivor spaces have not been increased.   The expected use
>>>> is to align survivor space allocations to cache line sizes.
>>>>
>>>> This is the webrev for the patch from jdk9.
>>>>
>>>> http://cr.openjdk.java.net/~jmasa/8031323/webrev.00/
>>>>
>>>> I made a change to the error message in arguments.cpp
>>>> here.  This change was based on a review comment I received
>>>> after the push to jdk9
>>> I would prefer if the change to the message were made to jdk9 first, 
>>> and
>>> then both changes backported to 8u.
>> Thomas,
>>
>> I will do that.  All your work to keep the jdk9 and the jdk8u sources
>> in sync (and backports easier) is very much appreciated by me.
>>
>> All,
>>
>> I'm removing the webrev_delta.00 from the code review request.
>
> That means that the backport applied cleanly, right? In that case I 
> guess you don't need any reviews to push to the 8u repo. Let me know 
> if I'm misunderstanding. If so, I will take a look at the webrev.00 
> webrev.

Yes, removing that part of the change (webrev_delta.00) means that
the patch applied cleanly.  Thanks.

Jon

>
> Thanks,
> Bengt
>
>>
>> jon
>>
>>>
>>> Otherwise it is hard to see what has already been backported and what
>>> not. (Say, by diffing the the summary lines of both branches).
>>>
>>> Thanks,
>>>    Thomas
>>>
>>>
>>>
>>
>



From jon.masamitsu at oracle.com  Thu Aug  7 18:07:53 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 07 Aug 2014 11:07:53 -0700
Subject: RFR (XS): 80357290: Code using assert(is_oop_or_null) needs better
	error messages
In-Reply-To: <53E333F7.3020301@oracle.com>
References: <53E1E71E.5010408@oracle.com>	<1407317063.2656.13.camel@cirrus>	<53E230D5.1020401@oracle.com>	<53E2693B.4010403@oracle.com>
	<53E333F7.3020301@oracle.com>
Message-ID: <53E3C079.6090404@oracle.com>


On 08/07/2014 01:08 AM, Marcus Larsson wrote:
> Hi Jon,
>
> Putting the assert in a function would remove the information about 
> file and line number for triggered asserts.

Yes, you're right about that but the information
about where the assertion failed is in the hs_err
log so should almost always be available.

> Perhaps we could make a macro for this, but I think it might just be 
> simpler to keep them as regular asserts in this case.

Not worth a macro.  Your call.  I think it makes it
easier to maintain.  I personally would trade the
line number/file info in the assert message for
the reduced code duplication.

Jon

>
> Thanks,
> Marcus
>
>
> On 08/06/2014 07:43 PM, Jon Masamitsu wrote:
>> Marcus,
>>
>> There are debug functions that just do assertion checking.
>> For example, assert_locked_or_safepoint() in mutexLocker.cpp.
>> Would it make it easier to create an
>>
>> void assert_is_oop_or_null(oop obj) {
>>   assert(obj->is_oop_or_null(), err_msg())"Expected an oop or NULL at 
>> " PTR_FORMAT, p2i(obj);
>> }
>>
>> and use that where you can?  Some of the uses have more specific 
>> messages
>> so this won't work everywhere.
>>
>> Jon
>>
>>
>>
>> On 8/6/2014 6:42 AM, Marcus Larsson wrote:
>>> Hi Thomas,
>>>
>>> I like your suggestion and updated the changeset.
>>>
>>> New CR:
>>> http://cr.openjdk.java.net/~brutisso/webrev-8035729v2/
>>>
>>> Thanks,
>>> Marcus
>>>
>>> On 08/06/2014 11:24 AM, Thomas Schatzl wrote:
>>>> Hi,
>>>>
>>>> On Wed, 2014-08-06 at 10:28 +0200, Marcus Larsson wrote:
>>>>> Hi,
>>>>>
>>>>> Can I have reviews for this small change adding oop information to
>>>>> is_oop_or_null assert fail messages?
>>>>>
>>>>> CR:
>>>>> http://cr.openjdk.java.net/~brutisso/webrev-8035729/
>>>>>
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8035729/
>>>>    not sure what the other think, but is it worth to try to make the
>>>> error messages themselves be more uniform?
>>>> While I do not want to be all the same, we have:
>>>>
>>>> 1) expected an oop or NULL
>>>> 2) expected an oop or NULL:
>>>> 3) Not an oop? (
>>>> 4) check for header:
>>>> 5) should be an oop now:
>>>> 6) Object should be whole at this point:
>>>> 7) Not an oop:
>>>> 8) discovered field is bad:
>>>> 9) bad referent:
>>>> 10) bad next field:
>>>> 11) bad discovered field:
>>>> 12) should always be an oop:
>>>>
>>>> Some suggestions:
>>>>
>>>> - Capitalize the first letter of the sentences
>>>> - change 1 to "Expected an oop or NULL at "
>>>> - replace 2,3,5,6,7,12 by 1
>>>> - change 4,9-11 to "Expected an oop for <type> field at "
>>>>
>>>> Otherwise the change is good.
>>>>
>>>> Thanks,
>>>>    Thomas
>>>>
>>>>
>>>>
>>>
>>
>



From jon.masamitsu at oracle.com  Thu Aug  7 18:20:45 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 07 Aug 2014 11:20:45 -0700
Subject: RFR: (S) 8050464: G1 string deduplication tests hang/timeout
	and leave running processes consuming all resources
In-Reply-To: <53E34E67.5060809@oracle.com>
References: <53737D83.2050205@oracle.com> <53E24F6F.5000704@oracle.com>
	<53E2885B.6040609@oracle.com> <53E34E67.5060809@oracle.com>
Message-ID: <53E3C37D.6010406@oracle.com>


On 08/07/2014 03:01 AM, Dmitry Fazunenko wrote:
> Jon,
>
> Thanks for looking!
> I love printing as much debug info as possible. But in this case I 
> have nothing to add.
> BTW, the deduplication tests are full of various System.out.prinltn(), 
> so I think the it will be enough information in case of failure.
>
> I modified a little the code to make test fail. The jtr is attached. 
> Please let me know if you believe that more data need to be printed.

Yes, lots of output on failures.  I looked for some output that told
me the addresses of the two strings (the two that don't verify)
and the addresses of their char arrays.  I couldn't find it.
I think if I were debugging a failure, that's the first thing I would
want to see.

Jon

>
> Thanks,
> Dima
>
> On 06.08.2014 23:56, Jon Masamitsu wrote:
>> Dima,
>>
>> If the test fails, can you print the strings with System.out.println() or
>> System.err.println()?  Any information about the strings might be
>> useful to understand why deduplication didn't work or why the
>> test thinks the deduplication didn't work (in case something
>> happens that the test doesn't expect)?
>>
>> Jon
>>
>> On 8/6/2014 8:53 AM, Dmitry Fazunenko wrote:
>>> Hi,
>>>
>>> Would you please look at the simple fix of String Deduplication tests.
>>>
>>> Description:
>>>
>>> When string deduplication has happened /s1.equals(s2)/ will be 
>>> equivalent to /s1 == s2/
>>> Deduplication is performed in a separate thread so it could be 
>>> delayed a bit.
>>> Tests are away about possible delay and give another chance if 
>>> deduplication hasn't
>>> happened by the moment of check.
>>> But tests wait for deduplication in infinitive loop, so if 
>>> deduplication doesn't work the tests
>>> will timeout, leaving hanging VM after. Which is not very elegant.
>>>
>>> The fix is simple: replace infinitive loops with limited ones and 
>>> report failure.
>>> The logic of the tests hasn't changed.
>>>
>>> http://cr.openjdk.java.net/~dfazunen/8050464/webrev.01/
>>> https://bugs.openjdk.java.net/browse/JDK-8050464
>>>
>>> Any comments are welcome.
>>>
>>> Thanks,
>>> Dima
>>>
>>>
>>>
>>
>

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

From thomas.schatzl at oracle.com  Thu Aug  7 20:19:31 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 07 Aug 2014 22:19:31 +0200
Subject: RFR (XS): 8052170: G1 asserts at collection exit with
	-XX:-G1DeferredRSUpdate
In-Reply-To: <53E27749.3060704@oracle.com>
References: <1407247637.2706.59.camel@cirrus>
	<1407334535.2656.41.camel@cirrus> <53E27749.3060704@oracle.com>
Message-ID: <1407442771.2739.18.camel@cirrus>

Hi,

On Wed, 2014-08-06 at 11:43 -0700, Jon Masamitsu wrote:
> On 8/6/2014 7:15 AM, Thomas Schatzl wrote:
> > Hi all,
> >
> >    Bengt had some suggestions to simplify the change: just skip
> > verification for the values that we do not print anyway.
> >
> > As this makes the change a lot simpler, I changed it as suggested. New
> > webrev is at
> > http://cr.openjdk.java.net/~tschatzl/8052170/webrev.1/
> 
> Yes, this is nicer.
> 
> Reviewed.

Thanks Jon, Bengt for the reviews!

Thomas



From bengt.rutisson at oracle.com  Fri Aug  8 12:35:07 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 08 Aug 2014 14:35:07 +0200
Subject: RFR (XXS): 8054362: gc/g1/TestEagerReclaimHumongousRegions2.java
	timeout
In-Reply-To: <53E3AAD2.4080306@oracle.com>
References: <1407426202.2631.27.camel@cirrus> <53E3AAD2.4080306@oracle.com>
Message-ID: <53E4C3FB.4080903@oracle.com>


Hi Thomas and Dima,

On 2014-08-07 18:35, Dmitry Fazunenko wrote:
> Hi Thomas,
>
> The fix you made is certainly safe but it makes the test weaker.
>
> As I see from your explanation the timeout happens only on very slow 
> machines.
> What if test tries to detect if the machine is slow or not and set the 
> iteration number accordingly.
> I mean something like:
>
> int iterations = 20;
> if (|Runtime.getRuntime().availableProcessors()|  < 2 ||
>           |Runtime.getRuntime().||maxMemory() < 1G)|  {
>    // perhaps the machine is slow, reducing iterations to avoid timeout
>    iterations = 2;
> }
> |
> Another suggestion (not related to that bug). What if update the test to check with various region sizes?
> Not only with 1M?|

Could we make the test check the time? Maybe do the loop for 1 minute 
but no more than 20 iterations?

Bengt

> |
>
> Thanks,
> Dima
> |
>
> On 07.08.2014 19:43, Thomas Schatzl wrote:
>> Hi all,
>>
>>    can I have reviews for this following tiny change? The test mentioned
>> in the subject times out on very slow machines (Atom N-270) on aurora.
>>
>> This is fixed by decreasing the number of internal runs of the test.
>>
>> The given value (2) has been determined to take ~1min on that machine,
>> while preserving the crash reproducability without the fix on large
>> machines. Going lower makes the test not fail sometimes.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8054362
>> Webrev:
>> http://cr.openjdk.java.net/~tschatzl/8054362/webrev/
>> Testing:
>> test case, jprt
>>
>> Thanks,
>> Thomas
>>
>

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

From thomas.schatzl at oracle.com  Mon Aug 11 09:12:04 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 11 Aug 2014 11:12:04 +0200
Subject: RFR (XXS): 8054362:
	gc/g1/TestEagerReclaimHumongousRegions2.java timeout
In-Reply-To: <53E4C3FB.4080903@oracle.com>
References: <1407426202.2631.27.camel@cirrus> <53E3AAD2.4080306@oracle.com>
	<53E4C3FB.4080903@oracle.com>
Message-ID: <1407748324.2718.6.camel@cirrus>

Hi Bengt, Dima,

On Fri, 2014-08-08 at 14:35 +0200, Bengt Rutisson wrote:
> 
> Hi Thomas and Dima,
> 
> On 2014-08-07 18:35, Dmitry Fazunenko wrote:
> 
> > Hi Thomas,
> > 
> > The fix you made is certainly safe but it makes the test weaker.
> > 
> > As I see from your explanation the timeout happens only on very slow
> > machines.
> > What if test tries to detect if the machine is slow or not and set
> > the iteration number accordingly.
> > I mean something like:
> > 
> > int iterations = 20;
> > if (Runtime.getRuntime().availableProcessors() < 2 || 
> >          Runtime.getRuntime().maxMemory() < 1G) {
> >   // perhaps the machine is slow, reducing iterations to avoid timeout
> >   iterations = 2;
> > }
> > 
> > Another suggestion (not related to that bug). What if update the test to check with various region sizes?
> > Not only with 1M?

There does not seem to be new information gain when running the test
with different region sizes as the problem is independent of it. Also,
the test has been set up to be highly reproducible using a 1M region
size and the given heap and object sizes.

It would take considerable effort to modify it for multiple region sizes
for no noticable gain.
> 
> Could we make the test check the time? Maybe do the loop for 1 minute
> but no more than 20 iterations?

I implemented this idea as it seems less failure prone than trying to
guess the speed of the machine. Fast machine easily finish the test
within the given time, slower ones should get enough coverage.

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

Webrev:
http://cr.openjdk.java.net/~tschatzl/8054362/webrev.1/

Testing:
jprt, local jtreg

Thanks,
Thomas



From erik.helin at oracle.com  Tue Aug 12 11:30:26 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Tue, 12 Aug 2014 13:30:26 +0200
Subject: RFR (XXS): 8054362: gc/g1/TestEagerReclaimHumongousRegions2.java
	timeout
In-Reply-To: <1407748324.2718.6.camel@cirrus>
References: <1407426202.2631.27.camel@cirrus> <53E4C3FB.4080903@oracle.com>
	<1407748324.2718.6.camel@cirrus>
Message-ID: <1887164.b2EGSIRoRu@ehelin-laptop>

Hi Thomas,

On Monday 11 August 2014 11:12:04 AM Thomas Schatzl wrote:
> Hi Bengt, Dima,
> 
> On Fri, 2014-08-08 at 14:35 +0200, Bengt Rutisson wrote:
> > Hi Thomas and Dima,
> > 
> > On 2014-08-07 18:35, Dmitry Fazunenko wrote:
> > > Hi Thomas,
> > > 
> > > The fix you made is certainly safe but it makes the test weaker.
> > > 
> > > As I see from your explanation the timeout happens only on very slow
> > > machines.
> > > What if test tries to detect if the machine is slow or not and set
> > > the iteration number accordingly.
> > > I mean something like:
> > > 
> > > int iterations = 20;
> > > if (Runtime.getRuntime().availableProcessors() < 2 ||
> > > 
> > >          Runtime.getRuntime().maxMemory() < 1G) {
> > >   
> > >   // perhaps the machine is slow, reducing iterations to avoid timeout
> > >   iterations = 2;
> > > 
> > > }
> > > 
> > > Another suggestion (not related to that bug). What if update the test to
> > > check with various region sizes? Not only with 1M?
> 
> There does not seem to be new information gain when running the test
> with different region sizes as the problem is independent of it. Also,
> the test has been set up to be highly reproducible using a 1M region
> size and the given heap and object sizes.
> 
> It would take considerable effort to modify it for multiple region sizes
> for no noticable gain.
> 
> > Could we make the test check the time? Maybe do the loop for 1 minute
> > but no more than 20 iterations?
> 
> I implemented this idea as it seems less failure prone than trying to
> guess the speed of the machine. Fast machine easily finish the test
> within the given time, slower ones should get enough coverage.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8054362
> 
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8054362/webrev.1/

looks good!

Thanks,
Erik

> Testing:
> jprt, local jtreg
> 
> Thanks,
> Thomas



From thomas.schatzl at oracle.com  Tue Aug 12 15:09:04 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 12 Aug 2014 17:09:04 +0200
Subject: RFR (XL): 8054818: Refactor HeapRegionSeq to manage heap region and
	auxiliary data
Message-ID: <1407856144.2700.34.camel@cirrus>

Hi all,

  can I have reviews for this somewhat large refactoring change? It is
about refactoring the HeapRegionSeq class to manage heap region and
auxiliary data.

I.e. currently HeapRegionSeq only manages the HeapRegion instances
corresponding to the heap's region. The change gives HeapRegionSeq more
responsibilities, encapsulating functionality related to heap memory
management. This decreases the amount of responsibilities (and
complexity) for the G1CollectedHeap class: decisions about how heap
related memory is allocated/freed/iterated (i.e. how the heap regions
are actually allocated in the heap) is removed from G1CollectedHeap.

This change only changes the interface to this functionality. It is a
preparatory change for JDK-8038423 "G1: Decommit memory within the
heap", so the change might be slightly more extensive than really
required.

The RFR for JDK-8038423 will follow to look at it in context.

There is another CR that renames HeapRegionSeq to HeapRegionmanager too.

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

Webrev:
http://cr.openjdk.java.net/~tschatzl/8054818/webrev/

Testing:
jprt, nightly and bigapps (kitchensink, ...) with -XX:+UseG1GC

Thanks,
  Thomas






From thomas.schatzl at oracle.com  Tue Aug 12 15:12:07 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 12 Aug 2014 17:12:07 +0200
Subject: RFR (XXL): 8038423: G1: Decommit memory within the heap
Message-ID: <1407856327.2700.39.camel@cirrus>

Hi all,

  can I have reviews for this change? It implements the capability for
G1 to shrink/expand the heap on a per-region basis without the
constraint that shrinking/expansion needs to occur at the highest
address of the reserved space.

Further it implements automatic commit/uncommit of all (relevant) large
heap data structures (auxiliary data like block offset table, card
table, mark bitmaps, hot card cache) at the same time the corresponding
heap region is (un-)committed.

This change implements basic support for this new behavior: selection of
regions to (un-)commit is not particularly sophisticated.

For easier reviewing, some notes:
- start at the new initialization code in G1CollectedHeap::initialize()
- all memory commit/uncommit activity of auxiliary data is tied to
regions: the new G1RegionToSpaceMapper class manages translation between
regions and whatever granularity the auxiliary data is
committed/uncommitted.
- these G1RegionToSpaceMappers are managed by HeapRegionSeq.

This change is based on the review for JDK-8054818. As mentioned there,
there will be some cleanup CRs after this change: at least a CR to
rename HeapRegionSeq to HeapRegionManager, and another one that cleans
up the card table code.

They were split out for easier review, as they are quite large too but
do not contribute to the functionality.

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

Webrev:
http://cr.openjdk.java.net/~tschatzl/8038423/webrev/

Testing:
jprt, aurora (nightly, bigapps, lots of test suites) with -XX:+UseG1GC,
crm fuse

Thanks,
  Thomas





From jon.masamitsu at oracle.com  Tue Aug 12 20:29:37 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 12 Aug 2014 13:29:37 -0700
Subject: Request for review (small) 8026303: CMS: JVM intermittently
	crashes
	with "FreeList of size 258 violates Con,servation Principle" assert
In-Reply-To: <52900AE7.8040109@oracle.com>
References: <52900AE7.8040109@oracle.com>
Message-ID: <53EA7931.6070607@oracle.com>

This change has been reviewed before but the integration
was delayed so these are webrevs with respect to the current
source.

The patches applied cleanly and, except as noted below, the
changes in the .00 and .01 webrevs are equivalent.

New webrev for fix for the bug.

http://cr.openjdk.java.net/~jmasa/8026303/webrev.01/

New webrev for code restructuring where the
fix was made.

http://cr.openjdk.java.net/~jmasa/8026303/webrev_cleanup.01/

This change was applied in an earlier changeset so is no
longer part of this patch.

--- 
old/src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp 
  Fri Nov 22 14:41:11 2013
+++ 
new/src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp 
  Fri Nov 22 14:41:10 2013
@@ -158,7 +158,7 @@
                   " coal_deaths(" SIZE_FORMAT ")"
                   " + count(" SSIZE_FORMAT ")",
                   this, size(), _allocation_stats.prev_sweep(), 
_allocation_stats.split_births(),
-                 _allocation_stats.split_births(), 
_allocation_stats.split_deaths(),
+                 _allocation_stats.coal_births(), 
_allocation_stats.split_deaths(),
                   _allocation_stats.coal_deaths(), count()));
  }
  #endif

On 11/22/2013 05:54 PM, Jon Masamitsu wrote:
> 8026303: CMS: JVM intermittently crashes with "FreeList of size 258 
> violates Con
> servation Principle" assert
>
> CompactibleFreeListSpace:: par_get_chunk_of_blocks() replenishes
> the free list of a given size by splitting a larger chunk. The code
> searched for a block that was large enough to split. If a large enough
> chunk was found it was removed from the dictionary and a split death
> was recorded. If the remainder after splitting would be too small, that
> block was returned to the dictionary but forgot to fix the split death
> accounting
>
> The fix was to move the split death accounting to the point where
> it was known that the chunk would not be put back into the dictionary.
> There was also code moved which did the accounting for the
> _unallocated_block (updated it to account for the allocation which
> could change _unallocated_block).
>
> The fix
>
> http://cr.openjdk.java.net/~jmasa/8026303/webrev.00/
>
> A small amount of code refactoring was done and is in
> a second webrev (along with the fix above).  Both changes
> will be put back together.
>
> http://cr.openjdk.java.net/~jmasa/8026303/webrev_cleanup.00/
>
> Thanks.
>
> Jon
>
>
>



From jesper.wilhelmsson at oracle.com  Wed Aug 13 15:01:24 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 13 Aug 2014 17:01:24 +0200
Subject: RFR (XL): 8054818: Refactor HeapRegionSeq to manage heap region
	and auxiliary data
In-Reply-To: <1407856144.2700.34.camel@cirrus>
References: <1407856144.2700.34.camel@cirrus>
Message-ID: <53EB7DC4.8070001@oracle.com>

Looks good.

You made changes in vmStructs_g1.hpp. Did you verify that this didn't trigger 
any changes in the serviceability agent?
/Jesper

Thomas Schatzl skrev 12/8/14 17:09:
> Hi all,
>
>    can I have reviews for this somewhat large refactoring change? It is
> about refactoring the HeapRegionSeq class to manage heap region and
> auxiliary data.
>
> I.e. currently HeapRegionSeq only manages the HeapRegion instances
> corresponding to the heap's region. The change gives HeapRegionSeq more
> responsibilities, encapsulating functionality related to heap memory
> management. This decreases the amount of responsibilities (and
> complexity) for the G1CollectedHeap class: decisions about how heap
> related memory is allocated/freed/iterated (i.e. how the heap regions
> are actually allocated in the heap) is removed from G1CollectedHeap.
>
> This change only changes the interface to this functionality. It is a
> preparatory change for JDK-8038423 "G1: Decommit memory within the
> heap", so the change might be slightly more extensive than really
> required.
>
> The RFR for JDK-8038423 will follow to look at it in context.
>
> There is another CR that renames HeapRegionSeq to HeapRegionmanager too.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8054818
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8054818/webrev/
>
> Testing:
> jprt, nightly and bigapps (kitchensink, ...) with -XX:+UseG1GC
>
> Thanks,
>    Thomas
>
>
>
>


From jesper.wilhelmsson at oracle.com  Wed Aug 13 15:05:46 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 13 Aug 2014 17:05:46 +0200
Subject: RFR (XXL): 8038423: G1: Decommit memory within the heap
In-Reply-To: <1407856327.2700.39.camel@cirrus>
References: <1407856327.2700.39.camel@cirrus>
Message-ID: <53EB7ECA.3090901@oracle.com>

Looks good!
/Jesper

Thomas Schatzl skrev 12/8/14 17:12:
> Hi all,
>
>    can I have reviews for this change? It implements the capability for
> G1 to shrink/expand the heap on a per-region basis without the
> constraint that shrinking/expansion needs to occur at the highest
> address of the reserved space.
>
> Further it implements automatic commit/uncommit of all (relevant) large
> heap data structures (auxiliary data like block offset table, card
> table, mark bitmaps, hot card cache) at the same time the corresponding
> heap region is (un-)committed.
>
> This change implements basic support for this new behavior: selection of
> regions to (un-)commit is not particularly sophisticated.
>
> For easier reviewing, some notes:
> - start at the new initialization code in G1CollectedHeap::initialize()
> - all memory commit/uncommit activity of auxiliary data is tied to
> regions: the new G1RegionToSpaceMapper class manages translation between
> regions and whatever granularity the auxiliary data is
> committed/uncommitted.
> - these G1RegionToSpaceMappers are managed by HeapRegionSeq.
>
> This change is based on the review for JDK-8054818. As mentioned there,
> there will be some cleanup CRs after this change: at least a CR to
> rename HeapRegionSeq to HeapRegionManager, and another one that cleans
> up the card table code.
>
> They were split out for easier review, as they are quite large too but
> do not contribute to the functionality.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8038423
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8038423/webrev/
>
> Testing:
> jprt, aurora (nightly, bigapps, lots of test suites) with -XX:+UseG1GC,
> crm fuse
>
> Thanks,
>    Thomas
>
>
>


From thomas.schatzl at oracle.com  Wed Aug 13 16:17:53 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 13 Aug 2014 18:17:53 +0200
Subject: RFR (XL): 8054818: Refactor HeapRegionSeq to manage heap region
	and auxiliary data
In-Reply-To: <53EB7DC4.8070001@oracle.com>
References: <1407856144.2700.34.camel@cirrus> <53EB7DC4.8070001@oracle.com>
Message-ID: <1407946673.3420.32.camel@cirrus>

Hi,

On Wed, 2014-08-13 at 17:01 +0200, Jesper Wilhelmsson wrote:
> Looks good.
> 
> You made changes in vmStructs_g1.hpp. Did you verify that this didn't trigger 
> any changes in the serviceability agent?

The change contains the necessary SA agent changes. :)

They have been verified to not break the SA agent using the appropriate
SA tests on aurora.

Thanks,
  Thomas




From jesper.wilhelmsson at oracle.com  Wed Aug 13 16:24:02 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 13 Aug 2014 18:24:02 +0200
Subject: RFR (XL): 8054818: Refactor HeapRegionSeq to manage heap region
	and auxiliary data
In-Reply-To: <1407946673.3420.32.camel@cirrus>
References: <1407856144.2700.34.camel@cirrus> <53EB7DC4.8070001@oracle.com>
	<1407946673.3420.32.camel@cirrus>
Message-ID: <53EB9122.70608@oracle.com>

Ignore me, just ship it! ;)
/Jesper

Thomas Schatzl skrev 13/8/14 18:17:
> Hi,
>
> On Wed, 2014-08-13 at 17:01 +0200, Jesper Wilhelmsson wrote:
>> Looks good.
>>
>> You made changes in vmStructs_g1.hpp. Did you verify that this didn't trigger
>> any changes in the serviceability agent?
>
> The change contains the necessary SA agent changes. :)
>
> They have been verified to not break the SA agent using the appropriate
> SA tests on aurora.
>
> Thanks,
>    Thomas
>
>


From mikael.gerdin at oracle.com  Thu Aug 14 07:47:23 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 14 Aug 2014 09:47:23 +0200
Subject: RFR (XL): 8054818: Refactor HeapRegionSeq to manage heap region
	and auxiliary data
In-Reply-To: <1407856144.2700.34.camel@cirrus>
References: <1407856144.2700.34.camel@cirrus>
Message-ID: <1894411.HW1AMZr9eS@mgerdin03>

On Tuesday 12 August 2014 17.09.04 Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews for this somewhat large refactoring change? It is
> about refactoring the HeapRegionSeq class to manage heap region and
> auxiliary data.
> 
> I.e. currently HeapRegionSeq only manages the HeapRegion instances
> corresponding to the heap's region. The change gives HeapRegionSeq more
> responsibilities, encapsulating functionality related to heap memory
> management. This decreases the amount of responsibilities (and
> complexity) for the G1CollectedHeap class: decisions about how heap
> related memory is allocated/freed/iterated (i.e. how the heap regions
> are actually allocated in the heap) is removed from G1CollectedHeap.
> 
> This change only changes the interface to this functionality. It is a
> preparatory change for JDK-8038423 "G1: Decommit memory within the
> heap", so the change might be slightly more extensive than really
> required.
> 
> The RFR for JDK-8038423 will follow to look at it in context.
> 
> There is another CR that renames HeapRegionSeq to HeapRegionmanager too.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8054818
> 
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8054818/webrev/

It took me a while to figure out that 

50 inline HeapWord* G1CollectedHeap::bottom_addr_for_region(uint index) const 
{
  51   return _reserved.start() + index * HeapRegion::GrainWords;
  52 }

Is actually referencing CollectedHeap::_reserved

It's not clear to me if it ever differs from HeapRegionSeq::_reserved but I 
suggest that you use that one instead.

The code which does
heap_rs.first_part(max_byte_size);
looks like remnants of perm gen, where the rest of the heap_rs would be the 
reserved memory for the perm gen.

CollectedHeap::_reserved is a protected field but only used in a few places 
where it's initialized by subclasses. I'll file an RFE for it to be made 
private with a protected initialization method instead.


heapRegionSeq.hpp
 177 
 178   MemRegion committed() const { MemRegion temp(heap_bottom(), 
heap_top()); return temp; }

why not just
return MemRegion(heap_bottom(), heap_top());

 179   
 180   MemRegion reserved() const { MemRegion temp(heap_bottom(), heap_end()); 
return temp; }

return MemRegion(heap_bottom(), heap_end());

 181 


I didn't look in detail at the humongous allocation code moved from G1CH to 
HRS but I assume that you've tested this :)

/Mikel

> 
> Testing:
> jprt, nightly and bigapps (kitchensink, ...) with -XX:+UseG1GC
> 
> Thanks,
>   Thomas



From mikael.gerdin at oracle.com  Thu Aug 14 09:39:31 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 14 Aug 2014 11:39:31 +0200
Subject: RFR (XXL): 8038423: G1: Decommit memory within the heap
In-Reply-To: <1407856327.2700.39.camel@cirrus>
References: <1407856327.2700.39.camel@cirrus>
Message-ID: <10439232.cEubY2hMkq@mgerdin03>

Hi Thomas,

On Tuesday 12 August 2014 17.12.07 Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews for this change? It implements the capability for
> G1 to shrink/expand the heap on a per-region basis without the
> constraint that shrinking/expansion needs to occur at the highest
> address of the reserved space.
> 
> Further it implements automatic commit/uncommit of all (relevant) large
> heap data structures (auxiliary data like block offset table, card
> table, mark bitmaps, hot card cache) at the same time the corresponding
> heap region is (un-)committed.
> 
> This change implements basic support for this new behavior: selection of
> regions to (un-)commit is not particularly sophisticated.
> 
> For easier reviewing, some notes:
> - start at the new initialization code in G1CollectedHeap::initialize()
> - all memory commit/uncommit activity of auxiliary data is tied to
> regions: the new G1RegionToSpaceMapper class manages translation between
> regions and whatever granularity the auxiliary data is
> committed/uncommitted.
> - these G1RegionToSpaceMappers are managed by HeapRegionSeq.
> 
> This change is based on the review for JDK-8054818. As mentioned there,
> there will be some cleanup CRs after this change: at least a CR to
> rename HeapRegionSeq to HeapRegionManager, and another one that cleans
> up the card table code.
> 
> They were split out for easier review, as they are quite large too but
> do not contribute to the functionality.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8038423
> 
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8038423/webrev/

g1CollectedHeap.cpp

2006   g1_barrier_set()->initialize(cardtable_storage);

Can this initialization be moved to below all the create_mapper calls?
It's easy to miss it in all the similar calls there.


g1RegionToSpaceMapper.cpp

  55   G1RegionsLargerThanCommitSizeMapper(ReservedSpace rs, size_t 
os_commit_granularity,
  56     size_t alloc_granularity, size_t commit_factor, MemoryType type) :
  57      G1RegionToSpaceMapper(rs, os_commit_granularity, alloc_granular

Please line up the parameters like you did in the SmallerThan variant.

  94  public:
  95   G1RegionsSmallerThanCommitSizeMapper(ReservedSpace rs,
  96                                         size_t os_commit_granularity,

The rest of the parameters are not aligned with the ReservedSpace one.


g1BlockOffsetTable.inline.hpp

 50 #define check_index(index, msg)                                                
\
  51   assert((index) < (_reserved.word_size() >> LogN_words),                      
\
  52          err_msg("%s - "                                                       
\
  53                  "index: " SIZE_FORMAT ", _vs.committed_size: " 
SIZE_FORMAT,   \
  54                  msg, (index), (_reserved.word_size() >> LogN_words)));        
\

You should be able to do string concat on msg in the macro instead of using %s 
in err_msg, something like
err_msg(msg  " - index: " ...)

g1BlockOffsetTable.cpp

  38   // exacuted after commit of a region already needs to do some re-
initialization of

Typo: should be "executed"

/Mikael

> 
> Testing:
> jprt, aurora (nightly, bigapps, lots of test suites) with -XX:+UseG1GC,
> crm fuse
> 
> Thanks,
>   Thomas



From stefan.karlsson at oracle.com  Thu Aug 14 12:04:18 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 14 Aug 2014 14:04:18 +0200
Subject: 8055111: [TESTBUG] jdk.testlibrary.Utils.removeGcOpts doesn't remove
	-Xconcgc
Message-ID: <53ECA5C2.10801@oracle.com>

Hi all,

Please, review this patch to add -Xconcgc to the set of flags to be 
filtered out by Utils.removeGcOpts:
http://cr.openjdk.java.net/~stefank/8055111/webrev.00/

This fixes one of the instances in:
https://bugs.openjdk.java.net/browse/JDK-8019361 - [TESTBUG] Conflicting 
collector combinations in option list for GC tests

Tested by running:
jtreg -vmoption:-Xconcgc -jdk:/localhome/java/jdk-9-ea-bin-b26/ 
test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java
jtreg -vmoption:-XX:+UseConcMarkSweepGC 
-jdk:/localhome/java/jdk-9-ea-bin-b26/ 
test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java

thanks,
StefanK


From thomas.schatzl at oracle.com  Thu Aug 14 13:37:02 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 14 Aug 2014 15:37:02 +0200
Subject: RFR (XXL): 8038423: G1: Decommit memory within the heap
In-Reply-To: <10439232.cEubY2hMkq@mgerdin03>
References: <1407856327.2700.39.camel@cirrus> <10439232.cEubY2hMkq@mgerdin03>
Message-ID: <1408023422.2686.77.camel@cirrus>

Hi Mikael,

  thanks for the review :)

On Thu, 2014-08-14 at 11:39 +0200, Mikael Gerdin wrote:
> Hi Thomas,
> 
> On Tuesday 12 August 2014 17.12.07 Thomas Schatzl wrote:
> > Hi all,
> > 
> >   can I have reviews for this change? It implements the capability for
> > G1 to shrink/expand the heap on a per-region basis without the
> > constraint that shrinking/expansion needs to occur at the highest
> > address of the reserved space.
> > 
> > Further it implements automatic commit/uncommit of all (relevant) large
> > heap data structures (auxiliary data like block offset table, card
> > table, mark bitmaps, hot card cache) at the same time the corresponding
> > heap region is (un-)committed.
> > 
> > This change implements basic support for this new behavior: selection of
> > regions to (un-)commit is not particularly sophisticated.
> > 
> > For easier reviewing, some notes:
> > - start at the new initialization code in G1CollectedHeap::initialize()
> > - all memory commit/uncommit activity of auxiliary data is tied to
> > regions: the new G1RegionToSpaceMapper class manages translation between
> > regions and whatever granularity the auxiliary data is
> > committed/uncommitted.
> > - these G1RegionToSpaceMappers are managed by HeapRegionSeq.
> > 
> > This change is based on the review for JDK-8054818. As mentioned there,
> > there will be some cleanup CRs after this change: at least a CR to
> > rename HeapRegionSeq to HeapRegionManager, and another one that cleans
> > up the card table code.
> > 
> > They were split out for easier review, as they are quite large too but
> > do not contribute to the functionality.
> > 
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8038423
> > 
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8038423/webrev/
> 
> g1CollectedHeap.cpp
> 
> 2006   g1_barrier_set()->initialize(cardtable_storage);
> 
> Can this initialization be moved to below all the create_mapper calls?
> It's easy to miss it in all the similar calls there.

Fixed.

> g1RegionToSpaceMapper.cpp
> 
>   55   G1RegionsLargerThanCommitSizeMapper(ReservedSpace rs, size_t 
> os_commit_granularity,
>   56     size_t alloc_granularity, size_t commit_factor, MemoryType type) :
>   57      G1RegionToSpaceMapper(rs, os_commit_granularity, alloc_granular
> 
> Please line up the parameters like you did in the SmallerThan variant.
> 
>   94  public:
>   95   G1RegionsSmallerThanCommitSizeMapper(ReservedSpace rs,
>   96                                         size_t os_commit_granularity,
> 
> The rest of the parameters are not aligned with the ReservedSpace one.

Fixed. I also did more alignment.

> g1BlockOffsetTable.inline.hpp
> 
>  50 #define check_index(index, msg)                                                
> \
>   51   assert((index) < (_reserved.word_size() >> LogN_words),                      
> \
>   52          err_msg("%s - "                                                       
> \
>   53                  "index: " SIZE_FORMAT ", _vs.committed_size: " 
> SIZE_FORMAT,   \
>   54                  msg, (index), (_reserved.word_size() >> LogN_words)));        
> \
> 
> You should be able to do string concat on msg in the macro instead of using %s 
> in err_msg, something like
> err_msg(msg  " - index: " ...)
> 

No, that does not work. I kept it, but realigned the lines in the macro.

> g1BlockOffsetTable.cpp

> 
>   38   // exacuted after commit of a region already needs to do some re-
> initialization of
> 
> Typo: should be "executed"

Done.

New webrev at:
http://cr.openjdk.java.net/~tschatzl/8038423/webrev.1/
Diff webrev at:
http://cr.openjdk.java.net/~tschatzl/8038423/webrev.0_to_1/

Thanks,
  Thomas




From thomas.schatzl at oracle.com  Thu Aug 14 13:37:16 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 14 Aug 2014 15:37:16 +0200
Subject: RFR (XL): 8054818: Refactor HeapRegionSeq to manage heap region
	and auxiliary data
In-Reply-To: <1894411.HW1AMZr9eS@mgerdin03>
References: <1407856144.2700.34.camel@cirrus> <1894411.HW1AMZr9eS@mgerdin03>
Message-ID: <1408023436.2686.78.camel@cirrus>

Hi Mikael,

  thanks for the review.

On Thu, 2014-08-14 at 09:47 +0200, Mikael Gerdin wrote:
> On Tuesday 12 August 2014 17.09.04 Thomas Schatzl wrote:
> > Hi all,
> > 
> >   can I have reviews for this somewhat large refactoring change? It is
> > about refactoring the HeapRegionSeq class to manage heap region and
> > auxiliary data.
> > 
> > I.e. currently HeapRegionSeq only manages the HeapRegion instances
> > corresponding to the heap's region. The change gives HeapRegionSeq more
> > responsibilities, encapsulating functionality related to heap memory
> > management. This decreases the amount of responsibilities (and
> > complexity) for the G1CollectedHeap class: decisions about how heap
> > related memory is allocated/freed/iterated (i.e. how the heap regions
> > are actually allocated in the heap) is removed from G1CollectedHeap.
> > 
> > This change only changes the interface to this functionality. It is a
> > preparatory change for JDK-8038423 "G1: Decommit memory within the
> > heap", so the change might be slightly more extensive than really
> > required.
> > 
> > The RFR for JDK-8038423 will follow to look at it in context.
> > 
> > There is another CR that renames HeapRegionSeq to HeapRegionmanager too.
> > 
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8054818
> > 
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8054818/webrev/
> 
> It took me a while to figure out that 
> 
> 50 inline HeapWord* G1CollectedHeap::bottom_addr_for_region(uint index) const 
> {
>   51   return _reserved.start() + index * HeapRegion::GrainWords;
>   52 }
> 
> Is actually referencing CollectedHeap::_reserved
> 
> It's not clear to me if it ever differs from HeapRegionSeq::_reserved but I 
> suggest that you use that one instead.

Fixed.

> 
> The code which does
> heap_rs.first_part(max_byte_size);
> looks like remnants of perm gen, where the rest of the heap_rs would be the 
> reserved memory for the perm gen.
> 
> CollectedHeap::_reserved is a protected field but only used in a few places 
> where it's initialized by subclasses. I'll file an RFE for it to be made 
> private with a protected initialization method instead.

Okay, thanks.

> 
> 
> heapRegionSeq.hpp
>  177 
>  178   MemRegion committed() const { MemRegion temp(heap_bottom(), 
> heap_top()); return temp; }
> 
> why not just
> return MemRegion(heap_bottom(), heap_top());
> 
>  179   
>  180   MemRegion reserved() const { MemRegion temp(heap_bottom(), heap_end()); 
> return temp; }
> 
> return MemRegion(heap_bottom(), heap_end());
> 

Fixed.


> I didn't look in detail at the humongous allocation code moved from G1CH to 
> HRS but I assume that you've tested this :)

Of course :)

New webrev at 
http://cr.openjdk.java.net/~tschatzl/8054818/webrev.1
Diff:
http://cr.openjdk.java.net/~tschatzl/8054818/webrev.0_to_1

Testing:
jprt

Thanks,
  Thomas



From staffan.larsen at oracle.com  Thu Aug 14 14:04:46 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 14 Aug 2014 16:04:46 +0200
Subject: 8055111: [TESTBUG] jdk.testlibrary.Utils.removeGcOpts doesn't
	remove -Xconcgc
In-Reply-To: <53ECA5C2.10801@oracle.com>
References: <53ECA5C2.10801@oracle.com>
Message-ID: <FE1E2268-A3C5-4694-A97E-1F40E23204BF@oracle.com>

Looks good!

Thanks,
/Staffan

On 14 aug 2014, at 14:04, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:

> Hi all,
> 
> Please, review this patch to add -Xconcgc to the set of flags to be filtered out by Utils.removeGcOpts:
> http://cr.openjdk.java.net/~stefank/8055111/webrev.00/
> 
> This fixes one of the instances in:
> https://bugs.openjdk.java.net/browse/JDK-8019361 - [TESTBUG] Conflicting collector combinations in option list for GC tests
> 
> Tested by running:
> jtreg -vmoption:-Xconcgc -jdk:/localhome/java/jdk-9-ea-bin-b26/ test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java
> jtreg -vmoption:-XX:+UseConcMarkSweepGC -jdk:/localhome/java/jdk-9-ea-bin-b26/ test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java
> 
> thanks,
> StefanK



From jon.masamitsu at oracle.com  Thu Aug 14 16:43:00 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 14 Aug 2014 09:43:00 -0700
Subject: RFR (XL): 8054818: Refactor HeapRegionSeq to manage heap region
	and auxiliary data
In-Reply-To: <1407856144.2700.34.camel@cirrus>
References: <1407856144.2700.34.camel@cirrus>
Message-ID: <53ECE714.8090209@oracle.com>

Thomas,

http://cr.openjdk.java.net/~tschatzl/8054818/webrev/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html

  800     } else {
  801       // Policy: Potentially trigger a defragmentation GC.
  802     }

Is the" defragmentation GC" a full compacting STW GC?
Since this is just a comment I expect that a full compacting STW GC will
happen if the allocation fails?  So why contemplate one here?

Jon

On 8/12/2014 8:09 AM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for this somewhat large refactoring change? It is
> about refactoring the HeapRegionSeq class to manage heap region and
> auxiliary data.
>
> I.e. currently HeapRegionSeq only manages the HeapRegion instances
> corresponding to the heap's region. The change gives HeapRegionSeq more
> responsibilities, encapsulating functionality related to heap memory
> management. This decreases the amount of responsibilities (and
> complexity) for the G1CollectedHeap class: decisions about how heap
> related memory is allocated/freed/iterated (i.e. how the heap regions
> are actually allocated in the heap) is removed from G1CollectedHeap.
>
> This change only changes the interface to this functionality. It is a
> preparatory change for JDK-8038423 "G1: Decommit memory within the
> heap", so the change might be slightly more extensive than really
> required.
>
> The RFR for JDK-8038423 will follow to look at it in context.
>
> There is another CR that renames HeapRegionSeq to HeapRegionmanager too.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8054818
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8054818/webrev/
>
> Testing:
> jprt, nightly and bigapps (kitchensink, ...) with -XX:+UseG1GC
>
> Thanks,
>    Thomas
>
>
>
>



From thomas.schatzl at oracle.com  Thu Aug 14 18:07:47 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 14 Aug 2014 20:07:47 +0200
Subject: RFR (XL): 8054818: Refactor HeapRegionSeq to manage heap region
	and auxiliary data
In-Reply-To: <53ECE714.8090209@oracle.com>
References: <1407856144.2700.34.camel@cirrus> <53ECE714.8090209@oracle.com>
Message-ID: <1408039667.2866.8.camel@cirrus>

Hi,

On Thu, 2014-08-14 at 09:43 -0700, Jon Masamitsu wrote:
> Thomas,
> 
> http://cr.openjdk.java.net/~tschatzl/8054818/webrev/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html
> 
>   800     } else {
>   801       // Policy: Potentially trigger a defragmentation GC.
>   802     }
> 
> Is the" defragmentation GC" a full compacting STW GC?
> Since this is just a comment I expect that a full compacting STW GC will
> happen if the allocation fails?  So why contemplate one here?

No, this one: https://bugs.openjdk.java.net/browse/JDK-8038487

This is the place to calculate the "best" (fewest) regions to evacuate
using information from HeapRegionSeq (e.g. least amount of commits) and
the gc efficiences (e.g. largest sum of efficiencies), and execute that
mixed GC (also reserving this area so that it will not be used during
GC).

That's just an idea.

A few lines above, before expansion, the code also contains a note about
that, but that is the wrong place. (It reads: "Alternatively we could do
a defragmentation gc" - the else part, where this comment you noticed
is, is this mentioned alternative).

Thanks,
  Thomas




From thomas.schatzl at oracle.com  Thu Aug 14 18:13:36 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 14 Aug 2014 20:13:36 +0200
Subject: RFR (XL): 8054818: Refactor HeapRegionSeq to manage heap region
	and auxiliary data
In-Reply-To: <1408039667.2866.8.camel@cirrus>
References: <1407856144.2700.34.camel@cirrus> <53ECE714.8090209@oracle.com>
	<1408039667.2866.8.camel@cirrus>
Message-ID: <1408040016.2866.11.camel@cirrus>

Hi,

On Thu, 2014-08-14 at 20:07 +0200, Thomas Schatzl wrote:
> Hi,
> 
> On Thu, 2014-08-14 at 09:43 -0700, Jon Masamitsu wrote:
> > Thomas,
> > 
> > http://cr.openjdk.java.net/~tschatzl/8054818/webrev/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html
> > 
> >   800     } else {
> >   801       // Policy: Potentially trigger a defragmentation GC.
> >   802     }
> > 
> > Is the" defragmentation GC" a full compacting STW GC?
> > Since this is just a comment I expect that a full compacting STW GC will
> > happen if the allocation fails?  So why contemplate one here?
> 
> No, this one: https://bugs.openjdk.java.net/browse/JDK-8038487
> 
> This is the place to calculate the "best" (fewest) regions to evacuate
> using information from HeapRegionSeq (e.g. least amount of commits) and
> the gc efficiences (e.g. largest sum of efficiencies), and execute that
> mixed GC (also reserving this area so that it will not be used during
> GC).
> 
> That's just an idea.

I.e. other conditions could be thought of: e.g. potentially it is
sufficient to do a young-only gc to free up enough contiguous space.

Note that this is sort of almost-last resort as one could try to avoid
fragmentation during normal gc in the first place.

The very-last resort would probably be a full gc that also moves
humongous objects (which the current one does not).

Thomas



From jon.masamitsu at oracle.com  Thu Aug 14 23:10:26 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 14 Aug 2014 16:10:26 -0700
Subject: RFR (XL): 8054818: Refactor HeapRegionSeq to manage heap region
	and auxiliary data
In-Reply-To: <1408039667.2866.8.camel@cirrus>
References: <1407856144.2700.34.camel@cirrus> <53ECE714.8090209@oracle.com>
	<1408039667.2866.8.camel@cirrus>
Message-ID: <53ED41E2.3090908@oracle.com>


On 08/14/2014 11:07 AM, Thomas Schatzl wrote:
> Hi,
>
> On Thu, 2014-08-14 at 09:43 -0700, Jon Masamitsu wrote:
>> Thomas,
>>
>> http://cr.openjdk.java.net/~tschatzl/8054818/webrev/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html
>>
>>    800     } else {
>>    801       // Policy: Potentially trigger a defragmentation GC.
>>    802     }
>>
>> Is the" defragmentation GC" a full compacting STW GC?
>> Since this is just a comment I expect that a full compacting STW GC will
>> happen if the allocation fails?  So why contemplate one here?
> No, this one: https://bugs.openjdk.java.net/browse/JDK-8038487
>
> This is the place to calculate the "best" (fewest) regions to evacuate
> using information from HeapRegionSeq (e.g. least amount of commits) and
> the gc efficiences (e.g. largest sum of efficiencies), and execute that
> mixed GC (also reserving this area so that it will not be used during
> GC).
>
> That's just an idea.
>
> A few lines above, before expansion, the code also contains a note about
> that, but that is the wrong place. (It reads: "Alternatively we could do
> a defragmentation gc" - the else part, where this comment you noticed
> is, is this mentioned alternative).

Thanks for the explanation.  Changes look good.

Reviewed.

> Thanks,
>    Thomas
>
>



From poonam.bajaj at oracle.com  Sun Aug 17 00:54:46 2014
From: poonam.bajaj at oracle.com (Poonam Bajaj)
Date: Sun, 17 Aug 2014 06:24:46 +0530
Subject: Request for review: 8044406: JVM crash with JDK8 (build 1.8.0-b132)
	with G1 GC
Message-ID: <53EFFD56.3060600@oracle.com>

Hi,

Could I have reviews for the fix for a G1 GC crash:

8044406 <https://bugs.openjdk.java.net/browse/JDK-8044406>: JVM crash 
with JDK8 (build 1.8.0-b132) with G1 GC
Webrev: http://cr.openjdk.java.net/~poonam/8044406/webrev.00/webrev/

The crash happens with the following stack trace:
Stack: [0x00007fd435a1f000,0x00007fd435b20000],  sp=0x00007fd435b1bc30,  
free space=1011k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
C=native code)
V  [libjvm.so+0x541261]  
G1BlockOffsetArray::forward_to_block_containing_addr_slow(HeapWord*, 
HeapWord*, void const*)+0xf1
V  [libjvm.so+0x959e54]  DirtyCardToOopClosure::do_MemRegion(MemRegion)+0x64
V  [libjvm.so+0x56d2a4]  ScanRSClosure::doHeapRegion(HeapRegion*)+0x374
V  [libjvm.so+0x542dd0]  
G1CollectedHeap::collection_set_iterate_from(HeapRegion*, 
HeapRegionClosure*)+0x60
V  [libjvm.so+0x56c08c]  G1RemSet::scanRS(OopsInHeapRegionClosure*, 
CodeBlobToOopClosure*, int)+0xdc
V  [libjvm.so+0x56c4d5]  
G1RemSet::oops_into_collection_set_do(OopsInHeapRegionClosure*, 
CodeBlobToOopClosure*, int)+0x145
V  [libjvm.so+0x549ef4]  G1CollectedHeap::g1_process_strong_roots(bool, 
SharedHeap::ScanningOption, OopClosure*, OopsInHeapRegionClosure*, 
G1KlassScanClosure*, int)+0x224
V  [libjvm.so+0x558a88]  G1ParTask::work(unsigned int)+0xb88
V  [libjvm.so+0xa4a9ff]  GangWorker::loop()+0xcf
V  [libjvm.so+0x8a0058]  java_start(Thread*)+0x108

Here, the GC thread crashes while scanning the RemSet (part of the 
non-CSet regions). And it happens to scan a region to which another 
thread in G1ParEvacuateFollowersClosure is copying contents to, and this 
region was found out to be an Old GC alloc region.

This change makes sure that we fill up the last card of the Old GC alloc 
region that was being allocated into, with a dummy object so that it 
does not get scanned by the remset scanning GC threads.

This change applies cleanly to 8u and 7u repos.

Thanks to Thomas Schatzl for his help in investigating the crash and 
suggesting this solution.

Testing:
- JPRT
- Testing by Coherence QA

Thanks,
Poonam

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

From marcus.larsson at oracle.com  Mon Aug 18 07:27:22 2014
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Mon, 18 Aug 2014 09:27:22 +0200
Subject: RFR (XS): 8053998: Hot card cache flush chunk size too coarse grained
Message-ID: <53F1AADA.7000604@oracle.com>

Hi,

Can I have reviews for this small patch changing the hot card cache 
flush chunks to a fixed size?

CR:
http://cr.openjdk.java.net/~mgerdin/mlarsson/webrev-8053998/

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

Testing:
jprt, SPECjbb2013

Thanks,
Marcus


From marcus.larsson at oracle.com  Mon Aug 18 07:31:01 2014
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Mon, 18 Aug 2014 09:31:01 +0200
Subject: RFR (XS): 8054491: Remove wrong assert and refactor code in
	G1CollectorPolicy::record_concurrent_mark_end
Message-ID: <53F1ABB5.2080406@oracle.com>

Hi,

Can I have reviews for this small change cleaning up and refactoring 
record_concurrent_mark_end()?

CR:
http://cr.openjdk.java.net/~mgerdin/mlarsson/webrev-8054491/

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

Testing:
jprt

Thanks,
Marcus


From marcus.larsson at oracle.com  Mon Aug 18 07:35:40 2014
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Mon, 18 Aug 2014 09:35:40 +0200
Subject: RFR (XS): 8055091: CollectedHeap::_reserved usage should be cleaned up
Message-ID: <53F1ACCC.9080102@oracle.com>

Hi,

Can I have reviews for this small change to make the _reserved field of 
CollectedHeap private, unifying its initialization in a protected method.

CR:
http://cr.openjdk.java.net/~mgerdin/mlarsson/webrev-8055091/

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

Testing:
jprt

Thanks,
Marcus


From mikael.gerdin at oracle.com  Mon Aug 18 08:32:04 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 18 Aug 2014 10:32:04 +0200
Subject: Request for review: 8044406: JVM crash with JDK8 (build
	1.8.0-b132) with G1 GC
In-Reply-To: <53EFFD56.3060600@oracle.com>
References: <53EFFD56.3060600@oracle.com>
Message-ID: <53F1BA04.6010902@oracle.com>

Hi Poonam,

On 2014-08-17 02:54, Poonam Bajaj wrote:
> Hi,
>
> Could I have reviews for the fix for a G1 GC crash:
>
> 8044406 <https://bugs.openjdk.java.net/browse/JDK-8044406>: JVM crash
> with JDK8 (build 1.8.0-b132) with G1 GC
> Webrev: http://cr.openjdk.java.net/~poonam/8044406/webrev.00/webrev/

7020     // Determine how far we are from the next card boundary. If it 
is smaller than
7021     // the minimum object size we can allocate into, expand into 
the next card.
7022     size_t top = cur->used();
7023     size_t aligned_top = align_size_up_(top, 
G1BlockOffsetSharedArray::N_bytes);

It seems a bit odd to me to do this calculation on the sizes instead of 
the addresses in the region. Also, the naming is confusing since "top" 
almost always refers to the topmost allocated address in a particular 
memory range.
Can you change the above to
HeapWord* top = cur->top();
HeapWord* aligned_top = align_ptr_up...


7024
7025     size_t to_allocate_words = (aligned_top - top) / HeapWordSize;

The subtraction should be replaced by a call to pointer_delta if you 
change the types of top and aligned_top to pointers.

7026     if ((cur->top() + to_allocate_words) != cur->end() && // Not 
completely filled yet.
7027         (to_allocate_words != 0) && // Not at card boundary.
7028         (to_allocate_words <= CollectedHeap::min_fill_size())) {
7029       // Cannot fit any object into the area to the next card 
boundary. Simply create
7030       // an object that fits a single object.
7031       to_allocate_words += CollectedHeap::min_fill_size();
7032     }

Generally, if you feel the need to explain each condition in a 
three-clause if statement then maybe it's a good idea to rephrase it in 
some way. Maybe use a MAX2-expression to get above the minimum object 
size and move the "to_allocate_words != 0" check to encompass the entire 
filling logic?

7033
7034     if (to_allocate_words != 0) {
7035       HeapWord* dummy = 
G1AllocRegion::attempt_allocation(to_allocate_words, true /* bot_updates 
*/);

You don't need the G1AllocRegion scope prefix here, attempt_allocation 
is in the current scope.

7036       CollectedHeap::fill_with_object(dummy, to_allocate_words);
7037     }

/Mikael

>
> The crash happens with the following stack trace:
> Stack: [0x00007fd435a1f000,0x00007fd435b20000], sp=0x00007fd435b1bc30,
> free space=1011k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
> C=native code)
> V  [libjvm.so+0x541261]
> G1BlockOffsetArray::forward_to_block_containing_addr_slow(HeapWord*,
> HeapWord*, void const*)+0xf1
> V  [libjvm.so+0x959e54] DirtyCardToOopClosure::do_MemRegion(MemRegion)+0x64
> V  [libjvm.so+0x56d2a4] ScanRSClosure::doHeapRegion(HeapRegion*)+0x374
> V  [libjvm.so+0x542dd0]
> G1CollectedHeap::collection_set_iterate_from(HeapRegion*,
> HeapRegionClosure*)+0x60
> V  [libjvm.so+0x56c08c]  G1RemSet::scanRS(OopsInHeapRegionClosure*,
> CodeBlobToOopClosure*, int)+0xdc
> V  [libjvm.so+0x56c4d5]
> G1RemSet::oops_into_collection_set_do(OopsInHeapRegionClosure*,
> CodeBlobToOopClosure*, int)+0x145
> V  [libjvm.so+0x549ef4] G1CollectedHeap::g1_process_strong_roots(bool,
> SharedHeap::ScanningOption, OopClosure*, OopsInHeapRegionClosure*,
> G1KlassScanClosure*, int)+0x224
> V  [libjvm.so+0x558a88]  G1ParTask::work(unsigned int)+0xb88
> V  [libjvm.so+0xa4a9ff]  GangWorker::loop()+0xcf
> V  [libjvm.so+0x8a0058]  java_start(Thread*)+0x108
>
> Here, the GC thread crashes while scanning the RemSet (part of the
> non-CSet regions). And it happens to scan a region to which another
> thread in G1ParEvacuateFollowersClosure is copying contents to, and this
> region was found out to be an Old GC alloc region.
>
> This change makes sure that we fill up the last card of the Old GC alloc
> region that was being allocated into, with a dummy object so that it
> does not get scanned by the remset scanning GC threads.
>
> This change applies cleanly to 8u and 7u repos.
>
> Thanks to Thomas Schatzl for his help in investigating the crash and
> suggesting this solution.
>
> Testing:
> - JPRT
> - Testing by Coherence QA
>
> Thanks,
> Poonam
>


From mikael.gerdin at oracle.com  Mon Aug 18 08:52:32 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 18 Aug 2014 10:52:32 +0200
Subject: RFR (XS): 8055091: CollectedHeap::_reserved usage should be
	cleaned up
In-Reply-To: <53F1ACCC.9080102@oracle.com>
References: <53F1ACCC.9080102@oracle.com>
Message-ID: <53F1BED0.10605@oracle.com>

Hi Marcus,

On 2014-08-18 09:35, Marcus Larsson wrote:
> Hi,
>
> Can I have reviews for this small change to make the _reserved field of
> CollectedHeap private, unifying its initialization in a protected method.
>
> CR:
> http://cr.openjdk.java.net/~mgerdin/mlarsson/webrev-8055091/

This looks good, but can you please rename set_reserved_region to 
initialize_reserved_region to signal that it should only be called once. 
I don't need to re-review the name change.

/Mikael

>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8055091
>
> Testing:
> jprt
>
> Thanks,
> Marcus


From marcus.larsson at oracle.com  Mon Aug 18 09:04:13 2014
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Mon, 18 Aug 2014 11:04:13 +0200
Subject: RFR (XS): 8055091: CollectedHeap::_reserved usage should be
	cleaned up
In-Reply-To: <53F1BED0.10605@oracle.com>
References: <53F1ACCC.9080102@oracle.com> <53F1BED0.10605@oracle.com>
Message-ID: <53F1C18D.7050709@oracle.com>

Hi,

On 08/18/2014 10:52 AM, Mikael Gerdin wrote:
> Hi Marcus,
>
> On 2014-08-18 09:35, Marcus Larsson wrote:
>> Hi,
>>
>> Can I have reviews for this small change to make the _reserved field of
>> CollectedHeap private, unifying its initialization in a protected 
>> method.
>>
>> CR:
>> http://cr.openjdk.java.net/~mgerdin/mlarsson/webrev-8055091/
>
> This looks good, but can you please rename set_reserved_region to 
> initialize_reserved_region to signal that it should only be called 
> once. I don't need to re-review the name change.
I will do that.
Thank you for reviewing.

>
> /Mikael
>
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8055091
>>
>> Testing:
>> jprt
>>
>> Thanks,
>> Marcus



From dmitry.fazunenko at oracle.com  Mon Aug 18 10:14:00 2014
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko)
Date: Mon, 18 Aug 2014 14:14:00 +0400
Subject: RFR (XXS): 8054362: gc/g1/TestEagerReclaimHumongousRegions2.java
	timeout
In-Reply-To: <1407748324.2718.6.camel@cirrus>
References: <1407426202.2631.27.camel@cirrus> <53E3AAD2.4080306@oracle.com>
	<53E4C3FB.4080903@oracle.com> <1407748324.2718.6.camel@cirrus>
Message-ID: <53F1D1E8.8010602@oracle.com>

Hi Thomas,

On 11.08.2014 13:12, Thomas Schatzl wrote:
> Hi Bengt, Dima,
>
> On Fri, 2014-08-08 at 14:35 +0200, Bengt Rutisson wrote:
>> Hi Thomas and Dima,
>>
>> On 2014-08-07 18:35, Dmitry Fazunenko wrote:
>>
>>> Hi Thomas,
>>>
>>> The fix you made is certainly safe but it makes the test weaker.
>>>
>>> As I see from your explanation the timeout happens only on very slow
>>> machines.
>>> What if test tries to detect if the machine is slow or not and set
>>> the iteration number accordingly.
>>> I mean something like:
>>>
>>> int iterations = 20;
>>> if (Runtime.getRuntime().availableProcessors() < 2 ||
>>>           Runtime.getRuntime().maxMemory() < 1G) {
>>>    // perhaps the machine is slow, reducing iterations to avoid timeout
>>>    iterations = 2;
>>> }
>>>
>>> Another suggestion (not related to that bug). What if update the test to check with various region sizes?
>>> Not only with 1M?
> There does not seem to be new information gain when running the test
> with different region sizes as the problem is independent of it. Also,
> the test has been set up to be highly reproducible using a 1M region
> size and the given heap and object sizes.
>
> It would take considerable effort to modify it for multiple region sizes
> for no noticable gain.

Yes, TestEagerReclaimHumongousRegions2 is the regression test for 
8051973 problem.
Minimal effort is required to update it to cover more. If you don't mind 
I can file an RFE for it.


>> Could we make the test check the time? Maybe do the loop for 1 minute
>> but no more than 20 iterations?
> I implemented this idea as it seems less failure prone than trying to
> guess the speed of the machine. Fast machine easily finish the test
> within the given time, slower ones should get enough coverage.

I agree, this approach is better. The fix looks good to me.
One minor note: I would reduce timeout from 60 seconds to 50 to finish 
normally if timeout is set to 1 minute.

Thanks,
Dima

>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8054362
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8054362/webrev.1/
>
> Testing:
> jprt, local jtreg
>
> Thanks,
> Thomas
>



From poonam.bajaj at oracle.com  Mon Aug 18 11:08:24 2014
From: poonam.bajaj at oracle.com (Poonam Bajaj)
Date: Mon, 18 Aug 2014 16:38:24 +0530
Subject: Request for review: 8044406: JVM crash with JDK8 (build
	1.8.0-b132) with G1 GC
In-Reply-To: <53F1BA04.6010902@oracle.com>
References: <53EFFD56.3060600@oracle.com> <53F1BA04.6010902@oracle.com>
Message-ID: <53F1DEA8.5070606@oracle.com>

Hello Mikael,

Thanks for your review. Here's the updated webrev:
http://cr.openjdk.java.net/~poonam/8044406/webrev.01/

regards,
Poonam


On 8/18/2014 2:02 PM, Mikael Gerdin wrote:
> Hi Poonam,
>
> On 2014-08-17 02:54, Poonam Bajaj wrote:
>> Hi,
>>
>> Could I have reviews for the fix for a G1 GC crash:
>>
>> 8044406 <https://bugs.openjdk.java.net/browse/JDK-8044406>: JVM crash
>> with JDK8 (build 1.8.0-b132) with G1 GC
>> Webrev: http://cr.openjdk.java.net/~poonam/8044406/webrev.00/webrev/
>
> 7020     // Determine how far we are from the next card boundary. If 
> it is smaller than
> 7021     // the minimum object size we can allocate into, expand into 
> the next card.
> 7022     size_t top = cur->used();
> 7023     size_t aligned_top = align_size_up_(top, 
> G1BlockOffsetSharedArray::N_bytes);
>
> It seems a bit odd to me to do this calculation on the sizes instead 
> of the addresses in the region. Also, the naming is confusing since 
> "top" almost always refers to the topmost allocated address in a 
> particular memory range.
> Can you change the above to
> HeapWord* top = cur->top();
> HeapWord* aligned_top = align_ptr_up...
>
>
> 7024
> 7025     size_t to_allocate_words = (aligned_top - top) / HeapWordSize;
>
> The subtraction should be replaced by a call to pointer_delta if you 
> change the types of top and aligned_top to pointers.
>
> 7026     if ((cur->top() + to_allocate_words) != cur->end() && // Not 
> completely filled yet.
> 7027         (to_allocate_words != 0) && // Not at card boundary.
> 7028         (to_allocate_words <= CollectedHeap::min_fill_size())) {
> 7029       // Cannot fit any object into the area to the next card 
> boundary. Simply create
> 7030       // an object that fits a single object.
> 7031       to_allocate_words += CollectedHeap::min_fill_size();
> 7032     }
>
> Generally, if you feel the need to explain each condition in a 
> three-clause if statement then maybe it's a good idea to rephrase it 
> in some way. Maybe use a MAX2-expression to get above the minimum 
> object size and move the "to_allocate_words != 0" check to encompass 
> the entire filling logic?
>
> 7033
> 7034     if (to_allocate_words != 0) {
> 7035       HeapWord* dummy = 
> G1AllocRegion::attempt_allocation(to_allocate_words, true /* 
> bot_updates */);
>
> You don't need the G1AllocRegion scope prefix here, attempt_allocation 
> is in the current scope.
>
> 7036       CollectedHeap::fill_with_object(dummy, to_allocate_words);
> 7037     }
>
> /Mikael
>
>>
>> The crash happens with the following stack trace:
>> Stack: [0x00007fd435a1f000,0x00007fd435b20000], sp=0x00007fd435b1bc30,
>> free space=1011k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>> C=native code)
>> V  [libjvm.so+0x541261]
>> G1BlockOffsetArray::forward_to_block_containing_addr_slow(HeapWord*,
>> HeapWord*, void const*)+0xf1
>> V  [libjvm.so+0x959e54] 
>> DirtyCardToOopClosure::do_MemRegion(MemRegion)+0x64
>> V  [libjvm.so+0x56d2a4] ScanRSClosure::doHeapRegion(HeapRegion*)+0x374
>> V  [libjvm.so+0x542dd0]
>> G1CollectedHeap::collection_set_iterate_from(HeapRegion*,
>> HeapRegionClosure*)+0x60
>> V  [libjvm.so+0x56c08c]  G1RemSet::scanRS(OopsInHeapRegionClosure*,
>> CodeBlobToOopClosure*, int)+0xdc
>> V  [libjvm.so+0x56c4d5]
>> G1RemSet::oops_into_collection_set_do(OopsInHeapRegionClosure*,
>> CodeBlobToOopClosure*, int)+0x145
>> V  [libjvm.so+0x549ef4] G1CollectedHeap::g1_process_strong_roots(bool,
>> SharedHeap::ScanningOption, OopClosure*, OopsInHeapRegionClosure*,
>> G1KlassScanClosure*, int)+0x224
>> V  [libjvm.so+0x558a88]  G1ParTask::work(unsigned int)+0xb88
>> V  [libjvm.so+0xa4a9ff]  GangWorker::loop()+0xcf
>> V  [libjvm.so+0x8a0058]  java_start(Thread*)+0x108
>>
>> Here, the GC thread crashes while scanning the RemSet (part of the
>> non-CSet regions). And it happens to scan a region to which another
>> thread in G1ParEvacuateFollowersClosure is copying contents to, and this
>> region was found out to be an Old GC alloc region.
>>
>> This change makes sure that we fill up the last card of the Old GC alloc
>> region that was being allocated into, with a dummy object so that it
>> does not get scanned by the remset scanning GC threads.
>>
>> This change applies cleanly to 8u and 7u repos.
>>
>> Thanks to Thomas Schatzl for his help in investigating the crash and
>> suggesting this solution.
>>
>> Testing:
>> - JPRT
>> - Testing by Coherence QA
>>
>> Thanks,
>> Poonam
>>


From stefan.karlsson at oracle.com  Mon Aug 18 11:43:58 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 18 Aug 2014 13:43:58 +0200
Subject: 8055111: [TESTBUG] jdk.testlibrary.Utils.removeGcOpts doesn't
	remove -Xconcgc
In-Reply-To: <53ECA5C2.10801@oracle.com>
References: <53ECA5C2.10801@oracle.com>
Message-ID: <53F1E6FE.5010105@oracle.com>

Jon suggested that I should add -Xincgc.

Here's the updated webrev:
http://cr.openjdk.java.net/~stefank/8055111/webrev.01/

thanks,
StefanK

On 2014-08-14 14:04, Stefan Karlsson wrote:
> Hi all,
>
> Please, review this patch to add -Xconcgc to the set of flags to be 
> filtered out by Utils.removeGcOpts:
> http://cr.openjdk.java.net/~stefank/8055111/webrev.00/
>
> This fixes one of the instances in:
> https://bugs.openjdk.java.net/browse/JDK-8019361 - [TESTBUG] 
> Conflicting collector combinations in option list for GC tests
>
> Tested by running:
> jtreg -vmoption:-Xconcgc -jdk:/localhome/java/jdk-9-ea-bin-b26/ 
> test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java
> jtreg -vmoption:-XX:+UseConcMarkSweepGC 
> -jdk:/localhome/java/jdk-9-ea-bin-b26/ 
> test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java
>
> thanks,
> StefanK



From bengt.rutisson at oracle.com  Mon Aug 18 11:56:15 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 18 Aug 2014 13:56:15 +0200
Subject: 8055111: [TESTBUG] jdk.testlibrary.Utils.removeGcOpts doesn't
	remove -Xconcgc
In-Reply-To: <53F1E6FE.5010105@oracle.com>
References: <53ECA5C2.10801@oracle.com> <53F1E6FE.5010105@oracle.com>
Message-ID: <53F1E9DF.1080302@oracle.com>


Hi Stefan,

On 2014-08-18 13:43, Stefan Karlsson wrote:
> Jon suggested that I should add -Xincgc.
>
> Here's the updated webrev:
> http://cr.openjdk.java.net/~stefank/8055111/webrev.01/

Looks good.

Thanks,
Bengt

>
> thanks,
> StefanK
>
> On 2014-08-14 14:04, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please, review this patch to add -Xconcgc to the set of flags to be 
>> filtered out by Utils.removeGcOpts:
>> http://cr.openjdk.java.net/~stefank/8055111/webrev.00/
>>
>> This fixes one of the instances in:
>> https://bugs.openjdk.java.net/browse/JDK-8019361 - [TESTBUG] 
>> Conflicting collector combinations in option list for GC tests
>>
>> Tested by running:
>> jtreg -vmoption:-Xconcgc -jdk:/localhome/java/jdk-9-ea-bin-b26/ 
>> test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java
>> jtreg -vmoption:-XX:+UseConcMarkSweepGC 
>> -jdk:/localhome/java/jdk-9-ea-bin-b26/ 
>> test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java
>>
>> thanks,
>> StefanK
>



From mikael.gerdin at oracle.com  Mon Aug 18 12:04:14 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 18 Aug 2014 14:04:14 +0200
Subject: Request for review: 8044406: JVM crash with JDK8 (build
	1.8.0-b132) with G1 GC
In-Reply-To: <53F1DEA8.5070606@oracle.com>
References: <53EFFD56.3060600@oracle.com> <53F1BA04.6010902@oracle.com>
	<53F1DEA8.5070606@oracle.com>
Message-ID: <53F1EBBE.8000903@oracle.com>

Hi Poonam,

On 2014-08-18 13:08, Poonam Bajaj wrote:
> Hello Mikael,
>
> Thanks for your review. Here's the updated webrev:
> http://cr.openjdk.java.net/~poonam/8044406/webrev.01/

This looks good, Reviewed.

/Mikael

>
> regards,
> Poonam
>
>
> On 8/18/2014 2:02 PM, Mikael Gerdin wrote:
>> Hi Poonam,
>>
>> On 2014-08-17 02:54, Poonam Bajaj wrote:
>>> Hi,
>>>
>>> Could I have reviews for the fix for a G1 GC crash:
>>>
>>> 8044406 <https://bugs.openjdk.java.net/browse/JDK-8044406>: JVM crash
>>> with JDK8 (build 1.8.0-b132) with G1 GC
>>> Webrev: http://cr.openjdk.java.net/~poonam/8044406/webrev.00/webrev/
>>
>> 7020     // Determine how far we are from the next card boundary. If
>> it is smaller than
>> 7021     // the minimum object size we can allocate into, expand into
>> the next card.
>> 7022     size_t top = cur->used();
>> 7023     size_t aligned_top = align_size_up_(top,
>> G1BlockOffsetSharedArray::N_bytes);
>>
>> It seems a bit odd to me to do this calculation on the sizes instead
>> of the addresses in the region. Also, the naming is confusing since
>> "top" almost always refers to the topmost allocated address in a
>> particular memory range.
>> Can you change the above to
>> HeapWord* top = cur->top();
>> HeapWord* aligned_top = align_ptr_up...
>>
>>
>> 7024
>> 7025     size_t to_allocate_words = (aligned_top - top) / HeapWordSize;
>>
>> The subtraction should be replaced by a call to pointer_delta if you
>> change the types of top and aligned_top to pointers.
>>
>> 7026     if ((cur->top() + to_allocate_words) != cur->end() && // Not
>> completely filled yet.
>> 7027         (to_allocate_words != 0) && // Not at card boundary.
>> 7028         (to_allocate_words <= CollectedHeap::min_fill_size())) {
>> 7029       // Cannot fit any object into the area to the next card
>> boundary. Simply create
>> 7030       // an object that fits a single object.
>> 7031       to_allocate_words += CollectedHeap::min_fill_size();
>> 7032     }
>>
>> Generally, if you feel the need to explain each condition in a
>> three-clause if statement then maybe it's a good idea to rephrase it
>> in some way. Maybe use a MAX2-expression to get above the minimum
>> object size and move the "to_allocate_words != 0" check to encompass
>> the entire filling logic?
>>
>> 7033
>> 7034     if (to_allocate_words != 0) {
>> 7035       HeapWord* dummy =
>> G1AllocRegion::attempt_allocation(to_allocate_words, true /*
>> bot_updates */);
>>
>> You don't need the G1AllocRegion scope prefix here, attempt_allocation
>> is in the current scope.
>>
>> 7036       CollectedHeap::fill_with_object(dummy, to_allocate_words);
>> 7037     }
>>
>> /Mikael
>>
>>>
>>> The crash happens with the following stack trace:
>>> Stack: [0x00007fd435a1f000,0x00007fd435b20000], sp=0x00007fd435b1bc30,
>>> free space=1011k
>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>> C=native code)
>>> V  [libjvm.so+0x541261]
>>> G1BlockOffsetArray::forward_to_block_containing_addr_slow(HeapWord*,
>>> HeapWord*, void const*)+0xf1
>>> V  [libjvm.so+0x959e54]
>>> DirtyCardToOopClosure::do_MemRegion(MemRegion)+0x64
>>> V  [libjvm.so+0x56d2a4] ScanRSClosure::doHeapRegion(HeapRegion*)+0x374
>>> V  [libjvm.so+0x542dd0]
>>> G1CollectedHeap::collection_set_iterate_from(HeapRegion*,
>>> HeapRegionClosure*)+0x60
>>> V  [libjvm.so+0x56c08c]  G1RemSet::scanRS(OopsInHeapRegionClosure*,
>>> CodeBlobToOopClosure*, int)+0xdc
>>> V  [libjvm.so+0x56c4d5]
>>> G1RemSet::oops_into_collection_set_do(OopsInHeapRegionClosure*,
>>> CodeBlobToOopClosure*, int)+0x145
>>> V  [libjvm.so+0x549ef4] G1CollectedHeap::g1_process_strong_roots(bool,
>>> SharedHeap::ScanningOption, OopClosure*, OopsInHeapRegionClosure*,
>>> G1KlassScanClosure*, int)+0x224
>>> V  [libjvm.so+0x558a88]  G1ParTask::work(unsigned int)+0xb88
>>> V  [libjvm.so+0xa4a9ff]  GangWorker::loop()+0xcf
>>> V  [libjvm.so+0x8a0058]  java_start(Thread*)+0x108
>>>
>>> Here, the GC thread crashes while scanning the RemSet (part of the
>>> non-CSet regions). And it happens to scan a region to which another
>>> thread in G1ParEvacuateFollowersClosure is copying contents to, and this
>>> region was found out to be an Old GC alloc region.
>>>
>>> This change makes sure that we fill up the last card of the Old GC alloc
>>> region that was being allocated into, with a dummy object so that it
>>> does not get scanned by the remset scanning GC threads.
>>>
>>> This change applies cleanly to 8u and 7u repos.
>>>
>>> Thanks to Thomas Schatzl for his help in investigating the crash and
>>> suggesting this solution.
>>>
>>> Testing:
>>> - JPRT
>>> - Testing by Coherence QA
>>>
>>> Thanks,
>>> Poonam
>>>


From stefan.karlsson at oracle.com  Mon Aug 18 12:07:32 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 18 Aug 2014 14:07:32 +0200
Subject: RFR: 8055275: Several gc/class_unloading/ tests fail due to missed
	+UnlockDiagnosticVMOptions flag
Message-ID: <53F1EC84.1060502@oracle.com>

Hi,

Please, review this small patch to add the missing flag: 
-XX:+UnlockDiagnosticVMOptions

http://cr.openjdk.java.net/~stefank/8055275/webrev.00/

thanks,
StefanK


From mikael.gerdin at oracle.com  Mon Aug 18 12:20:58 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 18 Aug 2014 14:20:58 +0200
Subject: RFR: 8055275: Several gc/class_unloading/ tests fail due to missed
	+UnlockDiagnosticVMOptions flag
In-Reply-To: <53F1EC84.1060502@oracle.com>
References: <53F1EC84.1060502@oracle.com>
Message-ID: <53F1EFAA.1060304@oracle.com>

Stefan,

On 2014-08-18 14:07, Stefan Karlsson wrote:
> Hi,
>
> Please, review this small patch to add the missing flag:
> -XX:+UnlockDiagnosticVMOptions
>
> http://cr.openjdk.java.net/~stefank/8055275/webrev.00/

Seems reasonable.

/Mikael

>
> thanks,
> StefanK


From jesper.wilhelmsson at oracle.com  Mon Aug 18 12:22:16 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 18 Aug 2014 14:22:16 +0200
Subject: RFR: 8055275: Several gc/class_unloading/ tests fail due to missed
	+UnlockDiagnosticVMOptions flag
In-Reply-To: <53F1EC84.1060502@oracle.com>
References: <53F1EC84.1060502@oracle.com>
Message-ID: <53F1EFF8.2000800@oracle.com>

Shit it!
/Jesper


Stefan Karlsson skrev 18/8/14 14:07:
> Hi,
>
> Please, review this small patch to add the missing flag:
> -XX:+UnlockDiagnosticVMOptions
>
> http://cr.openjdk.java.net/~stefank/8055275/webrev.00/
>
> thanks,
> StefanK


From stefan.karlsson at oracle.com  Mon Aug 18 12:11:49 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 18 Aug 2014 14:11:49 +0200
Subject: RFR: 8055275: Several gc/class_unloading/ tests fail due to missed
	+UnlockDiagnosticVMOptions flag
In-Reply-To: <53F1EFAA.1060304@oracle.com>
References: <53F1EC84.1060502@oracle.com> <53F1EFAA.1060304@oracle.com>
Message-ID: <53F1ED85.5070202@oracle.com>


On 2014-08-18 14:20, Mikael Gerdin wrote:
> Stefan,
>
> On 2014-08-18 14:07, Stefan Karlsson wrote:
>> Hi,
>>
>> Please, review this small patch to add the missing flag:
>> -XX:+UnlockDiagnosticVMOptions
>>
>> http://cr.openjdk.java.net/~stefank/8055275/webrev.00/
>
> Seems reasonable.

Thanks.

StefanK

>
> /Mikael
>
>>
>> thanks,
>> StefanK



From stefan.karlsson at oracle.com  Mon Aug 18 12:12:15 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 18 Aug 2014 14:12:15 +0200
Subject: RFR: 8055275: Several gc/class_unloading/ tests fail due to missed
	+UnlockDiagnosticVMOptions flag
In-Reply-To: <53F1EFF8.2000800@oracle.com>
References: <53F1EC84.1060502@oracle.com> <53F1EFF8.2000800@oracle.com>
Message-ID: <53F1ED9F.7080201@oracle.com>

Thanks!

StefanK

On 2014-08-18 14:22, Jesper Wilhelmsson wrote:
> Shit it!
> /Jesper
>
>
> Stefan Karlsson skrev 18/8/14 14:07:
>> Hi,
>>
>> Please, review this small patch to add the missing flag:
>> -XX:+UnlockDiagnosticVMOptions
>>
>> http://cr.openjdk.java.net/~stefank/8055275/webrev.00/
>>
>> thanks,
>> StefanK



From jesper.wilhelmsson at oracle.com  Mon Aug 18 13:00:13 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 18 Aug 2014 15:00:13 +0200
Subject: RFR (XS): 8055091: CollectedHeap::_reserved usage should be
	cleaned up
In-Reply-To: <53F1C18D.7050709@oracle.com>
References: <53F1ACCC.9080102@oracle.com> <53F1BED0.10605@oracle.com>
	<53F1C18D.7050709@oracle.com>
Message-ID: <53F1F8DD.7020202@oracle.com>

With the changes suggested by Mikael this looks good.
Ship it!
/Jesper

Marcus Larsson skrev 18/8/14 11:04:
> Hi,
>
> On 08/18/2014 10:52 AM, Mikael Gerdin wrote:
>> Hi Marcus,
>>
>> On 2014-08-18 09:35, Marcus Larsson wrote:
>>> Hi,
>>>
>>> Can I have reviews for this small change to make the _reserved field of
>>> CollectedHeap private, unifying its initialization in a protected method.
>>>
>>> CR:
>>> http://cr.openjdk.java.net/~mgerdin/mlarsson/webrev-8055091/
>>
>> This looks good, but can you please rename set_reserved_region to
>> initialize_reserved_region to signal that it should only be called once. I
>> don't need to re-review the name change.
> I will do that.
> Thank you for reviewing.
>
>>
>> /Mikael
>>
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8055091
>>>
>>> Testing:
>>> jprt
>>>
>>> Thanks,
>>> Marcus
>


From thomas.schatzl at oracle.com  Mon Aug 18 13:09:56 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 18 Aug 2014 15:09:56 +0200
Subject: RFR (XXS): 8054362:
	gc/g1/TestEagerReclaimHumongousRegions2.java timeout
In-Reply-To: <53F1D1E8.8010602@oracle.com>
References: <1407426202.2631.27.camel@cirrus> <53E3AAD2.4080306@oracle.com>
	<53E4C3FB.4080903@oracle.com> <1407748324.2718.6.camel@cirrus>
	<53F1D1E8.8010602@oracle.com>
Message-ID: <1408367396.2650.35.camel@cirrus>

Hi Dmitry,

  thanks for looking at the change again:

On Mon, 2014-08-18 at 14:14 +0400, Dmitry Fazunenko wrote:
> Hi Thomas,
> 
[...]
> > It would take considerable effort to modify it for multiple region sizes
> > for no noticable gain.
> 
> Yes, TestEagerReclaimHumongousRegions2 is the regression test for 
> 8051973 problem.
> Minimal effort is required to update it to cover more. If you don't mind 
> I can file an RFE for it.

Yes, let's file an RFE for it. 

> >> Could we make the test check the time? Maybe do the loop for 1 minute
> >> but no more than 20 iterations?
> > I implemented this idea as it seems less failure prone than trying to
> > guess the speed of the machine. Fast machine easily finish the test
> > within the given time, slower ones should get enough coverage.
> 
> I agree, this approach is better. The fix looks good to me.
> One minor note: I would reduce timeout from 60 seconds to 50 to finish 
> normally if timeout is set to 1 minute.
> 

Done.

Webrev:
http://cr.openjdk.java.net/~tschatzl/8054362/webrev.2/

Thanks,
  Thomas



From bengt.rutisson at oracle.com  Mon Aug 18 13:21:33 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 18 Aug 2014 15:21:33 +0200
Subject: RFR (XXL): 8038423: G1: Decommit memory within the heap
In-Reply-To: <1408023422.2686.77.camel@cirrus>
References: <1407856327.2700.39.camel@cirrus> <10439232.cEubY2hMkq@mgerdin03>
	<1408023422.2686.77.camel@cirrus>
Message-ID: <53F1FDDD.3040005@oracle.com>


Hi Thomas,

Latest webrev looks good to me.

One very minor nit.
Line 133 in the new version of cardTableModRefBS.cpp has three spaces 
indentation. This was already like that, but since you have correctly 
indented the lines after it might be worth indenting this line correctly 
also. :)

Thanks,
Bengt


On 2014-08-14 15:37, Thomas Schatzl wrote:
> Hi Mikael,
>
>    thanks for the review :)
>
> On Thu, 2014-08-14 at 11:39 +0200, Mikael Gerdin wrote:
>> Hi Thomas,
>>
>> On Tuesday 12 August 2014 17.12.07 Thomas Schatzl wrote:
>>> Hi all,
>>>
>>>    can I have reviews for this change? It implements the capability for
>>> G1 to shrink/expand the heap on a per-region basis without the
>>> constraint that shrinking/expansion needs to occur at the highest
>>> address of the reserved space.
>>>
>>> Further it implements automatic commit/uncommit of all (relevant) large
>>> heap data structures (auxiliary data like block offset table, card
>>> table, mark bitmaps, hot card cache) at the same time the corresponding
>>> heap region is (un-)committed.
>>>
>>> This change implements basic support for this new behavior: selection of
>>> regions to (un-)commit is not particularly sophisticated.
>>>
>>> For easier reviewing, some notes:
>>> - start at the new initialization code in G1CollectedHeap::initialize()
>>> - all memory commit/uncommit activity of auxiliary data is tied to
>>> regions: the new G1RegionToSpaceMapper class manages translation between
>>> regions and whatever granularity the auxiliary data is
>>> committed/uncommitted.
>>> - these G1RegionToSpaceMappers are managed by HeapRegionSeq.
>>>
>>> This change is based on the review for JDK-8054818. As mentioned there,
>>> there will be some cleanup CRs after this change: at least a CR to
>>> rename HeapRegionSeq to HeapRegionManager, and another one that cleans
>>> up the card table code.
>>>
>>> They were split out for easier review, as they are quite large too but
>>> do not contribute to the functionality.
>>>
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8038423
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~tschatzl/8038423/webrev/
>> g1CollectedHeap.cpp
>>
>> 2006   g1_barrier_set()->initialize(cardtable_storage);
>>
>> Can this initialization be moved to below all the create_mapper calls?
>> It's easy to miss it in all the similar calls there.
> Fixed.
>
>> g1RegionToSpaceMapper.cpp
>>
>>    55   G1RegionsLargerThanCommitSizeMapper(ReservedSpace rs, size_t
>> os_commit_granularity,
>>    56     size_t alloc_granularity, size_t commit_factor, MemoryType type) :
>>    57      G1RegionToSpaceMapper(rs, os_commit_granularity, alloc_granular
>>
>> Please line up the parameters like you did in the SmallerThan variant.
>>
>>    94  public:
>>    95   G1RegionsSmallerThanCommitSizeMapper(ReservedSpace rs,
>>    96                                         size_t os_commit_granularity,
>>
>> The rest of the parameters are not aligned with the ReservedSpace one.
> Fixed. I also did more alignment.
>
>> g1BlockOffsetTable.inline.hpp
>>
>>   50 #define check_index(index, msg)
>> \
>>    51   assert((index) < (_reserved.word_size() >> LogN_words),
>> \
>>    52          err_msg("%s - "
>> \
>>    53                  "index: " SIZE_FORMAT ", _vs.committed_size: "
>> SIZE_FORMAT,   \
>>    54                  msg, (index), (_reserved.word_size() >> LogN_words)));
>> \
>>
>> You should be able to do string concat on msg in the macro instead of using %s
>> in err_msg, something like
>> err_msg(msg  " - index: " ...)
>>
> No, that does not work. I kept it, but realigned the lines in the macro.
>
>> g1BlockOffsetTable.cpp
>>    38   // exacuted after commit of a region already needs to do some re-
>> initialization of
>>
>> Typo: should be "executed"
> Done.
>
> New webrev at:
> http://cr.openjdk.java.net/~tschatzl/8038423/webrev.1/
> Diff webrev at:
> http://cr.openjdk.java.net/~tschatzl/8038423/webrev.0_to_1/
>
> Thanks,
>    Thomas
>
>



From dmitry.fazunenko at oracle.com  Mon Aug 18 13:27:33 2014
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko)
Date: Mon, 18 Aug 2014 17:27:33 +0400
Subject: RFR (XXS): 8054362: gc/g1/TestEagerReclaimHumongousRegions2.java
	timeout
In-Reply-To: <1408367396.2650.35.camel@cirrus>
References: <1407426202.2631.27.camel@cirrus> <53E3AAD2.4080306@oracle.com>
	<53E4C3FB.4080903@oracle.com> <1407748324.2718.6.camel@cirrus>
	<53F1D1E8.8010602@oracle.com> <1408367396.2650.35.camel@cirrus>
Message-ID: <53F1FF45.1020009@oracle.com>

> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8054362/webrev.2/

Looks good to me.

Thanks,
Dima



On 18.08.2014 17:09, Thomas Schatzl wrote:
> Hi Dmitry,
>
>    thanks for looking at the change again:
>
> On Mon, 2014-08-18 at 14:14 +0400, Dmitry Fazunenko wrote:
>> Hi Thomas,
>>
> [...]
>>> It would take considerable effort to modify it for multiple region sizes
>>> for no noticable gain.
>> Yes, TestEagerReclaimHumongousRegions2 is the regression test for
>> 8051973 problem.
>> Minimal effort is required to update it to cover more. If you don't mind
>> I can file an RFE for it.
> Yes, let's file an RFE for it.
>
>>>> Could we make the test check the time? Maybe do the loop for 1 minute
>>>> but no more than 20 iterations?
>>> I implemented this idea as it seems less failure prone than trying to
>>> guess the speed of the machine. Fast machine easily finish the test
>>> within the given time, slower ones should get enough coverage.
>> I agree, this approach is better. The fix looks good to me.
>> One minor note: I would reduce timeout from 60 seconds to 50 to finish
>> normally if timeout is set to 1 minute.
>>
> Done.
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8054362/webrev.2/
>
> Thanks,
>    Thomas
>



From thomas.schatzl at oracle.com  Mon Aug 18 13:28:29 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 18 Aug 2014 15:28:29 +0200
Subject: Request for review: 8044406: JVM crash with JDK8 (build
	1.8.0-b132) with G1 GC
In-Reply-To: <53F1DEA8.5070606@oracle.com>
References: <53EFFD56.3060600@oracle.com> <53F1BA04.6010902@oracle.com>
	<53F1DEA8.5070606@oracle.com>
Message-ID: <1408368509.2650.44.camel@cirrus>

Hi Poonam,

On Mon, 2014-08-18 at 16:38 +0530, Poonam Bajaj wrote:
> Hello Mikael,
> 
> Thanks for your review. Here's the updated webrev:
> http://cr.openjdk.java.net/~poonam/8044406/webrev.01/

Looks good.

Thanks,
Thomas




From mikael.gerdin at oracle.com  Mon Aug 18 13:36:25 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 18 Aug 2014 15:36:25 +0200
Subject: RFR (XXL): 8038423: G1: Decommit memory within the heap
In-Reply-To: <1408023422.2686.77.camel@cirrus>
References: <1407856327.2700.39.camel@cirrus>	 <10439232.cEubY2hMkq@mgerdin03>
	<1408023422.2686.77.camel@cirrus>
Message-ID: <53F20159.9040004@oracle.com>

Hi Thomas,

On 2014-08-14 15:37, Thomas Schatzl wrote:
> Hi Mikael,
>
>    thanks for the review :)
>
> On Thu, 2014-08-14 at 11:39 +0200, Mikael Gerdin wrote:
>> Hi Thomas,
>>
>> On Tuesday 12 August 2014 17.12.07 Thomas Schatzl wrote:
>>> Hi all,
>>>
>>>    can I have reviews for this change? It implements the capability for
>>> G1 to shrink/expand the heap on a per-region basis without the
>>> constraint that shrinking/expansion needs to occur at the highest
>>> address of the reserved space.
>>>
>>> Further it implements automatic commit/uncommit of all (relevant) large
>>> heap data structures (auxiliary data like block offset table, card
>>> table, mark bitmaps, hot card cache) at the same time the corresponding
>>> heap region is (un-)committed.
>>>
>>> This change implements basic support for this new behavior: selection of
>>> regions to (un-)commit is not particularly sophisticated.
>>>
>>> For easier reviewing, some notes:
>>> - start at the new initialization code in G1CollectedHeap::initialize()
>>> - all memory commit/uncommit activity of auxiliary data is tied to
>>> regions: the new G1RegionToSpaceMapper class manages translation between
>>> regions and whatever granularity the auxiliary data is
>>> committed/uncommitted.
>>> - these G1RegionToSpaceMappers are managed by HeapRegionSeq.
>>>
>>> This change is based on the review for JDK-8054818. As mentioned there,
>>> there will be some cleanup CRs after this change: at least a CR to
>>> rename HeapRegionSeq to HeapRegionManager, and another one that cleans
>>> up the card table code.
>>>
>>> They were split out for easier review, as they are quite large too but
>>> do not contribute to the functionality.
>>>
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8038423
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~tschatzl/8038423/webrev/
>>
>> g1CollectedHeap.cpp
>>
>> 2006   g1_barrier_set()->initialize(cardtable_storage);
>>
>> Can this initialization be moved to below all the create_mapper calls?
>> It's easy to miss it in all the similar calls there.
>
> Fixed.
>
>> g1RegionToSpaceMapper.cpp
>>
>>    55   G1RegionsLargerThanCommitSizeMapper(ReservedSpace rs, size_t
>> os_commit_granularity,
>>    56     size_t alloc_granularity, size_t commit_factor, MemoryType type) :
>>    57      G1RegionToSpaceMapper(rs, os_commit_granularity, alloc_granular
>>
>> Please line up the parameters like you did in the SmallerThan variant.
>>
>>    94  public:
>>    95   G1RegionsSmallerThanCommitSizeMapper(ReservedSpace rs,
>>    96                                         size_t os_commit_granularity,
>>
>> The rest of the parameters are not aligned with the ReservedSpace one.
>
> Fixed. I also did more alignment.
>
>> g1BlockOffsetTable.inline.hpp
>>
>>   50 #define check_index(index, msg)
>> \
>>    51   assert((index) < (_reserved.word_size() >> LogN_words),
>> \
>>    52          err_msg("%s - "
>> \
>>    53                  "index: " SIZE_FORMAT ", _vs.committed_size: "
>> SIZE_FORMAT,   \
>>    54                  msg, (index), (_reserved.word_size() >> LogN_words)));
>> \
>>
>> You should be able to do string concat on msg in the macro instead of using %s
>> in err_msg, something like
>> err_msg(msg  " - index: " ...)
>>
>
> No, that does not work. I kept it, but realigned the lines in the macro.
>
>> g1BlockOffsetTable.cpp
>
>>
>>    38   // exacuted after commit of a region already needs to do some re-
>> initialization of
>>
>> Typo: should be "executed"
>
> Done.
>
> New webrev at:
> http://cr.openjdk.java.net/~tschatzl/8038423/webrev.1/
> Diff webrev at:
> http://cr.openjdk.java.net/~tschatzl/8038423/webrev.0_to_1/

Looks good.

/Mikael

>
> Thanks,
>    Thomas
>
>


From mikael.gerdin at oracle.com  Mon Aug 18 13:37:31 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 18 Aug 2014 15:37:31 +0200
Subject: RFR (XL): 8054818: Refactor HeapRegionSeq to manage heap region
	and auxiliary data
In-Reply-To: <1408023436.2686.78.camel@cirrus>
References: <1407856144.2700.34.camel@cirrus> <1894411.HW1AMZr9eS@mgerdin03>
	<1408023436.2686.78.camel@cirrus>
Message-ID: <53F2019B.6070308@oracle.com>

Hi Thomas,

On 2014-08-14 15:37, Thomas Schatzl wrote:
> Hi Mikael,
>
>    thanks for the review.
>
> On Thu, 2014-08-14 at 09:47 +0200, Mikael Gerdin wrote:
>> On Tuesday 12 August 2014 17.09.04 Thomas Schatzl wrote:
>>> Hi all,
>>>
>>>    can I have reviews for this somewhat large refactoring change? It is
>>> about refactoring the HeapRegionSeq class to manage heap region and
>>> auxiliary data.
>>>
>>> I.e. currently HeapRegionSeq only manages the HeapRegion instances
>>> corresponding to the heap's region. The change gives HeapRegionSeq more
>>> responsibilities, encapsulating functionality related to heap memory
>>> management. This decreases the amount of responsibilities (and
>>> complexity) for the G1CollectedHeap class: decisions about how heap
>>> related memory is allocated/freed/iterated (i.e. how the heap regions
>>> are actually allocated in the heap) is removed from G1CollectedHeap.
>>>
>>> This change only changes the interface to this functionality. It is a
>>> preparatory change for JDK-8038423 "G1: Decommit memory within the
>>> heap", so the change might be slightly more extensive than really
>>> required.
>>>
>>> The RFR for JDK-8038423 will follow to look at it in context.
>>>
>>> There is another CR that renames HeapRegionSeq to HeapRegionmanager too.
>>>
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8054818
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~tschatzl/8054818/webrev/
>>
>> It took me a while to figure out that
>>
>> 50 inline HeapWord* G1CollectedHeap::bottom_addr_for_region(uint index) const
>> {
>>    51   return _reserved.start() + index * HeapRegion::GrainWords;
>>    52 }
>>
>> Is actually referencing CollectedHeap::_reserved
>>
>> It's not clear to me if it ever differs from HeapRegionSeq::_reserved but I
>> suggest that you use that one instead.
>
> Fixed.
>
>>
>> The code which does
>> heap_rs.first_part(max_byte_size);
>> looks like remnants of perm gen, where the rest of the heap_rs would be the
>> reserved memory for the perm gen.
>>
>> CollectedHeap::_reserved is a protected field but only used in a few places
>> where it's initialized by subclasses. I'll file an RFE for it to be made
>> private with a protected initialization method instead.
>
> Okay, thanks.
>
>>
>>
>> heapRegionSeq.hpp
>>   177
>>   178   MemRegion committed() const { MemRegion temp(heap_bottom(),
>> heap_top()); return temp; }
>>
>> why not just
>> return MemRegion(heap_bottom(), heap_top());
>>
>>   179
>>   180   MemRegion reserved() const { MemRegion temp(heap_bottom(), heap_end());
>> return temp; }
>>
>> return MemRegion(heap_bottom(), heap_end());
>>
>
> Fixed.
>
>
>> I didn't look in detail at the humongous allocation code moved from G1CH to
>> HRS but I assume that you've tested this :)
>
> Of course :)
>
> New webrev at
> http://cr.openjdk.java.net/~tschatzl/8054818/webrev.1
> Diff:
> http://cr.openjdk.java.net/~tschatzl/8054818/webrev.0_to_1

Looks good.

/Mikael

>
> Testing:
> jprt
>
> Thanks,
>    Thomas
>


From bengt.rutisson at oracle.com  Mon Aug 18 13:33:07 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 18 Aug 2014 15:33:07 +0200
Subject: RFR (XL): 8054818: Refactor HeapRegionSeq to manage heap region
	and auxiliary data
In-Reply-To: <1408023436.2686.78.camel@cirrus>
References: <1407856144.2700.34.camel@cirrus> <1894411.HW1AMZr9eS@mgerdin03>
	<1408023436.2686.78.camel@cirrus>
Message-ID: <53F20093.4030000@oracle.com>


Hi Thomas,

Looks good.

Bengt


On 2014-08-14 15:37, Thomas Schatzl wrote:
> Hi Mikael,
>
>    thanks for the review.
>
> On Thu, 2014-08-14 at 09:47 +0200, Mikael Gerdin wrote:
>> On Tuesday 12 August 2014 17.09.04 Thomas Schatzl wrote:
>>> Hi all,
>>>
>>>    can I have reviews for this somewhat large refactoring change? It is
>>> about refactoring the HeapRegionSeq class to manage heap region and
>>> auxiliary data.
>>>
>>> I.e. currently HeapRegionSeq only manages the HeapRegion instances
>>> corresponding to the heap's region. The change gives HeapRegionSeq more
>>> responsibilities, encapsulating functionality related to heap memory
>>> management. This decreases the amount of responsibilities (and
>>> complexity) for the G1CollectedHeap class: decisions about how heap
>>> related memory is allocated/freed/iterated (i.e. how the heap regions
>>> are actually allocated in the heap) is removed from G1CollectedHeap.
>>>
>>> This change only changes the interface to this functionality. It is a
>>> preparatory change for JDK-8038423 "G1: Decommit memory within the
>>> heap", so the change might be slightly more extensive than really
>>> required.
>>>
>>> The RFR for JDK-8038423 will follow to look at it in context.
>>>
>>> There is another CR that renames HeapRegionSeq to HeapRegionmanager too.
>>>
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8054818
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~tschatzl/8054818/webrev/
>> It took me a while to figure out that
>>
>> 50 inline HeapWord* G1CollectedHeap::bottom_addr_for_region(uint index) const
>> {
>>    51   return _reserved.start() + index * HeapRegion::GrainWords;
>>    52 }
>>
>> Is actually referencing CollectedHeap::_reserved
>>
>> It's not clear to me if it ever differs from HeapRegionSeq::_reserved but I
>> suggest that you use that one instead.
> Fixed.
>
>> The code which does
>> heap_rs.first_part(max_byte_size);
>> looks like remnants of perm gen, where the rest of the heap_rs would be the
>> reserved memory for the perm gen.
>>
>> CollectedHeap::_reserved is a protected field but only used in a few places
>> where it's initialized by subclasses. I'll file an RFE for it to be made
>> private with a protected initialization method instead.
> Okay, thanks.
>
>>
>> heapRegionSeq.hpp
>>   177
>>   178   MemRegion committed() const { MemRegion temp(heap_bottom(),
>> heap_top()); return temp; }
>>
>> why not just
>> return MemRegion(heap_bottom(), heap_top());
>>
>>   179
>>   180   MemRegion reserved() const { MemRegion temp(heap_bottom(), heap_end());
>> return temp; }
>>
>> return MemRegion(heap_bottom(), heap_end());
>>
> Fixed.
>
>
>> I didn't look in detail at the humongous allocation code moved from G1CH to
>> HRS but I assume that you've tested this :)
> Of course :)
>
> New webrev at
> http://cr.openjdk.java.net/~tschatzl/8054818/webrev.1
> Diff:
> http://cr.openjdk.java.net/~tschatzl/8054818/webrev.0_to_1
>
> Testing:
> jprt
>
> Thanks,
>    Thomas
>



From mikael.gerdin at oracle.com  Mon Aug 18 14:50:09 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 18 Aug 2014 16:50:09 +0200
Subject: RFR (XS): 8053998: Hot card cache flush chunk size too coarse
	grained
In-Reply-To: <53F1AADA.7000604@oracle.com>
References: <53F1AADA.7000604@oracle.com>
Message-ID: <53F212A1.1090205@oracle.com>

Hi Marcus,

On 2014-08-18 09:27, Marcus Larsson wrote:
> Hi,
>
> Can I have reviews for this small patch changing the hot card cache
> flush chunks to a fixed size?
>
> CR:
> http://cr.openjdk.java.net/~mgerdin/mlarsson/webrev-8053998/

Can you move the value "32" to a constant? Both stringTable.cpp and 
symbolTable.cpp define a
const int ClaimChunkSize = 32;
That seems like a reasonable pattern, but you should probably make it a 
static global or scope it inside G1HotCardCache.

Otherwise it looks good.

For the record I asked Marcus about the value "32" and he had done some 
experiments to come up with the number.

/Mikael

>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8053998
>
> Testing:
> jprt, SPECjbb2013
>
> Thanks,
> Marcus


From thomas.schatzl at oracle.com  Tue Aug 19 07:18:32 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 19 Aug 2014 09:18:32 +0200
Subject: RFR (S): 8055358: G1: Clean up usages of heap_region_containing
	(8u40 backport)
Message-ID: <1408432712.2732.7.camel@cirrus>

Hi all,

  can I have reviews for the following backport of 8040722 to 8u40? It
helps merging the 

There were two merge errors:

- in g1OopClosures.inline.hpp,
G1UpdateRSOrPushRefOopClosure::do_oop_nv() did not apply because of some
typo fixes in a comment.

- in heapRegionSeq.inline.hpp, HeapRegionSeq::addr_to_region_unsafe()
changes did not apply because of include changes.

Webrev:
http://cr.openjdk.java.net/~tschatzl/8040722/webrev/

Original webrev:
http://cr.openjdk.java.net/~brutisso/8040722/webrev.03/

Thanks,
  Thomas






From bengt.rutisson at oracle.com  Tue Aug 19 07:55:13 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 19 Aug 2014 09:55:13 +0200
Subject: RFR (S): 8055358: G1: Clean up usages of heap_region_containing
	(8u40 backport)
In-Reply-To: <1408432712.2732.7.camel@cirrus>
References: <1408432712.2732.7.camel@cirrus>
Message-ID: <53F302E1.1040708@oracle.com>


Hi Thomas,

Looks good. Thanks for backporting this.

You will use the original bug number (8040722) for the backport, right?
Thanks,
Bengt


On 2014-08-19 09:18, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for the following backport of 8040722 to 8u40? It
> helps merging the
>
> There were two merge errors:
>
> - in g1OopClosures.inline.hpp,
> G1UpdateRSOrPushRefOopClosure::do_oop_nv() did not apply because of some
> typo fixes in a comment.
>
> - in heapRegionSeq.inline.hpp, HeapRegionSeq::addr_to_region_unsafe()
> changes did not apply because of include changes.
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8040722/webrev/
>
> Original webrev:
> http://cr.openjdk.java.net/~brutisso/8040722/webrev.03/
>
> Thanks,
>    Thomas
>
>
>
>



From thomas.schatzl at oracle.com  Tue Aug 19 08:20:20 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 19 Aug 2014 10:20:20 +0200
Subject: RFR (S): 8u40 Backport of 8054818: Refactor HeapRegionSeq to manage
	heap region and auxiliary data
Message-ID: <1408436420.2732.12.camel@cirrus>

Hi all,

  can I have reviews for the backport of 8054818?

The file heapRegionSeq.hpp did not apply because of an unfixed typo.
I.e. the current file reads "Empty contructor", while the patch expects
"Empty constructor" in some comment.

New webrev:
http://cr.openjdk.java.net/~tschatzl/8054818/webrev.8u40/

Original change:
http://cr.openjdk.java.net/~tschatzl/8054818/webrev.1/

Testing:
jprt

Thanks,
  Thomas




From thomas.schatzl at oracle.com  Tue Aug 19 08:24:35 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 19 Aug 2014 10:24:35 +0200
Subject: RFR (S): 8055358: G1: Clean up usages of heap_region_containing
	(8u40 backport)
In-Reply-To: <53F302E1.1040708@oracle.com>
References: <1408432712.2732.7.camel@cirrus> <53F302E1.1040708@oracle.com>
Message-ID: <1408436675.2732.13.camel@cirrus>

Hi Bengt,

On Tue, 2014-08-19 at 09:55 +0200, Bengt Rutisson wrote:
> Hi Thomas,
> 
> Looks good. Thanks for backporting this.
> 
> You will use the original bug number (8040722) for the backport, right?
> Thanks,
> Bengt

  thanks for the review. Sure, I will use the original commit message
for this. :)

Thanks,
  Thomas




From bengt.rutisson at oracle.com  Tue Aug 19 08:33:06 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 19 Aug 2014 10:33:06 +0200
Subject: RFR (S): 8u40 Backport of 8054818: Refactor HeapRegionSeq to
	manage heap region and auxiliary data
In-Reply-To: <1408436420.2732.12.camel@cirrus>
References: <1408436420.2732.12.camel@cirrus>
Message-ID: <53F30BC2.6040300@oracle.com>


Hi Thomas,

I only checked the heapRegionSeq.hpp file and that looks ok to me.

Reviewed.

Bengt


On 2014-08-19 10:20, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for the backport of 8054818?
>
> The file heapRegionSeq.hpp did not apply because of an unfixed typo.
> I.e. the current file reads "Empty contructor", while the patch expects
> "Empty constructor" in some comment.
>
> New webrev:
> http://cr.openjdk.java.net/~tschatzl/8054818/webrev.8u40/
>
> Original change:
> http://cr.openjdk.java.net/~tschatzl/8054818/webrev.1/
>
> Testing:
> jprt
>
> Thanks,
>    Thomas
>
>



From stefan.karlsson at oracle.com  Tue Aug 19 10:25:15 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 19 Aug 2014 12:25:15 +0200
Subject: RFR: 8035939: java/lang/management/MemoryMXBean/MemoryManagement.java
	timed out on Linux-amd64
Message-ID: <53F3260B.3080400@oracle.com>

Hi all,

Please review this patch harden two MemoryMXBean tests. These tests 
cause intermittent test failures when the allocated objects are put in 
the young gen instead of the old gen. The proposed fix/workaround is to 
lower the young gen size and assert that the allocated objects are large 
enough to not fit in the young gen.

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

thanks,
StefanK


From staffan.larsen at oracle.com  Tue Aug 19 10:51:44 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 19 Aug 2014 12:51:44 +0200
Subject: RFR: 8035939:
	java/lang/management/MemoryMXBean/MemoryManagement.java timed
	out on Linux-amd64
In-Reply-To: <53F3260B.3080400@oracle.com>
References: <53F3260B.3080400@oracle.com>
Message-ID: <904492CB-C134-4FED-AB48-3F39846EE900@oracle.com>

Looks good!

Thanks,
/Staffan

On 19 aug 2014, at 12:25, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:

> Hi all,
> 
> Please review this patch harden two MemoryMXBean tests. These tests cause intermittent test failures when the allocated objects are put in the young gen instead of the old gen. The proposed fix/workaround is to lower the young gen size and assert that the allocated objects are large enough to not fit in the young gen.
> 
> http://cr.openjdk.java.net/~stefank/8035939/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8035939
> 
> thanks,
> StefanK



From bengt.rutisson at oracle.com  Tue Aug 19 10:48:56 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 19 Aug 2014 12:48:56 +0200
Subject: RFR: 8035939:
	java/lang/management/MemoryMXBean/MemoryManagement.java
	timed out on Linux-amd64
In-Reply-To: <53F3260B.3080400@oracle.com>
References: <53F3260B.3080400@oracle.com>
Message-ID: <53F32B98.2010809@oracle.com>


Hi Stefank,

Seems reasonable. Reviewed.

Bengt


On 2014-08-19 12:25, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch harden two MemoryMXBean tests. These tests 
> cause intermittent test failures when the allocated objects are put in 
> the young gen instead of the old gen. The proposed fix/workaround is 
> to lower the young gen size and assert that the allocated objects are 
> large enough to not fit in the young gen.
>
> http://cr.openjdk.java.net/~stefank/8035939/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8035939
>
> thanks,
> StefanK



From stefan.karlsson at oracle.com  Tue Aug 19 10:50:39 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 19 Aug 2014 12:50:39 +0200
Subject: RFR: 8035939:
	java/lang/management/MemoryMXBean/MemoryManagement.java
	timed out on Linux-amd64
In-Reply-To: <904492CB-C134-4FED-AB48-3F39846EE900@oracle.com>
References: <53F3260B.3080400@oracle.com>
	<904492CB-C134-4FED-AB48-3F39846EE900@oracle.com>
Message-ID: <53F32BFF.90409@oracle.com>

On 2014-08-19 12:51, Staffan Larsen wrote:
> Looks good!

Thanks!

StefanK

>
> Thanks,
> /Staffan
>
> On 19 aug 2014, at 12:25, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
>
>> Hi all,
>>
>> Please review this patch harden two MemoryMXBean tests. These tests cause intermittent test failures when the allocated objects are put in the young gen instead of the old gen. The proposed fix/workaround is to lower the young gen size and assert that the allocated objects are large enough to not fit in the young gen.
>>
>> http://cr.openjdk.java.net/~stefank/8035939/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8035939
>>
>> thanks,
>> StefanK



From stefan.karlsson at oracle.com  Tue Aug 19 10:50:55 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 19 Aug 2014 12:50:55 +0200
Subject: RFR: 8035939:
	java/lang/management/MemoryMXBean/MemoryManagement.java
	timed out on Linux-amd64
In-Reply-To: <53F32B98.2010809@oracle.com>
References: <53F3260B.3080400@oracle.com> <53F32B98.2010809@oracle.com>
Message-ID: <53F32C0F.4030006@oracle.com>


On 2014-08-19 12:48, Bengt Rutisson wrote:
>
> Hi Stefank,
>
> Seems reasonable. Reviewed.

Thanks. =)

StefanK

>
> Bengt
>
>
> On 2014-08-19 12:25, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch harden two MemoryMXBean tests. These tests 
>> cause intermittent test failures when the allocated objects are put 
>> in the young gen instead of the old gen. The proposed fix/workaround 
>> is to lower the young gen size and assert that the allocated objects 
>> are large enough to not fit in the young gen.
>>
>> http://cr.openjdk.java.net/~stefank/8035939/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8035939
>>
>> thanks,
>> StefanK
>



From mikael.gerdin at oracle.com  Tue Aug 19 11:28:02 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 19 Aug 2014 13:28:02 +0200
Subject: RFR: 8035939:
	java/lang/management/MemoryMXBean/MemoryManagement.java
	timed out on Linux-amd64
In-Reply-To: <53F3260B.3080400@oracle.com>
References: <53F3260B.3080400@oracle.com>
Message-ID: <53F334C2.6020505@oracle.com>

Hi Stefan,

On 2014-08-19 12:25, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch harden two MemoryMXBean tests. These tests
> cause intermittent test failures when the allocated objects are put in
> the young gen instead of the old gen. The proposed fix/workaround is to
> lower the young gen size and assert that the allocated objects are large
> enough to not fit in the young gen.
>
> http://cr.openjdk.java.net/~stefank/8035939/webrev.00/

Looks good.

/Mikael

> https://bugs.openjdk.java.net/browse/JDK-8035939
>
> thanks,
> StefanK


From stefan.karlsson at oracle.com  Tue Aug 19 11:52:10 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 19 Aug 2014 13:52:10 +0200
Subject: RFR: 8035939:
	java/lang/management/MemoryMXBean/MemoryManagement.java
	timed out on Linux-amd64
In-Reply-To: <53F334C2.6020505@oracle.com>
References: <53F3260B.3080400@oracle.com> <53F334C2.6020505@oracle.com>
Message-ID: <53F33A6A.7010108@oracle.com>


On 2014-08-19 13:28, Mikael Gerdin wrote:
> Hi Stefan,
>
> On 2014-08-19 12:25, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch harden two MemoryMXBean tests. These tests
>> cause intermittent test failures when the allocated objects are put in
>> the young gen instead of the old gen. The proposed fix/workaround is to
>> lower the young gen size and assert that the allocated objects are large
>> enough to not fit in the young gen.
>>
>> http://cr.openjdk.java.net/~stefank/8035939/webrev.00/
>
> Looks good.

Thanks.

StefanK

>
> /Mikael
>
>> https://bugs.openjdk.java.net/browse/JDK-8035939
>>
>> thanks,
>> StefanK



From Leonid.Mesnik at oracle.com  Tue Aug 19 12:44:23 2014
From: Leonid.Mesnik at oracle.com (Leonid Mesnik)
Date: Tue, 19 Aug 2014 16:44:23 +0400
Subject: RFR 8055098: WB API should be extended to provide information about
	size and age of object.
Message-ID: <53F346A7.1090209@oracle.com>

Dear All

Could I have review for this patch.
issue: https://bugs.openjdk.java.net/browse/JDK-8055098
webrev: http://cr.openjdk.java.net/~jcoomes/8u/lmesnik/8055098-wbapi/
This patch applied clearly to jdk8u and jdk9. This is RFR for 
integration into jdk9/hs-gc. The RFR for backporting I'll send after fix 
is integrated into jdk9.

Fix:
WB API was extended by methods which allow to know object size and if it 
is in old generation. Also whitebox method which added young GC was 
added. Fix included unit test.
Testing: JPRT for 8u and 9, adhoc testing with different GCs.

Thank you
Leonid



From thomas.schatzl at oracle.com  Tue Aug 19 14:21:08 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 19 Aug 2014 16:21:08 +0200
Subject: RFR (XS): 8u40 Backport of 8038423: G1: Decommit memory within the
	heap
Message-ID: <1408458068.2732.36.camel@cirrus>

Hi all,

  can I have reviews for backport merge conflicts for 8038423?

Again, it's two minor issues:

 - typo in g1CardCounts.cpp (expects "... will be an OOB access...", but
is "... will be an OOB accesss...").

 - missing change in heapRegionRemSet.cpp, the format string for the
initializer of the OtherRegionTable mutex is expected to read
"HeapRegionRemSet lock #%u", but is "HeapRegionRemSet lock
#"UINT32_FORMAT".
[The missing change seems to be 8039244, which cannot be easily
backported.]

Webrev:
http://cr.openjdk.java.net/~tschatzl/8038423/webrev.8u40/

Original webrev:
http://cr.openjdk.java.net/~tschatzl/8038423/webrev.1/

Thanks,
  Thomas



From bengt.rutisson at oracle.com  Wed Aug 20 07:01:52 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 20 Aug 2014 09:01:52 +0200
Subject: RFR (XS): 8u40 Backport of 8038423: G1: Decommit memory within
	the heap
In-Reply-To: <1408458068.2732.36.camel@cirrus>
References: <1408458068.2732.36.camel@cirrus>
Message-ID: <53F447E0.7010608@oracle.com>


Hi Thomas,

Merge looks good.

The four new files (g1PageBasedVirtualSpace.cpp/hpp and 
g1RegionToSpaceMapper.cpp/hpp) are missing from the backport webrev. 
Don't forget to 'hg add' them before you push ;) No need for a new review.

Thanks,
Bengt


On 2014-08-19 16:21, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for backport merge conflicts for 8038423?
>
> Again, it's two minor issues:
>
>   - typo in g1CardCounts.cpp (expects "... will be an OOB access...", but
> is "... will be an OOB accesss...").
>
>   - missing change in heapRegionRemSet.cpp, the format string for the
> initializer of the OtherRegionTable mutex is expected to read
> "HeapRegionRemSet lock #%u", but is "HeapRegionRemSet lock
> #"UINT32_FORMAT".
> [The missing change seems to be 8039244, which cannot be easily
> backported.]
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8038423/webrev.8u40/
>
> Original webrev:
> http://cr.openjdk.java.net/~tschatzl/8038423/webrev.1/
>
> Thanks,
>    Thomas
>



From thomas.schatzl at oracle.com  Wed Aug 20 11:05:21 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 20 Aug 2014 13:05:21 +0200
Subject: RFR (XS): JDK-8055635: Missing include in g1RegionToSpaceMapper.hpp
	results in unresolved symbol of fastdebug build without precompiled
	headers
Message-ID: <1408532721.2677.10.camel@cirrus>

Hi,

  can I have reviews for the following small change? It fixes a missing
symbol error when trying to run the VM after JDK-8038423, if the VM is
built on Linux with gcc 4.8.2-16 without precompiled headers in
fastdebug mode.

Not sure how that slipped through since I always build without
precompiled headers, but well...

CR:
https://bugs.openjdk.java.net/browse/JDK-8055635
Webrev:
http://cr.openjdk.java.net/~tschatzl/8055635/webrev/

Testing:
local testing, jprt building

Thanks,
  Thomas




From mikael.gerdin at oracle.com  Wed Aug 20 11:11:56 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 20 Aug 2014 13:11:56 +0200
Subject: RFR (XS): JDK-8055635: Missing include in
	g1RegionToSpaceMapper.hpp
	results in unresolved symbol of fastdebug build without precompiled
	headers
In-Reply-To: <1408532721.2677.10.camel@cirrus>
References: <1408532721.2677.10.camel@cirrus>
Message-ID: <53F4827C.7030003@oracle.com>

Hi Thoms,

On 2014-08-20 13:05, Thomas Schatzl wrote:
> Hi,
>
>    can I have reviews for the following small change? It fixes a missing
> symbol error when trying to run the VM after JDK-8038423, if the VM is
> built on Linux with gcc 4.8.2-16 without precompiled headers in
> fastdebug mode.
>
> Not sure how that slipped through since I always build without
> precompiled headers, but well...
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8055635
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8055635/webrev/

Looks good.

/Mikael

>
> Testing:
> local testing, jprt building
>
> Thanks,
>    Thomas
>
>


From mikael.gerdin at oracle.com  Wed Aug 20 11:12:03 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 20 Aug 2014 13:12:03 +0200
Subject: RFR (XS): JDK-8055635: Missing include in
	g1RegionToSpaceMapper.hpp
	results in unresolved symbol of fastdebug build without precompiled
	headers
In-Reply-To: <1408532721.2677.10.camel@cirrus>
References: <1408532721.2677.10.camel@cirrus>
Message-ID: <53F48283.2010304@oracle.com>

Hi Thomas,

On 2014-08-20 13:05, Thomas Schatzl wrote:
> Hi,
>
>    can I have reviews for the following small change? It fixes a missing
> symbol error when trying to run the VM after JDK-8038423, if the VM is
> built on Linux with gcc 4.8.2-16 without precompiled headers in
> fastdebug mode.
>
> Not sure how that slipped through since I always build without
> precompiled headers, but well...
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8055635
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8055635/webrev/

Looks good.

/Mikael

>
> Testing:
> local testing, jprt building
>
> Thanks,
>    Thomas
>
>


From erik.helin at oracle.com  Wed Aug 20 11:34:27 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 20 Aug 2014 13:34:27 +0200
Subject: RFR (XS): JDK-8055635: Missing include in
	g1RegionToSpaceMapper.hpp
	results in unresolved symbol of fastdebug build without precompiled
	headers
In-Reply-To: <1408532721.2677.10.camel@cirrus>
References: <1408532721.2677.10.camel@cirrus>
Message-ID: <53F487C3.7020601@oracle.com>

Looks good, Reviewed.

Thanks,
Erik

On 2014-08-20 13:05, Thomas Schatzl wrote:
> Hi,
>
>    can I have reviews for the following small change? It fixes a missing
> symbol error when trying to run the VM after JDK-8038423, if the VM is
> built on Linux with gcc 4.8.2-16 without precompiled headers in
> fastdebug mode.
>
> Not sure how that slipped through since I always build without
> precompiled headers, but well...
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8055635
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8055635/webrev/
>
> Testing:
> local testing, jprt building
>
> Thanks,
>    Thomas
>
>


From thomas.schatzl at oracle.com  Wed Aug 20 11:41:22 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 20 Aug 2014 13:41:22 +0200
Subject: RFR (XS): 8055525: Bigapp weblogic+medrec fails to startup after
	JDK-8038423
Message-ID: <1408534882.2677.15.camel@cirrus>

Hi all,

  can I have reviews for the following tiny change that fixes startup on
linux with large pages enabled and said large pages configured by the
OS?

The problem is some unnecessary initialization in G1RegionToSpaceMapper
that fakes that all regions are initially committed in that case.

This is not required, because the lower layer (G1PageBasedVirtualSpace)
already does fake commit/uncommit calls (in that case these calls are
nops like done elsewhere).

CR:
https://bugs.openjdk.java.net/browse/JDK-8055525
Webrev:
http://cr.openjdk.java.net/~tschatzl/8055525/webrev/

Testing:
jprt, manual local testing of bigapps/medrec before/after the change

Thanks,
  Thomas




From thomas.schatzl at oracle.com  Wed Aug 20 12:08:19 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 20 Aug 2014 14:08:19 +0200
Subject: RFR (XS): 8055525: Bigapp weblogic+medrec fails to startup
	after JDK-8038423
In-Reply-To: <1408534882.2677.15.camel@cirrus>
References: <1408534882.2677.15.camel@cirrus>
Message-ID: <1408536499.2677.22.camel@cirrus>

Hi all,

  some correction to my explanation:

On Wed, 2014-08-20 at 13:41 +0200, Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews for the following tiny change that fixes startup on
> linux with large pages enabled and said large pages configured by the
> OS?
> 
> The problem is some unnecessary initialization in G1RegionToSpaceMapper
> that fakes that all regions are initially committed in that case.

s/G1RegionToSpaceMapper/G1PageBasedVirtualSpace 

> 
> This is not required, because the lower layer (G1PageBasedVirtualSpace)

... because G1PageBasedVirtualSpace already does ...

> already does fake commit/uncommit calls (in that case these calls are
> nops like done elsewhere).
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8055525
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8055525/webrev/
> 
> Testing:
> jprt, manual local testing of bigapps/medrec before/after the change

Thanks,
  Thomas




From stefan.johansson at oracle.com  Wed Aug 20 12:08:48 2014
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Wed, 20 Aug 2014 14:08:48 +0200
Subject: RFR 8055098: WB API should be extended to provide information
	about size and age of object.
In-Reply-To: <53F346A7.1090209@oracle.com>
References: <53F346A7.1090209@oracle.com>
Message-ID: <53F48FD0.6050308@oracle.com>

Looks good,

Stefan

On 2014-08-19 14:44, Leonid Mesnik wrote:
> Dear All
>
> Could I have review for this patch.
> issue: https://bugs.openjdk.java.net/browse/JDK-8055098
> webrev: http://cr.openjdk.java.net/~jcoomes/8u/lmesnik/8055098-wbapi/
> This patch applied clearly to jdk8u and jdk9. This is RFR for 
> integration into jdk9/hs-gc. The RFR for backporting I'll send after 
> fix is integrated into jdk9.
>
> Fix:
> WB API was extended by methods which allow to know object size and if 
> it is in old generation. Also whitebox method which added young GC was 
> added. Fix included unit test.
> Testing: JPRT for 8u and 9, adhoc testing with different GCs.
>
> Thank you
> Leonid
>



From mikael.gerdin at oracle.com  Wed Aug 20 12:18:15 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 20 Aug 2014 14:18:15 +0200
Subject: RFR (XS): 8055525: Bigapp weblogic+medrec fails to startup after
	JDK-8038423
In-Reply-To: <1408536499.2677.22.camel@cirrus>
References: <1408534882.2677.15.camel@cirrus> <1408536499.2677.22.camel@cirrus>
Message-ID: <53F49207.8040506@oracle.com>

Hi Thomas,

On 2014-08-20 14:08, Thomas Schatzl wrote:
> Hi all,
>
>    some correction to my explanation:

Thanks :)

>
> On Wed, 2014-08-20 at 13:41 +0200, Thomas Schatzl wrote:
>> Hi all,
>>
>>    can I have reviews for the following tiny change that fixes startup on
>> linux with large pages enabled and said large pages configured by the
>> OS?
>>
>> The problem is some unnecessary initialization in G1RegionToSpaceMapper
>> that fakes that all regions are initially committed in that case.
>
> s/G1RegionToSpaceMapper/G1PageBasedVirtualSpace
>
>>
>> This is not required, because the lower layer (G1PageBasedVirtualSpace)
>
> ... because G1PageBasedVirtualSpace already does ...
>
>> already does fake commit/uncommit calls (in that case these calls are
>> nops like done elsewhere).
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8055525
>> Webrev:
>> http://cr.openjdk.java.net/~tschatzl/8055525/webrev/

Looks good.

/Mikael

>>
>> Testing:
>> jprt, manual local testing of bigapps/medrec before/after the change
>
> Thanks,
>    Thomas
>
>


From thomas.schatzl at oracle.com  Wed Aug 20 12:21:02 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 20 Aug 2014 14:21:02 +0200
Subject: RFR (XS): 8u40 Backport of 8038423: G1: Decommit memory within
	the heap
In-Reply-To: <53F447E0.7010608@oracle.com>
References: <1408458068.2732.36.camel@cirrus> <53F447E0.7010608@oracle.com>
Message-ID: <1408537262.2677.24.camel@cirrus>

Hi Bengt,

On Wed, 2014-08-20 at 09:01 +0200, Bengt Rutisson wrote:
> Hi Thomas,
> 
> Merge looks good.
> 
> The four new files (g1PageBasedVirtualSpace.cpp/hpp and 
> g1RegionToSpaceMapper.cpp/hpp) are missing from the backport webrev. 
> Don't forget to 'hg add' them before you push ;) No need for a new review.
> 

Thanks for the review. I won't miss that, and compilation will fail
anyway during pushing - but sorry for the oversight.

Thanks,
Thomas




From thomas.schatzl at oracle.com  Wed Aug 20 12:21:33 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 20 Aug 2014 14:21:33 +0200
Subject: RFR (XS): JDK-8055635: Missing include in
	g1RegionToSpaceMapper.hpp results in unresolved symbol of fastdebug
	build without precompiled headers
In-Reply-To: <53F487C3.7020601@oracle.com>
References: <1408532721.2677.10.camel@cirrus> <53F487C3.7020601@oracle.com>
Message-ID: <1408537293.2677.25.camel@cirrus>

Hi Erik, Mikael,

On Wed, 2014-08-20 at 13:34 +0200, Erik Helin wrote:
> Looks good, Reviewed.
> 

  thanks for the reviews.

Thomas




From thomas.schatzl at oracle.com  Wed Aug 20 12:22:45 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 20 Aug 2014 14:22:45 +0200
Subject: RFR (XS): 8055525: Bigapp weblogic+medrec fails to startup
	after JDK-8038423
In-Reply-To: <53F49207.8040506@oracle.com>
References: <1408534882.2677.15.camel@cirrus>
	<1408536499.2677.22.camel@cirrus> <53F49207.8040506@oracle.com>
Message-ID: <1408537365.2677.26.camel@cirrus>

Hi Mikael,

On Wed, 2014-08-20 at 14:18 +0200, Mikael Gerdin wrote:
> Hi Thomas,
> 
> On 2014-08-20 14:08, Thomas Schatzl wrote:
> > Hi all,
> >
> >    some correction to my explanation:
> 
> Thanks :)
> 
> >
> > On Wed, 2014-08-20 at 13:41 +0200, Thomas Schatzl wrote:
> >> Hi all,
> >>
> >>    can I have reviews for the following tiny change that fixes startup on
> >> linux with large pages enabled and said large pages configured by the
> >> OS?
[...]
> >> already does fake commit/uncommit calls (in that case these calls are
> >> nops like done elsewhere).
> >>
> >> CR:
> >> https://bugs.openjdk.java.net/browse/JDK-8055525
> >> Webrev:
> >> http://cr.openjdk.java.net/~tschatzl/8055525/webrev/
> 
> Looks good.

Thanks for the review,
  Thomas




From marcus.larsson at oracle.com  Wed Aug 20 13:42:27 2014
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Wed, 20 Aug 2014 15:42:27 +0200
Subject: RFR (XS): 8053998: Hot card cache flush chunk size too coarse
	grained
In-Reply-To: <53F212A1.1090205@oracle.com>
References: <53F1AADA.7000604@oracle.com> <53F212A1.1090205@oracle.com>
Message-ID: <53F4A5C3.1060505@oracle.com>

Hello,

On 08/18/2014 04:50 PM, Mikael Gerdin wrote:
> Hi Marcus,
>
> On 2014-08-18 09:27, Marcus Larsson wrote:
>> Hi,
>>
>> Can I have reviews for this small patch changing the hot card cache
>> flush chunks to a fixed size?
>>
>> CR:
>> http://cr.openjdk.java.net/~mgerdin/mlarsson/webrev-8053998/
>
> Can you move the value "32" to a constant? Both stringTable.cpp and 
> symbolTable.cpp define a
> const int ClaimChunkSize = 32;
> That seems like a reasonable pattern, but you should probably make it 
> a static global or scope it inside G1HotCardCache.

Made it a static constant in G1HotCardCache.

New webrev:
http://cr.openjdk.java.net/~mgerdin/mlarsson/webrev-8053998v2/

>
> Otherwise it looks good.
>
> For the record I asked Marcus about the value "32" and he had done 
> some experiments to come up with the number.

Yes, I should have mentioned this in my first email.
I measured with some different fixed sizes, and also by 
over-partitioning the cache to 10 chunks per active worker thread.
The smaller the chunk size the better results I got, so 32 seemed like a 
good number without making it too small.

>
> /Mikael
>
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8053998
>>
>> Testing:
>> jprt, SPECjbb2013
>>
>> Thanks,
>> Marcus

Thanks,
Marcus


From thomas.schatzl at oracle.com  Wed Aug 20 13:44:42 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 20 Aug 2014 15:44:42 +0200
Subject: RFR (XS): 8053998: Hot card cache flush chunk size too coarse
	grained
In-Reply-To: <53F4A5C3.1060505@oracle.com>
References: <53F1AADA.7000604@oracle.com> <53F212A1.1090205@oracle.com>
	<53F4A5C3.1060505@oracle.com>
Message-ID: <1408542282.2677.36.camel@cirrus>

Hi,

On Wed, 2014-08-20 at 15:42 +0200, Marcus Larsson wrote:
> Hello,
> 
> On 08/18/2014 04:50 PM, Mikael Gerdin wrote:
> > Hi Marcus,
> >
> > On 2014-08-18 09:27, Marcus Larsson wrote:
> >> Hi,
> >>
> >> Can I have reviews for this small patch changing the hot card cache
> >> flush chunks to a fixed size?
> >>
> >> CR:
> >> http://cr.openjdk.java.net/~mgerdin/mlarsson/webrev-8053998/
> >
> > Can you move the value "32" to a constant? Both stringTable.cpp and 
> > symbolTable.cpp define a
> > const int ClaimChunkSize = 32;
> > That seems like a reasonable pattern, but you should probably make it 
> > a static global or scope it inside G1HotCardCache.
> 
> Made it a static constant in G1HotCardCache.
> 
> New webrev:
> http://cr.openjdk.java.net/~mgerdin/mlarsson/webrev-8053998v2/


Looks good now, thanks.

Thomas



From mikael.gerdin at oracle.com  Wed Aug 20 13:51:16 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 20 Aug 2014 15:51:16 +0200
Subject: RFR (XS): 8053998: Hot card cache flush chunk size too coarse
	grained
In-Reply-To: <53F4A5C3.1060505@oracle.com>
References: <53F1AADA.7000604@oracle.com> <53F212A1.1090205@oracle.com>
	<53F4A5C3.1060505@oracle.com>
Message-ID: <53F4A7D4.70009@oracle.com>

Hi,

On 2014-08-20 15:42, Marcus Larsson wrote:
> Hello,
>
> On 08/18/2014 04:50 PM, Mikael Gerdin wrote:
>> Hi Marcus,
>>
>> On 2014-08-18 09:27, Marcus Larsson wrote:
>>> Hi,
>>>
>>> Can I have reviews for this small patch changing the hot card cache
>>> flush chunks to a fixed size?
>>>
>>> CR:
>>> http://cr.openjdk.java.net/~mgerdin/mlarsson/webrev-8053998/
>>
>> Can you move the value "32" to a constant? Both stringTable.cpp and
>> symbolTable.cpp define a
>> const int ClaimChunkSize = 32;
>> That seems like a reasonable pattern, but you should probably make it
>> a static global or scope it inside G1HotCardCache.
>
> Made it a static constant in G1HotCardCache.
>
> New webrev:
> http://cr.openjdk.java.net/~mgerdin/mlarsson/webrev-8053998v2/

Looks good.

/Mikael

>
>>
>> Otherwise it looks good.
>>
>> For the record I asked Marcus about the value "32" and he had done
>> some experiments to come up with the number.
>
> Yes, I should have mentioned this in my first email.
> I measured with some different fixed sizes, and also by
> over-partitioning the cache to 10 chunks per active worker thread.
> The smaller the chunk size the better results I got, so 32 seemed like a
> good number without making it too small.
>
>>
>> /Mikael
>>
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8053998
>>>
>>> Testing:
>>> jprt, SPECjbb2013
>>>
>>> Thanks,
>>> Marcus
>
> Thanks,
> Marcus


From thomas.schatzl at oracle.com  Wed Aug 20 13:55:40 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 20 Aug 2014 15:55:40 +0200
Subject: RFR 8055098: WB API should be extended to provide information
	about size and age of object.
In-Reply-To: <53F346A7.1090209@oracle.com>
References: <53F346A7.1090209@oracle.com>
Message-ID: <1408542940.2677.41.camel@cirrus>

Hi Leonid,

On Tue, 2014-08-19 at 16:44 +0400, Leonid Mesnik wrote:
> Dear All
> 
> Could I have review for this patch.
> issue: https://bugs.openjdk.java.net/browse/JDK-8055098
> webrev: http://cr.openjdk.java.net/~jcoomes/8u/lmesnik/8055098-wbapi/
> This patch applied clearly to jdk8u and jdk9. This is RFR for 
> integration into jdk9/hs-gc. The RFR for backporting I'll send after fix 
> is integrated into jdk9.
> 
> Fix:
> WB API was extended by methods which allow to know object size and if it 
> is in old generation. Also whitebox method which added young GC was 
> added. Fix included unit test.
> Testing: JPRT for 8u and 9, adhoc testing with different GCs.

  some comments about the test, the other changes look good:

- TestWBGC.java should probably get a 2014 copyright date

- the test does not have a bug id

- could you set the tenuring threshold for this test to 1 so that the
likelihood that the object is promoted is higher? Different collectors
may have different default tenuring thresholds.

I.e. actually, adding -XX:+AlwaysTenure should be sufficient.

Thanks,
  Thomas



From thomas.schatzl at oracle.com  Wed Aug 20 14:17:46 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 20 Aug 2014 16:17:46 +0200
Subject: RFR (XS): 8054491: Remove wrong assert and refactor code in
	G1CollectorPolicy::record_concurrent_mark_end
In-Reply-To: <53F1ABB5.2080406@oracle.com>
References: <53F1ABB5.2080406@oracle.com>
Message-ID: <1408544266.2677.43.camel@cirrus>

Hi,

On Mon, 2014-08-18 at 09:31 +0200, Marcus Larsson wrote:
> Hi,
> 
> Can I have reviews for this small change cleaning up and refactoring 
> record_concurrent_mark_end()?
> 
> CR:
> http://cr.openjdk.java.net/~mgerdin/mlarsson/webrev-8054491/
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8054491

Looks good to me.

Thanks,
Thomas




From jesper.wilhelmsson at oracle.com  Wed Aug 20 14:23:44 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 20 Aug 2014 16:23:44 +0200
Subject: Prepare for verification?
Message-ID: <53F4AF70.7020708@oracle.com>

Hi,

When removing the generations array I ran in to the following question.

In GenCollectedHeap::do_collection() there is this code:

if (VerifyBeforeGC && i >= VerifyGCLevel &&
     total_collections() >= VerifyGCStartAt) {
   HandleMark hm;  // Discard invalid handles created during verification
   if (!prepared_for_verification) {
     prepare_for_verify();
     prepared_for_verification = true;
   }
   Universe::verify(" VerifyBeforeGC:");
}

Note that we make sure to run prepare_for_verify() before calling 
Universe::verify().

Later there is this code:

if (VerifyAfterGC && i >= VerifyGCLevel &&
     total_collections() >= VerifyGCStartAt) {
   HandleMark hm;  // Discard invalid handles created during verification
   Universe::verify(" VerifyAfterGC:");
}

Here we do not prepare for verification.


Now, what happens if we run with VerifyBeforeGC=false and VerifyAfterGC=true?

As far as I can see, only CMS has an implementation for prepare_for_verify(), 
where it does things like CompactibleFreeListSpace::repairLinearAllocationBlocks()

I have been playing around with CMS trying to provoke something here but I can't 
say that I understand the linear allocation blocks well enough to know how to 
create a potentially bad situation. Could there be a problem here or is the 
preparation before verification voluntary?

Since I'm rewriting this code slightly I need to know if I should preserve this 
behavior or make sure that we have prepared in the after GC case as well.

Thanks,
/Jesper


From Leonid.Mesnik at oracle.com  Wed Aug 20 14:44:11 2014
From: Leonid.Mesnik at oracle.com (Leonid Mesnik)
Date: Wed, 20 Aug 2014 18:44:11 +0400
Subject: RFR 8055098: WB API should be extended to provide information
	about size and age of object.
In-Reply-To: <1408542940.2677.41.camel@cirrus>
References: <53F346A7.1090209@oracle.com> <1408542940.2677.41.camel@cirrus>
Message-ID: <53F4B43B.4000302@oracle.com>

Thomas

Thank you very match. I fixed year and bugid.
Here is new webrev:

http://cr.openjdk.java.net/~tschatzl/8055098/webrev/

The tenuring threshold is already set in ProcessBuilder.

Leonid

On 20.08.2014 17:55, Thomas Schatzl wrote:
> Hi Leonid,
>
> On Tue, 2014-08-19 at 16:44 +0400, Leonid Mesnik wrote:
>> Dear All
>>
>> Could I have review for this patch.
>> issue: https://bugs.openjdk.java.net/browse/JDK-8055098
>> webrev: http://cr.openjdk.java.net/~jcoomes/8u/lmesnik/8055098-wbapi/
>> This patch applied clearly to jdk8u and jdk9. This is RFR for
>> integration into jdk9/hs-gc. The RFR for backporting I'll send after fix
>> is integrated into jdk9.
>>
>> Fix:
>> WB API was extended by methods which allow to know object size and if it
>> is in old generation. Also whitebox method which added young GC was
>> added. Fix included unit test.
>> Testing: JPRT for 8u and 9, adhoc testing with different GCs.
>    some comments about the test, the other changes look good:
>
> - TestWBGC.java should probably get a 2014 copyright date
>
> - the test does not have a bug id
>
> - could you set the tenuring threshold for this test to 1 so that the
> likelihood that the object is promoted is higher? Different collectors
> may have different default tenuring thresholds.
>
> I.e. actually, adding -XX:+AlwaysTenure should be sufficient.
>
> Thanks,
>    Thomas
>



From jon.masamitsu at oracle.com  Wed Aug 20 16:43:49 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 20 Aug 2014 09:43:49 -0700
Subject: Prepare for verification?
In-Reply-To: <53F4AF70.7020708@oracle.com>
References: <53F4AF70.7020708@oracle.com>
Message-ID: <53F4D045.5090000@oracle.com>

prepare_for_verify() was needed by CMS, partly, because CMS could
have dead objects in the CMS generation after the collection.  I think
it was needed with the VerifyDuringGC for CMS.  There was something
like a scan of the CMS generation to check that all the objects on the
freelists were dead and objects not on the freelists were live.  The
prepare_for_verify() is not optional.

The linear allocation blocks were used for perm gen allocation.
Maybe also for the initial allocations from the cms gen.  Linear
allocation blocks are allocated from the cms gen and then
objects are allocated from them by pointer bumps.  Generally
the coalescing of the free blocks isn't good enough to get
contiguous chunks of space big enough for the linear
allocation blocks.  Don't recall why they need to be
fixed up for verification.  Maybe filler objects had to be
inserted.

Jon


On 8/20/2014 7:23 AM, Jesper Wilhelmsson wrote:
> Hi,
>
> When removing the generations array I ran in to the following question.
>
> In GenCollectedHeap::do_collection() there is this code:
>
> if (VerifyBeforeGC && i >= VerifyGCLevel &&
>     total_collections() >= VerifyGCStartAt) {
>   HandleMark hm;  // Discard invalid handles created during verification
>   if (!prepared_for_verification) {
>     prepare_for_verify();
>     prepared_for_verification = true;
>   }
>   Universe::verify(" VerifyBeforeGC:");
> }
>
> Note that we make sure to run prepare_for_verify() before calling 
> Universe::verify().
>
> Later there is this code:
>
> if (VerifyAfterGC && i >= VerifyGCLevel &&
>     total_collections() >= VerifyGCStartAt) {
>   HandleMark hm;  // Discard invalid handles created during verification
>   Universe::verify(" VerifyAfterGC:");
> }
>
> Here we do not prepare for verification.
>
>
> Now, what happens if we run with VerifyBeforeGC=false and 
> VerifyAfterGC=true?
>
> As far as I can see, only CMS has an implementation for 
> prepare_for_verify(), where it does things like 
> CompactibleFreeListSpace::repairLinearAllocationBlocks()
>
> I have been playing around with CMS trying to provoke something here 
> but I can't say that I understand the linear allocation blocks well 
> enough to know how to create a potentially bad situation. Could there 
> be a problem here or is the preparation before verification voluntary?
>
> Since I'm rewriting this code slightly I need to know if I should 
> preserve this behavior or make sure that we have prepared in the after 
> GC case as well.
>
> Thanks,
> /Jesper



From jon.masamitsu at oracle.com  Wed Aug 20 17:44:17 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 20 Aug 2014 10:44:17 -0700
Subject: RFR (XS): 8u40 Backport of 8038423: G1: Decommit memory within
	the heap
In-Reply-To: <1408458068.2732.36.camel@cirrus>
References: <1408458068.2732.36.camel@cirrus>
Message-ID: <53F4DE71.4030607@oracle.com>


On 8/19/2014 7:21 AM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for backport merge conflicts for 8038423?
>
> Again, it's two minor issues:
>
>   - typo in g1CardCounts.cpp (expects "... will be an OOB access...", but
> is "... will be an OOB accesss...").
>
>   - missing change in heapRegionRemSet.cpp, the format string for the
> initializer of the OtherRegionTable mutex is expected to read
> "HeapRegionRemSet lock #%u", but is "HeapRegionRemSet lock
> #"UINT32_FORMAT".
> [The missing change seems to be 8039244, which cannot be easily
> backported.]

I looked at the changes you indicated above and both are consistent
with the jdk9 sources.  If that is what you were seeking - Reviewed.

jon

>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8038423/webrev.8u40/
>
> Original webrev:
> http://cr.openjdk.java.net/~tschatzl/8038423/webrev.1/
>
> Thanks,
>    Thomas
>



From jesper.wilhelmsson at oracle.com  Thu Aug 21 06:58:54 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 21 Aug 2014 08:58:54 +0200
Subject: Prepare for verification?
In-Reply-To: <53F4D045.5090000@oracle.com>
References: <53F4AF70.7020708@oracle.com> <53F4D045.5090000@oracle.com>
Message-ID: <53F598AE.8050401@oracle.com>

Thanks Jon!

Bengt had the theory that the fixing up was only needed before GC since 
afterwards the GC itself has fixed everything already. That sounds reasonable to 
me so I'll just keep the current behavior in my change. Later we should consider 
renaming prepare_for_verify() to prepare_for_verify_before_gc() to indicate that 
it's only needed at this point.
/Jesper


Jon Masamitsu skrev 20/8/14 18:43:
> prepare_for_verify() was needed by CMS, partly, because CMS could
> have dead objects in the CMS generation after the collection.  I think
> it was needed with the VerifyDuringGC for CMS.  There was something
> like a scan of the CMS generation to check that all the objects on the
> freelists were dead and objects not on the freelists were live.  The
> prepare_for_verify() is not optional.
>
> The linear allocation blocks were used for perm gen allocation.
> Maybe also for the initial allocations from the cms gen.  Linear
> allocation blocks are allocated from the cms gen and then
> objects are allocated from them by pointer bumps.  Generally
> the coalescing of the free blocks isn't good enough to get
> contiguous chunks of space big enough for the linear
> allocation blocks.  Don't recall why they need to be
> fixed up for verification.  Maybe filler objects had to be
> inserted.
>
> Jon
>
>
> On 8/20/2014 7:23 AM, Jesper Wilhelmsson wrote:
>> Hi,
>>
>> When removing the generations array I ran in to the following question.
>>
>> In GenCollectedHeap::do_collection() there is this code:
>>
>> if (VerifyBeforeGC && i >= VerifyGCLevel &&
>>     total_collections() >= VerifyGCStartAt) {
>>   HandleMark hm;  // Discard invalid handles created during verification
>>   if (!prepared_for_verification) {
>>     prepare_for_verify();
>>     prepared_for_verification = true;
>>   }
>>   Universe::verify(" VerifyBeforeGC:");
>> }
>>
>> Note that we make sure to run prepare_for_verify() before calling
>> Universe::verify().
>>
>> Later there is this code:
>>
>> if (VerifyAfterGC && i >= VerifyGCLevel &&
>>     total_collections() >= VerifyGCStartAt) {
>>   HandleMark hm;  // Discard invalid handles created during verification
>>   Universe::verify(" VerifyAfterGC:");
>> }
>>
>> Here we do not prepare for verification.
>>
>>
>> Now, what happens if we run with VerifyBeforeGC=false and VerifyAfterGC=true?
>>
>> As far as I can see, only CMS has an implementation for prepare_for_verify(),
>> where it does things like
>> CompactibleFreeListSpace::repairLinearAllocationBlocks()
>>
>> I have been playing around with CMS trying to provoke something here but I
>> can't say that I understand the linear allocation blocks well enough to know
>> how to create a potentially bad situation. Could there be a problem here or is
>> the preparation before verification voluntary?
>>
>> Since I'm rewriting this code slightly I need to know if I should preserve
>> this behavior or make sure that we have prepared in the after GC case as well.
>>
>> Thanks,
>> /Jesper
>


From bengt.rutisson at oracle.com  Fri Aug 22 12:54:52 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 22 Aug 2014 14:54:52 +0200
Subject: RFR (XS): JDK-8055818: Remove PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC
	from g1BlockOffsetTable.cpp
Message-ID: <53F73D9C.6040303@oracle.com>


Hi all,

Can I get reviews for this small change to remove the 
PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC from g1BlockOffsetTable.cpp?


http://cr.openjdk.java.net/~brutisso/8055818/webrev.00/

https://bugs.openjdk.java.net/browse/JDK-8055818

Thanks,
Bengt


From bengt.rutisson at oracle.com  Fri Aug 22 13:01:18 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 22 Aug 2014 15:01:18 +0200
Subject: RFR (S): JDK-8055816: Remove dead code in g1BlockOffsetTable
Message-ID: <53F73F1E.6080302@oracle.com>


Hi all,

Can I get reviews for this small change to remove dead code from the 
G1BlockOffsetTable implementation?

Webrev:
http://cr.openjdk.java.net/~brutisso/8055816/webrev.00/

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


Background:
I'm working on a fix for JDK-8025564 that will involve adding 
verification code to G1BlockOffsetTable. There is already some 
verification code in that class but most of it is unused. To be able to 
know what code I need to add I first need to remove the dead code that 
is not being used.

This patch removes all the dead code that I found. Mostly it is just 
simple removal of unused methods. There is one change that is a little 
bit more complicated. The G1BlockOffsetArray constructor took a 
parameter called init_to_zero. Some places in the code checked for this 
value, but in reality it was always true. The checks were for 
!init_to_zero, so the corresponding code was also dead code.

Thanks,
Bengt


From stefan.karlsson at oracle.com  Fri Aug 22 12:56:01 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 22 Aug 2014 14:56:01 +0200
Subject: RFR (XS): JDK-8055818: Remove PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC
	from g1BlockOffsetTable.cpp
In-Reply-To: <53F73D9C.6040303@oracle.com>
References: <53F73D9C.6040303@oracle.com>
Message-ID: <53F73DE1.2060401@oracle.com>


On 2014-08-22 14:54, Bengt Rutisson wrote:
>
> Hi all,
>
> Can I get reviews for this small change to remove the 
> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC from g1BlockOffsetTable.cpp?
>
>
> http://cr.openjdk.java.net/~brutisso/8055818/webrev.00/

Looks good.

StefanK

>
> https://bugs.openjdk.java.net/browse/JDK-8055818
>
> Thanks,
> Bengt



From mikael.gerdin at oracle.com  Fri Aug 22 13:11:48 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 22 Aug 2014 15:11:48 +0200
Subject: RFR (XS): JDK-8055818: Remove PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC
	from g1BlockOffsetTable.cpp
In-Reply-To: <53F73D9C.6040303@oracle.com>
References: <53F73D9C.6040303@oracle.com>
Message-ID: <1579270.hHsRQpdLKS@mgerdin03>

Bengt,

On Friday 22 August 2014 14.54.52 Bengt Rutisson wrote:
> Hi all,
> 
> Can I get reviews for this small change to remove the
> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC from g1BlockOffsetTable.cpp?
> 
> 
> http://cr.openjdk.java.net/~brutisso/8055818/webrev.00/

Looks good.

/Mikael

> 
> https://bugs.openjdk.java.net/browse/JDK-8055818
> 
> Thanks,
> Bengt



From bengt.rutisson at oracle.com  Fri Aug 22 13:10:58 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 22 Aug 2014 15:10:58 +0200
Subject: RFR (XS): JDK-8055818: Remove PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC
	from g1BlockOffsetTable.cpp
In-Reply-To: <1579270.hHsRQpdLKS@mgerdin03>
References: <53F73D9C.6040303@oracle.com> <1579270.hHsRQpdLKS@mgerdin03>
Message-ID: <53F74162.5020008@oracle.com>


Thanks for the reviews Stefan and Mikael!

Bengt


On 2014-08-22 15:11, Mikael Gerdin wrote:
> Bengt,
>
> On Friday 22 August 2014 14.54.52 Bengt Rutisson wrote:
>> Hi all,
>>
>> Can I get reviews for this small change to remove the
>> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC from g1BlockOffsetTable.cpp?
>>
>>
>> http://cr.openjdk.java.net/~brutisso/8055818/webrev.00/
> Looks good.
>
> /Mikael
>
>> https://bugs.openjdk.java.net/browse/JDK-8055818
>>
>> Thanks,
>> Bengt



From stefan.karlsson at oracle.com  Fri Aug 22 13:07:55 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 22 Aug 2014 15:07:55 +0200
Subject: RFR: 8055416: Several vm/gc/heap/summary "After GC" events emitted
	for the same GC ID
Message-ID: <53F740AB.1030607@oracle.com>

Hi all,

Please review this patch to make sure that the "heap summary after gc" 
events  are only sent once.

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

This was found in one of our closed JFR tests. From the bug report:
---
For client VM and G1 GC several vm/gc/heap/summary events with property 
when='After GC' could be emitted for the same GC ID.
At the same time there will be only one 'Before GC' vm/gc/heap/summary 
event for the same GC ID.
---

thanks,
StefanK


From jesper.wilhelmsson at oracle.com  Fri Aug 22 13:20:15 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Fri, 22 Aug 2014 15:20:15 +0200
Subject: RFR: 8055702 - Remove the generations array
Message-ID: <53F7438F.9030507@oracle.com>

Hi,

This is the first part of the generation array removal. Here I remove the _gens 
array and introduce _young_gen and _old_gen instead. The main change is in 
GenCollectedHeap::do_collection() which used a loop to iterate through the 
generation array. I extracted the contents of that loop into a new method and 
call it with a reference to the generation to be collected.

Webrev: http://cr.openjdk.java.net/~jwilhelm/8055702/webrev/

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


More cleanups in this area are coming. Among other things I will remove from 
GenCollectedHeap: _n_gen, SomeConstants, get_gen(), next_gen(), prev_gen(), 
n_gens() and the concept of levels that is passed around all over the place. 
These will be replaced with a more explicit use of young and old as appropriate.

All that is actually already done, it just needs to be split into more 
reviewable changes. Stay tuned.

Thanks,
/Jesper


From bengt.rutisson at oracle.com  Fri Aug 22 13:29:34 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 22 Aug 2014 15:29:34 +0200
Subject: RFR: 8055416: Several vm/gc/heap/summary "After GC" events emitted
	for the same GC ID
In-Reply-To: <53F740AB.1030607@oracle.com>
References: <53F740AB.1030607@oracle.com>
Message-ID: <53F745BE.6070700@oracle.com>


Hi StefanK,

Looks good.

Bengt


On 2014-08-22 15:07, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to make sure that the "heap summary after gc" 
> events  are only sent once.
>
> http://cr.openjdk.java.net/~stefank/8055416/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8055416
>
> This was found in one of our closed JFR tests. From the bug report:
> ---
> For client VM and G1 GC several vm/gc/heap/summary events with 
> property when='After GC' could be emitted for the same GC ID.
> At the same time there will be only one 'Before GC' vm/gc/heap/summary 
> event for the same GC ID.
> ---
>
> thanks,
> StefanK



From erik.helin at oracle.com  Fri Aug 22 15:01:11 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Fri, 22 Aug 2014 17:01:11 +0200
Subject: RFR: 8055416: Several vm/gc/heap/summary "After GC" events emitted
	for the same GC ID
In-Reply-To: <53F740AB.1030607@oracle.com>
References: <53F740AB.1030607@oracle.com>
Message-ID: <53F75B37.1020609@oracle.com>

Hi Stefan,

looks good, Reviewed! Thanks for fixing this!

Erik

On 2014-08-22 15:07, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to make sure that the "heap summary after gc"
> events  are only sent once.
>
> http://cr.openjdk.java.net/~stefank/8055416/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8055416
>
> This was found in one of our closed JFR tests. From the bug report:
> ---
> For client VM and G1 GC several vm/gc/heap/summary events with property
> when='After GC' could be emitted for the same GC ID.
> At the same time there will be only one 'Before GC' vm/gc/heap/summary
> event for the same GC ID.
> ---
>
> thanks,
> StefanK


From stefan.karlsson at oracle.com  Mon Aug 25 07:21:57 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 25 Aug 2014 09:21:57 +0200
Subject: RFR: 8055416: Several vm/gc/heap/summary "After GC" events emitted
	for the same GC ID
In-Reply-To: <53F745BE.6070700@oracle.com>
References: <53F740AB.1030607@oracle.com> <53F745BE.6070700@oracle.com>
Message-ID: <53FAE415.1090104@oracle.com>

On 22/08/14 15:29, Bengt Rutisson wrote:
>
> Hi StefanK,
>
> Looks good.

Thanks.

StefanK

>
> Bengt
>
>
> On 2014-08-22 15:07, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to make sure that the "heap summary after 
>> gc" events  are only sent once.
>>
>> http://cr.openjdk.java.net/~stefank/8055416/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8055416
>>
>> This was found in one of our closed JFR tests. From the bug report:
>> ---
>> For client VM and G1 GC several vm/gc/heap/summary events with 
>> property when='After GC' could be emitted for the same GC ID.
>> At the same time there will be only one 'Before GC' 
>> vm/gc/heap/summary event for the same GC ID.
>> ---
>>
>> thanks,
>> StefanK
>



From stefan.karlsson at oracle.com  Mon Aug 25 07:22:15 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 25 Aug 2014 09:22:15 +0200
Subject: RFR: 8055416: Several vm/gc/heap/summary "After GC" events emitted
	for the same GC ID
In-Reply-To: <53F75B37.1020609@oracle.com>
References: <53F740AB.1030607@oracle.com> <53F75B37.1020609@oracle.com>
Message-ID: <53FAE427.7040505@oracle.com>

On 22/08/14 17:01, Erik Helin wrote:
> Hi Stefan,
>
> looks good, Reviewed! Thanks for fixing this!

Thanks!

StefanK

>
> Erik
>
> On 2014-08-22 15:07, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to make sure that the "heap summary after gc"
>> events  are only sent once.
>>
>> http://cr.openjdk.java.net/~stefank/8055416/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8055416
>>
>> This was found in one of our closed JFR tests. From the bug report:
>> ---
>> For client VM and G1 GC several vm/gc/heap/summary events with property
>> when='After GC' could be emitted for the same GC ID.
>> At the same time there will be only one 'Before GC' vm/gc/heap/summary
>> event for the same GC ID.
>> ---
>>
>> thanks,
>> StefanK



From thomas.schatzl at oracle.com  Mon Aug 25 14:23:23 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 25 Aug 2014 16:23:23 +0200
Subject: RFR (M): 8054819: Rename HeapRegionSeq to HeapRegionManager
Message-ID: <1408976603.22007.10.camel@cirrus>

Hi all,

  can I have reviews for the following change that renames HeapRegionSeq
to HeapRegionManager?

The reason is that after recent changes HeapRegionSeq got many new
responsibilities. It is not a straight sequence of heap regions any more
at all.

It's a straight rename of the class, moving into new files, and changing
"hrs"-prefixes to "hrm"-prefix.

Further the same change is done to the SA-agent.

CR:
https://bugs.openjdk.java.net/browse/JDK-8054819
Webrev:
http://cr.openjdk.java.net/~tschatzl/8054819/webrev/
Testing:
jprt, vm.heapdump (SA-agent tests), vm.gc tests on aurora

Thanks,
  Thomas



From thomas.schatzl at oracle.com  Mon Aug 25 15:35:23 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 25 Aug 2014 17:35:23 +0200
Subject: RFR (XS): 8055919: Remove dead code in G1 concurrent marking code
Message-ID: <1408980923.22007.21.camel@cirrus>

Hi all,

  can I have reviews for the following change the removes ~150 LOC of
dead code from G1's concurrentMark* source files?

CR:
https://bugs.openjdk.java.net/browse/JDK-8055919
Webrev:
http://cr.openjdk.java.net/~tschatzl/8055919/webrev/
Testing:
jprt

Thanks,
  Thomas



From jesper.wilhelmsson at oracle.com  Mon Aug 25 16:00:51 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 25 Aug 2014 18:00:51 +0200
Subject: RFR (XS): 8055919: Remove dead code in G1 concurrent marking code
In-Reply-To: <1408980923.22007.21.camel@cirrus>
References: <1408980923.22007.21.camel@cirrus>
Message-ID: <53FB5DB3.7010201@oracle.com>

Hi Thomas,

In CMConcurrentMarkingTask::work() you remove the call to 
_cm->do_yield_check(worker_id). Even though the return value is unused the 
method itself has side effects and I wouldn't necessary call it dead code. Is it 
safe to remove this code?

/Jesper


Thomas Schatzl skrev 25/8/14 17:35:
> Hi all,
>
>    can I have reviews for the following change the removes ~150 LOC of
> dead code from G1's concurrentMark* source files?
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8055919
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8055919/webrev/
> Testing:
> jprt
>
> Thanks,
>    Thomas
>


From thomas.schatzl at oracle.com  Mon Aug 25 16:04:37 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 25 Aug 2014 18:04:37 +0200
Subject: RFR (XS): 8055919: Remove dead code in G1 concurrent marking code
In-Reply-To: <53FB5DB3.7010201@oracle.com>
References: <1408980923.22007.21.camel@cirrus> <53FB5DB3.7010201@oracle.com>
Message-ID: <1408982677.31362.1.camel@cirrus>

Hi,

On Mon, 2014-08-25 at 18:00 +0200, Jesper Wilhelmsson wrote:
> Hi Thomas,
> 
> In CMConcurrentMarkingTask::work() you remove the call to 
> _cm->do_yield_check(worker_id). Even though the return value is unused the 
> method itself has side effects and I wouldn't necessary call it dead code. Is it 
> safe to remove this code?

No, this is certainly not okay. Thanks for finding this. I will fix
that.

Thanks,
  Thomas




From staffan.friberg at oracle.com  Mon Aug 25 16:28:34 2014
From: staffan.friberg at oracle.com (Staffan Friberg)
Date: Mon, 25 Aug 2014 09:28:34 -0700
Subject: RFR: JDK-8055845 - Add trace event for promoted objects
Message-ID: <53FB6432.1010501@oracle.com>

Hi,

Could I please get reviews for this RFE that adds a trace event for 
aging and promotion for young collections in G1, CMS and Parallel GC.
It works similarly to allocation events, and generates the event on the 
slow path when either a direct copy occurs or a new PLAB is request.

Since I'm adding an event I cc:ed the serviceability list in case anyone 
has any comments on the event and changes to trace.xml.

RFE: https://bugs.openjdk.java.net/browse/JDK-8055845
Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00

Bengt has been kind and agreed to both sponsor and host the the webrev.

Thanks,
Staffan



From jon.masamitsu at oracle.com  Mon Aug 25 16:38:02 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 25 Aug 2014 09:38:02 -0700
Subject: RFR (XS): 8055919: Remove dead code in G1 concurrent marking code
In-Reply-To: <1408982677.31362.1.camel@cirrus>
References: <1408980923.22007.21.camel@cirrus> <53FB5DB3.7010201@oracle.com>
	<1408982677.31362.1.camel@cirrus>
Message-ID: <53FB666A.8020408@oracle.com>

Thomas,

Other than as noted in Jesper's comments,
changes look good.  Reviewed.

Jon

On 8/25/2014 9:04 AM, Thomas Schatzl wrote:
> Hi,
>
> On Mon, 2014-08-25 at 18:00 +0200, Jesper Wilhelmsson wrote:
>> Hi Thomas,
>>
>> In CMConcurrentMarkingTask::work() you remove the call to
>> _cm->do_yield_check(worker_id). Even though the return value is unused the
>> method itself has side effects and I wouldn't necessary call it dead code. Is it
>> safe to remove this code?
> No, this is certainly not okay. Thanks for finding this. I will fix
> that.
>
> Thanks,
>    Thomas
>
>



From jon.masamitsu at oracle.com  Mon Aug 25 21:04:27 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 25 Aug 2014 14:04:27 -0700
Subject: RFR (M): 8054819: Rename HeapRegionSeq to HeapRegionManager
In-Reply-To: <1408976603.22007.10.camel@cirrus>
References: <1408976603.22007.10.camel@cirrus>
Message-ID: <53FBA4DB.8010803@oracle.com>

Looked good.

Reviewed.

Jon

On 08/25/2014 07:23 AM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for the following change that renames HeapRegionSeq
> to HeapRegionManager?
>
> The reason is that after recent changes HeapRegionSeq got many new
> responsibilities. It is not a straight sequence of heap regions any more
> at all.
>
> It's a straight rename of the class, moving into new files, and changing
> "hrs"-prefixes to "hrm"-prefix.
>
> Further the same change is done to the SA-agent.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8054819
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8054819/webrev/
> Testing:
> jprt, vm.heapdump (SA-agent tests), vm.gc tests on aurora
>
> Thanks,
>    Thomas
>



From Kannan.Krishnamurthy at contractor.cengage.com  Mon Aug 25 15:11:21 2014
From: Kannan.Krishnamurthy at contractor.cengage.com (Krishnamurthy, Kannan)
Date: Mon, 25 Aug 2014 15:11:21 +0000
Subject: Unexplained long stop the world pauses during concurrent marking
	step in G1 Collector
In-Reply-To: <CE6F8973BA99BB4CAE71AC901973A625538C4C8E@OHCINMAIL03.corp.local>
References: <CE6F8973BA99BB4CAE71AC901973A625538C4C8E@OHCINMAIL03.corp.local>
Message-ID: <CE6F8973BA99BB4CAE71AC901973A625538C593F@OHCINMAIL03.corp.local>

Greetings,

We are experiencing unexplained/unknown long pauses (8 seconds) during concurrent marking step of G1 collector.

    2014-08-07T13:42:30.552-0400: 92183.303: [GC concurrent-root-region-scan-start]
    2014-08-07T13:42:30.555-0400: 92183.305: [GC concurrent-root-region-scan-end, 0.0025230 secs]
    **2014-08-07T13:42:30.555-0400: 92183.305: [GC concurrent-mark-start]**
    **2014-08-07T13:42:39.598-0400: 92192.348: Application time: 9.0448670 seconds**
    2014-08-07T13:42:39.601-0400: 92192.351: Total time for which application threads were stopped: 0.0029740 seconds
    2014-08-07T13:42:39.603-0400: 92192.353: [GC pause (G1 Evacuation Pause) (young) 92192.354: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 7980, predicted base time: 28.19 ms, remaining time: 71.81 ms, target pause time: 100.00 ms


`2014-08-07T13:42:30.555-0400: 92183.305` is when the concurrent mark starts, approximately after 2 seconds of this step the application starts to pause. However the GC logs claims the application was not paused during this window.
Linux "top" shows single CPU at 100% and rest of the CPUs at 0% during the pause.

Any help in understanding the root cause of this issue is appreciated.

Our target JVMS:

    java version "1.7.0_04"
    Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
    Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)

    java version "1.8.0_11"
    Java(TM) SE Runtime Environment (build 1.8.0_11-b12)
    Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode)


Our JVM options :

    -Xms20G -Xmx20G -Xss10M -XX:PermSize=128M -XX:MaxPermSize=128M -XX:MarkStackSize=16M
    -XX:+UnlockDiagnosticVMOptions -XX:+G1PrintRegionLivenessInfo -XX:+TraceGCTaskThread
    -XX:+G1SummarizeConcMark -XX:+G1SummarizeRSetStats -XX:+G1TraceConcRefinement
    -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:InitiatingHeapOccupancyPercent=65
    -XX:ParallelGCThreads=24 -verbose:gc -XX:+PrintGC -XX:+PrintGCDetails
    -XX:+PrintGCDateStamps -XX:+PrintAdaptiveSizePolicy -XX:+PrintTenuringDistribution
    -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime
    -Xloggc:/common/logs/ocean-partition-gc.log


Thanks and regards,
Kannan



From jesper.wilhelmsson at oracle.com  Mon Aug 25 21:40:40 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 25 Aug 2014 23:40:40 +0200
Subject: RFR (M): 8054819: Rename HeapRegionSeq to HeapRegionManager
In-Reply-To: <1408976603.22007.10.camel@cirrus>
References: <1408976603.22007.10.camel@cirrus>
Message-ID: <53FBAD58.3080604@oracle.com>

Ship it!
/Jesper

Thomas Schatzl skrev 25/8/14 16:23:
> Hi all,
>
>    can I have reviews for the following change that renames HeapRegionSeq
> to HeapRegionManager?
>
> The reason is that after recent changes HeapRegionSeq got many new
> responsibilities. It is not a straight sequence of heap regions any more
> at all.
>
> It's a straight rename of the class, moving into new files, and changing
> "hrs"-prefixes to "hrm"-prefix.
>
> Further the same change is done to the SA-agent.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8054819
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8054819/webrev/
> Testing:
> jprt, vm.heapdump (SA-agent tests), vm.gc tests on aurora
>
> Thanks,
>    Thomas
>


From ysr1729 at gmail.com  Tue Aug 26 00:56:25 2014
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Mon, 25 Aug 2014 17:56:25 -0700
Subject: Unexplained long stop the world pauses during concurrent marking
	step in G1 Collector
In-Reply-To: <CE6F8973BA99BB4CAE71AC901973A625538C593F@OHCINMAIL03.corp.local>
References: <CE6F8973BA99BB4CAE71AC901973A625538C4C8E@OHCINMAIL03.corp.local>
	<CE6F8973BA99BB4CAE71AC901973A625538C593F@OHCINMAIL03.corp.local>
Message-ID: <CABzyjykwMBjoK+qxS0sDEfeJvd4=L2ifDyUiWU=vtEpgOQYTzg@mail.gmail.com>

Does this happen at each concurrent marking phase, or only at some?
If you can reproduce the problem under controlled conditions, you might
consider starting by
collecting a few native stack traces (pstack) in quick succession during
the marking phase
(if you react fast enough! -- I'd suggest running pstack in a loop next to
the JVM when heap
occupancy approaches 65%, and you can look at the ones corresponding to the
pause during
the marking phase.)

-- ramki


On Mon, Aug 25, 2014 at 8:11 AM, Krishnamurthy, Kannan <
Kannan.Krishnamurthy at contractor.cengage.com> wrote:

> Greetings,
>
> We are experiencing unexplained/unknown long pauses (8 seconds) during
> concurrent marking step of G1 collector.
>
>     2014-08-07T13:42:30.552-0400: 92183.303: [GC
> concurrent-root-region-scan-start]
>     2014-08-07T13:42:30.555-0400: 92183.305: [GC
> concurrent-root-region-scan-end, 0.0025230 secs]
>     **2014-08-07T13:42:30.555-0400: 92183.305: [GC concurrent-mark-start]**
>     **2014-08-07T13:42:39.598-0400: 92192.348: Application time: 9.0448670
> seconds**
>     2014-08-07T13:42:39.601-0400: 92192.351: Total time for which
> application threads were stopped: 0.0029740 seconds
>     2014-08-07T13:42:39.603-0400: 92192.353: [GC pause (G1 Evacuation
> Pause) (young) 92192.354: [G1Ergonomics (CSet Construction) start choosing
> CSet, _pending_cards: 7980, predicted base time: 28.19 ms, remaining time:
> 71.81 ms, target pause time: 100.00 ms
>
>
> `2014-08-07T13:42:30.555-0400: 92183.305` is when the concurrent mark
> starts, approximately after 2 seconds of this step the application starts
> to pause. However the GC logs claims the application was not paused during
> this window.
> Linux "top" shows single CPU at 100% and rest of the CPUs at 0% during the
> pause.
>
> Any help in understanding the root cause of this issue is appreciated.
>
> Our target JVMS:
>
>     java version "1.7.0_04"
>     Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
>     Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
>
>     java version "1.8.0_11"
>     Java(TM) SE Runtime Environment (build 1.8.0_11-b12)
>     Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode)
>
>
> Our JVM options :
>
>     -Xms20G -Xmx20G -Xss10M -XX:PermSize=128M -XX:MaxPermSize=128M
> -XX:MarkStackSize=16M
>     -XX:+UnlockDiagnosticVMOptions -XX:+G1PrintRegionLivenessInfo
> -XX:+TraceGCTaskThread
>     -XX:+G1SummarizeConcMark -XX:+G1SummarizeRSetStats
> -XX:+G1TraceConcRefinement
>     -XX:+UseG1GC -XX:MaxGCPauseMillis=100
> -XX:InitiatingHeapOccupancyPercent=65
>     -XX:ParallelGCThreads=24 -verbose:gc -XX:+PrintGC -XX:+PrintGCDetails
>     -XX:+PrintGCDateStamps -XX:+PrintAdaptiveSizePolicy
> -XX:+PrintTenuringDistribution
>     -XX:+PrintGCApplicationStoppedTime
> -XX:+PrintGCApplicationConcurrentTime
>     -Xloggc:/common/logs/ocean-partition-gc.log
>
>
> Thanks and regards,
> Kannan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140825/87aa5bc2/attachment.htm>

From thomas.schatzl at oracle.com  Tue Aug 26 07:23:33 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 26 Aug 2014 09:23:33 +0200
Subject: RFR (M): 8054819: Rename HeapRegionSeq to HeapRegionManager
In-Reply-To: <53FBAD58.3080604@oracle.com>
References: <1408976603.22007.10.camel@cirrus> <53FBAD58.3080604@oracle.com>
Message-ID: <1409037813.2670.0.camel@cirrus>

Hi Jesper,

On Mon, 2014-08-25 at 23:40 +0200, Jesper Wilhelmsson wrote:
> Ship it!
> /Jesper
> 

  thanks for the review.

Thomas




From thomas.schatzl at oracle.com  Tue Aug 26 07:35:20 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 26 Aug 2014 09:35:20 +0200
Subject: RFR (XS): 8055919: Remove dead code in G1 concurrent marking code
In-Reply-To: <53FB5DB3.7010201@oracle.com>
References: <1408980923.22007.21.camel@cirrus> <53FB5DB3.7010201@oracle.com>
Message-ID: <1409038520.2670.3.camel@cirrus>

Hi Jesper, Jon,

On Mon, 2014-08-25 at 18:00 +0200, Jesper Wilhelmsson wrote:
> Hi Thomas,
> 
> In CMConcurrentMarkingTask::work() you remove the call to 
> _cm->do_yield_check(worker_id). Even though the return value is unused the 
> method itself has side effects and I wouldn't necessary call it dead code. Is it 
> safe to remove this code?

  here's a diff webrev for the changes:
http://cr.openjdk.java.net/~tschatzl/8055919/webrev.0_to_1/
And the full webrev:
http://cr.openjdk.java.net/~tschatzl/8055919/webrev.1/

I also fixed a few parameter lists in that change. I hope this is not
too much of a bother.

Thanks,
  Thomas




From Leonid.Mesnik at oracle.com  Tue Aug 26 07:59:44 2014
From: Leonid.Mesnik at oracle.com (Leonid Mesnik)
Date: Tue, 26 Aug 2014 11:59:44 +0400
Subject: RFR: 8u40 Backport of 8055098: WB API should be extended to provide
	information about size and age of object.
Message-ID: <53FC3E70.4070100@oracle.com>

Hi

Could I have a review for backport of fix for 8055098. Patch from JDK 9 
applied cleanly to 8u-dev and pass JPRT.
Link to JDK 9 patch:
http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/bf4d2f5595bc
Link to mail:
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-August/010520.html

Unfortunately the JDK9 commit doesn't include unit test from original 
webrev. I've filed JDK-8055953 for this.
Leonid




From Leonid.Mesnik at oracle.com  Tue Aug 26 09:29:18 2014
From: Leonid.Mesnik at oracle.com (Leonid Mesnik)
Date: Tue, 26 Aug 2014 13:29:18 +0400
Subject: RFR: 8055953: [TESTBUG] Fix for 8055098 does not contain unit test
Message-ID: <53FC536E.6090507@oracle.com>

Hi

Could I please have a review for this small fix.
http://cr.openjdk.java.net/~tschatzl/8055953/webrev 
<http://cr.openjdk.java.net/%7Etschatzl/8055953/webrev>

It is a test unit for WB API in 8055098. Test passed with all GC's.

Leonid


From thomas.schatzl at oracle.com  Tue Aug 26 09:29:50 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 26 Aug 2014 11:29:50 +0200
Subject: RFR: 8055953: [TESTBUG] Fix for 8055098 does not contain unit test
In-Reply-To: <53FC536E.6090507@oracle.com>
References: <53FC536E.6090507@oracle.com>
Message-ID: <1409045390.2670.15.camel@cirrus>

Hi,

On Tue, 2014-08-26 at 13:29 +0400, Leonid Mesnik wrote:
> Hi
> 
> Could I please have a review for this small fix.
> http://cr.openjdk.java.net/~tschatzl/8055953/webrev 
> <http://cr.openjdk.java.net/%7Etschatzl/8055953/webrev>
> 
> It is a test unit for WB API in 8055098. Test passed with all GC's.
> 

  fyi, this unit test has been forgotten to be committed for 8055098.

Reviewed.

Thanks,
Thomas



From Leonid.Mesnik at oracle.com  Tue Aug 26 09:33:51 2014
From: Leonid.Mesnik at oracle.com (Leonid Mesnik)
Date: Tue, 26 Aug 2014 13:33:51 +0400
Subject: RFR: 8055953: [TESTBUG] Fix for 8055098 does not contain unit test
In-Reply-To: <1409045390.2670.15.camel@cirrus>
References: <53FC536E.6090507@oracle.com> <1409045390.2670.15.camel@cirrus>
Message-ID: <53FC547F.3020000@oracle.com>

Thank you for review.

Leonid
On 26.08.2014 13:29, Thomas Schatzl wrote:
> Hi,
>
> On Tue, 2014-08-26 at 13:29 +0400, Leonid Mesnik wrote:
>> Hi
>>
>> Could I please have a review for this small fix.
>> http://cr.openjdk.java.net/~tschatzl/8055953/webrev
>> <http://cr.openjdk.java.net/%7Etschatzl/8055953/webrev>
>>
>> It is a test unit for WB API in 8055098. Test passed with all GC's.
>>
>    fyi, this unit test has been forgotten to be committed for 8055098.
>
> Reviewed.
>
> Thanks,
> Thomas
>



From stefan.johansson at oracle.com  Tue Aug 26 09:46:01 2014
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 26 Aug 2014 11:46:01 +0200
Subject: RFR: 8028787: tmtools/jstat/gcoldcapacity/jstat_gcoldcapacity02 fails
	nsk.share.Failure: OGC < OGCMN in RT_Baseline
Message-ID: <53FC5759.5090607@oracle.com>

Hi,

Please review this fix for:
https://bugs.openjdk.java.net/browse/JDK-8028787

Webrev:
http://cr.openjdk.java.net/~sjohanss/8028787/webrev.00

Summary:
When setting up the counters used by jstat for determining the min and 
max size of the generations we currently do not use the collector policy 
to get these values. Instead the underlying space has been used, and 
that do not have any notion of a minimum. Changing to use the collector 
policy will avoid the problems we are seeing where the current capacity 
is smaller than the minimum. This was previously possible if a 
generation was resized to something smaller than the initial size (which 
was setup as minimum for the counter).

Testing:
I did not manage to reproduce the failure with the test in question on 
my machine but I was able to manually construct the same symptoms 
(getting a smaller OGC than OGCMN) using the default collector and with 
this fix they are gone.

Thanks,
StefanJ


From stefan.karlsson at oracle.com  Tue Aug 26 10:05:29 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 26 Aug 2014 12:05:29 +0200
Subject: RFR: 8028787: tmtools/jstat/gcoldcapacity/jstat_gcoldcapacity02
	fails nsk.share.Failure: OGC < OGCMN in RT_Baseline
In-Reply-To: <53FC5759.5090607@oracle.com>
References: <53FC5759.5090607@oracle.com>
Message-ID: <53FC5BE9.60200@oracle.com>

On 26/08/14 11:46, Stefan Johansson wrote:
> Hi,
>
> Please review this fix for:
> https://bugs.openjdk.java.net/browse/JDK-8028787
>
> Webrev:
> http://cr.openjdk.java.net/~sjohanss/8028787/webrev.00

Looks good. Thanks for fixing this!

StefanK

>
> Summary:
> When setting up the counters used by jstat for determining the min and 
> max size of the generations we currently do not use the collector 
> policy to get these values. Instead the underlying space has been 
> used, and that do not have any notion of a minimum. Changing to use 
> the collector policy will avoid the problems we are seeing where the 
> current capacity is smaller than the minimum. This was previously 
> possible if a generation was resized to something smaller than the 
> initial size (which was setup as minimum for the counter).
>
> Testing:
> I did not manage to reproduce the failure with the test in question on 
> my machine but I was able to manually construct the same symptoms 
> (getting a smaller OGC than OGCMN) using the default collector and 
> with this fix they are gone.
>
> Thanks,
> StefanJ



From thomas.schatzl at oracle.com  Tue Aug 26 10:08:26 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 26 Aug 2014 12:08:26 +0200
Subject: RFR (S): JDK-8055816: Remove dead code in g1BlockOffsetTable
In-Reply-To: <53F73F1E.6080302@oracle.com>
References: <53F73F1E.6080302@oracle.com>
Message-ID: <1409047706.2670.20.camel@cirrus>

Hi,

On Fri, 2014-08-22 at 15:01 +0200, Bengt Rutisson wrote:
> Hi all,
> 
> Can I get reviews for this small change to remove dead code from the 
> G1BlockOffsetTable implementation?
> 
> Webrev:
> http://cr.openjdk.java.net/~brutisso/8055816/webrev.00/
> 
> Bug report:
> https://bugs.openjdk.java.net/browse/JDK-8055816
> 

  could you fix the comment for
G1BlockOffsetArrayContigSpace::zero_bottom_entry_raw? It refers to the
removed method zero_bottom_entry.

Otherwise looks good. Thanks.

Thomas




From bengt.rutisson at oracle.com  Tue Aug 26 10:21:09 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 26 Aug 2014 12:21:09 +0200
Subject: RFR (S): JDK-8055816: Remove dead code in g1BlockOffsetTable
In-Reply-To: <1409047706.2670.20.camel@cirrus>
References: <53F73F1E.6080302@oracle.com> <1409047706.2670.20.camel@cirrus>
Message-ID: <53FC5F95.8020302@oracle.com>


Hi Thomas,

Thanks for the review!


On 2014-08-26 12:08, Thomas Schatzl wrote:
> Hi,
>
> On Fri, 2014-08-22 at 15:01 +0200, Bengt Rutisson wrote:
>> Hi all,
>>
>> Can I get reviews for this small change to remove dead code from the
>> G1BlockOffsetTable implementation?
>>
>> Webrev:
>> http://cr.openjdk.java.net/~brutisso/8055816/webrev.00/
>>
>> Bug report:
>> https://bugs.openjdk.java.net/browse/JDK-8055816
>>
>    could you fix the comment for
> G1BlockOffsetArrayContigSpace::zero_bottom_entry_raw? It refers to the
> removed method zero_bottom_entry.

Fixed:

http://cr.openjdk.java.net/~brutisso/8055816/webrev.01/

Diff compared to last version:
http://cr.openjdk.java.net/~brutisso/8055816/webrev.00-01.diff/

> Otherwise looks good. Thanks.

Great! Thanks!

Bengt

>
> Thomas
>
>



From thomas.schatzl at oracle.com  Tue Aug 26 10:27:40 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 26 Aug 2014 12:27:40 +0200
Subject: RFR: 8028787: tmtools/jstat/gcoldcapacity/jstat_gcoldcapacity02
	fails nsk.share.Failure: OGC < OGCMN in RT_Baseline
In-Reply-To: <53FC5759.5090607@oracle.com>
References: <53FC5759.5090607@oracle.com>
Message-ID: <1409048860.2670.28.camel@cirrus>

Hi,

On Tue, 2014-08-26 at 11:46 +0200, Stefan Johansson wrote:
> Hi,
> 
> Please review this fix for:
> https://bugs.openjdk.java.net/browse/JDK-8028787
> 
> Webrev:
> http://cr.openjdk.java.net/~sjohanss/8028787/webrev.00

Looks good.

Thomas




From thomas.schatzl at oracle.com  Tue Aug 26 10:35:34 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 26 Aug 2014 12:35:34 +0200
Subject: RFR (S): JDK-8055816: Remove dead code in g1BlockOffsetTable
In-Reply-To: <53FC5F95.8020302@oracle.com>
References: <53F73F1E.6080302@oracle.com> <1409047706.2670.20.camel@cirrus>
	<53FC5F95.8020302@oracle.com>
Message-ID: <1409049334.2670.29.camel@cirrus>

Hi,

On Tue, 2014-08-26 at 12:21 +0200, Bengt Rutisson wrote:
> Hi Thomas,
> 
> Thanks for the review!
> 
> On 2014-08-26 12:08, Thomas Schatzl wrote:
> > Hi,
> > On Fri, 2014-08-22 at 15:01 +0200, Bengt Rutisson wrote:
> >> Hi all,
> >> Can I get reviews for this small change to remove dead code from the
> >> G1BlockOffsetTable implementation?
> >>
> >> Webrev:
> >> http://cr.openjdk.java.net/~brutisso/8055816/webrev.00/
> >>
> >> Bug report:
> >> https://bugs.openjdk.java.net/browse/JDK-8055816
> >>
> >    could you fix the comment for
> > G1BlockOffsetArrayContigSpace::zero_bottom_entry_raw? It refers to the
> > removed method zero_bottom_entry.
> 
> Fixed:

  looks good.

Thanks,
  Thomas




From jesper.wilhelmsson at oracle.com  Tue Aug 26 10:51:53 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 26 Aug 2014 12:51:53 +0200
Subject: RFR (XS): 8055919: Remove dead code in G1 concurrent marking code
In-Reply-To: <1409038520.2670.3.camel@cirrus>
References: <1408980923.22007.21.camel@cirrus> <53FB5DB3.7010201@oracle.com>
	<1409038520.2670.3.camel@cirrus>
Message-ID: <53FC66C9.2040208@oracle.com>

Looks good!
/Jesper

Thomas Schatzl skrev 26/8/14 09:35:
> Hi Jesper, Jon,
>
> On Mon, 2014-08-25 at 18:00 +0200, Jesper Wilhelmsson wrote:
>> Hi Thomas,
>>
>> In CMConcurrentMarkingTask::work() you remove the call to
>> _cm->do_yield_check(worker_id). Even though the return value is unused the
>> method itself has side effects and I wouldn't necessary call it dead code. Is it
>> safe to remove this code?
>
>    here's a diff webrev for the changes:
> http://cr.openjdk.java.net/~tschatzl/8055919/webrev.0_to_1/
> And the full webrev:
> http://cr.openjdk.java.net/~tschatzl/8055919/webrev.1/
>
> I also fixed a few parameter lists in that change. I hope this is not
> too much of a bother.
>
> Thanks,
>    Thomas
>
>


From thomas.schatzl at oracle.com  Tue Aug 26 11:04:39 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 26 Aug 2014 13:04:39 +0200
Subject: RFR (XS): 8055919: Remove dead code in G1 concurrent marking code
In-Reply-To: <53FC66C9.2040208@oracle.com>
References: <1408980923.22007.21.camel@cirrus> <53FB5DB3.7010201@oracle.com>
	<1409038520.2670.3.camel@cirrus> <53FC66C9.2040208@oracle.com>
Message-ID: <1409051079.2670.37.camel@cirrus>

Hi Jesper,

On Tue, 2014-08-26 at 12:51 +0200, Jesper Wilhelmsson wrote:
> Looks good!
> /Jesper

  thanks for the review.

Thomas




From stefan.johansson at oracle.com  Tue Aug 26 14:14:35 2014
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 26 Aug 2014 16:14:35 +0200
Subject: RFR: 8028787: tmtools/jstat/gcoldcapacity/jstat_gcoldcapacity02
	fails nsk.share.Failure: OGC < OGCMN in RT_Baseline
In-Reply-To: <53FC5BE9.60200@oracle.com>
References: <53FC5759.5090607@oracle.com> <53FC5BE9.60200@oracle.com>
Message-ID: <53FC964B.8080408@oracle.com>

Thanks Thomas and Stefan for reviewing.

Just an update about testing, after some good input from Bengt I managed 
to reproduce with the tmtools-test in question and also verify that the 
fix works as intended with the test.

Thanks,
Stefan

On 2014-08-26 12:05, Stefan Karlsson wrote:
> On 26/08/14 11:46, Stefan Johansson wrote:
>> Hi,
>>
>> Please review this fix for:
>> https://bugs.openjdk.java.net/browse/JDK-8028787
>>
>> Webrev:
>> http://cr.openjdk.java.net/~sjohanss/8028787/webrev.00
>
> Looks good. Thanks for fixing this!
>
> StefanK
>
>>
>> Summary:
>> When setting up the counters used by jstat for determining the min 
>> and max size of the generations we currently do not use the collector 
>> policy to get these values. Instead the underlying space has been 
>> used, and that do not have any notion of a minimum. Changing to use 
>> the collector policy will avoid the problems we are seeing where the 
>> current capacity is smaller than the minimum. This was previously 
>> possible if a generation was resized to something smaller than the 
>> initial size (which was setup as minimum for the counter).
>>
>> Testing:
>> I did not manage to reproduce the failure with the test in question 
>> on my machine but I was able to manually construct the same symptoms 
>> (getting a smaller OGC than OGCMN) using the default collector and 
>> with this fix they are gone.
>>
>> Thanks,
>> StefanJ
>



From thomas.schatzl at oracle.com  Tue Aug 26 14:55:51 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 26 Aug 2014 16:55:51 +0200
Subject: RFR (S): 8056043: G1 does not uncommit within the heap after
	JDK-8038423
Message-ID: <1409064951.2670.70.camel@cirrus>

Hi all,

 can I have reviews for the following change that removes some code that
has accidentally been left in when splitting off refactoring changes
JDK-8054818 from (the original) JDK-8038423?

Basically, to implement JDK-8054818 there has been need to retain the
old commit/uncommit strategy to only allow uncommit at the end of the
heap. One check that guaranteed that has been left in.

This change removes that one. It also reenables a jtreg test that checks
that, which had been disabled until now because of the functionality
lacking.

CR:
https://bugs.openjdk.java.net/browse/JDK-8056043
Webrev:
http://cr.openjdk.java.net/~tschatzl/8056043/webrev/
Testing:
jprt, vm.gc testlist run, gcbasher for an hour, test case

Thanks,
  Thomas



From jesper.wilhelmsson at oracle.com  Tue Aug 26 15:08:05 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 26 Aug 2014 17:08:05 +0200
Subject: RFR (S): 8056043: G1 does not uncommit within the heap after
	JDK-8038423
In-Reply-To: <1409064951.2670.70.camel@cirrus>
References: <1409064951.2670.70.camel@cirrus>
Message-ID: <53FCA2D5.4020206@oracle.com>

Looks good!
/Jesper

Thomas Schatzl skrev 26/8/14 16:55:
> Hi all,
>
>   can I have reviews for the following change that removes some code that
> has accidentally been left in when splitting off refactoring changes
> JDK-8054818 from (the original) JDK-8038423?
>
> Basically, to implement JDK-8054818 there has been need to retain the
> old commit/uncommit strategy to only allow uncommit at the end of the
> heap. One check that guaranteed that has been left in.
>
> This change removes that one. It also reenables a jtreg test that checks
> that, which had been disabled until now because of the functionality
> lacking.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8056043
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8056043/webrev/
> Testing:
> jprt, vm.gc testlist run, gcbasher for an hour, test case
>
> Thanks,
>    Thomas
>


From mikael.gerdin at oracle.com  Tue Aug 26 15:42:21 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 26 Aug 2014 17:42:21 +0200
Subject: RFR 8048268: G1 Code Root Migration performs poorly
Message-ID: <1819337.ruQN7pby6E@mgerdin03>

Hi,

In order to combat the spikes in code root migration times I suggest that we 
reimplement the code cache remembered set using hash tables instead of the 
current chunked array variant.

While we're at it I suggest that we get rid of the entire migration phase and 
update the code cache remembered set during the parallel RSet scanning phase.
The contains()-check when adding during RSet scanning is designed to be lock-
free in order to reduce contention on the HRRS locks.
This led me to remove some contains-checks in asserts since they were done 
during a phase where operations which could not guarantee lock-free reads to 
succeed were performed.

Testing: Kitchensink 14hrs, JPRT, Aurora perf testing of several industry 
benchmarks and CRM Fuse (where it actually makes a difference since we had 
300ms spikes in code root migration times).

The table sizes in G1CodeRootSet are completely unscientific but seem to work 
good enough for now. An even larger table size could possibly be considered 
for pathological cases where we get thousands of nmethods (as can occur in CRM 
Fuse) but currently the two sizes seem good enough.

This change depends on "JDK-8056084: Refactor Hashtable to allow 
implementations without rehashing support" since the remembered sets are 
allocated and deallocated I needed to allow for deallocation of instances of 
HashtableEntry and deallocation of freelist contents.

Webrev: http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev/
Buglink: https://bugs.openjdk.java.net/browse/JDK-8048268

a note about g1RemSetSummary.cpp
the code failed to update _max_code_root_mem_sz, so the code to list the most 
expensive code root remset was broken.

/Mikael


From jon.masamitsu at oracle.com  Tue Aug 26 17:20:49 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 26 Aug 2014 10:20:49 -0700
Subject: RFR (XS): 8055919: Remove dead code in G1 concurrent marking code
In-Reply-To: <1409038520.2670.3.camel@cirrus>
References: <1408980923.22007.21.camel@cirrus> <53FB5DB3.7010201@oracle.com>
	<1409038520.2670.3.camel@cirrus>
Message-ID: <53FCC1F1.9010904@oracle.com>


On 08/26/2014 12:35 AM, Thomas Schatzl wrote:
> Hi Jesper, Jon,
>
> On Mon, 2014-08-25 at 18:00 +0200, Jesper Wilhelmsson wrote:
>> Hi Thomas,
>>
>> In CMConcurrentMarkingTask::work() you remove the call to
>> _cm->do_yield_check(worker_id). Even though the return value is unused the
>> method itself has side effects and I wouldn't necessary call it dead code. Is it
>> safe to remove this code?
>    here's a diff webrev for the changes:
> http://cr.openjdk.java.net/~tschatzl/8055919/webrev.0_to_1/

Still looks good.

> And the full webrev:
> http://cr.openjdk.java.net/~tschatzl/8055919/webrev.1/
>
> I also fixed a few parameter lists in that change. I hope this is not
> too much of a bother.

I like your fix of the formatting on the parameter lists.  Thanks.

Jon

>
> Thanks,
>    Thomas
>
>



From jon.masamitsu at oracle.com  Tue Aug 26 18:25:24 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 26 Aug 2014 11:25:24 -0700
Subject: RFR (S): 8056043: G1 does not uncommit within the heap after
	JDK-8038423
In-Reply-To: <1409064951.2670.70.camel@cirrus>
References: <1409064951.2670.70.camel@cirrus>
Message-ID: <53FCD114.3010801@oracle.com>

Changes look good.

Reviewed.

Jon

On 08/26/2014 07:55 AM, Thomas Schatzl wrote:
> Hi all,
>
>   can I have reviews for the following change that removes some code that
> has accidentally been left in when splitting off refactoring changes
> JDK-8054818 from (the original) JDK-8038423?
>
> Basically, to implement JDK-8054818 there has been need to retain the
> old commit/uncommit strategy to only allow uncommit at the end of the
> heap. One check that guaranteed that has been left in.
>
> This change removes that one. It also reenables a jtreg test that checks
> that, which had been disabled until now because of the functionality
> lacking.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8056043
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8056043/webrev/
> Testing:
> jprt, vm.gc testlist run, gcbasher for an hour, test case
>
> Thanks,
>    Thomas
>



From Kannan.Krishnamurthy at contractor.cengage.com  Tue Aug 26 16:43:15 2014
From: Kannan.Krishnamurthy at contractor.cengage.com (Krishnamurthy, Kannan)
Date: Tue, 26 Aug 2014 16:43:15 +0000
Subject: Unexplained long stop the world pauses during concurrent
	marking step in G1 Collector
In-Reply-To: <CABzyjykwMBjoK+qxS0sDEfeJvd4=L2ifDyUiWU=vtEpgOQYTzg@mail.gmail.com>
References: <CE6F8973BA99BB4CAE71AC901973A625538C4C8E@OHCINMAIL03.corp.local>
	<CE6F8973BA99BB4CAE71AC901973A625538C593F@OHCINMAIL03.corp.local>,
	<CABzyjykwMBjoK+qxS0sDEfeJvd4=L2ifDyUiWU=vtEpgOQYTzg@mail.gmail.com>
Message-ID: <CE6F8973BA99BB4CAE71AC901973A625538C5A89@OHCINMAIL03.corp.local>

Yes this happens at every single concurrent mark step and consistently reproducible. Still trying to get some native stack traces, initial tries with gstack was terminating the JVM. Thank you.
________________________________
From: Srinivas Ramakrishna [ysr1729 at gmail.com]
Sent: Monday, August 25, 2014 8:56 PM
To: Krishnamurthy, Kannan
Cc: hotspot-gc-dev at openjdk.java.net; kndkannan at gmail.com
Subject: Re: Unexplained long stop the world pauses during concurrent marking step in G1 Collector

Does this happen at each concurrent marking phase, or only at some?
If you can reproduce the problem under controlled conditions, you might consider starting by
collecting a few native stack traces (pstack) in quick succession during the marking phase
(if you react fast enough! -- I'd suggest running pstack in a loop next to the JVM when heap
occupancy approaches 65%, and you can look at the ones corresponding to the pause during
the marking phase.)

-- ramki


On Mon, Aug 25, 2014 at 8:11 AM, Krishnamurthy, Kannan <Kannan.Krishnamurthy at contractor.cengage.com<mailto:Kannan.Krishnamurthy at contractor.cengage.com>> wrote:
Greetings,

We are experiencing unexplained/unknown long pauses (8 seconds) during concurrent marking step of G1 collector.

    2014-08-07T13:42:30.552-0400: 92183.303: [GC concurrent-root-region-scan-start]
    2014-08-07T13:42:30.555-0400: 92183.305: [GC concurrent-root-region-scan-end, 0.0025230 secs]
    **2014-08-07T13:42:30.555-0400: 92183.305: [GC concurrent-mark-start]**
    **2014-08-07T13:42:39.598-0400: 92192.348: Application time: 9.0448670 seconds**
    2014-08-07T13:42:39.601-0400: 92192.351: Total time for which application threads were stopped: 0.0029740 seconds
    2014-08-07T13:42:39.603-0400: 92192.353: [GC pause (G1 Evacuation Pause) (young) 92192.354: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 7980, predicted base time: 28.19 ms, remaining time: 71.81 ms, target pause time: 100.00 ms


`2014-08-07T13:42:30.555-0400: 92183.305` is when the concurrent mark starts, approximately after 2 seconds of this step the application starts to pause. However the GC logs claims the application was not paused during this window.
Linux "top" shows single CPU at 100% and rest of the CPUs at 0% during the pause.

Any help in understanding the root cause of this issue is appreciated.

Our target JVMS:

    java version "1.7.0_04"
    Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
    Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)

    java version "1.8.0_11"
    Java(TM) SE Runtime Environment (build 1.8.0_11-b12)
    Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode)


Our JVM options :

    -Xms20G -Xmx20G -Xss10M -XX:PermSize=128M -XX:MaxPermSize=128M -XX:MarkStackSize=16M
    -XX:+UnlockDiagnosticVMOptions -XX:+G1PrintRegionLivenessInfo -XX:+TraceGCTaskThread
    -XX:+G1SummarizeConcMark -XX:+G1SummarizeRSetStats -XX:+G1TraceConcRefinement
    -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:InitiatingHeapOccupancyPercent=65
    -XX:ParallelGCThreads=24 -verbose:gc -XX:+PrintGC -XX:+PrintGCDetails
    -XX:+PrintGCDateStamps -XX:+PrintAdaptiveSizePolicy -XX:+PrintTenuringDistribution
    -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime
    -Xloggc:/common/logs/ocean-partition-gc.log


Thanks and regards,
Kannan


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

From bernd-2014 at eckenfels.net  Wed Aug 27 02:15:20 2014
From: bernd-2014 at eckenfels.net (Bernd Eckenfels)
Date: Wed, 27 Aug 2014 04:15:20 +0200
Subject: Unexplained long stop the world pauses during concurrent
	marking step in G1 Collector
In-Reply-To: <CE6F8973BA99BB4CAE71AC901973A625538C5A89@OHCINMAIL03.corp.local>
References: <CE6F8973BA99BB4CAE71AC901973A625538C4C8E@OHCINMAIL03.corp.local>
	<CE6F8973BA99BB4CAE71AC901973A625538C593F@OHCINMAIL03.corp.local>
	<CABzyjykwMBjoK+qxS0sDEfeJvd4=L2ifDyUiWU=vtEpgOQYTzg@mail.gmail.com>
	<CE6F8973BA99BB4CAE71AC901973A625538C5A89@OHCINMAIL03.corp.local>
Message-ID: <20140827041520.00007fb2.bernd-2014@eckenfels.net>

Hello,

are you using any external JNI libraries? Maybe its a safepoint thing.
Not sure about G1, but generally you might see something with
-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1.

Gruss
Bernd

Am Tue, 26 Aug 2014 16:43:15 +0000
schrieb "Krishnamurthy, Kannan"
<Kannan.Krishnamurthy at contractor.cengage.com>:

> Yes this happens at every single concurrent mark step and
> consistently reproducible. Still trying to get some native stack
> traces, initial tries with gstack was terminating the JVM. Thank you.
> ________________________________ From: Srinivas Ramakrishna
> [ysr1729 at gmail.com] Sent: Monday, August 25, 2014 8:56 PM To:
> Krishnamurthy, Kannan Cc: hotspot-gc-dev at openjdk.java.net;
> kndkannan at gmail.com Subject: Re: Unexplained long stop the world
> pauses during concurrent marking step in G1 Collector
> 
> Does this happen at each concurrent marking phase, or only at some?
> If you can reproduce the problem under controlled conditions, you
> might consider starting by collecting a few native stack traces
> (pstack) in quick succession during the marking phase (if you react
> fast enough! -- I'd suggest running pstack in a loop next to the JVM
> when heap occupancy approaches 65%, and you can look at the ones
> corresponding to the pause during the marking phase.)
> 
> -- ramki
> 
> 
> On Mon, Aug 25, 2014 at 8:11 AM, Krishnamurthy, Kannan
> <Kannan.Krishnamurthy at contractor.cengage.com<mailto:Kannan.Krishnamurthy at contractor.cengage.com>>
> wrote: Greetings,
> 
> We are experiencing unexplained/unknown long pauses (8 seconds)
> during concurrent marking step of G1 collector.
> 
>     2014-08-07T13:42:30.552-0400: 92183.303: [GC
> concurrent-root-region-scan-start] 2014-08-07T13:42:30.555-0400:
> 92183.305: [GC concurrent-root-region-scan-end, 0.0025230 secs]
> **2014-08-07T13:42:30.555-0400: 92183.305: [GC
> concurrent-mark-start]** **2014-08-07T13:42:39.598-0400: 92192.348:
> Application time: 9.0448670 seconds** 2014-08-07T13:42:39.601-0400:
> 92192.351: Total time for which application threads were stopped:
> 0.0029740 seconds 2014-08-07T13:42:39.603-0400: 92192.353: [GC pause
> (G1 Evacuation Pause) (young) 92192.354: [G1Ergonomics (CSet
> Construction) start choosing CSet, _pending_cards: 7980, predicted
> base time: 28.19 ms, remaining time: 71.81 ms, target pause time:
> 100.00 ms
> 
> 
> `2014-08-07T13:42:30.555-0400: 92183.305` is when the concurrent mark
> starts, approximately after 2 seconds of this step the application
> starts to pause. However the GC logs claims the application was not
> paused during this window. Linux "top" shows single CPU at 100% and
> rest of the CPUs at 0% during the pause.
> 
> Any help in understanding the root cause of this issue is appreciated.
> 
> Our target JVMS:
> 
>     java version "1.7.0_04"
>     Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
>     Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
> 
>     java version "1.8.0_11"
>     Java(TM) SE Runtime Environment (build 1.8.0_11-b12)
>     Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode)
> 
> 
> Our JVM options :
> 
>     -Xms20G -Xmx20G -Xss10M -XX:PermSize=128M -XX:MaxPermSize=128M
> -XX:MarkStackSize=16M -XX:+UnlockDiagnosticVMOptions
> -XX:+G1PrintRegionLivenessInfo -XX:+TraceGCTaskThread
> -XX:+G1SummarizeConcMark -XX:+G1SummarizeRSetStats
> -XX:+G1TraceConcRefinement -XX:+UseG1GC -XX:MaxGCPauseMillis=100
> -XX:InitiatingHeapOccupancyPercent=65 -XX:ParallelGCThreads=24
> -verbose:gc -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps
> -XX:+PrintAdaptiveSizePolicy -XX:+PrintTenuringDistribution
> -XX:+PrintGCApplicationStoppedTime
> -XX:+PrintGCApplicationConcurrentTime
> -Xloggc:/common/logs/ocean-partition-gc.log
> 
> 
> Thanks and regards,
> Kannan
> 
> 
> 



From mikael.gerdin at oracle.com  Wed Aug 27 08:51:42 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 27 Aug 2014 10:51:42 +0200
Subject: RFR (S): JDK-8055816: Remove dead code in g1BlockOffsetTable
In-Reply-To: <53FC5F95.8020302@oracle.com>
References: <53F73F1E.6080302@oracle.com> <1409047706.2670.20.camel@cirrus>
	<53FC5F95.8020302@oracle.com>
Message-ID: <9460491.UXfuULMnsS@mgerdin03>

Hi Bengt,

On Tuesday 26 August 2014 12.21.09 Bengt Rutisson wrote:
> Hi Thomas,
> 
> Thanks for the review!
> 
> On 2014-08-26 12:08, Thomas Schatzl wrote:
> > Hi,
> > 
> > On Fri, 2014-08-22 at 15:01 +0200, Bengt Rutisson wrote:
> >> Hi all,
> >> 
> >> Can I get reviews for this small change to remove dead code from the
> >> G1BlockOffsetTable implementation?
> >> 
> >> Webrev:
> >> http://cr.openjdk.java.net/~brutisso/8055816/webrev.00/
> >> 
> >> Bug report:
> >> https://bugs.openjdk.java.net/browse/JDK-8055816
> >> 
> >    could you fix the comment for
> > 
> > G1BlockOffsetArrayContigSpace::zero_bottom_entry_raw? It refers to the
> > removed method zero_bottom_entry.
> 
> Fixed:
> 
> http://cr.openjdk.java.net/~brutisso/8055816/webrev.01/

Looks good. Nice cleanup.

/Mikael

> 
> Diff compared to last version:
> http://cr.openjdk.java.net/~brutisso/8055816/webrev.00-01.diff/
> 
> > Otherwise looks good. Thanks.
> 
> Great! Thanks!
> 
> Bengt
> 
> > Thomas



From bengt.rutisson at oracle.com  Wed Aug 27 08:53:32 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 27 Aug 2014 10:53:32 +0200
Subject: RFR (S): JDK-8055816: Remove dead code in g1BlockOffsetTable
In-Reply-To: <9460491.UXfuULMnsS@mgerdin03>
References: <53F73F1E.6080302@oracle.com> <1409047706.2670.20.camel@cirrus>
	<53FC5F95.8020302@oracle.com> <9460491.UXfuULMnsS@mgerdin03>
Message-ID: <53FD9C8C.9080804@oracle.com>


Thanks Thomas and Mikael for the reviews!

Bengt


On 2014-08-27 10:51, Mikael Gerdin wrote:
> Hi Bengt,
>
> On Tuesday 26 August 2014 12.21.09 Bengt Rutisson wrote:
>> Hi Thomas,
>>
>> Thanks for the review!
>>
>> On 2014-08-26 12:08, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Fri, 2014-08-22 at 15:01 +0200, Bengt Rutisson wrote:
>>>> Hi all,
>>>>
>>>> Can I get reviews for this small change to remove dead code from the
>>>> G1BlockOffsetTable implementation?
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~brutisso/8055816/webrev.00/
>>>>
>>>> Bug report:
>>>> https://bugs.openjdk.java.net/browse/JDK-8055816
>>>>
>>>     could you fix the comment for
>>>
>>> G1BlockOffsetArrayContigSpace::zero_bottom_entry_raw? It refers to the
>>> removed method zero_bottom_entry.
>> Fixed:
>>
>> http://cr.openjdk.java.net/~brutisso/8055816/webrev.01/
> Looks good. Nice cleanup.
>
> /Mikael
>
>> Diff compared to last version:
>> http://cr.openjdk.java.net/~brutisso/8055816/webrev.00-01.diff/
>>
>>> Otherwise looks good. Thanks.
>> Great! Thanks!
>>
>> Bengt
>>
>>> Thomas



From dmitry.fazunenko at oracle.com  Wed Aug 27 11:08:03 2014
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko)
Date: Wed, 27 Aug 2014 15:08:03 +0400
Subject: RFR: JDK-8055845 - Add trace event for promoted objects
In-Reply-To: <53FB6432.1010501@oracle.com>
References: <53FB6432.1010501@oracle.com>
Message-ID: <53FDBC13.9030209@oracle.com>

Hi Staffan,

Thanks for submitting RFE and implementing it! This event seems to be 
used widely.
So it's very important to design it correctly.
May I ask you to provide some extra information:
- format of event
   (this could be included in the CR description)
- regression tests for that event will be also required
- please include hotspot-dev on CC

Thanks,
Dima

On 25.08.2014 20:28, Staffan Friberg wrote:
> Hi,
>
> Could I please get reviews for this RFE that adds a trace event for 
> aging and promotion for young collections in G1, CMS and Parallel GC.
> It works similarly to allocation events, and generates the event on 
> the slow path when either a direct copy occurs or a new PLAB is request.
>
> Since I'm adding an event I cc:ed the serviceability list in case 
> anyone has any comments on the event and changes to trace.xml.
>
> RFE: https://bugs.openjdk.java.net/browse/JDK-8055845
> Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00
>
> Bengt has been kind and agreed to both sponsor and host the the webrev.
>
> Thanks,
> Staffan
>



From mikael.gerdin at oracle.com  Wed Aug 27 11:39:34 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 27 Aug 2014 13:39:34 +0200
Subject: RFR: 8055702 - Remove the generations array
In-Reply-To: <53F7438F.9030507@oracle.com>
References: <53F7438F.9030507@oracle.com>
Message-ID: <3280315.lOXy9KeohI@mgerdin03>

Hi Jesper,

On Friday 22 August 2014 15.20.15 Jesper Wilhelmsson wrote:
> Hi,
> 
> This is the first part of the generation array removal. Here I remove the
> _gens array and introduce _young_gen and _old_gen instead. The main change
> is in GenCollectedHeap::do_collection() which used a loop to iterate
> through the generation array. I extracted the contents of that loop into a
> new method and call it with a reference to the generation to be collected.
> 
> Webrev: http://cr.openjdk.java.net/~jwilhelm/8055702/webrev/

There are still some strange bits and pieces in the code but overall I think 
this is a nice cleanup.

Reviewed.

/Mikael

> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8055702
> 
> 
> More cleanups in this area are coming. Among other things I will remove from
> GenCollectedHeap: _n_gen, SomeConstants, get_gen(), next_gen(), prev_gen(),
> n_gens() and the concept of levels that is passed around all over the
> place. These will be replaced with a more explicit use of young and old as
> appropriate.
> 
> All that is actually already done, it just needs to be split into more
> reviewable changes. Stay tuned.
> 
> Thanks,
> /Jesper



From thomas.schatzl at oracle.com  Wed Aug 27 13:24:08 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 27 Aug 2014 15:24:08 +0200
Subject: RFR (XS): 8054808: Bitmap verification sometimes fails after Full
	GC aborts concurrent mark
Message-ID: <1409145848.2765.22.camel@cirrus>

Hi all,

  can I have reviews for the following fix that fixes next bitmap
verification after a full gc aborted concurrent mark?

The original code to verify whether a region's next bitmap contained a
mark or not was racy: in CheckBitmapClearHRClosure::doHeapRegion the
result whether the bitmap had marks was:

    return _bitmap->getNextMarkedWordAddress(r->bottom(), r->end()) !=
r->end();

The problem is that concurrent humongous object allocation changes
HeapRegion::_end, and if that occurs between the initial evaluation for
the method call and the comparison, the checking will fail.

CR:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8054808
Webrev:
http://cr.openjdk.java.net/~tschatzl/8054808/webrev/
Testing:
Inspecting generated code, test case in the CR, jprt

Thanks,
  Thomas




From jon.masamitsu at oracle.com  Wed Aug 27 15:00:04 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 27 Aug 2014 08:00:04 -0700
Subject: RFR (XS): 8054808: Bitmap verification sometimes fails after
	Full GC aborts concurrent mark
In-Reply-To: <1409145848.2765.22.camel@cirrus>
References: <1409145848.2765.22.camel@cirrus>
Message-ID: <53FDF274.7090002@oracle.com>

Thomas,

Would it work to snapshot the value for end()

end =r-> end()

and use that instead of calculating "end" from
r->bottom()?

Jon

On 8/27/2014 6:24 AM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for the following fix that fixes next bitmap
> verification after a full gc aborted concurrent mark?
>
> The original code to verify whether a region's next bitmap contained a
> mark or not was racy: in CheckBitmapClearHRClosure::doHeapRegion the
> result whether the bitmap had marks was:
>
>      return _bitmap->getNextMarkedWordAddress(r->bottom(), r->end()) !=
> r->end();
>
> The problem is that concurrent humongous object allocation changes
> HeapRegion::_end, and if that occurs between the initial evaluation for
> the method call and the comparison, the checking will fail.
>
> CR:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8054808
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8054808/webrev/
> Testing:
> Inspecting generated code, test case in the CR, jprt
>
> Thanks,
>    Thomas
>
>



From dmitry.fazunenko at oracle.com  Wed Aug 27 15:23:11 2014
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko)
Date: Wed, 27 Aug 2014 19:23:11 +0400
Subject: RFR: (S) 8050464: G1 string deduplication tests hang/timeout
	and leave running processes consuming all resources
In-Reply-To: <53E3C37D.6010406@oracle.com>
References: <53737D83.2050205@oracle.com> <53E24F6F.5000704@oracle.com>
	<53E2885B.6040609@oracle.com> <53E34E67.5060809@oracle.com>
	<53E3C37D.6010406@oracle.com>
Message-ID: <53FDF7DF.7030109@oracle.com>

Jon,

My patch fixes the original problem: tests will fail instead, not hang up.
Printing extra debug info is a different story, and should require a 
separate RFE.
To print char[] addresses WhiteBoxAPI needs to be used, without it only 
following data could be printed out:

String   'DeduplicationTestString:7:XXXXXXXXXXXXXXXXXXXXXXXX' has not 
deduplicated
     char1[]: [C at 7ea987ac
     char2[]: [C at 12a3a380

but I think this is valueless.

May be we can fix
http://cr.openjdk.java.net/~dfazunen/8050464/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8050464

and file an RFE of further improvement?

Thanks,
Dima


On 07.08.2014 22:20, Jon Masamitsu wrote:
>
> On 08/07/2014 03:01 AM, Dmitry Fazunenko wrote:
>> Jon,
>>
>> Thanks for looking!
>> I love printing as much debug info as possible. But in this case I 
>> have nothing to add.
>> BTW, the deduplication tests are full of various 
>> System.out.prinltn(), so I think the it will be enough information in 
>> case of failure.
>>
>> I modified a little the code to make test fail. The jtr is attached. 
>> Please let me know if you believe that more data need to be printed.
>
> Yes, lots of output on failures.  I looked for some output that told
> me the addresses of the two strings (the two that don't verify)
> and the addresses of their char arrays.  I couldn't find it.
> I think if I were debugging a failure, that's the first thing I would
> want to see.
>
> Jon
>
>>
>> Thanks,
>> Dima
>>
>> On 06.08.2014 23:56, Jon Masamitsu wrote:
>>> Dima,
>>>
>>> If the test fails, can you print the strings with 
>>> System.out.println() or
>>> System.err.println()?  Any information about the strings might be
>>> useful to understand why deduplication didn't work or why the
>>> test thinks the deduplication didn't work (in case something
>>> happens that the test doesn't expect)?
>>>
>>> Jon
>>>
>>> On 8/6/2014 8:53 AM, Dmitry Fazunenko wrote:
>>>> Hi,
>>>>
>>>> Would you please look at the simple fix of String Deduplication tests.
>>>>
>>>> Description:
>>>>
>>>> When string deduplication has happened /s1.equals(s2)/ will be 
>>>> equivalent to /s1 == s2/
>>>> Deduplication is performed in a separate thread so it could be 
>>>> delayed a bit.
>>>> Tests are away about possible delay and give another chance if 
>>>> deduplication hasn't
>>>> happened by the moment of check.
>>>> But tests wait for deduplication in infinitive loop, so if 
>>>> deduplication doesn't work the tests
>>>> will timeout, leaving hanging VM after. Which is not very elegant.
>>>>
>>>> The fix is simple: replace infinitive loops with limited ones and 
>>>> report failure.
>>>> The logic of the tests hasn't changed.
>>>>
>>>> http://cr.openjdk.java.net/~dfazunen/8050464/webrev.01/
>>>> https://bugs.openjdk.java.net/browse/JDK-8050464
>>>>
>>>> Any comments are welcome.
>>>>
>>>> Thanks,
>>>> Dima
>>>>
>>>>
>>>>
>>>
>>
>

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

From thomas.schatzl at oracle.com  Wed Aug 27 15:35:34 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 27 Aug 2014 17:35:34 +0200
Subject: RFR (XS): 8054808: Bitmap verification sometimes fails after
	Full GC aborts concurrent mark
In-Reply-To: <53FDF274.7090002@oracle.com>
References: <1409145848.2765.22.camel@cirrus> <53FDF274.7090002@oracle.com>
Message-ID: <1409153734.2765.61.camel@cirrus>

Hi,

On Wed, 2014-08-27 at 08:00 -0700, Jon Masamitsu wrote:
> Thomas,
> 
> Would it work to snapshot the value for end()
> 
> end =r-> end()
> 
> and use that instead of calculating "end" from
> r->bottom()?

  not necessarily. As r->_end is not volatile the compiler is free to
replace any local variable with a re-read of it, resulting in the same
code and problem as before.

You would need something like "HeapWord* end = (HeapWord*
volatile)r->end();" to make sure that this replacement not done by the
compiler.

The proposed solution seemed simplest to me, since it avoids thinking
about what the contents of r->_end could be for the different types of
region.

E.g. the _end of humongous continues regions == _bottom iirc, so there
might be cases when we miss checking the bitmap. For example, due to
timing the code reads r->end() == r->bottom() + HeapRegion::GrainWords
for a region that has just been changed from Humongous Starts to normal,
but still gets the r->end() == r->bottom() for humongous continues
regions.

Above might not be possible for various reasons (I remember code at
least for creating humongous regions that makes sure that the various
_end values are written in a particular order), but to verify that I
would have to look in other places.

The current solution avoids requiring me to reason about this
completely.

Thanks,
  Thomas




From jon.masamitsu at oracle.com  Wed Aug 27 15:55:04 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 27 Aug 2014 08:55:04 -0700
Subject: RFR (XS): 8054808: Bitmap verification sometimes fails after
	Full GC aborts concurrent mark
In-Reply-To: <1409153734.2765.61.camel@cirrus>
References: <1409145848.2765.22.camel@cirrus> <53FDF274.7090002@oracle.com>
	<1409153734.2765.61.camel@cirrus>
Message-ID: <53FDFF58.90108@oracle.com>


On 8/27/2014 8:35 AM, Thomas Schatzl wrote:
> Hi,
>
> On Wed, 2014-08-27 at 08:00 -0700, Jon Masamitsu wrote:
>> Thomas,
>>
>> Would it work to snapshot the value for end()
>>
>> end =r-> end()
>>
>> and use that instead of calculating "end" from
>> r->bottom()?
>    not necessarily. As r->_end is not volatile the compiler is free to
> replace any local variable with a re-read of it, resulting in the same
> code and problem as before.
>
> You would need something like "HeapWord* end = (HeapWord*
> volatile)r->end();" to make sure that this replacement not done by the
> compiler.
>
> The proposed solution seemed simplest to me, since it avoids thinking
> about what the contents of r->_end could be for the different types of
> region.
>
> E.g. the _end of humongous continues regions == _bottom iirc, so there
> might be cases when we miss checking the bitmap. For example, due to
> timing the code reads r->end() == r->bottom() + HeapRegion::GrainWords
> for a region that has just been changed from Humongous Starts to normal,
> but still gets the r->end() == r->bottom() for humongous continues
> regions.
>
> Above might not be possible for various reasons (I remember code at
> least for creating humongous regions that makes sure that the various
> _end values are written in a particular order), but to verify that I
> would have to look in other places.
>
> The current solution avoids requiring me to reason about this
> completely.

Thanks.  I understand better now.
Change looks good.

Reviewed.

Jon

>
> Thanks,
>    Thomas
>
>



From jon.masamitsu at oracle.com  Wed Aug 27 16:06:07 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 27 Aug 2014 09:06:07 -0700
Subject: RFR: (S) 8050464: G1 string deduplication tests hang/timeout
	and leave running processes consuming all resources
In-Reply-To: <53FDF7DF.7030109@oracle.com>
References: <53737D83.2050205@oracle.com> <53E24F6F.5000704@oracle.com>
	<53E2885B.6040609@oracle.com> <53E34E67.5060809@oracle.com>
	<53E3C37D.6010406@oracle.com> <53FDF7DF.7030109@oracle.com>
Message-ID: <53FE01EF.1010903@oracle.com>


On 8/27/2014 8:23 AM, Dmitry Fazunenko wrote:
> Jon,
>
> My patch fixes the original problem: tests will fail instead, not hang up.
> Printing extra debug info is a different story, and should require a 
> separate RFE.

Agreed.

> To print char[] addresses WhiteBoxAPI needs to be used, without it 
> only following data could be printed out:
>
> String   'DeduplicationTestString:7:XXXXXXXXXXXXXXXXXXXXXXXX' has not 
> deduplicated
>     char1[]: [C at 7ea987ac
>     char2[]: [C at 12a3a380
>
> but I think this is valueless.

I think there is some value is seeing that the two char arrays
are different.   Maybe not enough though.  Your call on this.

>
> May be we can fix
> http://cr.openjdk.java.net/~dfazunen/8050464/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8050464

Changes look good.  If we see failures of the test, we can
look at why it failed and maybe come up with some additional
output.

Reviewed.

Jon



>
> and file an RFE of further improvement?
>
> Thanks,
> Dima
>
>
> On 07.08.2014 22:20, Jon Masamitsu wrote:
>>
>> On 08/07/2014 03:01 AM, Dmitry Fazunenko wrote:
>>> Jon,
>>>
>>> Thanks for looking!
>>> I love printing as much debug info as possible. But in this case I 
>>> have nothing to add.
>>> BTW, the deduplication tests are full of various 
>>> System.out.prinltn(), so I think the it will be enough information 
>>> in case of failure.
>>>
>>> I modified a little the code to make test fail. The jtr is attached. 
>>> Please let me know if you believe that more data need to be printed.
>>
>> Yes, lots of output on failures.  I looked for some output that told
>> me the addresses of the two strings (the two that don't verify)
>> and the addresses of their char arrays.  I couldn't find it.
>> I think if I were debugging a failure, that's the first thing I would
>> want to see.
>>
>> Jon
>>
>>>
>>> Thanks,
>>> Dima
>>>
>>> On 06.08.2014 23:56, Jon Masamitsu wrote:
>>>> Dima,
>>>>
>>>> If the test fails, can you print the strings with 
>>>> System.out.println() or
>>>> System.err.println()?  Any information about the strings might be
>>>> useful to understand why deduplication didn't work or why the
>>>> test thinks the deduplication didn't work (in case something
>>>> happens that the test doesn't expect)?
>>>>
>>>> Jon
>>>>
>>>> On 8/6/2014 8:53 AM, Dmitry Fazunenko wrote:
>>>>> Hi,
>>>>>
>>>>> Would you please look at the simple fix of String Deduplication 
>>>>> tests.
>>>>>
>>>>> Description:
>>>>>
>>>>> When string deduplication has happened /s1.equals(s2)/ will be 
>>>>> equivalent to /s1 == s2/
>>>>> Deduplication is performed in a separate thread so it could be 
>>>>> delayed a bit.
>>>>> Tests are away about possible delay and give another chance if 
>>>>> deduplication hasn't
>>>>> happened by the moment of check.
>>>>> But tests wait for deduplication in infinitive loop, so if 
>>>>> deduplication doesn't work the tests
>>>>> will timeout, leaving hanging VM after. Which is not very elegant.
>>>>>
>>>>> The fix is simple: replace infinitive loops with limited ones and 
>>>>> report failure.
>>>>> The logic of the tests hasn't changed.
>>>>>
>>>>> http://cr.openjdk.java.net/~dfazunen/8050464/webrev.01/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8050464
>>>>>
>>>>> Any comments are welcome.
>>>>>
>>>>> Thanks,
>>>>> Dima
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

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

From dmitry.fazunenko at oracle.com  Wed Aug 27 16:48:58 2014
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko)
Date: Wed, 27 Aug 2014 20:48:58 +0400
Subject: RFR: (S) 8050464: G1 string deduplication tests hang/timeout
	and leave running processes consuming all resources
In-Reply-To: <53FE01EF.1010903@oracle.com>
References: <53737D83.2050205@oracle.com> <53E24F6F.5000704@oracle.com>
	<53E2885B.6040609@oracle.com> <53E34E67.5060809@oracle.com>
	<53E3C37D.6010406@oracle.com> <53FDF7DF.7030109@oracle.com>
	<53FE01EF.1010903@oracle.com>
Message-ID: <53FE0BFA.8050901@oracle.com>

Thanks for review, Jon!
-- Dima

On 27.08.2014 20:06, Jon Masamitsu wrote:
>
> On 8/27/2014 8:23 AM, Dmitry Fazunenko wrote:
>> Jon,
>>
>> My patch fixes the original problem: tests will fail instead, not 
>> hang up.
>> Printing extra debug info is a different story, and should require a 
>> separate RFE.
>
> Agreed.
>
>> To print char[] addresses WhiteBoxAPI needs to be used, without it 
>> only following data could be printed out:
>>
>> String   'DeduplicationTestString:7:XXXXXXXXXXXXXXXXXXXXXXXX' has not 
>> deduplicated
>>     char1[]: [C at 7ea987ac
>>     char2[]: [C at 12a3a380
>>
>> but I think this is valueless.
>
> I think there is some value is seeing that the two char arrays
> are different.   Maybe not enough though.  Your call on this.
>
>>
>> May be we can fix
>> http://cr.openjdk.java.net/~dfazunen/8050464/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8050464
>
> Changes look good.  If we see failures of the test, we can
> look at why it failed and maybe come up with some additional
> output.
>
> Reviewed.
>
> Jon
>
>
>
>>
>> and file an RFE of further improvement?
>>
>> Thanks,
>> Dima
>>
>>
>> On 07.08.2014 22:20, Jon Masamitsu wrote:
>>>
>>> On 08/07/2014 03:01 AM, Dmitry Fazunenko wrote:
>>>> Jon,
>>>>
>>>> Thanks for looking!
>>>> I love printing as much debug info as possible. But in this case I 
>>>> have nothing to add.
>>>> BTW, the deduplication tests are full of various 
>>>> System.out.prinltn(), so I think the it will be enough information 
>>>> in case of failure.
>>>>
>>>> I modified a little the code to make test fail. The jtr is 
>>>> attached. Please let me know if you believe that more data need to 
>>>> be printed.
>>>
>>> Yes, lots of output on failures.  I looked for some output that told
>>> me the addresses of the two strings (the two that don't verify)
>>> and the addresses of their char arrays.  I couldn't find it.
>>> I think if I were debugging a failure, that's the first thing I would
>>> want to see.
>>>
>>> Jon
>>>
>>>>
>>>> Thanks,
>>>> Dima
>>>>
>>>> On 06.08.2014 23:56, Jon Masamitsu wrote:
>>>>> Dima,
>>>>>
>>>>> If the test fails, can you print the strings with 
>>>>> System.out.println() or
>>>>> System.err.println()?  Any information about the strings might be
>>>>> useful to understand why deduplication didn't work or why the
>>>>> test thinks the deduplication didn't work (in case something
>>>>> happens that the test doesn't expect)?
>>>>>
>>>>> Jon
>>>>>
>>>>> On 8/6/2014 8:53 AM, Dmitry Fazunenko wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Would you please look at the simple fix of String Deduplication 
>>>>>> tests.
>>>>>>
>>>>>> Description:
>>>>>>
>>>>>> When string deduplication has happened /s1.equals(s2)/ will be 
>>>>>> equivalent to /s1 == s2/
>>>>>> Deduplication is performed in a separate thread so it could be 
>>>>>> delayed a bit.
>>>>>> Tests are away about possible delay and give another chance if 
>>>>>> deduplication hasn't
>>>>>> happened by the moment of check.
>>>>>> But tests wait for deduplication in infinitive loop, so if 
>>>>>> deduplication doesn't work the tests
>>>>>> will timeout, leaving hanging VM after. Which is not very elegant.
>>>>>>
>>>>>> The fix is simple: replace infinitive loops with limited ones and 
>>>>>> report failure.
>>>>>> The logic of the tests hasn't changed.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dfazunen/8050464/webrev.01/
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8050464
>>>>>>
>>>>>> Any comments are welcome.
>>>>>>
>>>>>> Thanks,
>>>>>> Dima
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From staffan.friberg at oracle.com  Wed Aug 27 16:52:26 2014
From: staffan.friberg at oracle.com (Staffan Friberg)
Date: Wed, 27 Aug 2014 09:52:26 -0700
Subject: RFR: JDK-8055845 - Add trace event for promoted objects
In-Reply-To: <53FDBC13.9030209@oracle.com>
References: <53FB6432.1010501@oracle.com> <53FDBC13.9030209@oracle.com>
Message-ID: <53FE0CCA.6000208@oracle.com>

HI Dima,

The event is specified in trace.xml as all other events, please see the 
updated webrev as some changes was made to the descriptions.
http://cr.openjdk.java.net/~brutisso/8055845/webrev.01

I'm in the process of writing regression tests, but they will be a 
separate webrev as they will be located in a separate repository.

Regards,
Staffan

On 08/27/2014 04:08 AM, Dmitry Fazunenko wrote:
> Hi Staffan,
>
> Thanks for submitting RFE and implementing it! This event seems to be 
> used widely.
> So it's very important to design it correctly.
> May I ask you to provide some extra information:
> - format of event
>   (this could be included in the CR description)
> - regression tests for that event will be also required
> - please include hotspot-dev on CC
>
> Thanks,
> Dima
>
> On 25.08.2014 20:28, Staffan Friberg wrote:
>> Hi,
>>
>> Could I please get reviews for this RFE that adds a trace event for 
>> aging and promotion for young collections in G1, CMS and Parallel GC.
>> It works similarly to allocation events, and generates the event on 
>> the slow path when either a direct copy occurs or a new PLAB is request.
>>
>> Since I'm adding an event I cc:ed the serviceability list in case 
>> anyone has any comments on the event and changes to trace.xml.
>>
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8055845
>> Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00
>>
>> Bengt has been kind and agreed to both sponsor and host the the webrev.
>>
>> Thanks,
>> Staffan
>>
>



From dmitry.fazunenko at oracle.com  Wed Aug 27 16:59:59 2014
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko)
Date: Wed, 27 Aug 2014 20:59:59 +0400
Subject: RFR: JDK-8055845 - Add trace event for promoted objects
In-Reply-To: <53FE0CCA.6000208@oracle.com>
References: <53FB6432.1010501@oracle.com> <53FDBC13.9030209@oracle.com>
	<53FE0CCA.6000208@oracle.com>
Message-ID: <53FE0E8F.30501@oracle.com>

Staffan,

Yes, I saw trace.xml. But I think this event not specified there, but 
implemented )
I will appreciate if you copy it in the message, people might review 
that and decide if the event contain all the necessary fields.

And thank you for working on tests!

-- Dima


On 27.08.2014 20:52, Staffan Friberg wrote:
> HI Dima,
>
> The event is specified in trace.xml as all other events, please see 
> the updated webrev as some changes was made to the descriptions.
> http://cr.openjdk.java.net/~brutisso/8055845/webrev.01
>
> I'm in the process of writing regression tests, but they will be a 
> separate webrev as they will be located in a separate repository.
>
> Regards,
> Staffan
>
> On 08/27/2014 04:08 AM, Dmitry Fazunenko wrote:
>> Hi Staffan,
>>
>> Thanks for submitting RFE and implementing it! This event seems to be 
>> used widely.
>> So it's very important to design it correctly.
>> May I ask you to provide some extra information:
>> - format of event
>>   (this could be included in the CR description)
>> - regression tests for that event will be also required
>> - please include hotspot-dev on CC
>>
>> Thanks,
>> Dima
>>
>> On 25.08.2014 20:28, Staffan Friberg wrote:
>>> Hi,
>>>
>>> Could I please get reviews for this RFE that adds a trace event for 
>>> aging and promotion for young collections in G1, CMS and Parallel GC.
>>> It works similarly to allocation events, and generates the event on 
>>> the slow path when either a direct copy occurs or a new PLAB is 
>>> request.
>>>
>>> Since I'm adding an event I cc:ed the serviceability list in case 
>>> anyone has any comments on the event and changes to trace.xml.
>>>
>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8055845
>>> Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00
>>>
>>> Bengt has been kind and agreed to both sponsor and host the the webrev.
>>>
>>> Thanks,
>>> Staffan
>>>
>>
>



From tprintezis at twitter.com  Thu Aug 28 02:06:08 2014
From: tprintezis at twitter.com (Tony Printezis)
Date: Wed, 27 Aug 2014 22:06:08 -0400
Subject: Fix for JDK-8048556 (GCLocker issues): feedback and some testing
	please?
Message-ID: <53FE8E90.7090508@twitter.com>

Hi all,

I have a fix for the GCLocker causing unnecessary young GCs issue 
(JDK-8048556). Here's the webrev:

http://cr.openjdk.java.net/~tonyp/8048556/webrev.0/

Any chance of a) getting some feedback on whether the fix is reasonable 
and b) getting it through some testing (I did as much testing as I could 
but you know how fragile the GCLocker is...)?

I didn't really want to change the CollectedHeap API. However, I can't 
work out another way to pass the two GC counts to the VM op without 
changes to the CollectedHeap. I could have expanded the collect() method 
to also accept the count arguments. However, I don't think collect() 
should really be used for the GCLocker GC and I feel that a separate 
method is appropriate here.

I also ended up renaming an argument to a c'tor from _cause to cause, as 
the former should only be used for class members. Hope that's OK.

Thanks,

Tony

-- 
Tony Printezis | JVM/GC Engineer / VM Team | Twitter

@TonyPrintezis
tprintezis at twitter.com



From bengt.rutisson at oracle.com  Thu Aug 28 08:02:29 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 28 Aug 2014 10:02:29 +0200
Subject: RFR (XS): 8054808: Bitmap verification sometimes fails after
	Full GC aborts concurrent mark
In-Reply-To: <1409145848.2765.22.camel@cirrus>
References: <1409145848.2765.22.camel@cirrus>
Message-ID: <53FEE215.5080308@oracle.com>


Hi Thomas,

(Had an offline discussion with Thomas about this. Replying here for the 
record.)

The proposed fix works fine but there is a slightly simpler solution. 
For all HeapRegions we store the original end value in a variable that 
does not change. We could use that for this fix instead of having to 
calculate the end value.

Something like:

HeapWord* end = r->orig_end();
return _bitmap->getNextMarkedWordAddress(r->bottom(), end) != end;

Thanks,
Bengt


On 2014-08-27 15:24, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for the following fix that fixes next bitmap
> verification after a full gc aborted concurrent mark?
>
> The original code to verify whether a region's next bitmap contained a
> mark or not was racy: in CheckBitmapClearHRClosure::doHeapRegion the
> result whether the bitmap had marks was:
>
>      return _bitmap->getNextMarkedWordAddress(r->bottom(), r->end()) !=
> r->end();
>
> The problem is that concurrent humongous object allocation changes
> HeapRegion::_end, and if that occurs between the initial evaluation for
> the method call and the comparison, the checking will fail.
>
> CR:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8054808
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8054808/webrev/
> Testing:
> Inspecting generated code, test case in the CR, jprt
>
> Thanks,
>    Thomas
>
>



From thomas.schatzl at oracle.com  Thu Aug 28 08:34:09 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 28 Aug 2014 10:34:09 +0200
Subject: RFR (XS): 8054808: Bitmap verification sometimes fails after
	Full GC aborts concurrent mark
In-Reply-To: <53FEE215.5080308@oracle.com>
References: <1409145848.2765.22.camel@cirrus> <53FEE215.5080308@oracle.com>
Message-ID: <1409214849.2658.14.camel@cirrus>

Hi Bengt and Jon,

  thanks for the reviews :)

On Thu, 2014-08-28 at 10:02 +0200, Bengt Rutisson wrote:
> Hi Thomas,
> 
> (Had an offline discussion with Thomas about this. Replying here for the 
> record.)
> 
> The proposed fix works fine but there is a slightly simpler solution. 
> For all HeapRegions we store the original end value in a variable that 
> does not change. We could use that for this fix instead of having to 
> calculate the end value.
> 
> Something like:
> 
> HeapWord* end = r->orig_end();
> return _bitmap->getNextMarkedWordAddress(r->bottom(), end) != end;
> 

New webrev implementing this at
http://cr.openjdk.java.net/~tschatzl/8054808/webrev.1/

Thanks,
  Thomas




From bengt.rutisson at oracle.com  Thu Aug 28 08:32:08 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 28 Aug 2014 10:32:08 +0200
Subject: RFR (XS): 8054808: Bitmap verification sometimes fails after
	Full GC aborts concurrent mark
In-Reply-To: <1409214849.2658.14.camel@cirrus>
References: <1409145848.2765.22.camel@cirrus> <53FEE215.5080308@oracle.com>
	<1409214849.2658.14.camel@cirrus>
Message-ID: <53FEE908.60708@oracle.com>


Hi Thomas,

Looks good. Thanks for fixing this.

Bengt



On 2014-08-28 10:34, Thomas Schatzl wrote:
> Hi Bengt and Jon,
>
>    thanks for the reviews :)
>
> On Thu, 2014-08-28 at 10:02 +0200, Bengt Rutisson wrote:
>> Hi Thomas,
>>
>> (Had an offline discussion with Thomas about this. Replying here for the
>> record.)
>>
>> The proposed fix works fine but there is a slightly simpler solution.
>> For all HeapRegions we store the original end value in a variable that
>> does not change. We could use that for this fix instead of having to
>> calculate the end value.
>>
>> Something like:
>>
>> HeapWord* end = r->orig_end();
>> return _bitmap->getNextMarkedWordAddress(r->bottom(), end) != end;
>>
> New webrev implementing this at
> http://cr.openjdk.java.net/~tschatzl/8054808/webrev.1/
>
> Thanks,
>    Thomas
>
>



From thomas.schatzl at oracle.com  Thu Aug 28 09:45:30 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 28 Aug 2014 11:45:30 +0200
Subject: RFR (3*XS): Backports to 8u40 of 8054819, 8055919, 8056043
Message-ID: <1409219130.2658.35.camel@cirrus>

Hi all,

  can I have a few reviews for these backports that have a few minor
merge errors?

8054819: Rename HeapRegionSeq to HeapRegionManager:

There were some merge failures due to whitespace differences:

- at HeapRegionManager::HeapRegionManager()
- in heapRegionRemSet.cpp line 497:

if (G1TraceHeapRegionRememberedSet) {
  gclog_or_tty->print_cr("   [tid %d] sparse table entry "
                "overflow(f: %d, t: %d)",  (*)
                tid, from_hrs_ind, cur_hrs_ind);
}

(*) the second %d has already been fixed in 9 but not in 8u

Original webrev:
http://cr.openjdk.java.net/~tschatzl/8054819/webrev/
New webrev:
http://cr.openjdk.java.net/~tschatzl/8054819/webrev.8u40/

8055919: Remove dead code in G1 concurrent marking code

Merge failures due to typos not fixed in 8uX:

concurrentMark.hpp:

line 946: 8u has "reponsibility", 9 has "responsibility"
line 950: 8u has "unconditinally", 9 has "unconditionally"

concurrentMark.inline.hpp

line 108: 8u has "incremement", 9 has "increment"
line 225: 8u has "unconditinally", 9 has "unconditionally"

Original webrev:
http://cr.openjdk.java.net/~tschatzl/8055919/webrev.1/
New webrev:
http://cr.openjdk.java.net/~tschatzl/8055919/webrev.8u40

8037925: CMM Testing: an allocated humongous object at the end of the
heap should not prevents shrinking the heap

had to backport this one too, no failures though.

8056043: G1 does not uncommit within the heap after JDK-8038423

There are merge errors in the test case
test/gc/g1/TestHumongousShrinkHeap.java that has been re-enabled in this
CR. The 8u test case does not have the @ignore line.
This has been added in another CR (8044132: Quarantine unstable/broken
GC tests), but that one has dependencies on many other unrelated CRs, so
I did not try to backport it.

Original webrev:
http://cr.openjdk.java.net/~tschatzl/8056043/webrev/
New webrev:
http://cr.openjdk.java.net/~tschatzl/8056043/webrev.8u40/

Please review these differences.

Thanks,
  Thomas




From marcus.larsson at oracle.com  Thu Aug 28 11:06:55 2014
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Thu, 28 Aug 2014 13:06:55 +0200
Subject: RFR (S): 8049341: Parallelize clearing the next mark bitmap
Message-ID: <53FF0D4F.3040505@oracle.com>

Hi,

I would like reviews for the following patch to parallelize the clearing 
of the next mark bitmap in G1.

Short summary:
The heap is divided into as many parts as there are workers and each 
worker will clear its corresponding part of the bitmap. Workers will 
join the suspendible thread set instead of the concurrent mark thread to 
properly allow them to yield during clearing work. Added support for 
applying heap region closures to a specific part of the heap. 
SPECjbb2013 shows a slight performance gain with this change (4%, using 
4 concurrent threads).

Webrev:
http://cr.openjdk.java.net/~brutisso/webrev-8049341/

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

Testing:
jprt, SPECjbb2013, SPECjbb2005, SPECjvm2008

Thanks,
Marcus


From marcus.larsson at oracle.com  Thu Aug 28 11:46:56 2014
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Thu, 28 Aug 2014 13:46:56 +0200
Subject: RFR (S): 8043243: convert SCAN_AND_FORWARD, SCAN_AND_ADJUST_POINTERS, 
	SCAN_AND_COMPACT macros to methods
Message-ID: <53FF16B0.4090809@oracle.com>

Hi,

I would like reviews for the following patch converting the SCAN_AND_* 
macros into (inline) methods.

Short summary:
The change is based on the demacroify.patch (bug attachment), using a 
proxy class to enable different functions for obj_size and similar to be 
used for different types of Spaces. Each type of space has a proxy 
defining which methods should be used in the scan_and_* functions.
Made no changes to the actual code in the macros, except for replacing a 
multi-line debug_only(...) with #ifdef ASSERT ... #endif.

Webrev:
http://cr.openjdk.java.net/~brutisso/webrev-8043243/

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

Testing:
jprt without problems
SPECjbb2013, SPECjbb2005, SPECjvm2008 - no significant changes

Thanks,
Marcus


From stefan.karlsson at oracle.com  Thu Aug 28 12:14:07 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 28 Aug 2014 14:14:07 +0200
Subject: RFR (S): 8043243: convert SCAN_AND_FORWARD,
	SCAN_AND_ADJUST_POINTERS, SCAN_AND_COMPACT macros to methods
In-Reply-To: <53FF16B0.4090809@oracle.com>
References: <53FF16B0.4090809@oracle.com>
Message-ID: <53FF1D0F.8030906@oracle.com>

Hi Marcus,

On 28/08/14 13:46, Marcus Larsson wrote:
> Hi,
>
> I would like reviews for the following patch converting the SCAN_AND_* 
> macros into (inline) methods.
>
> Short summary:
> The change is based on the demacroify.patch (bug attachment), using a 
> proxy class to enable different functions for obj_size and similar to 
> be used for different types of Spaces. Each type of space has a proxy 
> defining which methods should be used in the scan_and_* functions.
> Made no changes to the actual code in the macros, except for replacing 
> a multi-line debug_only(...) with #ifdef ASSERT ... #endif.

Some background to this change. I wrote it as PoC to see if we could get 
rid of these large macros. At that time there werw concerns raised that 
some compilers might not be able to inline the template functions. I 
checked the code generated by gcc and it was inlined as expected, but I 
didn't check the code from the other compilers.

Are the list of benchmarks below performance runs? Was it done on 
different platforms? Did you measure the changed phases 
(prepare_for_compation, adjust_pointers, etc.) or did you measure the 
benchmark score?

>
> Webrev:
> http://cr.openjdk.java.net/~brutisso/webrev-8043243/

Looking at the patch now, I wonder if we shouldn't get rid of the 
instance variables in the *SpaceProxy classes and instead pass down 
'this' from the call sites? And make these classes AllStatic.

thanks,
StefanK

>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8043243
>
> Testing:
> jprt without problems
> SPECjbb2013, SPECjbb2005, SPECjvm2008 - no significant changes
>
> Thanks,
> Marcus



From mikael.gerdin at oracle.com  Thu Aug 28 12:21:31 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 28 Aug 2014 14:21:31 +0200
Subject: RFR (S): 8043243: convert SCAN_AND_FORWARD,
	SCAN_AND_ADJUST_POINTERS, SCAN_AND_COMPACT macros to methods
In-Reply-To: <53FF16B0.4090809@oracle.com>
References: <53FF16B0.4090809@oracle.com>
Message-ID: <53FF1ECB.7050200@oracle.com>

Hi Marcus,

On 08/28/2014 01:46 PM, Marcus Larsson wrote:
> Hi,
>
> I would like reviews for the following patch converting the SCAN_AND_*
> macros into (inline) methods.
>
> Short summary:
> The change is based on the demacroify.patch (bug attachment), using a
> proxy class to enable different functions for obj_size and similar to be
> used for different types of Spaces. Each type of space has a proxy
> defining which methods should be used in the scan_and_* functions.
> Made no changes to the actual code in the macros, except for replacing a
> multi-line debug_only(...) with #ifdef ASSERT ... #endif.
>
> Webrev:
> http://cr.openjdk.java.net/~brutisso/webrev-8043243/

It looks like you replaced all the C-style /* */ comments in 
SCAN_AND_FORWARD but not in the other variants. Please change all of 
them or leave them in the old style.

In the places where you call block_is_obj and block_size for known 
subclasses of Space, should we consider doing direct calls to the known 
implementations to avoid the cost of the virtual call?
Something like
_cfls->CompactibleFreeListSpace::block_is_obj(addr)
and so on.
It's just an idea, though.

I agree with Stefan's comments about looking at GC times on the 
benchmarks and not only the scores. If the benchmarks don't do that many 
full gcs a regression in full gc times may not affect the score 
significantly.

/Mikael

>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8043243
>
> Testing:
> jprt without problems
> SPECjbb2013, SPECjbb2005, SPECjvm2008 - no significant changes
>
> Thanks,
> Marcus



From jesper.wilhelmsson at oracle.com  Thu Aug 28 13:02:11 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 28 Aug 2014 15:02:11 +0200
Subject: RFR (3*XS): Backports to 8u40 of 8054819, 8055919, 8056043
In-Reply-To: <1409219130.2658.35.camel@cirrus>
References: <1409219130.2658.35.camel@cirrus>
Message-ID: <53FF2853.6080708@oracle.com>

Looks good!
/Jesper

Thomas Schatzl skrev 28/8/14 11:45:
> Hi all,
>
>    can I have a few reviews for these backports that have a few minor
> merge errors?
>
> 8054819: Rename HeapRegionSeq to HeapRegionManager:
>
> There were some merge failures due to whitespace differences:
>
> - at HeapRegionManager::HeapRegionManager()
> - in heapRegionRemSet.cpp line 497:
>
> if (G1TraceHeapRegionRememberedSet) {
>    gclog_or_tty->print_cr("   [tid %d] sparse table entry "
>                  "overflow(f: %d, t: %d)",  (*)
>                  tid, from_hrs_ind, cur_hrs_ind);
> }
>
> (*) the second %d has already been fixed in 9 but not in 8u
>
> Original webrev:
> http://cr.openjdk.java.net/~tschatzl/8054819/webrev/
> New webrev:
> http://cr.openjdk.java.net/~tschatzl/8054819/webrev.8u40/
>
> 8055919: Remove dead code in G1 concurrent marking code
>
> Merge failures due to typos not fixed in 8uX:
>
> concurrentMark.hpp:
>
> line 946: 8u has "reponsibility", 9 has "responsibility"
> line 950: 8u has "unconditinally", 9 has "unconditionally"
>
> concurrentMark.inline.hpp
>
> line 108: 8u has "incremement", 9 has "increment"
> line 225: 8u has "unconditinally", 9 has "unconditionally"
>
> Original webrev:
> http://cr.openjdk.java.net/~tschatzl/8055919/webrev.1/
> New webrev:
> http://cr.openjdk.java.net/~tschatzl/8055919/webrev.8u40
>
> 8037925: CMM Testing: an allocated humongous object at the end of the
> heap should not prevents shrinking the heap
>
> had to backport this one too, no failures though.
>
> 8056043: G1 does not uncommit within the heap after JDK-8038423
>
> There are merge errors in the test case
> test/gc/g1/TestHumongousShrinkHeap.java that has been re-enabled in this
> CR. The 8u test case does not have the @ignore line.
> This has been added in another CR (8044132: Quarantine unstable/broken
> GC tests), but that one has dependencies on many other unrelated CRs, so
> I did not try to backport it.
>
> Original webrev:
> http://cr.openjdk.java.net/~tschatzl/8056043/webrev/
> New webrev:
> http://cr.openjdk.java.net/~tschatzl/8056043/webrev.8u40/
>
> Please review these differences.
>
> Thanks,
>    Thomas
>
>


From jon.masamitsu at oracle.com  Thu Aug 28 14:55:19 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 28 Aug 2014 07:55:19 -0700
Subject: RFR (XS): 8054808: Bitmap verification sometimes fails after
	Full GC aborts concurrent mark
In-Reply-To: <1409214849.2658.14.camel@cirrus>
References: <1409145848.2765.22.camel@cirrus> <53FEE215.5080308@oracle.com>
	<1409214849.2658.14.camel@cirrus>
Message-ID: <53FF42D7.6000004@oracle.com>


On 08/28/2014 01:34 AM, Thomas Schatzl wrote:
> Hi Bengt and Jon,
>
>    thanks for the reviews :)
>
> On Thu, 2014-08-28 at 10:02 +0200, Bengt Rutisson wrote:
>> Hi Thomas,
>>
>> (Had an offline discussion with Thomas about this. Replying here for the
>> record.)
>>
>> The proposed fix works fine but there is a slightly simpler solution.
>> For all HeapRegions we store the original end value in a variable that
>> does not change. We could use that for this fix instead of having to
>> calculate the end value.
>>
>> Something like:
>>
>> HeapWord* end = r->orig_end();
>> return _bitmap->getNextMarkedWordAddress(r->bottom(), end) != end;
>>
> New webrev implementing this at
> http://cr.openjdk.java.net/~tschatzl/8054808/webrev.1/

Looks even better.  Reviewed.

Jon

>
> Thanks,
>    Thomas
>
>



From thomas.schatzl at oracle.com  Thu Aug 28 15:04:49 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 28 Aug 2014 17:04:49 +0200
Subject: RFR (XS): 8054808: Bitmap verification sometimes fails after
	Full GC aborts concurrent mark
In-Reply-To: <53FF42D7.6000004@oracle.com>
References: <1409145848.2765.22.camel@cirrus> <53FEE215.5080308@oracle.com>
	<1409214849.2658.14.camel@cirrus> <53FF42D7.6000004@oracle.com>
Message-ID: <1409238289.2658.41.camel@cirrus>

Hi Bengt, Jon,

On Thu, 2014-08-28 at 07:55 -0700, Jon Masamitsu wrote:
> On 08/28/2014 01:34 AM, Thomas Schatzl wrote:
> > Hi Bengt and Jon,
> >
> >    thanks for the reviews :)

  thanks again for the reviews.

Thomas




From jon.masamitsu at oracle.com  Thu Aug 28 21:04:09 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 28 Aug 2014 14:04:09 -0700
Subject: RFR 8048268: G1 Code Root Migration performs poorly
In-Reply-To: <1819337.ruQN7pby6E@mgerdin03>
References: <1819337.ruQN7pby6E@mgerdin03>
Message-ID: <53FF9949.4050604@oracle.com>

Mikael,

In

http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev/src/share/vm/gc_implementation/g1/g1EvacFailure.hpp.frames.html

that there was not a call to rebuild_strong_code_roots() was a bug?

Jon


On 08/26/2014 08:42 AM, Mikael Gerdin wrote:
> Hi,
>
> In order to combat the spikes in code root migration times I suggest that we
> reimplement the code cache remembered set using hash tables instead of the
> current chunked array variant.
>
> While we're at it I suggest that we get rid of the entire migration phase and
> update the code cache remembered set during the parallel RSet scanning phase.
> The contains()-check when adding during RSet scanning is designed to be lock-
> free in order to reduce contention on the HRRS locks.
> This led me to remove some contains-checks in asserts since they were done
> during a phase where operations which could not guarantee lock-free reads to
> succeed were performed.
>
> Testing: Kitchensink 14hrs, JPRT, Aurora perf testing of several industry
> benchmarks and CRM Fuse (where it actually makes a difference since we had
> 300ms spikes in code root migration times).
>
> The table sizes in G1CodeRootSet are completely unscientific but seem to work
> good enough for now. An even larger table size could possibly be considered
> for pathological cases where we get thousands of nmethods (as can occur in CRM
> Fuse) but currently the two sizes seem good enough.
>
> This change depends on "JDK-8056084: Refactor Hashtable to allow
> implementations without rehashing support" since the remembered sets are
> allocated and deallocated I needed to allow for deallocation of instances of
> HashtableEntry and deallocation of freelist contents.
>
> Webrev: http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev/
> Buglink: https://bugs.openjdk.java.net/browse/JDK-8048268
>
> a note about g1RemSetSummary.cpp
> the code failed to update _max_code_root_mem_sz, so the code to list the most
> expensive code root remset was broken.
>
> /Mikael



From erik.helin at oracle.com  Fri Aug 29 06:34:39 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Fri, 29 Aug 2014 08:34:39 +0200
Subject: RFR: JDK-8055845 - Add trace event for promoted objects
In-Reply-To: <53FF9C00.5040306@oracle.com>
References: <53FB6432.1010501@oracle.com>	<53FB6A86.1080908@oracle.com>	<53FB7338.9030208@oracle.com>	<53FC4A57.3030100@oracle.com>
	<53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com>
	<53FF9C00.5040306@oracle.com>
Message-ID: <54001EFF.3030802@oracle.com>

(it seems like we lost hotspot-gc-dev at openjdk.java.net somewhere in this 
thread, I'm adding it back)

On 2014-08-28 23:15, Staffan Friberg wrote:
> Hi Erik,
>
> Thanks for the comments.
>> - Aren't the events for promotion to the tenured generation (SerialOld)
>>   and the CMS generation missing?
> The reason for leaving out these two, Serial completely and CMS
> promotion, was due to that neither as far as I understand make use of
> PLABs.

I might be wrong here, but looking at the function 
TenuredGeneration::par_promote (in tenuredGeneration.cpp) it looks to me 
like SerialOld is using PLABs when ParNew is promoting objects from 
young to old.

As for CMS, looking at ConcurrentMarkSweepGeneration::par_promote (in 
concurrentMarkSweepGeneration.cpp) it seems like each 
CMSParGCThreadState has a CFLS_LAB (CompactibleFreeListSpace Local 
Allocation Buffer) that is a thread-local allocation buffer. See 
compactibleFreeListSpace.{hpp,cpp} for more details.

Given this, I think we should add events for Serial and CMS as well.

On 2014-08-28 23:15, Staffan Friberg wrote:
> So without a good sampling type of event it would end up being an
> event for each aging and/or promotion that happened in the GC. As this
> would be a very large number of events so I decided not to support those
> cases due to performance concerns. If you have a good idea on how to
> support it please let me know. I would see CMS as the priority of the
> two, client workloads can usually be analyzed with a different collector
> which might not be the case for a latency sensitive application.
>
>> - We try to keep the trace dependency (the header file) in
>>   gcTraceSend.cpp, see the pattern for all the other events in
>>   gcTrace.cpp (they all have a "report" and a "send" function).
> Will update it to follow that pattern.

Thanks!

On 2014-08-28 23:15, Staffan Friberg wrote:
>> - Would it make sense to differentiate, either by separate events or by
>>   a field in a event, between promotions to to-space and to the old
>>   generation?
>> - The are two events for TLAB allocations,
>>   java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB.
>>   What do you think about using two events for PLAB allocations as well:
>>   - java/object_alloc_in_new_PLAB
>>   - java/object_alloc_outside_PLAB
> I think this is a matter of taste and probably how similar we want the
> event to be to the existing allocation event. I personally prefer a
> single event but if the GC team and serviceability team feel it would be
> better to have two I can certainly rewrite. The reason for me preferring
> a single event is just ease of analysis, you can easily filter a list of
> events on a field, it is harder to merge two different events with
> different fields and work with them in an straight forward fashion.
>
> Any general preference for having a single or multiple events?

I would prefer to have two events in this case and try to follow the 
existing allocation events as much as possible (both in naming and in 
style). Keeping the tenured field (I missed it the first time I read the 
patch) is good.

On 2014-08-28 23:15, Staffan Friberg wrote:
>> - In PSPromotionManager, instead of utilizing the C++ friendship with
>>   PSScavenge, should we add a getter function for the gc_tracer?
> Created a getter function.

Thanks! If you make report_promotion_sample const, then the getter can 
return a const ParallelScavengeTracer*, right?

Thanks,
Erik

> Will upload a new webrev shortly.
>
> //Staffan
>
> On 08/28/2014 02:27 AM, Erik Helin wrote:
>> Hi Staffan,
>>
>> thanks for the patch, looks like a useful event!
>>
>> A few initial comments:
>> - Aren't the events for promotion to the tenured generation (SerialOld)
>>   and the CMS generation missing?
>> - We try to keep the trace dependency (the header file) in
>>   gcTraceSend.cpp, see the pattern for all the other events in
>>   gcTrace.cpp (they all have a "report" and a "send" function).
>> - Would it make sense to differentiate, either by separate events or by
>>   a field in a event, between promotions to to-space and to the old
>>   generation?
>> - The are two events for TLAB allocations,
>>   java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB.
>>   What do you think about using two events for PLAB allocations as well:
>>   - java/object_alloc_in_new_PLAB
>>   - java/object_alloc_outside_PLAB
>> - In PSPromotionManager, instead of utilizing the C++ friendship with
>>   PSScavenge, should we add a getter function for the gc_tracer?
>>
>> Thanks,
>> Erik
>>
>> On 2014-08-27 16:28, Bengt Rutisson wrote:
>>>
>>>
>>> Hi Staffan,
>>>
>>> Overall I think this change looks fine. I know that Erik Helin has some
>>> thoughts on the naming of the events. I'll let him communicate those
>>> thoughts.
>>>
>>> Apart from Erik's comments and the missing test case (that I know you
>>> are working on) I think the change looks good.
>>>
>>> Thanks,
>>> Bengt
>>>
>>> On 8/26/14 10:50 AM, Bengt Rutisson wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Staffan sent me an updated webrev based on Erik's comments. I uploaded
>>>> it here:
>>>> http://cr.openjdk.java.net/~brutisso/8055845/webrev.01/
>>>>
>>>> Thanks,
>>>> Bengt
>>>>
>>>>
>>>> On 2014-08-25 19:32, Staffan Friberg wrote:
>>>>> Hi Erik,
>>>>>
>>>>> No issue with naming the field class, since the event is similar to
>>>>> the Allocation event I used that as a starting point and it also uses
>>>>> class as name together with a couple of other events.
>>>>>
>>>>> Will go through the descriptions and remove periods.
>>>>>
>>>>> Object age is basically the how many times an object has been kept in
>>>>> survivor region, it is incremented each time a YC happens and the
>>>>> object is aged.
>>>>> Will see how I can update the description to make it clearer. Calling
>>>>> the field tenuringAge might help?
>>>>>
>>>>>> From the documentation,
>>>>>> http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
>>>>>>
>>>>>> -XX:MaxTenuringThreshold=/threshold/
>>>>>>
>>>>>>     Sets the maximum tenuring threshold for use in adaptive GC
>>>>>>     sizing. The largest value is 15. The default value is 15 for the
>>>>>>     parallel (throughput) collector, and 6 for the CMS collector.
>>>>>>
>>>>>>     The following example shows how to set the maximum tenuring
>>>>>>     threshold to 10:
>>>>>>
>>>>>>     -XX:MaxTenuringThreshold=10
>>>>>>
>>>>>>
>>>>>> -XX:+PrintTenuringDistribution
>>>>>>
>>>>>>     Enables printing of tenuring age information. The following is
>>>>>>     an example of the output:
>>>>>>
>>>>>>     Desired survivor size 48286924 bytes, new threshold 10 (max 10)
>>>>>>     - age 1: 28992024 bytes, 28992024 total
>>>>>>     - age 2: 1366864 bytes, 30358888 total
>>>>>>     - age 3: 1425912 bytes, 31784800 total
>>>>>>     ...
>>>>>>
>>>>>>     Age 1 objects are the youngest survivors (they were created
>>>>>>     after the previous scavenge, survived the latest scavenge, and
>>>>>>     moved from eden to survivor space). Age 2 objects have survived
>>>>>>     two scavenges (during the second scavenge they were copied from
>>>>>>     one survivor space to the next). And so on.
>>>>>>
>>>>>>     In the preceding example, 28 992 024 bytes survived one scavenge
>>>>>>     and were copied from eden to survivor space, 1 366 864 bytes are
>>>>>>     occupied by age 2 objects, etc. The third value in each row is
>>>>>>     the cumulative size of objects of age n or less.
>>>>>>
>>>>>>     By default, this option is disabled.
>>>>>>
>>>>>
>>>>> Thanks for the comments,
>>>>> Staffan
>>>>>
>>>>> On 08/25/2014 09:55 AM, Erik Gahlin wrote:
>>>>>> Did you manage to call the field "class"? It's a reserved word in
>>>>>> C++, so we had to use "klass" in the past
>>>>>>
>>>>>> Descriptions with only one sentence shouldn't end with "."
>>>>>>
>>>>>> How is "Object Age" measured?
>>>>>>
>>>>>> As a user, I would expect the number to be in seconds/minutes/hours,
>>>>>> but that is not the case. Perhaps an explanation in the description
>>>>>> and/or a field name that better reflects what we really mean with
>>>>>> age.
>>>>>>
>>>>>> Otherwise trace.xml looks good!
>>>>>>
>>>>>> Erik
>>>>>>
>>>>>> Staffan Friberg skrev 25/08/14 18:28:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Could I please get reviews for this RFE that adds a trace event for
>>>>>>> aging and promotion for young collections in G1, CMS and Parallel
>>>>>>> GC.
>>>>>>> It works similarly to allocation events, and generates the event on
>>>>>>> the slow path when either a direct copy occurs or a new PLAB is
>>>>>>> request.
>>>>>>>
>>>>>>> Since I'm adding an event I cc:ed the serviceability list in case
>>>>>>> anyone has any comments on the event and changes to trace.xml.
>>>>>>>
>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8055845
>>>>>>> Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00
>>>>>>>
>>>>>>> Bengt has been kind and agreed to both sponsor and host the the
>>>>>>> webrev.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Staffan
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>


From mikael.gerdin at oracle.com  Fri Aug 29 08:05:27 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 29 Aug 2014 10:05:27 +0200
Subject: RFR 8048268: G1 Code Root Migration performs poorly
In-Reply-To: <53FF9949.4050604@oracle.com>
References: <1819337.ruQN7pby6E@mgerdin03> <53FF9949.4050604@oracle.com>
Message-ID: <54003447.60504@oracle.com>

Jon,

On 2014-08-28 23:04, Jon Masamitsu wrote:
> Mikael,
>
> In
>
> http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev/src/share/vm/gc_implementation/g1/g1EvacFailure.hpp.frames.html
>
>
> that there was not a call to rebuild_strong_code_roots() was a bug?

No, this was previously handled by 
HeapRegionRemSet::migrate_strong_code_roots where all nmethods were 
popped and then re-added from the to_be_retained GrowableArray.

Since I got rid of the entire migration phase I had to find a new home 
for the code to clean out the code roots for regions which failed to 
evacuate completely.

/Mikael

>
> Jon
>
>
> On 08/26/2014 08:42 AM, Mikael Gerdin wrote:
>> Hi,
>>
>> In order to combat the spikes in code root migration times I suggest
>> that we
>> reimplement the code cache remembered set using hash tables instead of
>> the
>> current chunked array variant.
>>
>> While we're at it I suggest that we get rid of the entire migration
>> phase and
>> update the code cache remembered set during the parallel RSet scanning
>> phase.
>> The contains()-check when adding during RSet scanning is designed to
>> be lock-
>> free in order to reduce contention on the HRRS locks.
>> This led me to remove some contains-checks in asserts since they were
>> done
>> during a phase where operations which could not guarantee lock-free
>> reads to
>> succeed were performed.
>>
>> Testing: Kitchensink 14hrs, JPRT, Aurora perf testing of several industry
>> benchmarks and CRM Fuse (where it actually makes a difference since we
>> had
>> 300ms spikes in code root migration times).
>>
>> The table sizes in G1CodeRootSet are completely unscientific but seem
>> to work
>> good enough for now. An even larger table size could possibly be
>> considered
>> for pathological cases where we get thousands of nmethods (as can
>> occur in CRM
>> Fuse) but currently the two sizes seem good enough.
>>
>> This change depends on "JDK-8056084: Refactor Hashtable to allow
>> implementations without rehashing support" since the remembered sets are
>> allocated and deallocated I needed to allow for deallocation of
>> instances of
>> HashtableEntry and deallocation of freelist contents.
>>
>> Webrev: http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev/
>> Buglink: https://bugs.openjdk.java.net/browse/JDK-8048268
>>
>> a note about g1RemSetSummary.cpp
>> the code failed to update _max_code_root_mem_sz, so the code to list
>> the most
>> expensive code root remset was broken.
>>
>> /Mikael
>


From mikael.gerdin at oracle.com  Fri Aug 29 11:04:18 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 29 Aug 2014 13:04:18 +0200
Subject: RFR (S): 8049341: Parallelize clearing the next mark bitmap
In-Reply-To: <53FF0D4F.3040505@oracle.com>
References: <53FF0D4F.3040505@oracle.com>
Message-ID: <54005E32.8040201@oracle.com>

Hi Marcus,

On 2014-08-28 13:06, Marcus Larsson wrote:
> Hi,
>
> I would like reviews for the following patch to parallelize the clearing
> of the next mark bitmap in G1.
>
> Short summary:
> The heap is divided into as many parts as there are workers and each
> worker will clear its corresponding part of the bitmap. Workers will
> join the suspendible thread set instead of the concurrent mark thread to
> properly allow them to yield during clearing work. Added support for
> applying heap region closures to a specific part of the heap.
> SPECjbb2013 shows a slight performance gain with this change (4%, using
> 4 concurrent threads).
>
> Webrev:
> http://cr.openjdk.java.net/~brutisso/webrev-8049341/

In g1Collectedheap.cpp
2624 void
2625 G1CollectedHeap::heap_region_par_iterate_chunked(HeapRegionClosure* cl,
2626                                                  uint worker_id,
2627                                                  uint num_workers,
2628                                                  jint claim_value) 
const {
2629   _hrs.par_iterate(cl, worker_id, num_workers, claim_value);
2630 }
2631
2632 void
2633 G1CollectedHeap::heap_region_iterate_range(HeapRegionClosure* cl, 
uint start, uint end) const {
2634   _hrs.iterate_range(cl, start, end);
2635 }

Can you change heap_region_par_iterate_chunked to have the return type 
on the same line as the name instead of making heap_region_iterate_range 
copy its style? All surrounding methods follow that convention.

Otherwise I think the change looks good.

/Mikael


>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8049341
>
> Testing:
> jprt, SPECjbb2013, SPECjbb2005, SPECjvm2008
>
> Thanks,
> Marcus


From thomas.schatzl at oracle.com  Fri Aug 29 12:07:17 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 29 Aug 2014 14:07:17 +0200
Subject: RFR (S): 8049341: Parallelize clearing the next mark bitmap
In-Reply-To: <53FF0D4F.3040505@oracle.com>
References: <53FF0D4F.3040505@oracle.com>
Message-ID: <1409314037.2663.34.camel@cirrus>

Hi Marcus,

On Thu, 2014-08-28 at 13:06 +0200, Marcus Larsson wrote:
> Hi,
> 
> I would like reviews for the following patch to parallelize the clearing 
> of the next mark bitmap in G1.
> 
> Short summary:
> The heap is divided into as many parts as there are workers and each 
> worker will clear its corresponding part of the bitmap. Workers will 
> join the suspendible thread set instead of the concurrent mark thread to 
> properly allow them to yield during clearing work. Added support for 
> applying heap region closures to a specific part of the heap. 
> SPECjbb2013 shows a slight performance gain with this change (4%, using 
> 4 concurrent threads).
> 
> Webrev:
> http://cr.openjdk.java.net/~brutisso/webrev-8049341/
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8049341
> 

  could you update your changeset? It references files that have been
moved days ago ;) (heapRegionSeq*)

Thanks,
  Thomas




From thomas.viessmann at oracle.com  Fri Aug 29 12:15:18 2014
From: thomas.viessmann at oracle.com (Thomas Viessmann)
Date: Fri, 29 Aug 2014 14:15:18 +0200
Subject: Bug in G1 logging? incorrect stop times?
Message-ID: <54006ED6.7050006@oracle.com>

Hi all,


I suspect a bug in G1 logging. Before I file a (possibly incorrect) bug 
I would like to ask here.
Is my understanding correct that the stw evacuation phase starts at 
*48448.931* and ends at *48454**.034* ?
This would mean a stop time of 5.103 s, which is clearly a mismatch to 
the reported *9.3426141* s
If the stw phase in fact started at a later time e.g. at *48449.288 
*then the stop pause would have been even shorter.

In addition I do not understand how all the relatively short evacuation 
phases sum up to several seconds.
If I add all the MAX values *69.1 + 22.2 + 45+ 150.8 + 0.1 + 155.1 + 0.9 
+ 0.5**= 443.7**ms*




48443.380: Total time for which application threads were stopped: 
0.0084701 seconds
*48448.931*: [GC pause (mixed) 48448.931: [G1Ergonomics (CSet 
Construction) start choosing CSet, _pending_cards: 89458, predicted base 
time: 73.58 ms, remaining time: 176.42 ms, target pause time: 250.00 ms]
  48448.931: [G1Ergonomics (CSet Construction) add young regions to 
CSet, eden: 33 regions, survivors: 5 regions, predicted young region 
time: 35.73 ms]
  48448.933: [G1Ergonomics (CSet Construction) finish adding old regions 
to CSet, reason: reclaimable percentage not over threshold, old: 19 
regions, max: 77 regions, reclaimable: 2570649712 bytes (9.98 %), 
threshold: 10.00 %]
  48448.933: [G1Ergonomics (CSet Construction) added expensive regions 
to CSet, reason: old CSet region num not reached min, old: 19 regions, 
expensive: 7 regions, min: 26 regions, remaining time: 0.00 ms]
  48448.933: [G1Ergonomics (CSet Construction) finish choosing CSet, 
eden: 33 regions, survivors: 5 regions, old: 19 regions, predicted pause 
time: 340.58 ms, target pause time: 250.00 ms]
48449.252: [SoftReference, 962 refs, 0.0064679 secs]48449.259: 
[WeakReference, 7411 refs, 0.0027722 secs]48449.261: [FinalReference, 
272 refs, 0.0022754 secs]48449.264: [PhantomReference, 6 refs, 0.0024348 
secs]48449.266: [JNI Weak Reference, 0.0000337 secs] 48449.288: 
[G1Ergonomics (Concurrent Cycles) do not request concurrent cycle 
initiation, reason: still doing mixed collections, occupancy: 
14898167808 bytes, allocation request: 0 bytes, threshold: 11596411665 
bytes (45.00 %), source: end of GC]
*48449.288*: [G1Ergonomics (Mixed GCs) do not continue mixed GCs, 
reason: reclaimable percentage not over threshold, candidate old 
regions: 156 regions, reclaimable: 2570649712 bytes (9.98 %), threshold: 
10.00 %]
, 0.3573636 secs]
    [Parallel Time: 314.9 ms, GC Workers: 40]
       [GC Worker Start (ms): Min: 48448933.6, Avg: 48448934.2, Max: 
48448934.7, Diff: 1.1]
       [Ext Root Scanning (ms): Min: 15.1, Avg: 17.7, Max: *69.1*, Diff: 
54.0, Sum: 708.0]
       [Update RS (ms): Min: 0.0, Avg: 14.5, Max: *22.2*, Diff: 22.2, 
Sum: 580.3]
          [Processed Buffers: Min: 0, Avg: 22.0, Max: *45*, Diff: 45, 
Sum: 879]
       [Scan RS (ms): Min: 88.7, Avg: 142.6, Max: *150.8*, Diff: 62.1, 
Sum: 5705.2]
       [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: *0.1*, Diff: 
0.1, Sum: 0.1]
       [Object Copy (ms): Min: 131.4, Avg: 138.2, Max: *155.1*, Diff: 
23.8, Sum: 5526.6]
       [Termination (ms): Min: 0.0, Avg: 0.7, Max: *0.9*, Diff: 0.9, 
Sum: 27.2]
       [GC Worker Other (ms): Min: 0.0, Avg: 0.3, Max: *0.5*, Diff: 0.5, 
Sum: 10.0]
       [GC Worker Total (ms): Min: 313.2, Avg: 313.9, Max: *314.7*, 
Diff: 1.5, Sum: 12557.5]
       [GC Worker End (ms): Min: 48449247.9, Avg: 48449248.1, Max: 
48449248.4, Diff: 0.5]
    [Code Root Fixup: 2.2 ms]
    [Code Root Migration: 0.2 ms]
    [Clear CT: 2.0 ms]
    [Other: 38.2 ms]
       [Choose CSet: 1.7 ms]
       [Ref Proc: 15.6 ms]
       [Ref Enq: 1.2 ms]
       [Free CSet: 2.4 ms]
    [Eden: 1056.0M(1056.0M)->0.0B(1088.0M) Survivors: 160.0M->128.0M 
Heap: 14.5G(24.0G)->13.9G(24.0G)]
  [Times: user=12.45 sys=0.03, real=0.36 secs]
*48454**.034*: Total time for which application threads were stopped: 
*9.3426141* seconds

For completeness; here are the cmd line options:


/usr/jdk/instances/jdk1.7.0/bin/sparcv9/java -Xms24g -Xmx24g -server  
-XX:StringTableSize=27001  -XX:PermSize=512m -XX:MaxPermSize=512m  -Xss512k
-XX:+UseG1GC  -XX:SoftRefLRUPolicyMSPerMB=500 -XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps -Xloggc:/var/cacao/instances/oem-ec/logs/gc.log 
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 
-XX:GCLogFileSize=10m  -XX:+PrintGCApplicationStoppedTime 
-XX:MaxGCPauseMillis=250-XX:InitiatingHeapOccupancyPercent=45 
-XX:+ParallelRefProcEnabled  -XX:ParallelGCThreads=40 
-XX:+PrintAdaptiveSizePolicy  -XX:+PrintSafepointStatistics 
-XX:+PrintReferenceGC  -XX:G1HeapRegionSize=32m -XX:HeapBaseMinAddress=2G



Thanks and Regards

Thomas

-- 
Oracle <http://www.oracle.com>
THOMAS VIESSMANN | Senior Principal Technical Support Engineer - Java
Phone: +498914302496 <tel:+49814302496> | Mobile: +491743005467 
<tel:+491743005467>
Oracle Customer Technical Support - Java

ORACLE Deutschland B.V. & Co. KG | Riesstr.25 | D-80992 Muenchen

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 Muenchen
Registergericht: Amtsgericht Muenchen, HRA 95603
Gesch?ftsf?hrere: Juergen Kunz

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

------------------------------------------------------------------------
------------------------------------------------------------------------
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140829/5307ccf1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140829/5307ccf1/oracle_sig_logo.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: green-for-email-sig_0.gif
Type: image/gif
Size: 356 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140829/5307ccf1/green-for-email-sig_0.gif>

From staffan.friberg at oracle.com  Fri Aug 29 22:32:15 2014
From: staffan.friberg at oracle.com (Staffan Friberg)
Date: Fri, 29 Aug 2014 15:32:15 -0700
Subject: RFR: JDK-8055845 - Add trace event for promoted objects
In-Reply-To: <54001EFF.3030802@oracle.com>
References: <53FB6432.1010501@oracle.com>	<53FB6A86.1080908@oracle.com>	<53FB7338.9030208@oracle.com>	<53FC4A57.3030100@oracle.com>
	<53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com>
	<53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com>
Message-ID: <5400FF6F.5040203@oracle.com>

Hi Erik,

On 08/28/2014 11:34 PM, Erik Helin wrote:
> (it seems like we lost hotspot-gc-dev at openjdk.java.net somewhere in 
> this thread, I'm adding it back)
>
> On 2014-08-28 23:15, Staffan Friberg wrote:
>> Hi Erik,
>>
>> Thanks for the comments.
>>> - Aren't the events for promotion to the tenured generation (SerialOld)
>>>   and the CMS generation missing?
>> The reason for leaving out these two, Serial completely and CMS
>> promotion, was due to that neither as far as I understand make use of
>> PLABs.
>
> I might be wrong here, but looking at the function 
> TenuredGeneration::par_promote (in tenuredGeneration.cpp) it looks to 
> me like SerialOld is using PLABs when ParNew is promoting objects from 
> young to old.
>
> As for CMS, looking at ConcurrentMarkSweepGeneration::par_promote (in 
> concurrentMarkSweepGeneration.cpp) it seems like each 
> CMSParGCThreadState has a CFLS_LAB (CompactibleFreeListSpace Local 
> Allocation Buffer) that is a thread-local allocation buffer. See 
> compactibleFreeListSpace.{hpp,cpp} for more details.
>
> Given this, I think we should add events for Serial and CMS as well.
>

Ok I see what you mean with CMS, basically the equivalent to getting a 
PLAB would be when we refill the CFLS_LAB in the alloc function. It 
still does the allocation to a small memory (~ size of object) area from 
the freelist, but at least we did extra work to refill the local 
CFLS_LAB. Need to do some analysis to see how often we refill so the 
overhead doesn't get too high.
The only issue I run into is how I can in a nice way get access to the 
ParNewTracer from ParNewGeneration to call the report function. Let's 
sync up next week and see how it can be solved.

The tenured GC requires something similar to be supported, however since 
ParNewGC is deprecated for usage without CMS in JDK 8 we might want to 
skip that combination.


>
> On 2014-08-28 23:15, Staffan Friberg wrote:
>>> - Would it make sense to differentiate, either by separate events or by
>>>   a field in a event, between promotions to to-space and to the old
>>>   generation?
>>> - The are two events for TLAB allocations,
>>>   java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB.
>>>   What do you think about using two events for PLAB allocations as 
>>> well:
>>>   - java/object_alloc_in_new_PLAB
>>>   - java/object_alloc_outside_PLAB
>> I think this is a matter of taste and probably how similar we want the
>> event to be to the existing allocation event. I personally prefer a
>> single event but if the GC team and serviceability team feel it would be
>> better to have two I can certainly rewrite. The reason for me preferring
>> a single event is just ease of analysis, you can easily filter a list of
>> events on a field, it is harder to merge two different events with
>> different fields and work with them in an straight forward fashion.
>>
>> Any general preference for having a single or multiple events?
>
> I would prefer to have two events in this case and try to follow the 
> existing allocation events as much as possible (both in naming and in 
> style). Keeping the tenured field (I missed it the first time I read 
> the patch) is good.
>
Yes, tenured would be independent of having two events, only PLAB size 
and directAllocation would be affected when having two event types.

*Erik Gahlin*, any preference from your end?



> On 2014-08-28 23:15, Staffan Friberg wrote:
>>> - In PSPromotionManager, instead of utilizing the C++ friendship with
>>>   PSScavenge, should we add a getter function for the gc_tracer?
>> Created a getter function.
>
> Thanks! If you make report_promotion_sample const, then the getter can 
> return a const ParallelScavengeTracer*, right?
>
Done

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

From jon.masamitsu at oracle.com  Fri Aug 29 23:12:24 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 29 Aug 2014 16:12:24 -0700
Subject: RFR 8048268: G1 Code Root Migration performs poorly
In-Reply-To: <1819337.ruQN7pby6E@mgerdin03>
References: <1819337.ruQN7pby6E@mgerdin03>
Message-ID: <540108D8.3030504@oracle.com>

Mikael,

When an nmethod is made not_entrant,
the  G1CodeRootSet::remove() is called
and if the entries in the table go to 0, the
table is deleted (right?).   And then a new
table is reallocated if needed again (right?)
If yes and yes, why not just  keep the table?

Jon


On 8/26/2014 8:42 AM, Mikael Gerdin wrote:
> Hi,
>
> In order to combat the spikes in code root migration times I suggest that we
> reimplement the code cache remembered set using hash tables instead of the
> current chunked array variant.
>
> While we're at it I suggest that we get rid of the entire migration phase and
> update the code cache remembered set during the parallel RSet scanning phase.
> The contains()-check when adding during RSet scanning is designed to be lock-
> free in order to reduce contention on the HRRS locks.
> This led me to remove some contains-checks in asserts since they were done
> during a phase where operations which could not guarantee lock-free reads to
> succeed were performed.
>
> Testing: Kitchensink 14hrs, JPRT, Aurora perf testing of several industry
> benchmarks and CRM Fuse (where it actually makes a difference since we had
> 300ms spikes in code root migration times).
>
> The table sizes in G1CodeRootSet are completely unscientific but seem to work
> good enough for now. An even larger table size could possibly be considered
> for pathological cases where we get thousands of nmethods (as can occur in CRM
> Fuse) but currently the two sizes seem good enough.
>
> This change depends on "JDK-8056084: Refactor Hashtable to allow
> implementations without rehashing support" since the remembered sets are
> allocated and deallocated I needed to allow for deallocation of instances of
> HashtableEntry and deallocation of freelist contents.
>
> Webrev: http://cr.openjdk.java.net/~mgerdin/8048268/nm-hashtable/webrev/
> Buglink: https://bugs.openjdk.java.net/browse/JDK-8048268
>
> a note about g1RemSetSummary.cpp
> the code failed to update _max_code_root_mem_sz, so the code to list the most
> expensive code root remset was broken.
>
> /Mikael