From david.holmes at oracle.com  Tue Apr  1 06:02:41 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 01 Apr 2014 16:02:41 +1000
Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEABD3C@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CEABD3C@DEWDFEMB12A.global.corp.sap>
Message-ID: <533A5681.20607@oracle.com>

Hi Goetz,

Not a review ...

On 31/03/2014 10:42 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> could I please get reviews for this change?  I please also need a sponsor.
> I would like to get this into 8u20, as 8036330 was downported, too.
>
> I'd like to make the point of this change clear once more, independent
> of which compiler does what.
>
> I think we agree that basically
>    - a file should include all headers that define symbols or include
>      method bodies used in that file

Personally I don't see why a cpp file should have to be aware that a 
member function it uses just happens to have been defined in an 
inline.hpp file by its author. Seems to break encapsulation to me. :(

>    - a .hpp header should not include a .inline.hpp header

I see 277 occurrences of this in the existing OpenJDK hotspot code, so I 
don't think we can take this as a general rule either.

Note I'm not saying this fix isn't right or needed, just that the 
"rules" you are trying to embody don't seem to generally apply.

David
-----

> This is violated
>
> 1.)    by defining
>   template <class T> void immediate_rs_update(HeapRegion* from, T* p, int tid) {
>     if (!from->is_survivor()) {
>        _g1_rem->par_write_ref(from, p, tid);
>      }
> }
>   in g1CollectedHeap.hpp, as par_write_ref in declared 'inline' and only defined in
>      g1RemSet.inline.hpp - which is not included and should not be included
>      in g1CollectedHeap.hpp.
> 2. by including g1CollectedHeap.inline.hpp in sparsePRT.hpp
>
> This change fixes these two points by moving functions into .inline.hpp files
> and fixing the include.
>
> Best regards,
>    Goetz.
>
>
>
>
> From: Lindenmaier, Goetz
> Sent: Donnerstag, 27. M?rz 2014 17:46
> To: hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
> Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
>
> Hi,
>
> Please review and test this change.  I please need a sponsor:
> http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/
>
> Change 8035330: Remove G1ParScanPartialArrayClosure and G1ParScanHeapEvacClosure
> broke the dbg build on AIX. That's because do_oop_partial_array() is added in
> a header, but requires inline function par_write_ref() through several inlined
> calls. In some cpp files, like arguments.cpp, par_write_ref() is not defined
> as the corresponding inline header is not included.  The aix debug VM does not start.
>
> This can be solved by including g1RemSet.inline.hpp in g1CollectedHeap.inline.hpp.
>
> Unfortunately this now causes a cyclic dependency that breaks the linux build.
> A inline.hpp file is included ahead of a .hpp file, so that the code in the inline.hpp file
> can not see the class declaration.
> This is caused because g1CollectedHeap.inline.hpp is included in sparsePRT.hpp.
> But .inline.hpp files never should be included in .hpp files.
>
> To resolve this, I changed this inlcude to g1CollectedHeap.hpp.  As consequence,
> I had to move a row of functions to existing .inline.hpp files.
>
> I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64,
> sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up.
>
> Best regards,
>    Goetz
>


From bengt.rutisson at oracle.com  Tue Apr  1 06:03:33 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 01 Apr 2014 08:03:33 +0200
Subject: RFR (XXS): 8038829: G1: More useful information in a few assert
	messages
In-Reply-To: <5339EF1D.5040908@oracle.com>
References: <5339863A.5020106@oracle.com> <5339EF1D.5040908@oracle.com>
Message-ID: <533A56B5.5070106@oracle.com>


Thanks for the reviews Stefan and Jon!

Bengt

On 4/1/14 12:41 AM, Jon Masamitsu wrote:
> Looks good.
>
> Reviewed.
>
> Jon
>
> On 3/31/14 8:14 AM, Bengt Rutisson wrote:
>>
>> Hi everyone,
>>
>> Could I have a couple of reviews of this very small fix to some 
>> assert messages:
>>
>> http://cr.openjdk.java.net/~brutisso/8038829/webrev.00/
>>
>> https://bugs.openjdk.java.net/browse/JDK-8038829
>>
>> In VerifyRegionListsClosure::doHeapRegion() the assert messages print 
>> the region_num() value of the heap region. This value is the the 
>> number of regions that a humongous object covers. It is only relevant 
>> for starts humongous regions. For all other regions this value is 1.
>>
>> Most likely the intended value was hrs_index(), which is a sequential 
>> number enumerating all heap regions.
>>
>> Thanks,
>> Bengt
>

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

From stefan.karlsson at oracle.com  Tue Apr  1 06:40:04 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 01 Apr 2014 08:40:04 +0200
Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
In-Reply-To: <533A5681.20607@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CEABD3C@DEWDFEMB12A.global.corp.sap>
	<533A5681.20607@oracle.com>
Message-ID: <533A5F44.2000308@oracle.com>

On 2014-04-01 08:02, David Holmes wrote:
> Hi Goetz,
>
> Not a review ...
>
> On 31/03/2014 10:42 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> could I please get reviews for this change?  I please also need a 
>> sponsor.
>> I would like to get this into 8u20, as 8036330 was downported, too.
>>
>> I'd like to make the point of this change clear once more, independent
>> of which compiler does what.
>>
>> I think we agree that basically
>>    - a file should include all headers that define symbols or include
>>      method bodies used in that file
>
> Personally I don't see why a cpp file should have to be aware that a 
> member function it uses just happens to have been defined in an 
> inline.hpp file by its author. Seems to break encapsulation to me. :(

Yes, it's unfortunate, but necessary to prevent problems like circular 
dependencies. If we don't follow it, we not only risk breaking the code 
with the offending patch, but future patches might be harder to create 
because of the transitive closure of include files that is introduced by 
including the .inline.hpp file.
>
>>    - a .hpp header should not include a .inline.hpp header
>
> I see 277 occurrences of this in the existing OpenJDK hotspot code, so 
> I don't think we can take this as a general rule either.
>
> Note I'm not saying this fix isn't right or needed, just that the 
> "rules" you are trying to embody don't seem to generally apply.

This is a rule I try hard to enforce when reviewing changes. If you 
don't follow it we'll end up with problems like this.

I think it's worth adding to:
https://wiki.openjdk.java.net/display/HotSpot/StyleGuide

thanks,
StefanK

>
> David
> -----
>
>> This is violated
>>
>> 1.)    by defining
>>   template <class T> void immediate_rs_update(HeapRegion* from, T* p, 
>> int tid) {
>>     if (!from->is_survivor()) {
>>        _g1_rem->par_write_ref(from, p, tid);
>>      }
>> }
>>   in g1CollectedHeap.hpp, as par_write_ref in declared 'inline' and 
>> only defined in
>>      g1RemSet.inline.hpp - which is not included and should not be 
>> included
>>      in g1CollectedHeap.hpp.
>> 2. by including g1CollectedHeap.inline.hpp in sparsePRT.hpp
>>
>> This change fixes these two points by moving functions into 
>> .inline.hpp files
>> and fixing the include.
>>
>> Best regards,
>>    Goetz.
>>
>>
>>
>>
>> From: Lindenmaier, Goetz
>> Sent: Donnerstag, 27. M?rz 2014 17:46
>> To: hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
>> Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
>>
>> Hi,
>>
>> Please review and test this change.  I please need a sponsor:
>> http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/
>>
>> Change 8035330: Remove G1ParScanPartialArrayClosure and 
>> G1ParScanHeapEvacClosure
>> broke the dbg build on AIX. That's because do_oop_partial_array() is 
>> added in
>> a header, but requires inline function par_write_ref() through 
>> several inlined
>> calls. In some cpp files, like arguments.cpp, par_write_ref() is not 
>> defined
>> as the corresponding inline header is not included.  The aix debug VM 
>> does not start.
>>
>> This can be solved by including g1RemSet.inline.hpp in 
>> g1CollectedHeap.inline.hpp.
>>
>> Unfortunately this now causes a cyclic dependency that breaks the 
>> linux build.
>> A inline.hpp file is included ahead of a .hpp file, so that the code 
>> in the inline.hpp file
>> can not see the class declaration.
>> This is caused because g1CollectedHeap.inline.hpp is included in 
>> sparsePRT.hpp.
>> But .inline.hpp files never should be included in .hpp files.
>>
>> To resolve this, I changed this inlcude to g1CollectedHeap.hpp. As 
>> consequence,
>> I had to move a row of functions to existing .inline.hpp files.
>>
>> I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64,
>> sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up.
>>
>> Best regards,
>>    Goetz
>>



From erik.helin at oracle.com  Tue Apr  1 06:49:09 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Tue, 01 Apr 2014 08:49:09 +0200
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533955B0.7000601@oracle.com>
References: <5332FA20.5070607@oracle.com>
	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>
	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>
	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>
	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>
	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>
	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>
	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>
	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>
	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>
	<53394053.2070502@oracle.com> <533955B0.7000601@oracle.com>
Message-ID: <533A6165.80704@oracle.com>

Andrey,

a couple of comments:
- We do not use the @author tag in the tests
   (if you've seen other tests have the @author tag, then that is a bug)
- I'm not a big fan of using inheritance for sharing code between
   tests because it makes it very hard to open a test, e.g.
   TestHumongousShrinkHeap.java, and see what it does.

   The code you share in TestShrinkHeap is basically the check and the
   control flow of the tests. I would prefer if you could move the
   control flow (System.gc(), sample, eat, sample, free, check samples)
   into the tests and then write helper functions for retrieving the
   flag values.

   As for the check, please use the assertions in
   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
   throwing a RuntimeException.

Thanks,
Erik

On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
> Hi,
>
> New webrev uploaded.
>
> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>
> I'm not a Reviewer either so if you got Igor's blessing already, my
> review won't be enough to push unfortunately.
> /Jesper
>
> Andrey Zakharov skrev 31/3/14 12:15:
>> Hi,
>> Jepser, here is updated webrev.09
>> Thomas, Jesper can you review it as well?
>> Thanks.
>>
>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>> Andrey,
>>>
>>> 1. TEST.groups:
>>> please update copyright year:
>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All rights
>>>> reserved.
>>> should be
>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates. All
>>>> rights
>>>> reserved.
>>>
>>> 2. TestShrinkHeap.java
>>>>   22  */
>>>>   23 package com.oracle.java.testlibrary.gc;
>>> add empty line between 22 and 23 as you do in all other files,
>>>
>>> otherwise it looks good to me.
>>>
>>> Keep in mind I'm not a Reviewer, but I can be mentioned in 'Reviewed-by'
>>> section )
>>>
>>> Thanks,
>>> Igor
>>>
>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>> Hi, team
>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>
>>>> Thanks
>>>>
>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>> Webrev uploaded:
>>>>>
>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>
>>>>> /Jesper
>>>> Thank you, Jesper.
>>>>
>>>>>
>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>> Hi! Here is webrev.08,
>>>>>> Jesper, can you upload it? Thanks!
>>>>>>
>>>>>> Igor, thanks for well detailed review!
>>>>>>
>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>> Andrey,
>>>>>>>
>>>>>>> 1. both tests:
>>>>>>>>   48     public void eat() {
>>>>>>>> 61     public void free() {
>>>>>>> change visibility of concrete methods to protected
>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>  32  */
>>>>>>>>  33 import com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>> add empty line between these lines or remove empty line #32 in
>>>>>>> TestDynShrinkHeap
>>>>>>>>  62         //do not free last one list
>>>>>>> space after '//'
>>>>>>> 3. both tests:
>>>>>>>>   26  * @bug 8037924
>>>>>>>>   26  * @bug 8037925
>>>>>>> after @bug you should specify product bug ids which can be tested by
>>>>>>> this
>>>>>>> test. I guess 8016479 instead of 8037924, and 8036025/8037925.
>>>>>>>
>>>>>>> otherwise it looks good, thank you for your work and patience )
>>>>>>>
>>>>>>> Igor
>>>>>>>
>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>> Hi, New webrev in place:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>
>>>>>>>> /Jesper
>>>>>>>>
>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>> Hi, here updated webrev.
>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>> Igor, please, see comment below, everything uncommented is done.
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()' 'TestShrinkHeap.gc()'?
>>>>>>>>> I cut this out.
>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for it --
>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>
>>>>>>>>> Not sure is it applicable for me, because every time in feature
>>>>>>>>> ticket
>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>> Thanks
>>>>>>>>>> Igor
>>>>>>>>>>
>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>> Hi, team!
>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to review. It
>>>>>>>>>>>> will be
>>>>>>>>>>>> upload later.
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>  45     public static byte[] temp;
>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>
>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should have one
>>>>>>>>>>>>> super
>>>>>>>>>>>>> class,
>>>>>>>>>>>>>
>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>
>>>>>>>>>>>>> protected static final String MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>> protected static final String MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>
>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>
>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>
>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>   MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>   if (!(muFree.getCommitted() < muFull.getCommitted())) {
>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>       String.format("committed free heap size is not less than
>>>>>>>>>>>>> committed full heap size, heap hasn't been shrunk?%n%s =
>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>> %s",
>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>
>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(),
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>
>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue()
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>               )
>>>>>>>>>>>>>       );
>>>>>>>>>>>>>   }
>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>   MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>   MemoryUsagePrinter.printMemoryUsage("before full GC");
>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>   MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/
>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry for
>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary and just
>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   26  * @key gc
>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc', please don't
>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>> I think that this is used for test execution - to execute
>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, so we don't
>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/
>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct one is
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/.
>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry for
>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>   44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's not
>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>   96 StringBuilder strb = new StringBuilder("committed
>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than committed
>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>   97 strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>   99 strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>  101             throw new
>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>  throw new RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap size, heap
>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue));
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/
>>>>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>
>>


From goetz.lindenmaier at sap.com  Tue Apr  1 07:30:17 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 1 Apr 2014 07:30:17 +0000
Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
In-Reply-To: <533A5681.20607@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CEABD3C@DEWDFEMB12A.global.corp.sap>
	<533A5681.20607@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CEABFB5@DEWDFEMB12A.global.corp.sap>

Hi David, 

> Personally I don't see why a cpp file should have to be aware that a 
> member function it uses just happens to have been defined in an 
> inline.hpp file by its author. Seems to break encapsulation to me. :(
Because the .cpp file will not compile if the .inline.hpp header with 
the implementation is not visible during compilation.

> I see 277 occurrences of this in the existing OpenJDK hotspot code, so I
There are a lot of .hpp files with include methods that don't have 
a corresponding .inline.hpp file.  Like taskqueue.hpp, which includes
the atomic headers.  Would be nice if this was cleaned up.
Also, oop.inline.hpp often makes problems, because methods defined
there are used in .hpp files, which can not include oop.inline.hpp 
as it causes cycles.  If you include that header in a cpp file, you also have
to include oop.inline.hpp, which is really unintuitive.

Best regards,
  Goetz.

-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Dienstag, 1. April 2014 08:03
To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330

Hi Goetz,

Not a review ...

On 31/03/2014 10:42 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> could I please get reviews for this change?  I please also need a sponsor.
> I would like to get this into 8u20, as 8036330 was downported, too.
>
> I'd like to make the point of this change clear once more, independent
> of which compiler does what.
>
> I think we agree that basically
>    - a file should include all headers that define symbols or include
>      method bodies used in that file

Personally I don't see why a cpp file should have to be aware that a 
member function it uses just happens to have been defined in an 
inline.hpp file by its author. Seems to break encapsulation to me. :(

>    - a .hpp header should not include a .inline.hpp header

I see 277 occurrences of this in the existing OpenJDK hotspot code, so I 
don't think we can take this as a general rule either.

Note I'm not saying this fix isn't right or needed, just that the 
"rules" you are trying to embody don't seem to generally apply.

David
-----

> This is violated
>
> 1.)    by defining
>   template <class T> void immediate_rs_update(HeapRegion* from, T* p, int tid) {
>     if (!from->is_survivor()) {
>        _g1_rem->par_write_ref(from, p, tid);
>      }
> }
>   in g1CollectedHeap.hpp, as par_write_ref in declared 'inline' and only defined in
>      g1RemSet.inline.hpp - which is not included and should not be included
>      in g1CollectedHeap.hpp.
> 2. by including g1CollectedHeap.inline.hpp in sparsePRT.hpp
>
> This change fixes these two points by moving functions into .inline.hpp files
> and fixing the include.
>
> Best regards,
>    Goetz.
>
>
>
>
> From: Lindenmaier, Goetz
> Sent: Donnerstag, 27. M?rz 2014 17:46
> To: hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
> Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
>
> Hi,
>
> Please review and test this change.  I please need a sponsor:
> http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/
>
> Change 8035330: Remove G1ParScanPartialArrayClosure and G1ParScanHeapEvacClosure
> broke the dbg build on AIX. That's because do_oop_partial_array() is added in
> a header, but requires inline function par_write_ref() through several inlined
> calls. In some cpp files, like arguments.cpp, par_write_ref() is not defined
> as the corresponding inline header is not included.  The aix debug VM does not start.
>
> This can be solved by including g1RemSet.inline.hpp in g1CollectedHeap.inline.hpp.
>
> Unfortunately this now causes a cyclic dependency that breaks the linux build.
> A inline.hpp file is included ahead of a .hpp file, so that the code in the inline.hpp file
> can not see the class declaration.
> This is caused because g1CollectedHeap.inline.hpp is included in sparsePRT.hpp.
> But .inline.hpp files never should be included in .hpp files.
>
> To resolve this, I changed this inlcude to g1CollectedHeap.hpp.  As consequence,
> I had to move a row of functions to existing .inline.hpp files.
>
> I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64,
> sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up.
>
> Best regards,
>    Goetz
>


From david.holmes at oracle.com  Tue Apr  1 07:36:11 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 01 Apr 2014 17:36:11 +1000
Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEABFB5@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CEABD3C@DEWDFEMB12A.global.corp.sap>
	<533A5681.20607@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEABFB5@DEWDFEMB12A.global.corp.sap>
Message-ID: <533A6C6B.6090203@oracle.com>

On 1/04/2014 5:30 PM, Lindenmaier, Goetz wrote:
> Hi David,
>
>> Personally I don't see why a cpp file should have to be aware that a
>> member function it uses just happens to have been defined in an
>> inline.hpp file by its author. Seems to break encapsulation to me. :(
> Because the .cpp file will not compile if the .inline.hpp header with
> the implementation is not visible during compilation.

Understood - but there is more than one way to make the implementation 
visible to the cpp file eg cpp include .hpp and .hpp includes 
.inline.hpp (I suppose that is a "bad" thing to do?)

And that still doesn't change the fact it is breaking encapsulation :)

>> I see 277 occurrences of this in the existing OpenJDK hotspot code, so I
> There are a lot of .hpp files with include methods that don't have
> a corresponding .inline.hpp file.  Like taskqueue.hpp, which includes
> the atomic headers.  Would be nice if this was cleaned up.
> Also, oop.inline.hpp often makes problems, because methods defined
> there are used in .hpp files, which can not include oop.inline.hpp
> as it causes cycles.  If you include that header in a cpp file, you also have
> to include oop.inline.hpp, which is really unintuitive.

I find the inline situation to be unintuitive in general. There's a flow 
on affect that an inline function can't use other inline functions 
unless they all get moved to .inline.hpp files. I hope it is okay for 
one .inline.hpp file to include another one? Otherwise you have to 
expose the internal implementation detail of one class to its clients so 
they know which set of .inline.hpp files have to be included!

Cheers,
David

> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Dienstag, 1. April 2014 08:03
> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
> Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330
>
> Hi Goetz,
>
> Not a review ...
>
> On 31/03/2014 10:42 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> could I please get reviews for this change?  I please also need a sponsor.
>> I would like to get this into 8u20, as 8036330 was downported, too.
>>
>> I'd like to make the point of this change clear once more, independent
>> of which compiler does what.
>>
>> I think we agree that basically
>>     - a file should include all headers that define symbols or include
>>       method bodies used in that file
>
> Personally I don't see why a cpp file should have to be aware that a
> member function it uses just happens to have been defined in an
> inline.hpp file by its author. Seems to break encapsulation to me. :(
>
>>     - a .hpp header should not include a .inline.hpp header
>
> I see 277 occurrences of this in the existing OpenJDK hotspot code, so I
> don't think we can take this as a general rule either.
>
> Note I'm not saying this fix isn't right or needed, just that the
> "rules" you are trying to embody don't seem to generally apply.
>
> David
> -----
>
>> This is violated
>>
>> 1.)    by defining
>>    template <class T> void immediate_rs_update(HeapRegion* from, T* p, int tid) {
>>      if (!from->is_survivor()) {
>>         _g1_rem->par_write_ref(from, p, tid);
>>       }
>> }
>>    in g1CollectedHeap.hpp, as par_write_ref in declared 'inline' and only defined in
>>       g1RemSet.inline.hpp - which is not included and should not be included
>>       in g1CollectedHeap.hpp.
>> 2. by including g1CollectedHeap.inline.hpp in sparsePRT.hpp
>>
>> This change fixes these two points by moving functions into .inline.hpp files
>> and fixing the include.
>>
>> Best regards,
>>     Goetz.
>>
>>
>>
>>
>> From: Lindenmaier, Goetz
>> Sent: Donnerstag, 27. M?rz 2014 17:46
>> To: hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
>> Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
>>
>> Hi,
>>
>> Please review and test this change.  I please need a sponsor:
>> http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/
>>
>> Change 8035330: Remove G1ParScanPartialArrayClosure and G1ParScanHeapEvacClosure
>> broke the dbg build on AIX. That's because do_oop_partial_array() is added in
>> a header, but requires inline function par_write_ref() through several inlined
>> calls. In some cpp files, like arguments.cpp, par_write_ref() is not defined
>> as the corresponding inline header is not included.  The aix debug VM does not start.
>>
>> This can be solved by including g1RemSet.inline.hpp in g1CollectedHeap.inline.hpp.
>>
>> Unfortunately this now causes a cyclic dependency that breaks the linux build.
>> A inline.hpp file is included ahead of a .hpp file, so that the code in the inline.hpp file
>> can not see the class declaration.
>> This is caused because g1CollectedHeap.inline.hpp is included in sparsePRT.hpp.
>> But .inline.hpp files never should be included in .hpp files.
>>
>> To resolve this, I changed this inlcude to g1CollectedHeap.hpp.  As consequence,
>> I had to move a row of functions to existing .inline.hpp files.
>>
>> I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64,
>> sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up.
>>
>> Best regards,
>>     Goetz
>>


From per.liden at oracle.com  Tue Apr  1 07:54:23 2014
From: per.liden at oracle.com (Per Liden)
Date: Tue, 1 Apr 2014 09:54:23 +0200
Subject: RFR(s): 8038461: Test
	gc/g1/TestStringDeduplicationMemoryUsage.java fails with
	unexpected memory usage
In-Reply-To: <53392C28.9090402@oracle.com>
References: <53357C14.3060902@oracle.com> <53392C28.9090402@oracle.com>
Message-ID: <D0508778-5D7A-4473-A646-22AEDF04085F@oracle.com>

Thanks Stefan! Need one more Review.

/Per

On 31 Mar 2014, at 10:49, Stefan Johansson <stefan.johansson at oracle.com> wrote:

> Looks good!
> 
> Stefan
> 
> On 2014-03-28 14:41, Per Liden wrote:
>> Hi,
>> 
>> Could I please have this test fix reviewed.
>> 
>> Summary: The test in question tries to calculate the amount of memory saved when using string deduplication. The problem is that the JVM doing this calculation could be running without compressed class pointers when the JVM doing the actual string deduplication is running with compressed class pointers. When this happens the JVMs will have different views on the size of an array header, which in the end makes the calculation incorrect and the test thinks the deduplication failed. Exactly this situation happened in a nightly test run. This fix makes sure that the array header size of the JVM doing the deduplication is communicated to the JVM doing the memory savings calculation.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038461
>> Webrev: http://cr.openjdk.java.net/~pliden/8038461/webrev.0/
>> 
>> /Per
>> 
> 



From goetz.lindenmaier at sap.com  Tue Apr  1 08:04:48 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 1 Apr 2014 08:04:48 +0000
Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
In-Reply-To: <533A6C6B.6090203@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CEABD3C@DEWDFEMB12A.global.corp.sap>
	<533A5681.20607@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEABFB5@DEWDFEMB12A.global.corp.sap>
	<533A6C6B.6090203@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CEABFE1@DEWDFEMB12A.global.corp.sap>

Hi David, 

Well, the only reason for .inline.hpp files is to break include cycles.
If you include them in the corresponding .hpp files, you reintroduce
the cycles.

If you want encapsulation, don't use inline methods.

> There's a flow 
> on affect that an inline function can't use other inline functions 
> unless they all get moved to .inline.hpp files.
That's exactly the rule that should be enforced.

Yes, .inline.hpp files may include .inline.hpp files.  That will 
not cause cycles.  This way .hpp files will all be placed in the
beginning of a (preprocessed) cpp file, then the .include.hpp files
and last the code of the .cpp file.

Best regards,
  Goetz.



-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Dienstag, 1. April 2014 09:36
To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330

On 1/04/2014 5:30 PM, Lindenmaier, Goetz wrote:
> Hi David,
>
>> Personally I don't see why a cpp file should have to be aware that a
>> member function it uses just happens to have been defined in an
>> inline.hpp file by its author. Seems to break encapsulation to me. :(
> Because the .cpp file will not compile if the .inline.hpp header with
> the implementation is not visible during compilation.

Understood - but there is more than one way to make the implementation 
visible to the cpp file eg cpp include .hpp and .hpp includes 
.inline.hpp (I suppose that is a "bad" thing to do?)

And that still doesn't change the fact it is breaking encapsulation :)

>> I see 277 occurrences of this in the existing OpenJDK hotspot code, so I
> There are a lot of .hpp files with include methods that don't have
> a corresponding .inline.hpp file.  Like taskqueue.hpp, which includes
> the atomic headers.  Would be nice if this was cleaned up.
> Also, oop.inline.hpp often makes problems, because methods defined
> there are used in .hpp files, which can not include oop.inline.hpp
> as it causes cycles.  If you include that header in a cpp file, you also have
> to include oop.inline.hpp, which is really unintuitive.

I find the inline situation to be unintuitive in general. There's a flow 
on affect that an inline function can't use other inline functions 
unless they all get moved to .inline.hpp files. I hope it is okay for 
one .inline.hpp file to include another one? Otherwise you have to 
expose the internal implementation detail of one class to its clients so 
they know which set of .inline.hpp files have to be included!

Cheers,
David

> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Dienstag, 1. April 2014 08:03
> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
> Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330
>
> Hi Goetz,
>
> Not a review ...
>
> On 31/03/2014 10:42 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> could I please get reviews for this change?  I please also need a sponsor.
>> I would like to get this into 8u20, as 8036330 was downported, too.
>>
>> I'd like to make the point of this change clear once more, independent
>> of which compiler does what.
>>
>> I think we agree that basically
>>     - a file should include all headers that define symbols or include
>>       method bodies used in that file
>
> Personally I don't see why a cpp file should have to be aware that a
> member function it uses just happens to have been defined in an
> inline.hpp file by its author. Seems to break encapsulation to me. :(
>
>>     - a .hpp header should not include a .inline.hpp header
>
> I see 277 occurrences of this in the existing OpenJDK hotspot code, so I
> don't think we can take this as a general rule either.
>
> Note I'm not saying this fix isn't right or needed, just that the
> "rules" you are trying to embody don't seem to generally apply.
>
> David
> -----
>
>> This is violated
>>
>> 1.)    by defining
>>    template <class T> void immediate_rs_update(HeapRegion* from, T* p, int tid) {
>>      if (!from->is_survivor()) {
>>         _g1_rem->par_write_ref(from, p, tid);
>>       }
>> }
>>    in g1CollectedHeap.hpp, as par_write_ref in declared 'inline' and only defined in
>>       g1RemSet.inline.hpp - which is not included and should not be included
>>       in g1CollectedHeap.hpp.
>> 2. by including g1CollectedHeap.inline.hpp in sparsePRT.hpp
>>
>> This change fixes these two points by moving functions into .inline.hpp files
>> and fixing the include.
>>
>> Best regards,
>>     Goetz.
>>
>>
>>
>>
>> From: Lindenmaier, Goetz
>> Sent: Donnerstag, 27. M?rz 2014 17:46
>> To: hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
>> Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
>>
>> Hi,
>>
>> Please review and test this change.  I please need a sponsor:
>> http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/
>>
>> Change 8035330: Remove G1ParScanPartialArrayClosure and G1ParScanHeapEvacClosure
>> broke the dbg build on AIX. That's because do_oop_partial_array() is added in
>> a header, but requires inline function par_write_ref() through several inlined
>> calls. In some cpp files, like arguments.cpp, par_write_ref() is not defined
>> as the corresponding inline header is not included.  The aix debug VM does not start.
>>
>> This can be solved by including g1RemSet.inline.hpp in g1CollectedHeap.inline.hpp.
>>
>> Unfortunately this now causes a cyclic dependency that breaks the linux build.
>> A inline.hpp file is included ahead of a .hpp file, so that the code in the inline.hpp file
>> can not see the class declaration.
>> This is caused because g1CollectedHeap.inline.hpp is included in sparsePRT.hpp.
>> But .inline.hpp files never should be included in .hpp files.
>>
>> To resolve this, I changed this inlcude to g1CollectedHeap.hpp.  As consequence,
>> I had to move a row of functions to existing .inline.hpp files.
>>
>> I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64,
>> sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up.
>>
>> Best regards,
>>     Goetz
>>


From stefan.karlsson at oracle.com  Tue Apr  1 08:34:22 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 01 Apr 2014 10:34:22 +0200
Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEAAA44@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CEAAA44@DEWDFEMB12A.global.corp.sap>
Message-ID: <533A7A0E.5040100@oracle.com>

Hi Goetz,

Thanks for fixing this!

One comment below:

On 2014-03-27 17:45, Lindenmaier, Goetz wrote:
>
> Hi,
>
> Please review and test this change.  I please need a sponsor:
>
> http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/ 
> <http://cr.openjdk.java.net/%7Egoetz/webrevs/8038498-incl/>
>

http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html

I'm not sure what the performance implication is of moving these 
functions to the .cpp file. Is there a reason why we wouldn't want to 
put them in the g1CollectedHeap.inline.hpp file?

thanks,
StefanK

> Change 8035330: Remove G1ParScanPartialArrayClosure and 
> G1ParScanHeapEvacClosure
>
> broke the dbg build on AIX. That's because do_oop_partial_array() is 
> added in
>
> a header, but requires inline function par_write_ref() through several 
> inlined
>
> calls. In some cpp files, like arguments.cpp, par_write_ref() is not 
> defined
>
> as the corresponding inline header is not included.  The aix debug VM 
> does not start.
>
> This can be solved by including g1RemSet.inline.hpp in 
> g1CollectedHeap.inline.hpp.
>
> Unfortunately this now causes a cyclic dependency that breaks the 
> linux build.
>
> A inline.hpp file is included ahead of a .hpp file, so that the code 
> in the inline.hpp file
>
> can not see the class declaration.
>
> This is caused because g1CollectedHeap.inline.hpp is included in 
> sparsePRT.hpp.
>
> But .inline.hpp files never should be included in .hpp files.
>
> To resolve this, I changed this inlcude to g1CollectedHeap.hpp.  As 
> consequence,
>
> I had to move a row of functions to existing .inline.hpp files.
>
> I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64,
>
> sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up.
>
> Best regards,
>
>   Goetz
>

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

From andrey.x.zakharov at oracle.com  Tue Apr  1 09:05:05 2014
From: andrey.x.zakharov at oracle.com (Andrey Zakharov)
Date: Tue, 01 Apr 2014 13:05:05 +0400
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533A6165.80704@oracle.com>
References: <5332FA20.5070607@oracle.com>
	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>
	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>
	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>
	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>
	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>
	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>
	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>
	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>
	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>
	<53394053.2070502@oracle.com> <533955B0.7000601@oracle.com>
	<533A6165.80704@oracle.com>
Message-ID: <533A8141.2030608@oracle.com>

Hi, Erik. Thanks for comments.

On 01.04.2014 10:49, Erik Helin wrote:
> Andrey,
>
> a couple of comments:
> - We do not use the @author tag in the tests
>   (if you've seen other tests have the @author tag, then that is a bug)
removed
> - I'm not a big fan of using inheritance for sharing code between
>   tests because it makes it very hard to open a test, e.g.
>   TestHumongousShrinkHeap.java, and see what it does.
Agreed, I'm too. But doubled code leads to harder maintenance.
>
>   The code you share in TestShrinkHeap is basically the check and the
>   control flow of the tests. I would prefer if you could move the
>   control flow (System.gc(), sample, eat, sample, free, check samples)
>   into the tests and then write helper functions for retrieving the
>   flag values.
>
>   As for the check, please use the assertions in
>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>   throwing a RuntimeException.
Good point, changed.
Jesper, can we upload webrev.10 from attachment? Thanks.
I'm still need GC reviewers to approve push.

Thanks.
>
> Thanks,
> Erik
>
> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>> Hi,
>>
>> New webrev uploaded.
>>
>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>
>> I'm not a Reviewer either so if you got Igor's blessing already, my
>> review won't be enough to push unfortunately.
>> /Jesper
>>
>> Andrey Zakharov skrev 31/3/14 12:15:
>>> Hi,
>>> Jepser, here is updated webrev.09
>>> Thomas, Jesper can you review it as well?
>>> Thanks.
>>>
>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>> Andrey,
>>>>
>>>> 1. TEST.groups:
>>>> please update copyright year:
>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All rights
>>>>> reserved.
>>>> should be
>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates. All
>>>>> rights
>>>>> reserved.
>>>>
>>>> 2. TestShrinkHeap.java
>>>>>   22  */
>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>> add empty line between 22 and 23 as you do in all other files,
>>>>
>>>> otherwise it looks good to me.
>>>>
>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in 
>>>> 'Reviewed-by'
>>>> section )
>>>>
>>>> Thanks,
>>>> Igor
>>>>
>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>> Hi, team
>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>
>>>>> Thanks
>>>>>
>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>> Webrev uploaded:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>
>>>>>> /Jesper
>>>>> Thank you, Jesper.
>>>>>
>>>>>>
>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>> Hi! Here is webrev.08,
>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>
>>>>>>> Igor, thanks for well detailed review!
>>>>>>>
>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>> Andrey,
>>>>>>>>
>>>>>>>> 1. both tests:
>>>>>>>>>   48     public void eat() {
>>>>>>>>> 61     public void free() {
>>>>>>>> change visibility of concrete methods to protected
>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>  32  */
>>>>>>>>>  33 import com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>> add empty line between these lines or remove empty line #32 in
>>>>>>>> TestDynShrinkHeap
>>>>>>>>>  62         //do not free last one list
>>>>>>>> space after '//'
>>>>>>>> 3. both tests:
>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>   26  * @bug 8037925
>>>>>>>> after @bug you should specify product bug ids which can be 
>>>>>>>> tested by
>>>>>>>> this
>>>>>>>> test. I guess 8016479 instead of 8037924, and 8036025/8037925.
>>>>>>>>
>>>>>>>> otherwise it looks good, thank you for your work and patience )
>>>>>>>>
>>>>>>>> Igor
>>>>>>>>
>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>
>>>>>>>>> /Jesper
>>>>>>>>>
>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>> Igor, please, see comment below, everything uncommented is done.
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()' 'TestShrinkHeap.gc()'?
>>>>>>>>>> I cut this out.
>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for it --
>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>
>>>>>>>>>> Not sure is it applicable for me, because every time in feature
>>>>>>>>>> ticket
>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>> Thanks
>>>>>>>>>>> Igor
>>>>>>>>>>>
>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>> webrev: 
>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to review. It
>>>>>>>>>>>>> will be
>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>  45     public static byte[] temp;
>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should have one
>>>>>>>>>>>>>> super
>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> protected static final String MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>> protected static final String MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>   if (!(muFree.getCommitted() < muFull.getCommitted())) {
>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>       String.format("committed free heap size is not less 
>>>>>>>>>>>>>> than
>>>>>>>>>>>>>> committed full heap size, heap hasn't been shrunk?%n%s =
>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(), 
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue() 
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full GC");
>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/
>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry for
>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary and just
>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 26  * @key gc
>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc', please 
>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>> I think that this is used for test execution - to execute
>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, so we 
>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/
>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct one is
>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/. 
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry for
>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>   44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's not
>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>   96 StringBuilder strb = new 
>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than committed
>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>   97 
>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>   99 
>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>  101             throw new
>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>  throw new RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap size, 
>>>>>>>>>>>>>>>>>>>> heap
>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue)); 
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/ 
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/
>>>>>>>>>>>>>>>>>>>>>> bug: 
>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>
>>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8037924.tar.gz
Type: application/gzip
Size: 155404 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140401/8b25c4a0/8037924.tar.gz>

From mikael.gerdin at oracle.com  Tue Apr  1 09:52:20 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 01 Apr 2014 11:52:20 +0200
Subject: Request for review: 8038265: CMS: enable time based triggering of
	concurrent cycles
In-Reply-To: <N3AW5D$6641B558048C64803233A598D2C464DA@frajt.eu>
References: <1DDCA93502632C4DA22E9EE199CE907C015FAA93A0@SE002593.cs.commerzbank.com>
	<N3AW5D$6641B558048C64803233A598D2C464DA@frajt.eu>
Message-ID: <1666248.tj7xVnjxql@mgerdin03>

Hi Michal,

On Monday 31 March 2014 14.32.01 Michal Frajt wrote:
> Hi all,could you please review the following change we prepared together
> with Bengt? The change adds new CMSTriggerInterval flag which allows to
> invoke CMS collections periodically. The periodically running CMS
> collections are helping us with replacing the deprecated incremental CMS
> collector. We believe it might be useful for other customers currently
> using the CMS in the incremental mode.Bugs:
> https://bugs.openjdk.java.net/browse/JDK-8038265
> 
> Webrev:
> http://cr.openjdk.java.net/~brutisso/8038265/webrev.00/

If the addition of this functionality helps you replace iCMS then that's 
great! I think this code change is simple and easy to understand. 

I just have some small (mostly stylistic) comments:

	The other time output in PrintCMSInitiationStatistics seems to use 	
	%3.7f as the format specifier instead of %g.

1515     gclog_or_tty->print_cr("cms_time_since_begin=%g", 
stats().cms_time_since_begin());
1516     gclog_or_tty->print_cr("cms_time_since_end=%g", 
stats().cms_time_since_end());


	The HotSpot style is to have a space between if and the opening brace, 
	can you please change the if here:

1588     if(stats().cms_time_since_begin() >= (CMSTriggerInterval / ((double) 
MILLIUNITS))) {
1589       if (Verbose && PrintGCDetails) {

	And here:

1590         if(stats().valid()) {

	We usually align the parameters on the second line with the opening 	
	brace on the function call, something like:

gclog_or_tty->print_cr(foo, bar,
                       stats().baz());

1591           gclog_or_tty->print_cr("CMSCollector: collect because of 
trigger interval (time since last begin %g secs)",
1592             stats().cms_time_since_begin());
1593         } else {

	You pass in cms_time_since_begin() but don't actually use that value 	
	in the else branch. 

1594           gclog_or_tty->print_cr("CMSCollector: collect because of 
trigger interval (first collection)",
1595             stats().cms_time_since_begin());
1596         }
1597       }

/Mikael


> Thanks,
> Michal



From goetz.lindenmaier at sap.com  Tue Apr  1 09:53:36 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 1 Apr 2014 09:53:36 +0000
Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
In-Reply-To: <533A7A0E.5040100@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CEAAA44@DEWDFEMB12A.global.corp.sap>
	<533A7A0E.5040100@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAC068@DEWDFEMB12A.global.corp.sap>

Hi Stefan,

thanks for pointing me to that.
I think I did that to break the chain at some point.

But I only need to move two more functions so that all is
in the .inline file:
http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/webrev.01/

Best regards,
  Goetz.



From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com]
Sent: Dienstag, 1. April 2014 10:34
To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330

Hi Goetz,

Thanks for fixing this!

One comment below:
On 2014-03-27 17:45, Lindenmaier, Goetz wrote:
Hi,

Please review and test this change.  I please need a sponsor:
http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/<http://cr.openjdk.java.net/%7Egoetz/webrevs/8038498-incl/>

http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html

I'm not sure what the performance implication is of moving these functions to the .cpp file. Is there a reason why we wouldn't want to put them in the g1CollectedHeap.inline.hpp file?

thanks,
StefanK



Change 8035330: Remove G1ParScanPartialArrayClosure and G1ParScanHeapEvacClosure
broke the dbg build on AIX. That's because do_oop_partial_array() is added in
a header, but requires inline function par_write_ref() through several inlined
calls. In some cpp files, like arguments.cpp, par_write_ref() is not defined
as the corresponding inline header is not included.  The aix debug VM does not start.

This can be solved by including g1RemSet.inline.hpp in g1CollectedHeap.inline.hpp.

Unfortunately this now causes a cyclic dependency that breaks the linux build.
A inline.hpp file is included ahead of a .hpp file, so that the code in the inline.hpp file
can not see the class declaration.
This is caused because g1CollectedHeap.inline.hpp is included in sparsePRT.hpp.
But .inline.hpp files never should be included in .hpp files.

To resolve this, I changed this inlcude to g1CollectedHeap.hpp.  As consequence,
I had to move a row of functions to existing .inline.hpp files.

I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64,
sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up.

Best regards,
  Goetz

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

From stefan.karlsson at oracle.com  Tue Apr  1 10:07:20 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 01 Apr 2014 12:07:20 +0200
Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEAC068@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CEAAA44@DEWDFEMB12A.global.corp.sap>
	<533A7A0E.5040100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEAC068@DEWDFEMB12A.global.corp.sap>
Message-ID: <533A8FD8.3090400@oracle.com>

Hi Goetz,

On 2014-04-01 11:53, Lindenmaier, Goetz wrote:
>
> Hi Stefan,
>
> thanks for pointing me to that.
>
> I think I did that to break the chain at some point.
>
> But I only need to move two more functions so that all is
>
> in the .inline file:
>
> http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/webrev.01/ 
> <http://cr.openjdk.java.net/%7Egoetz/webrevs/8038498-incl/webrev.01/>
>

I see that you had to move the two G1CollectedHeap::is_obj_dead_cond 
functions out of g1CollectedHeap.hpp. I don't think they have to be 
inline functions, since they are only used by the verification code. 
Would you mind moving them to the g1CollectedHeap.cpp instead? Other 
than that, I think the patch looks good.

thanks!
StefanK

> Best regards,
>
>   Goetz.
>
> *From:*Stefan Karlsson [mailto:stefan.karlsson at oracle.com]
> *Sent:* Dienstag, 1. April 2014 10:34
> *To:* Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; 
> hotspot-gc-dev at openjdk.java.net
> *Subject:* Re: RFR(M): 8038498: Fix includes and C inlining after 8035330
>
> Hi Goetz,
>
> Thanks for fixing this!
>
> One comment below:
>
> On 2014-03-27 17:45, Lindenmaier, Goetz wrote:
>
>     Hi,
>
>     Please review and test this change.  I please need a sponsor:
>
>     http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/
>     <http://cr.openjdk.java.net/%7Egoetz/webrevs/8038498-incl/>
>
>
> http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html 
> <http://cr.openjdk.java.net/%7Egoetz/webrevs/8038498-incl/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html>
>
> I'm not sure what the performance implication is of moving these 
> functions to the .cpp file. Is there a reason why we wouldn't want to 
> put them in the g1CollectedHeap.inline.hpp file?
>
> thanks,
> StefanK
>
>
> Change 8035330: Remove G1ParScanPartialArrayClosure and 
> G1ParScanHeapEvacClosure
>
> broke the dbg build on AIX. That's because do_oop_partial_array() is 
> added in
>
> a header, but requires inline function par_write_ref() through several 
> inlined
>
> calls. In some cpp files, like arguments.cpp, par_write_ref() is not 
> defined
>
> as the corresponding inline header is not included.  The aix debug VM 
> does not start.
>
> This can be solved by including g1RemSet.inline.hpp in 
> g1CollectedHeap.inline.hpp.
>
> Unfortunately this now causes a cyclic dependency that breaks the 
> linux build.
>
> A inline.hpp file is included ahead of a .hpp file, so that the code 
> in the inline.hpp file
>
> can not see the class declaration.
>
> This is caused because g1CollectedHeap.inline.hpp is included in 
> sparsePRT.hpp.
>
> But .inline.hpp files never should be included in .hpp files.
>
> To resolve this, I changed this inlcude to g1CollectedHeap.hpp.  As 
> consequence,
>
> I had to move a row of functions to existing .inline.hpp files.
>
> I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64,
>
> sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up.
>
> Best regards,
>
>   Goetz
>

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

From goetz.lindenmaier at sap.com  Tue Apr  1 10:24:23 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 1 Apr 2014 10:24:23 +0000
Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
In-Reply-To: <533A8FD8.3090400@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CEAAA44@DEWDFEMB12A.global.corp.sap>
	<533A7A0E.5040100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEAC068@DEWDFEMB12A.global.corp.sap>
	<533A8FD8.3090400@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAC0A6@DEWDFEMB12A.global.corp.sap>

Sure!  I updated the webrev accordingly.

Best regards,
  Goetz.

From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com]
Sent: Dienstag, 1. April 2014 12:07
To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330

Hi Goetz,
On 2014-04-01 11:53, Lindenmaier, Goetz wrote:
Hi Stefan,

thanks for pointing me to that.
I think I did that to break the chain at some point.

But I only need to move two more functions so that all is
in the .inline file:
http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/webrev.01/<http://cr.openjdk.java.net/%7Egoetz/webrevs/8038498-incl/webrev.01/>

I see that you had to move the two G1CollectedHeap::is_obj_dead_cond functions out of g1CollectedHeap.hpp. I don't think they have to be inline functions, since they are only used by the verification code. Would you mind moving them to the g1CollectedHeap.cpp instead? Other than that, I think the patch looks good.

thanks!
StefanK



Best regards,
  Goetz.



From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com]
Sent: Dienstag, 1. April 2014 10:34
To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>; hotspot-gc-dev at openjdk.java.net<mailto:hotspot-gc-dev at openjdk.java.net>
Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330

Hi Goetz,

Thanks for fixing this!

One comment below:
On 2014-03-27 17:45, Lindenmaier, Goetz wrote:
Hi,

Please review and test this change.  I please need a sponsor:
http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/<http://cr.openjdk.java.net/%7Egoetz/webrevs/8038498-incl/>

http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html<http://cr.openjdk.java.net/%7Egoetz/webrevs/8038498-incl/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html>

I'm not sure what the performance implication is of moving these functions to the .cpp file. Is there a reason why we wouldn't want to put them in the g1CollectedHeap.inline.hpp file?

thanks,
StefanK




Change 8035330: Remove G1ParScanPartialArrayClosure and G1ParScanHeapEvacClosure
broke the dbg build on AIX. That's because do_oop_partial_array() is added in
a header, but requires inline function par_write_ref() through several inlined
calls. In some cpp files, like arguments.cpp, par_write_ref() is not defined
as the corresponding inline header is not included.  The aix debug VM does not start.

This can be solved by including g1RemSet.inline.hpp in g1CollectedHeap.inline.hpp.

Unfortunately this now causes a cyclic dependency that breaks the linux build.
A inline.hpp file is included ahead of a .hpp file, so that the code in the inline.hpp file
can not see the class declaration.
This is caused because g1CollectedHeap.inline.hpp is included in sparsePRT.hpp.
But .inline.hpp files never should be included in .hpp files.

To resolve this, I changed this inlcude to g1CollectedHeap.hpp.  As consequence,
I had to move a row of functions to existing .inline.hpp files.

I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64,
sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up.

Best regards,
  Goetz


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

From volker.simonis at gmail.com  Tue Apr  1 11:10:45 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 1 Apr 2014 13:10:45 +0200
Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
In-Reply-To: <533A6C6B.6090203@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CEABD3C@DEWDFEMB12A.global.corp.sap>
	<533A5681.20607@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEABFB5@DEWDFEMB12A.global.corp.sap>
	<533A6C6B.6090203@oracle.com>
Message-ID: <CA+3eh131dfH777XuNqfP+wF+bp7c0vCdKGxaEbhhEwKDektCwg@mail.gmail.com>

In C/C++ we have the fundamental problem that, as far as defined by
the standard, the compiler can only 'see' the things which are defined
in its current compilation unit where a compilation unit is defined by
a .cpp file together with all the files it includes.

That is exactly the reason why you should not declare a function 'F'
as "inline" in a header file (say "f.h") but define it in a .cpp file
(say "f.cpp"). This will make it impossible for a compiler to really
inline "F" in another compilation unit (say "g.cpp") which includes
"f.hpp" (but of course not "g.cpp").

One simple solution to overcome this problem is to not only declare
but to also define inline functions directly in their corresponding
header files. Unfortunately this only works for very small examples.
Once your program gets bigger, you'll get cyclic dependencies between
such header files. And that's actually clear, because defining
functions in a header file breaks the contract that header files
should contain interface declarations while .cpp files contain the
actual definitions (i.e. implementations).

So the next step (and the solution used in HotSpot) is to restrict
oneself to declarations in header files and place definitions which
are needed in more than one compilation unit into so called
".inline.hpp" files. These ".inline.hpp" include their corresponding
".hpp" files by default (because they actually implement something
which is declared in there - so they need access to it). On the other
hand, every compilation unit which requires a
definition/implementation of a class or function (and not only its
declaration) can now include that ".inline.hpp" file. And they don't
need to include the corresponding ".hpp" file, because the
".inline.hpp" already did that.

All that is the ideal world which would work perfectly fine.
Unfortunately, not all of the current HotSpot code adheres to these
conventions. The usual mistake people make is to define a very simple
inline function right in the header file (i.e. ".hpp") because it is
so simple and has no dependencies at all. But as time goes by, that
function grows, becomes more complicated and requires more and more
dependencies (i.e. ".inline.hpp" files). But instead of refactoring
such functions into their own ".inline.hpp" files, the ingenious
programmer naively includes the ".inline.hpp" file into the header.
And that's where it starts to get ugly!

All that said, there are a few things which influence the situation.
The first one is "precompiled headers". Precompiled headers are a
compiler hack which is not specified by the C/C++ standard and which
is implemented differently by different compilers with the only only
goal to speed up the compilation of a compilation unit. To achieve
this goal the compiler assumes that many compilation units contain a
lot of common code and therefore he "widens" the actual definition of
a "compilation unit" a little bit. With precompiled headers, the
compiler can see beyond its actual compilation unit because he sees
all the declarations and definitions from the precompiled header file
(or database or whatever) and not only the ones which are actually
transitively included by the current ".cpp" file. That's exactly the
reason why you don't realize missing dependencies if you only compile
with precompiled headers turned on (and why it is crucial to have a
sanity build without precompiled headers).

And there's yet another aspect to this: C++ templates. With templates
you have exactly the same problem like with inline functions - they
are declared in a header file, but their definition is potentially
required in several compilation units (actually everywhere they get
instantiated at). Now as long as the template functions are simple,
they can be defined right in their header files. But we will get very
fast to the point where the template definitions get more complicated
and where they would introduce cycles in the header files. Because
templates where specified later then the "inline mechanism" and the
designers were aware of the problem, they tried to somehow address
this within the language for examle with the "export" keyword.
Unfortunately this was not very successful and has meanwhile been
deprecated. As a consequence, a lot of techniques have been developed
to overcome these issues: put all template definitions into the
headers -> may lead to code bloat, use special template instantiation
files -> clumsy, compiler specific solutions like template
instantiation repositories -> proprietary.

One solution which always works and which is currently used in HotSpot
is to treat template definitions like the definition of inline
functions and place them into ".inline.hpp" files. We could of course
use ".template.hpp" but that's probably not worth the effort.

In the end, I absolutely agree with Stefan that we should add these
rules for the implementation of inline and template functions to the
corresponding HotSpot coding styles.

And finally I think that now, just at the beginning of the Java 9
development cycle, it is a perfect point in time to fix the current
code base where it violates these rules.

Regards,
Volker



On Tue, Apr 1, 2014 at 9:36 AM, David Holmes <david.holmes at oracle.com> wrote:
> On 1/04/2014 5:30 PM, Lindenmaier, Goetz wrote:
>>
>> Hi David,
>>
>>> Personally I don't see why a cpp file should have to be aware that a
>>> member function it uses just happens to have been defined in an
>>> inline.hpp file by its author. Seems to break encapsulation to me. :(
>>
>> Because the .cpp file will not compile if the .inline.hpp header with
>> the implementation is not visible during compilation.
>
>
> Understood - but there is more than one way to make the implementation
> visible to the cpp file eg cpp include .hpp and .hpp includes .inline.hpp (I
> suppose that is a "bad" thing to do?)
>
> And that still doesn't change the fact it is breaking encapsulation :)
>
>
>>> I see 277 occurrences of this in the existing OpenJDK hotspot code, so I
>>
>> There are a lot of .hpp files with include methods that don't have
>> a corresponding .inline.hpp file.  Like taskqueue.hpp, which includes
>> the atomic headers.  Would be nice if this was cleaned up.
>> Also, oop.inline.hpp often makes problems, because methods defined
>> there are used in .hpp files, which can not include oop.inline.hpp
>> as it causes cycles.  If you include that header in a cpp file, you also
>> have
>> to include oop.inline.hpp, which is really unintuitive.
>
>
> I find the inline situation to be unintuitive in general. There's a flow on
> affect that an inline function can't use other inline functions unless they
> all get moved to .inline.hpp files. I hope it is okay for one .inline.hpp
> file to include another one? Otherwise you have to expose the internal
> implementation detail of one class to its clients so they know which set of
> .inline.hpp files have to be included!
>
> Cheers,
> David
>
>
>> Best regards,
>>    Goetz.
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Dienstag, 1. April 2014 08:03
>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net;
>> hotspot-gc-dev at openjdk.java.net
>> Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330
>>
>> Hi Goetz,
>>
>> Not a review ...
>>
>> On 31/03/2014 10:42 PM, Lindenmaier, Goetz wrote:
>>>
>>> Hi,
>>>
>>> could I please get reviews for this change?  I please also need a
>>> sponsor.
>>> I would like to get this into 8u20, as 8036330 was downported, too.
>>>
>>> I'd like to make the point of this change clear once more, independent
>>> of which compiler does what.
>>>
>>> I think we agree that basically
>>>     - a file should include all headers that define symbols or include
>>>       method bodies used in that file
>>
>>
>> Personally I don't see why a cpp file should have to be aware that a
>> member function it uses just happens to have been defined in an
>> inline.hpp file by its author. Seems to break encapsulation to me. :(
>>
>>>     - a .hpp header should not include a .inline.hpp header
>>
>>
>> I see 277 occurrences of this in the existing OpenJDK hotspot code, so I
>> don't think we can take this as a general rule either.
>>
>> Note I'm not saying this fix isn't right or needed, just that the
>> "rules" you are trying to embody don't seem to generally apply.
>>
>> David
>> -----
>>
>>> This is violated
>>>
>>> 1.)    by defining
>>>    template <class T> void immediate_rs_update(HeapRegion* from, T* p,
>>> int tid) {
>>>      if (!from->is_survivor()) {
>>>         _g1_rem->par_write_ref(from, p, tid);
>>>       }
>>> }
>>>    in g1CollectedHeap.hpp, as par_write_ref in declared 'inline' and only
>>> defined in
>>>       g1RemSet.inline.hpp - which is not included and should not be
>>> included
>>>       in g1CollectedHeap.hpp.
>>> 2. by including g1CollectedHeap.inline.hpp in sparsePRT.hpp
>>>
>>> This change fixes these two points by moving functions into .inline.hpp
>>> files
>>> and fixing the include.
>>>
>>> Best regards,
>>>     Goetz.
>>>
>>>
>>>
>>>
>>> From: Lindenmaier, Goetz
>>> Sent: Donnerstag, 27. M?rz 2014 17:46
>>> To: hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
>>> Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
>>>
>>> Hi,
>>>
>>> Please review and test this change.  I please need a sponsor:
>>> http://cr.openjdk.java.net/~goetz/webrevs/8038498-incl/
>>>
>>> Change 8035330: Remove G1ParScanPartialArrayClosure and
>>> G1ParScanHeapEvacClosure
>>> broke the dbg build on AIX. That's because do_oop_partial_array() is
>>> added in
>>> a header, but requires inline function par_write_ref() through several
>>> inlined
>>> calls. In some cpp files, like arguments.cpp, par_write_ref() is not
>>> defined
>>> as the corresponding inline header is not included.  The aix debug VM
>>> does not start.
>>>
>>> This can be solved by including g1RemSet.inline.hpp in
>>> g1CollectedHeap.inline.hpp.
>>>
>>> Unfortunately this now causes a cyclic dependency that breaks the linux
>>> build.
>>> A inline.hpp file is included ahead of a .hpp file, so that the code in
>>> the inline.hpp file
>>> can not see the class declaration.
>>> This is caused because g1CollectedHeap.inline.hpp is included in
>>> sparsePRT.hpp.
>>> But .inline.hpp files never should be included in .hpp files.
>>>
>>> To resolve this, I changed this inlcude to g1CollectedHeap.hpp.  As
>>> consequence,
>>> I had to move a row of functions to existing .inline.hpp files.
>>>
>>> I did debug, fastdebug and product builds on linux_ppc64, aix_ppc64,
>>> sun_64, bsd_x86_64 and linux_x86_64 and tested that the VM starts up.
>>>
>>> Best regards,
>>>     Goetz
>>>
>


From jesper.wilhelmsson at oracle.com  Tue Apr  1 12:25:36 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 01 Apr 2014 14:25:36 +0200
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533A8141.2030608@oracle.com>
References: <5332FA20.5070607@oracle.com>
	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>
	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>
	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>
	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>
	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>
	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>
	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>
	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>
	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>
	<53394053.2070502@oracle.com> <533955B0.7000601@oracle.com>
	<533A6165.80704@oracle.com> <533A8141.2030608@oracle.com>
Message-ID: <533AB040.6000302@oracle.com>

Uploaded:

http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.10/

In general  would agree regarding avoiding duplicated code, but when it comes to 
the control flow I agree with Erik. More hard to read code leads to harder 
maintenance than duplicating a few lines of code.
/Jesper

Andrey Zakharov skrev 1/4/14 11:05:
> Hi, Erik. Thanks for comments.
>
> On 01.04.2014 10:49, Erik Helin wrote:
>> Andrey,
>>
>> a couple of comments:
>> - We do not use the @author tag in the tests
>>   (if you've seen other tests have the @author tag, then that is a bug)
> removed
>> - I'm not a big fan of using inheritance for sharing code between
>>   tests because it makes it very hard to open a test, e.g.
>>   TestHumongousShrinkHeap.java, and see what it does.
> Agreed, I'm too. But doubled code leads to harder maintenance.
>>
>>   The code you share in TestShrinkHeap is basically the check and the
>>   control flow of the tests. I would prefer if you could move the
>>   control flow (System.gc(), sample, eat, sample, free, check samples)
>>   into the tests and then write helper functions for retrieving the
>>   flag values.
>>
>>   As for the check, please use the assertions in
>>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>   throwing a RuntimeException.
> Good point, changed.
> Jesper, can we upload webrev.10 from attachment? Thanks.
> I'm still need GC reviewers to approve push.
>
> Thanks.
>>
>> Thanks,
>> Erik
>>
>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>> Hi,
>>>
>>> New webrev uploaded.
>>>
>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>
>>> I'm not a Reviewer either so if you got Igor's blessing already, my
>>> review won't be enough to push unfortunately.
>>> /Jesper
>>>
>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>> Hi,
>>>> Jepser, here is updated webrev.09
>>>> Thomas, Jesper can you review it as well?
>>>> Thanks.
>>>>
>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>> Andrey,
>>>>>
>>>>> 1. TEST.groups:
>>>>> please update copyright year:
>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All rights
>>>>>> reserved.
>>>>> should be
>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates. All
>>>>>> rights
>>>>>> reserved.
>>>>>
>>>>> 2. TestShrinkHeap.java
>>>>>>   22  */
>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>> add empty line between 22 and 23 as you do in all other files,
>>>>>
>>>>> otherwise it looks good to me.
>>>>>
>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in 'Reviewed-by'
>>>>> section )
>>>>>
>>>>> Thanks,
>>>>> Igor
>>>>>
>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>> Hi, team
>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>> Webrev uploaded:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>
>>>>>>> /Jesper
>>>>>> Thank you, Jesper.
>>>>>>
>>>>>>>
>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>> Hi! Here is webrev.08,
>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>
>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>
>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>> Andrey,
>>>>>>>>>
>>>>>>>>> 1. both tests:
>>>>>>>>>>   48     public void eat() {
>>>>>>>>>> 61     public void free() {
>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>  32  */
>>>>>>>>>>  33 import com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>> add empty line between these lines or remove empty line #32 in
>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>  62         //do not free last one list
>>>>>>>>> space after '//'
>>>>>>>>> 3. both tests:
>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>> after @bug you should specify product bug ids which can be tested by
>>>>>>>>> this
>>>>>>>>> test. I guess 8016479 instead of 8037924, and 8036025/8037925.
>>>>>>>>>
>>>>>>>>> otherwise it looks good, thank you for your work and patience )
>>>>>>>>>
>>>>>>>>> Igor
>>>>>>>>>
>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>
>>>>>>>>>> /Jesper
>>>>>>>>>>
>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>> Igor, please, see comment below, everything uncommented is done.
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()' 'TestShrinkHeap.gc()'?
>>>>>>>>>>> I cut this out.
>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for it --
>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>
>>>>>>>>>>> Not sure is it applicable for me, because every time in feature
>>>>>>>>>>> ticket
>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Igor
>>>>>>>>>>>>
>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to review. It
>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>  45     public static byte[] temp;
>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should have one
>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> protected static final String MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>> protected static final String MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() < muFull.getCommitted())) {
>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>       String.format("committed free heap size is not less than
>>>>>>>>>>>>>>> committed full heap size, heap hasn't been shrunk?%n%s =
>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(),
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue()
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full GC");
>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/
>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry for
>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary and just
>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 26  * @key gc
>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc', please don't
>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>> I think that this is used for test execution - to execute
>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, so we don't
>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/
>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct one is
>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/.
>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry for
>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>   44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's not
>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>   96 StringBuilder strb = new StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than committed
>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>   97 strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>   99 strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>  101             throw new
>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>  throw new RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap size, heap
>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue));
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/
>>>>>>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>


From erik.helin at oracle.com  Tue Apr  1 12:45:45 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Tue, 01 Apr 2014 14:45:45 +0200
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533A8141.2030608@oracle.com>
References: <5332FA20.5070607@oracle.com>
	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>
	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>
	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>
	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>
	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>
	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>
	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>
	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>
	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>
	<53394053.2070502@oracle.com> <533955B0.7000601@oracle.com>
	<533A6165.80704@oracle.com> <533A8141.2030608@oracle.com>
Message-ID: <533AB4F9.6090509@oracle.com>

On 2014-04-01 11:05, Andrey Zakharov wrote:
> Hi, Erik. Thanks for comments.
>
> On 01.04.2014 10:49, Erik Helin wrote:
>> Andrey,
>>
>> a couple of comments:
>> - We do not use the @author tag in the tests
>>   (if you've seen other tests have the @author tag, then that is a bug)
> removed
>> - I'm not a big fan of using inheritance for sharing code between
>>   tests because it makes it very hard to open a test, e.g.
>>   TestHumongousShrinkHeap.java, and see what it does.
> Agreed, I'm too. But doubled code leads to harder maintenance.

Duplicated code often leads to harder maintenance, but it is not the 
only thing making code hard to maintain. By using inheritance, you have 
moved the control flow from the test to another file. When I want to 
look at test test because it failed, I want to immediately see what it 
did. I do *not* want to traverse an inheritance hierarchy and build a 
mental model of how the control flows up and down in the inheritance 
hierarchy. It is very important that tests are explicit and clearly 
describe what they are testing.

Looking at the code in TestShrinkHeap::test:

public final void test() {
    System.gc();
    MemoryUsagePrinter.printMemoryUsage("init");

    eat();
    MemoryUsagePrinter.printMemoryUsage("eaten");
    MemoryUsage muFull =
        ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();

    free();
    MemoryUsagePrinter.printMemoryUsage("free");
    MemoryUsage muFree =
        ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();

    assertLessThan(muFree.getCommitted(), muFull.getCommitted(),
                   ...));
}

You can easily move the control flow back into tests and share code with 
utility classes, for example:

public class TestHumongousShrinkHeap {
     ....

     private void eat() {
         // old eat code
         ShrinkHeapUtils.log("eat");
     }

     private void free() {
        // old free code
        ShrinkHeapUtils.log("free");
     }

     public final void test() {
         System.gc();
         ShrinkHeapUtils.log("init");

         eat();
         MemoryUsage full = ShrinkHeapUtils.getMemoryUsage();

         free();
         MemoryUsage free = ShrinkHeapUtils.getMemoryUsage();

         ShrinkHeapUtils.assertLessThan(free, full);
     }
}

Now you can move the code from TestShrinkHeap to ShrinkHeapUtils. You 
are now duplicating the call to System.gc(), the calls to eat and free, 
the log calls, the getMemoryUsage calls and the assert. That is nine 
lines of code.

Duplicating nine lines of code and being able to see the flow in the 
test itself is better than sharing the nine lines of code and not being 
able to see the what test is doing.

Thanks,
Erik

>>
>>   The code you share in TestShrinkHeap is basically the check and the
>>   control flow of the tests. I would prefer if you could move the
>>   control flow (System.gc(), sample, eat, sample, free, check samples)
>>   into the tests and then write helper functions for retrieving the
>>   flag values.
>>
>>   As for the check, please use the assertions in
>>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>   throwing a RuntimeException.
> Good point, changed.
> Jesper, can we upload webrev.10 from attachment? Thanks.
> I'm still need GC reviewers to approve push.
>
> Thanks.
>>
>> Thanks,
>> Erik
>>
>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>> Hi,
>>>
>>> New webrev uploaded.
>>>
>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>
>>> I'm not a Reviewer either so if you got Igor's blessing already, my
>>> review won't be enough to push unfortunately.
>>> /Jesper
>>>
>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>> Hi,
>>>> Jepser, here is updated webrev.09
>>>> Thomas, Jesper can you review it as well?
>>>> Thanks.
>>>>
>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>> Andrey,
>>>>>
>>>>> 1. TEST.groups:
>>>>> please update copyright year:
>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All rights
>>>>>> reserved.
>>>>> should be
>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates. All
>>>>>> rights
>>>>>> reserved.
>>>>>
>>>>> 2. TestShrinkHeap.java
>>>>>>   22  */
>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>> add empty line between 22 and 23 as you do in all other files,
>>>>>
>>>>> otherwise it looks good to me.
>>>>>
>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in
>>>>> 'Reviewed-by'
>>>>> section )
>>>>>
>>>>> Thanks,
>>>>> Igor
>>>>>
>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>> Hi, team
>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>> Webrev uploaded:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>
>>>>>>> /Jesper
>>>>>> Thank you, Jesper.
>>>>>>
>>>>>>>
>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>> Hi! Here is webrev.08,
>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>
>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>
>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>> Andrey,
>>>>>>>>>
>>>>>>>>> 1. both tests:
>>>>>>>>>>   48     public void eat() {
>>>>>>>>>> 61     public void free() {
>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>  32  */
>>>>>>>>>>  33 import com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>> add empty line between these lines or remove empty line #32 in
>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>  62         //do not free last one list
>>>>>>>>> space after '//'
>>>>>>>>> 3. both tests:
>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>> after @bug you should specify product bug ids which can be
>>>>>>>>> tested by
>>>>>>>>> this
>>>>>>>>> test. I guess 8016479 instead of 8037924, and 8036025/8037925.
>>>>>>>>>
>>>>>>>>> otherwise it looks good, thank you for your work and patience )
>>>>>>>>>
>>>>>>>>> Igor
>>>>>>>>>
>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>
>>>>>>>>>> /Jesper
>>>>>>>>>>
>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>> Igor, please, see comment below, everything uncommented is done.
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()' 'TestShrinkHeap.gc()'?
>>>>>>>>>>> I cut this out.
>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for it --
>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>
>>>>>>>>>>> Not sure is it applicable for me, because every time in feature
>>>>>>>>>>> ticket
>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Igor
>>>>>>>>>>>>
>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to review. It
>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>  45     public static byte[] temp;
>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should have one
>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> protected static final String MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>> protected static final String MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() < muFull.getCommitted())) {
>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>       String.format("committed free heap size is not less
>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>> committed full heap size, heap hasn't been shrunk?%n%s =
>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(),
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue()
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full GC");
>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/
>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry for
>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary and just
>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 26  * @key gc
>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc', please
>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>> I think that this is used for test execution - to execute
>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, so we
>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/
>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct one is
>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry for
>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>   44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's not
>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>   96 StringBuilder strb = new
>>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than committed
>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>   97
>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>   99
>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>  101             throw new
>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>  throw new RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap size,
>>>>>>>>>>>>>>>>>>>>> heap
>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue));
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/
>>>>>>>>>>>>>>>>>>>>>>> bug:
>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>


From thomas.schatzl at oracle.com  Tue Apr  1 12:57:11 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 01 Apr 2014 14:57:11 +0200
Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEAC0A6@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CEAAA44@DEWDFEMB12A.global.corp.sap>
	<533A7A0E.5040100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEAC068@DEWDFEMB12A.global.corp.sap>
	<533A8FD8.3090400@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEAC0A6@DEWDFEMB12A.global.corp.sap>
Message-ID: <1396357031.2707.13.camel@cirrus>

Hi Goetz,

On Tue, 2014-04-01 at 10:24 +0000, Lindenmaier, Goetz wrote:
> Sure!  I updated the webrev accordingly.

  looks good to me.

I will sponsor the change.

Thanks,
  Thomas




From goetz.lindenmaier at sap.com  Tue Apr  1 13:07:59 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 1 Apr 2014 13:07:59 +0000
Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
In-Reply-To: <1396357031.2707.13.camel@cirrus>
References: <4295855A5C1DE049A61835A1887419CC2CEAAA44@DEWDFEMB12A.global.corp.sap>
	<533A7A0E.5040100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEAC068@DEWDFEMB12A.global.corp.sap>
	<533A8FD8.3090400@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEAC0A6@DEWDFEMB12A.global.corp.sap>
	<1396357031.2707.13.camel@cirrus>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAC15F@DEWDFEMB12A.global.corp.sap>

Thanks a lot, Thomas!

Best regards,
  Goetz.

-----Original Message-----
From: Thomas Schatzl [mailto:thomas.schatzl at oracle.com] 
Sent: Dienstag, 1. April 2014 14:57
To: Lindenmaier, Goetz
Cc: hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330

Hi Goetz,

On Tue, 2014-04-01 at 10:24 +0000, Lindenmaier, Goetz wrote:
> Sure!  I updated the webrev accordingly.

  looks good to me.

I will sponsor the change.

Thanks,
  Thomas



From igor.ignatyev at oracle.com  Tue Apr  1 13:24:57 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 01 Apr 2014 17:24:57 +0400
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533AB4F9.6090509@oracle.com>
References: <5332FA20.5070607@oracle.com>
	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>
	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>
	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>
	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>
	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>
	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>
	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>
	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>
	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>
	<53394053.2070502@oracle.com> <533955B0.7000601@oracle.com>
	<533A6165.80704@oracle.com> <533A8141.2030608@oracle.com>
	<533AB4F9.6090509@oracle.com>
Message-ID: <533ABE29.30805@oracle.com>

Erik/Jesper,

g1/TestHumongousShrinkHeap, parallelScavenge/TestDynShrinkHeap are test 
cases of TestShrinkHeap, so they suppose to share control flow, or more 
precisely they shouldn't contain control-flow.

let's say they just specify function in TestShrinkHeap:
> TestShrinkHeap {
>  Runnable eat;
>  Runnable free;
>  TestShrinkHeap(Runnable eat, Runnable free) { ... }
>  void test() {
>     System.gc();
>     MemoryUsagePrinter.printMemoryUsage("init");
>
>     eat.run();
>     MemoryUsagePrinter.printMemoryUsage("eaten");
>     MemoryUsage muFull =
>         ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>
>     free.run();
>     MemoryUsagePrinter.printMemoryUsage("free");
>     MemoryUsage muFree =
>         ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>
>     assertLessThan(muFree.getCommitted(), muFull.getCommitted(),
>                    ...));
>
>  }
> }

then g1/TestHumongousShrinkHeap is
new TestShrinkHeap(
()->{
> int HumongousObjectSize = Math.round(.9f * PAGE_SIZE);
>   51         System.out.println("Will allocate objects of size=" +
>   52                 MemoryUsagePrinter.humanReadableByteCount(HumongousObjectSize, true));
>   53
>   54         for (int i = 0; i < PAGES_NUM; i++) {
>   55             ArrayList<byte[]> stuff = new ArrayList<>();
>   56             eatList(stuff, 100, HumongousObjectSize);
>   57             MemoryUsagePrinter.printMemoryUsage("eat #" + i);
>   58             garbage.add(stuff);
>   59         }
},
()->{
>   63         // do not free last one list
>   64         garbage.subList(0, garbage.size() - 1).clear();
>   65
>   66         // do not free last one element from last list
>   67         ArrayList stuff = garbage.get(garbage.size() - 1);
>   68         stuff.subList(0, stuff.size() - 1).clear();
>   69         System.gc();
}

from my point of view, it's quite simple to understand and maintain (of 
course if we replace lambdas by method references), and it's much easier 
to write add new test-cases and extend test's logic.

however, it's just a question of code-style and preferences. Since these 
tests are gc tests, it's up to you to decide how to write better.

Igor

On 04/01/2014 04:45 PM, Erik Helin wrote:
> On 2014-04-01 11:05, Andrey Zakharov wrote:
>> Hi, Erik. Thanks for comments.
>>
>> On 01.04.2014 10:49, Erik Helin wrote:
>>> Andrey,
>>>
>>> a couple of comments:
>>> - We do not use the @author tag in the tests
>>>   (if you've seen other tests have the @author tag, then that is a bug)
>> removed
>>> - I'm not a big fan of using inheritance for sharing code between
>>>   tests because it makes it very hard to open a test, e.g.
>>>   TestHumongousShrinkHeap.java, and see what it does.
>> Agreed, I'm too. But doubled code leads to harder maintenance.
>
> Duplicated code often leads to harder maintenance, but it is not the
> only thing making code hard to maintain. By using inheritance, you have
> moved the control flow from the test to another file. When I want to
> look at test test because it failed, I want to immediately see what it
> did. I do *not* want to traverse an inheritance hierarchy and build a
> mental model of how the control flows up and down in the inheritance
> hierarchy. It is very important that tests are explicit and clearly
> describe what they are testing.
>
> Looking at the code in TestShrinkHeap::test:
>
> public final void test() {
>     System.gc();
>     MemoryUsagePrinter.printMemoryUsage("init");
>
>     eat();
>     MemoryUsagePrinter.printMemoryUsage("eaten");
>     MemoryUsage muFull =
>         ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>
>     free();
>     MemoryUsagePrinter.printMemoryUsage("free");
>     MemoryUsage muFree =
>         ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>
>     assertLessThan(muFree.getCommitted(), muFull.getCommitted(),
>                    ...));
> }
>
> You can easily move the control flow back into tests and share code with
> utility classes, for example:
>
> public class TestHumongousShrinkHeap {
>      ....
>
>      private void eat() {
>          // old eat code
>          ShrinkHeapUtils.log("eat");
>      }
>
>      private void free() {
>         // old free code
>         ShrinkHeapUtils.log("free");
>      }
>
>      public final void test() {
>          System.gc();
>          ShrinkHeapUtils.log("init");
>
>          eat();
>          MemoryUsage full = ShrinkHeapUtils.getMemoryUsage();
>
>          free();
>          MemoryUsage free = ShrinkHeapUtils.getMemoryUsage();
>
>          ShrinkHeapUtils.assertLessThan(free, full);
>      }
> }
>
> Now you can move the code from TestShrinkHeap to ShrinkHeapUtils. You
> are now duplicating the call to System.gc(), the calls to eat and free,
> the log calls, the getMemoryUsage calls and the assert. That is nine
> lines of code.
>
> Duplicating nine lines of code and being able to see the flow in the
> test itself is better than sharing the nine lines of code and not being
> able to see the what test is doing.
>
> Thanks,
> Erik
>
>>>
>>>   The code you share in TestShrinkHeap is basically the check and the
>>>   control flow of the tests. I would prefer if you could move the
>>>   control flow (System.gc(), sample, eat, sample, free, check samples)
>>>   into the tests and then write helper functions for retrieving the
>>>   flag values.
>>>
>>>   As for the check, please use the assertions in
>>>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>>   throwing a RuntimeException.
>> Good point, changed.
>> Jesper, can we upload webrev.10 from attachment? Thanks.
>> I'm still need GC reviewers to approve push.
>>
>> Thanks.
>>>
>>> Thanks,
>>> Erik
>>>
>>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>>> Hi,
>>>>
>>>> New webrev uploaded.
>>>>
>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>>
>>>> I'm not a Reviewer either so if you got Igor's blessing already, my
>>>> review won't be enough to push unfortunately.
>>>> /Jesper
>>>>
>>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>>> Hi,
>>>>> Jepser, here is updated webrev.09
>>>>> Thomas, Jesper can you review it as well?
>>>>> Thanks.
>>>>>
>>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>>> Andrey,
>>>>>>
>>>>>> 1. TEST.groups:
>>>>>> please update copyright year:
>>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All rights
>>>>>>> reserved.
>>>>>> should be
>>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates. All
>>>>>>> rights
>>>>>>> reserved.
>>>>>>
>>>>>> 2. TestShrinkHeap.java
>>>>>>>   22  */
>>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>>> add empty line between 22 and 23 as you do in all other files,
>>>>>>
>>>>>> otherwise it looks good to me.
>>>>>>
>>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in
>>>>>> 'Reviewed-by'
>>>>>> section )
>>>>>>
>>>>>> Thanks,
>>>>>> Igor
>>>>>>
>>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>>> Hi, team
>>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>>> Webrev uploaded:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>
>>>>>>>> /Jesper
>>>>>>> Thank you, Jesper.
>>>>>>>
>>>>>>>>
>>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>>> Hi! Here is webrev.08,
>>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>>
>>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>>
>>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>>> Andrey,
>>>>>>>>>>
>>>>>>>>>> 1. both tests:
>>>>>>>>>>>   48     public void eat() {
>>>>>>>>>>> 61     public void free() {
>>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>>  32  */
>>>>>>>>>>>  33 import com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>>> add empty line between these lines or remove empty line #32 in
>>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>>  62         //do not free last one list
>>>>>>>>>> space after '//'
>>>>>>>>>> 3. both tests:
>>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>>> after @bug you should specify product bug ids which can be
>>>>>>>>>> tested by
>>>>>>>>>> this
>>>>>>>>>> test. I guess 8016479 instead of 8037924, and 8036025/8037925.
>>>>>>>>>>
>>>>>>>>>> otherwise it looks good, thank you for your work and patience )
>>>>>>>>>>
>>>>>>>>>> Igor
>>>>>>>>>>
>>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>>
>>>>>>>>>>> /Jesper
>>>>>>>>>>>
>>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>>> Igor, please, see comment below, everything uncommented is
>>>>>>>>>>>> done.
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()' 'TestShrinkHeap.gc()'?
>>>>>>>>>>>> I cut this out.
>>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for it --
>>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>>
>>>>>>>>>>>> Not sure is it applicable for me, because every time in feature
>>>>>>>>>>>> ticket
>>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to review. It
>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>  45     public static byte[] temp;
>>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should have one
>>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> protected static final String MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>>> protected static final String MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() < muFull.getCommitted())) {
>>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>>       String.format("committed free heap size is not less
>>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>>> committed full heap size, heap hasn't been shrunk?%n%s =
>>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(),
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue()
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full GC");
>>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/
>>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry
>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary and just
>>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 26  * @key gc
>>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc', please
>>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>> I think that this is used for test execution - to
>>>>>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, so we
>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct one is
>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry
>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>>   44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's not
>>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>   96 StringBuilder strb = new
>>>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than committed
>>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>>   97
>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>   99
>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>  101             throw new
>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>>  throw new RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap size,
>>>>>>>>>>>>>>>>>>>>>> heap
>>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue));
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> bug:
>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>


From erik.helin at oracle.com  Tue Apr  1 14:05:56 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Tue, 01 Apr 2014 16:05:56 +0200
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533ABE29.30805@oracle.com>
References: <5332FA20.5070607@oracle.com>
	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>
	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>
	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>
	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>
	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>
	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>
	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>
	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>
	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>
	<53394053.2070502@oracle.com> <533955B0.7000601@oracle.com>
	<533A6165.80704@oracle.com> <533A8141.2030608@oracle.com>
	<533AB4F9.6090509@oracle.com> <533ABE29.30805@oracle.com>
Message-ID: <533AC7C4.9010909@oracle.com>

Igor,

On 2014-04-01 15:24, Igor Ignatyev wrote:
> Erik/Jesper,
>
> g1/TestHumongousShrinkHeap, parallelScavenge/TestDynShrinkHeap are test
> cases of TestShrinkHeap, so they suppose to share control flow, or more
> precisely they shouldn't contain control-flow.

As you can see in my previous email, I disagree. Each tests should 
contain control flow and we should not use inheritance.

>
> let's say they just specify function in TestShrinkHeap:
>> TestShrinkHeap {
>>  Runnable eat;
>>  Runnable free;
>>  TestShrinkHeap(Runnable eat, Runnable free) { ... }
>>  void test() {
>>     System.gc();
>>     MemoryUsagePrinter.printMemoryUsage("init");
>>
>>     eat.run();
>>     MemoryUsagePrinter.printMemoryUsage("eaten");
>>     MemoryUsage muFull =
>>         ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>
>>     free.run();
>>     MemoryUsagePrinter.printMemoryUsage("free");
>>     MemoryUsage muFree =
>>         ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>
>>     assertLessThan(muFree.getCommitted(), muFull.getCommitted(),
>>                    ...));
>>
>>  }
>> }
>
> then g1/TestHumongousShrinkHeap is
> new TestShrinkHeap(
> ()->{
>> int HumongousObjectSize = Math.round(.9f * PAGE_SIZE);
>>   51         System.out.println("Will allocate objects of size=" +
>>   52
>> MemoryUsagePrinter.humanReadableByteCount(HumongousObjectSize, true));
>>   53
>>   54         for (int i = 0; i < PAGES_NUM; i++) {
>>   55             ArrayList<byte[]> stuff = new ArrayList<>();
>>   56             eatList(stuff, 100, HumongousObjectSize);
>>   57             MemoryUsagePrinter.printMemoryUsage("eat #" + i);
>>   58             garbage.add(stuff);
>>   59         }
> },
> ()->{
>>   63         // do not free last one list
>>   64         garbage.subList(0, garbage.size() - 1).clear();
>>   65
>>   66         // do not free last one element from last list
>>   67         ArrayList stuff = garbage.get(garbage.size() - 1);
>>   68         stuff.subList(0, stuff.size() - 1).clear();
>>   69         System.gc();
> }
>
> from my point of view, it's quite simple to understand and maintain (of
> course if we replace lambdas by method references), and it's much easier
> to write add new test-cases and extend test's logic.

 From my point of view, using inheritance makes this harder to 
understand :).

> however, it's just a question of code-style and preferences. Since these
> tests are gc tests, it's up to you to decide how to write better.

I would prefer if we could avoid using inheritance in this case (note 
that there might be other cases where it is suitable to use inheritance).

Thanks,
Erik

> Igor
>
> On 04/01/2014 04:45 PM, Erik Helin wrote:
>> On 2014-04-01 11:05, Andrey Zakharov wrote:
>>> Hi, Erik. Thanks for comments.
>>>
>>> On 01.04.2014 10:49, Erik Helin wrote:
>>>> Andrey,
>>>>
>>>> a couple of comments:
>>>> - We do not use the @author tag in the tests
>>>>   (if you've seen other tests have the @author tag, then that is a bug)
>>> removed
>>>> - I'm not a big fan of using inheritance for sharing code between
>>>>   tests because it makes it very hard to open a test, e.g.
>>>>   TestHumongousShrinkHeap.java, and see what it does.
>>> Agreed, I'm too. But doubled code leads to harder maintenance.
>>
>> Duplicated code often leads to harder maintenance, but it is not the
>> only thing making code hard to maintain. By using inheritance, you have
>> moved the control flow from the test to another file. When I want to
>> look at test test because it failed, I want to immediately see what it
>> did. I do *not* want to traverse an inheritance hierarchy and build a
>> mental model of how the control flows up and down in the inheritance
>> hierarchy. It is very important that tests are explicit and clearly
>> describe what they are testing.
>>
>> Looking at the code in TestShrinkHeap::test:
>>
>> public final void test() {
>>     System.gc();
>>     MemoryUsagePrinter.printMemoryUsage("init");
>>
>>     eat();
>>     MemoryUsagePrinter.printMemoryUsage("eaten");
>>     MemoryUsage muFull =
>>         ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>
>>     free();
>>     MemoryUsagePrinter.printMemoryUsage("free");
>>     MemoryUsage muFree =
>>         ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>
>>     assertLessThan(muFree.getCommitted(), muFull.getCommitted(),
>>                    ...));
>> }
>>
>> You can easily move the control flow back into tests and share code with
>> utility classes, for example:
>>
>> public class TestHumongousShrinkHeap {
>>      ....
>>
>>      private void eat() {
>>          // old eat code
>>          ShrinkHeapUtils.log("eat");
>>      }
>>
>>      private void free() {
>>         // old free code
>>         ShrinkHeapUtils.log("free");
>>      }
>>
>>      public final void test() {
>>          System.gc();
>>          ShrinkHeapUtils.log("init");
>>
>>          eat();
>>          MemoryUsage full = ShrinkHeapUtils.getMemoryUsage();
>>
>>          free();
>>          MemoryUsage free = ShrinkHeapUtils.getMemoryUsage();
>>
>>          ShrinkHeapUtils.assertLessThan(free, full);
>>      }
>> }
>>
>> Now you can move the code from TestShrinkHeap to ShrinkHeapUtils. You
>> are now duplicating the call to System.gc(), the calls to eat and free,
>> the log calls, the getMemoryUsage calls and the assert. That is nine
>> lines of code.
>>
>> Duplicating nine lines of code and being able to see the flow in the
>> test itself is better than sharing the nine lines of code and not being
>> able to see the what test is doing.
>>
>> Thanks,
>> Erik
>>
>>>>
>>>>   The code you share in TestShrinkHeap is basically the check and the
>>>>   control flow of the tests. I would prefer if you could move the
>>>>   control flow (System.gc(), sample, eat, sample, free, check samples)
>>>>   into the tests and then write helper functions for retrieving the
>>>>   flag values.
>>>>
>>>>   As for the check, please use the assertions in
>>>>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>>>   throwing a RuntimeException.
>>> Good point, changed.
>>> Jesper, can we upload webrev.10 from attachment? Thanks.
>>> I'm still need GC reviewers to approve push.
>>>
>>> Thanks.
>>>>
>>>> Thanks,
>>>> Erik
>>>>
>>>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>>>> Hi,
>>>>>
>>>>> New webrev uploaded.
>>>>>
>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>>>
>>>>> I'm not a Reviewer either so if you got Igor's blessing already, my
>>>>> review won't be enough to push unfortunately.
>>>>> /Jesper
>>>>>
>>>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>>>> Hi,
>>>>>> Jepser, here is updated webrev.09
>>>>>> Thomas, Jesper can you review it as well?
>>>>>> Thanks.
>>>>>>
>>>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>>>> Andrey,
>>>>>>>
>>>>>>> 1. TEST.groups:
>>>>>>> please update copyright year:
>>>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All rights
>>>>>>>> reserved.
>>>>>>> should be
>>>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates. All
>>>>>>>> rights
>>>>>>>> reserved.
>>>>>>>
>>>>>>> 2. TestShrinkHeap.java
>>>>>>>>   22  */
>>>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>>>> add empty line between 22 and 23 as you do in all other files,
>>>>>>>
>>>>>>> otherwise it looks good to me.
>>>>>>>
>>>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in
>>>>>>> 'Reviewed-by'
>>>>>>> section )
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Igor
>>>>>>>
>>>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>>>> Hi, team
>>>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>>>> Webrev uploaded:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>
>>>>>>>>> /Jesper
>>>>>>>> Thank you, Jesper.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>>>> Hi! Here is webrev.08,
>>>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>>>
>>>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>>>
>>>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>>>> Andrey,
>>>>>>>>>>>
>>>>>>>>>>> 1. both tests:
>>>>>>>>>>>>   48     public void eat() {
>>>>>>>>>>>> 61     public void free() {
>>>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>>>  32  */
>>>>>>>>>>>>  33 import com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>>>> add empty line between these lines or remove empty line #32 in
>>>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>>>  62         //do not free last one list
>>>>>>>>>>> space after '//'
>>>>>>>>>>> 3. both tests:
>>>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>>>> after @bug you should specify product bug ids which can be
>>>>>>>>>>> tested by
>>>>>>>>>>> this
>>>>>>>>>>> test. I guess 8016479 instead of 8037924, and 8036025/8037925.
>>>>>>>>>>>
>>>>>>>>>>> otherwise it looks good, thank you for your work and patience )
>>>>>>>>>>>
>>>>>>>>>>> Igor
>>>>>>>>>>>
>>>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>>>
>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>
>>>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>>>> Igor, please, see comment below, everything uncommented is
>>>>>>>>>>>>> done.
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()' 'TestShrinkHeap.gc()'?
>>>>>>>>>>>>> I cut this out.
>>>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for it --
>>>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Not sure is it applicable for me, because every time in
>>>>>>>>>>>>> feature
>>>>>>>>>>>>> ticket
>>>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to
>>>>>>>>>>>>>>>> review. It
>>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>  45     public static byte[] temp;
>>>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should have one
>>>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> protected static final String MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>>>> protected static final String MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() < muFull.getCommitted())) {
>>>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>>>       String.format("committed free heap size is not less
>>>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>>>> committed full heap size, heap hasn't been shrunk?%n%s =
>>>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(),
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue()
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full GC");
>>>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/
>>>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry
>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary and
>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 26  * @key gc
>>>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc', please
>>>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>> I think that this is used for test execution - to
>>>>>>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, so we
>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct one is
>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry
>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>>>   44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's not
>>>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>>   96 StringBuilder strb = new
>>>>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than committed
>>>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>>>   97
>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>   99
>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>  101             throw new
>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>>>  throw new RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap size,
>>>>>>>>>>>>>>>>>>>>>>> heap
>>>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue));
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> bug:
>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>


From erik.helin at oracle.com  Tue Apr  1 15:22:31 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Tue, 01 Apr 2014 17:22:31 +0200
Subject: RFR: 8035667: EventMetaspaceSummary doesn't report committed
	Metaspace memory
In-Reply-To: <5335A704.30708@oracle.com>
References: <53358CA5.4060008@oracle.com> <5335A704.30708@oracle.com>
Message-ID: <533AD9B7.5070505@oracle.com>

On 2014-03-28 17:44, Jon Masamitsu wrote:
>
> On 3/28/2014 7:52 AM, Erik Helin wrote:
>> Hi all,
>>
>> this small patch makes the the trace event
>> vm/gc/heap/metaspace_summary report the amount of committed memory
>> instead of capacity. In the metaspace code, committed is used in all
>> places except one (and that will soon change) when making decisions
>> about sizing etc, therefore it makes much more sense that the trace
>> event reports the amount of committed memory.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ehelin/8035667/webrev.00/
>
> Changes look good.

Thanks!

> You changed the name allocated_capacity_bytes() to
> committed_bytes().  That was an appropriate change.
> Would you also consider changing allocated_used_bytes()
> to used_bytes()?

Sure, that is a great idea! I did as a separate change though, please 
see the thread "RFR: 8038934: Remove prefix allocated_ from methods and 
variables in Metaspace" on hotspot-dev at openjdk.java.net.

Thanks,
Erik

> The "allocated_" in the name was an
> effort to distinguish these two methods from
> capacity_bytes() and used_bytes() which have since
> changed names.
>
> Jon
>
>>
>> Testing:
>> - Running JTREG JFR tests.
>>
>> Thanks,
>> Erik
>


From erik.helin at oracle.com  Tue Apr  1 15:23:17 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Tue, 01 Apr 2014 17:23:17 +0200
Subject: RFR: 8035667: EventMetaspaceSummary doesn't report committed
	Metaspace memory
In-Reply-To: <53358F33.9030001@oracle.com>
References: <53358CA5.4060008@oracle.com> <53358F33.9030001@oracle.com>
Message-ID: <533AD9E5.5040101@oracle.com>

On 2014-03-28 16:03, Stefan Karlsson wrote:
>
> On 2014-03-28 15:52, Erik Helin wrote:
>> Hi all,
>>
>> this small patch makes the the trace event
>> vm/gc/heap/metaspace_summary report the amount of committed memory
>> instead of capacity. In the metaspace code, committed is used in all
>> places except one (and that will soon change) when making decisions
>> about sizing etc, therefore it makes much more sense that the trace
>> event reports the amount of committed memory.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ehelin/8035667/webrev.00/
>
> Looks good.

Thanks!
Erik

> thanks,
> StefanK
>>
>> Testing:
>> - Running JTREG JFR tests.
>>
>> Thanks,
>> Erik
>


From jon.masamitsu at oracle.com  Tue Apr  1 20:44:27 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 01 Apr 2014 13:44:27 -0700
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533ABE29.30805@oracle.com>
References: <5332FA20.5070607@oracle.com>	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>	<53394053.2070502@oracle.com>
	<533955B0.7000601@oracle.com>	<533A6165.80704@oracle.com>
	<533A8141.2030608@oracle.com>	<533AB4F9.6090509@oracle.com>
	<533ABE29.30805@oracle.com>
Message-ID: <533B252B.9080806@oracle.com>

Igor,

If I see a test failure of TestDynShrinkHeap, I need to understand
what that test is doing.  My recent experience (nightly testing)
tells me that I will easily be able to look at
TestDynShrinkHeap.java but maybe not much
more.

Given the current implementation of these tests, what will I need
to do to understand what TestDynShrinkHeap is doing?

Jon


On 4/1/14 6:24 AM, Igor Ignatyev wrote:
> Erik/Jesper,
>
> g1/TestHumongousShrinkHeap, parallelScavenge/TestDynShrinkHeap are 
> test cases of TestShrinkHeap, so they suppose to share control flow, 
> or more precisely they shouldn't contain control-flow.
>
> let's say they just specify function in TestShrinkHeap:
>> TestShrinkHeap {
>>  Runnable eat;
>>  Runnable free;
>>  TestShrinkHeap(Runnable eat, Runnable free) { ... }
>>  void test() {
>>     System.gc();
>>     MemoryUsagePrinter.printMemoryUsage("init");
>>
>>     eat.run();
>>     MemoryUsagePrinter.printMemoryUsage("eaten");
>>     MemoryUsage muFull =
>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>
>>     free.run();
>>     MemoryUsagePrinter.printMemoryUsage("free");
>>     MemoryUsage muFree =
>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>
>>     assertLessThan(muFree.getCommitted(), muFull.getCommitted(),
>>                    ...));
>>
>>  }
>> }
>
> then g1/TestHumongousShrinkHeap is
> new TestShrinkHeap(
> ()->{
>> int HumongousObjectSize = Math.round(.9f * PAGE_SIZE);
>>   51         System.out.println("Will allocate objects of size=" +
>>   52 MemoryUsagePrinter.humanReadableByteCount(HumongousObjectSize, 
>> true));
>>   53
>>   54         for (int i = 0; i < PAGES_NUM; i++) {
>>   55             ArrayList<byte[]> stuff = new ArrayList<>();
>>   56             eatList(stuff, 100, HumongousObjectSize);
>>   57             MemoryUsagePrinter.printMemoryUsage("eat #" + i);
>>   58             garbage.add(stuff);
>>   59         }
> },
> ()->{
>>   63         // do not free last one list
>>   64         garbage.subList(0, garbage.size() - 1).clear();
>>   65
>>   66         // do not free last one element from last list
>>   67         ArrayList stuff = garbage.get(garbage.size() - 1);
>>   68         stuff.subList(0, stuff.size() - 1).clear();
>>   69         System.gc();
> }
>
> from my point of view, it's quite simple to understand and maintain 
> (of course if we replace lambdas by method references), and it's much 
> easier to write add new test-cases and extend test's logic.
>
> however, it's just a question of code-style and preferences. Since 
> these tests are gc tests, it's up to you to decide how to write better.
>
> Igor
>
> On 04/01/2014 04:45 PM, Erik Helin wrote:
>> On 2014-04-01 11:05, Andrey Zakharov wrote:
>>> Hi, Erik. Thanks for comments.
>>>
>>> On 01.04.2014 10:49, Erik Helin wrote:
>>>> Andrey,
>>>>
>>>> a couple of comments:
>>>> - We do not use the @author tag in the tests
>>>>   (if you've seen other tests have the @author tag, then that is a 
>>>> bug)
>>> removed
>>>> - I'm not a big fan of using inheritance for sharing code between
>>>>   tests because it makes it very hard to open a test, e.g.
>>>>   TestHumongousShrinkHeap.java, and see what it does.
>>> Agreed, I'm too. But doubled code leads to harder maintenance.
>>
>> Duplicated code often leads to harder maintenance, but it is not the
>> only thing making code hard to maintain. By using inheritance, you have
>> moved the control flow from the test to another file. When I want to
>> look at test test because it failed, I want to immediately see what it
>> did. I do *not* want to traverse an inheritance hierarchy and build a
>> mental model of how the control flows up and down in the inheritance
>> hierarchy. It is very important that tests are explicit and clearly
>> describe what they are testing.
>>
>> Looking at the code in TestShrinkHeap::test:
>>
>> public final void test() {
>>     System.gc();
>>     MemoryUsagePrinter.printMemoryUsage("init");
>>
>>     eat();
>>     MemoryUsagePrinter.printMemoryUsage("eaten");
>>     MemoryUsage muFull =
>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>
>>     free();
>>     MemoryUsagePrinter.printMemoryUsage("free");
>>     MemoryUsage muFree =
>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>
>>     assertLessThan(muFree.getCommitted(), muFull.getCommitted(),
>>                    ...));
>> }
>>
>> You can easily move the control flow back into tests and share code with
>> utility classes, for example:
>>
>> public class TestHumongousShrinkHeap {
>>      ....
>>
>>      private void eat() {
>>          // old eat code
>>          ShrinkHeapUtils.log("eat");
>>      }
>>
>>      private void free() {
>>         // old free code
>>         ShrinkHeapUtils.log("free");
>>      }
>>
>>      public final void test() {
>>          System.gc();
>>          ShrinkHeapUtils.log("init");
>>
>>          eat();
>>          MemoryUsage full = ShrinkHeapUtils.getMemoryUsage();
>>
>>          free();
>>          MemoryUsage free = ShrinkHeapUtils.getMemoryUsage();
>>
>>          ShrinkHeapUtils.assertLessThan(free, full);
>>      }
>> }
>>
>> Now you can move the code from TestShrinkHeap to ShrinkHeapUtils. You
>> are now duplicating the call to System.gc(), the calls to eat and free,
>> the log calls, the getMemoryUsage calls and the assert. That is nine
>> lines of code.
>>
>> Duplicating nine lines of code and being able to see the flow in the
>> test itself is better than sharing the nine lines of code and not being
>> able to see the what test is doing.
>>
>> Thanks,
>> Erik
>>
>>>>
>>>>   The code you share in TestShrinkHeap is basically the check and the
>>>>   control flow of the tests. I would prefer if you could move the
>>>>   control flow (System.gc(), sample, eat, sample, free, check samples)
>>>>   into the tests and then write helper functions for retrieving the
>>>>   flag values.
>>>>
>>>>   As for the check, please use the assertions in
>>>>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>>>   throwing a RuntimeException.
>>> Good point, changed.
>>> Jesper, can we upload webrev.10 from attachment? Thanks.
>>> I'm still need GC reviewers to approve push.
>>>
>>> Thanks.
>>>>
>>>> Thanks,
>>>> Erik
>>>>
>>>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>>>> Hi,
>>>>>
>>>>> New webrev uploaded.
>>>>>
>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>>>
>>>>> I'm not a Reviewer either so if you got Igor's blessing already, my
>>>>> review won't be enough to push unfortunately.
>>>>> /Jesper
>>>>>
>>>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>>>> Hi,
>>>>>> Jepser, here is updated webrev.09
>>>>>> Thomas, Jesper can you review it as well?
>>>>>> Thanks.
>>>>>>
>>>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>>>> Andrey,
>>>>>>>
>>>>>>> 1. TEST.groups:
>>>>>>> please update copyright year:
>>>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All rights
>>>>>>>> reserved.
>>>>>>> should be
>>>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates. All
>>>>>>>> rights
>>>>>>>> reserved.
>>>>>>>
>>>>>>> 2. TestShrinkHeap.java
>>>>>>>>   22  */
>>>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>>>> add empty line between 22 and 23 as you do in all other files,
>>>>>>>
>>>>>>> otherwise it looks good to me.
>>>>>>>
>>>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in
>>>>>>> 'Reviewed-by'
>>>>>>> section )
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Igor
>>>>>>>
>>>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>>>> Hi, team
>>>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>>>> Webrev uploaded:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>
>>>>>>>>> /Jesper
>>>>>>>> Thank you, Jesper.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>>>> Hi! Here is webrev.08,
>>>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>>>
>>>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>>>
>>>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>>>> Andrey,
>>>>>>>>>>>
>>>>>>>>>>> 1. both tests:
>>>>>>>>>>>>   48     public void eat() {
>>>>>>>>>>>> 61     public void free() {
>>>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>>>  32  */
>>>>>>>>>>>>  33 import com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>>>> add empty line between these lines or remove empty line #32 in
>>>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>>>  62         //do not free last one list
>>>>>>>>>>> space after '//'
>>>>>>>>>>> 3. both tests:
>>>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>>>> after @bug you should specify product bug ids which can be
>>>>>>>>>>> tested by
>>>>>>>>>>> this
>>>>>>>>>>> test. I guess 8016479 instead of 8037924, and 8036025/8037925.
>>>>>>>>>>>
>>>>>>>>>>> otherwise it looks good, thank you for your work and patience )
>>>>>>>>>>>
>>>>>>>>>>> Igor
>>>>>>>>>>>
>>>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>>>
>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>
>>>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>>>> Igor, please, see comment below, everything uncommented is
>>>>>>>>>>>>> done.
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()' 'TestShrinkHeap.gc()'?
>>>>>>>>>>>>> I cut this out.
>>>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for 
>>>>>>>>>>>>>> it --
>>>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Not sure is it applicable for me, because every time in 
>>>>>>>>>>>>> feature
>>>>>>>>>>>>> ticket
>>>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to 
>>>>>>>>>>>>>>>> review. It
>>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>  45 public static byte[] temp;
>>>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should have one
>>>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> protected static final String MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>>>> protected static final String MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() < muFull.getCommitted())) {
>>>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>>>       String.format("committed free heap size is not less
>>>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>>>> committed full heap size, heap hasn't been shrunk?%n%s =
>>>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(), 
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue() 
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full GC");
>>>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/
>>>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string 
>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry
>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary and 
>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 26  * @key gc
>>>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc', please
>>>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>> I think that this is used for test execution - to
>>>>>>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, so we
>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/ 
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct one is
>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/. 
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string 
>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry
>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>>>   44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's not
>>>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>>   96 StringBuilder strb = new
>>>>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than 
>>>>>>>>>>>>>>>>>>>>>>>> committed
>>>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>>>   97
>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>   99
>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>  101 throw new
>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>>>  throw new 
>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap size,
>>>>>>>>>>>>>>>>>>>>>>> heap
>>>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue)); 
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/ 
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/ 
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> bug:
>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>



From jon.masamitsu at oracle.com  Tue Apr  1 21:21:13 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 01 Apr 2014 14:21:13 -0700
Subject: RFR 8037925: CMM Testing: an allocated humongous object at the
	end of the heap should not prevents shrinking the heap
In-Reply-To: <53367041.5060203@oracle.com>
References: <53332456.5060407@oracle.com>
	<533326B8.4020407@oracle.com>	<53341B70.8070603@oracle.com>
	<5334A527.4090209@oracle.com>	<53357A9E.4000505@oracle.com>
	<53358125.8020803@oracle.com> <53367041.5060203@oracle.com>
Message-ID: <533B2DC9.5010903@oracle.com>


On 3/29/14 12:03 AM, Andrey Zakharov wrote:
> Hi, here is updated webrev: 
> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.04/

   56         for (int i = 0; i < PagesNum; i++) {
   57             ArrayList< byte[] > stuff = new ArrayList<>();
   58             eat(stuff, 100, humonSize);
   59             MemoryUsagePrinter.printMemoryUsage("eat #" + i);
   60             garbage.add(stuff);
   61         }

Seems like an out-of-memory (OOME) can be thrown here (or anywhere below
this block of code).  Will an OOME be considered a pass, fail or
test-not-run?

Jon


> Thanks.
>
>
> On 28.03.2014 18:03, Igor Ignatyev wrote:
>>>>> how should I know about it? you didn't mention about it in your RFR
>>>> Nop, I did. Please, check my first message.
>> Oh, I'm sorry, I need more sleep or coffee.
>> in future, you can use one patch for multiple fixes, it'll solve such 
>> situation.
>>
>>>   47     private static final ArrayList< ArrayList< byte[] > > 
>>> garbage = new ArrayList< ArrayList< byte[] > >();
>>>   59             ArrayList< byte[] > stuff = new ArrayList< byte[] >();
>> redundant spaces, + use diamonds
>>
>>>>>>>   26  * @key gc
>>>>>> why do you need this?
>>>>> Hm, used as common practice.
>> if you don't understand meaning of '@key gc', please don't use it.
>>
>> 44-45,48-49:
>> According to section 9 in java code conventions[1]:
>>> The names of variables declared class constants and of ANSI 
>>> constants should be all uppercase with words separated by 
>>> underscores ("_"). (ANSI constants should be avoided, for ease of 
>>> debugging.)
>>
>> [1] 
>> http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html
>>
>> Igor
>>
>> On 03/28/2014 05:35 PM, Andrey Zakharov wrote:
>>> Hi,
>>> here is updated webrev:
>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.03/
>>>
>>> Igor, please, see comments below.
>>> Thanks.
>>>
>>> On 28.03.2014 02:24, Igor Ignatyev wrote:
>>>> Andrey,
>>>>
>>>>>> Most probably I forgot TEST.groups again...
>>>> yeap, you did.
>>> Ok, note that due I have two unpushed changes in TEST.groups I have
>>> change from previous webrev.
>>>>
>>>>>>> - I can't find MemoryUsagePrinter class in testlibrary[1]
>>>>>> It is in webrev: 
>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/
>>>> how should I know about it? you didn't mention about it in your RFR
>>> Nop, I did. Please, check my first message.
>>>>
>>>>>>> - please replace string constant, which use in 
>>>>>>> MemoryUsagePrinter, by
>>>>>>> enum
>>>> You don't need to use enum here and string constant (Labels.*) in
>>>> TestDynShrinkHeap. I've mistakenly think that MemoryUsagePrinter uses
>>>> String argument to change its own behavior. Sorry for useless extra 
>>>> work.
>>> Yes, its just string labels and nothing more.
>>>
>>>>
>>>>>>> - lines 79,82: why did you use
>>>>>>> sun.management.ManagementFactoryHelper.getDiagnosticMXBean() 
>>>>>>> instead
>>>>>>> of
>>>>>>> 'ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class)' 
>>>>>>> ?
>>>>>> Are we talking about this?
>>>>>>              throw new RuntimeException(
>>>>>>                      String.format("committed free heap size is not
>>>>>> less
>>>>>> than committed full heap size, heap hasn't been shrunk?%n"
>>>>>>                              + "%s = %s%n%s = %s",
>>>>>>                              MinFreeRatioFlagName,
>>>>>> ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class).
>>>>>> getVMOption(MinFreeRatioFlagName).getValue(),
>>>>>>                              MaxFreeRatioFlagName,
>>>>>> ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class).
>>>>>> getVMOption(MaxFreeRatioFlagName).getValue()
>>>>>>                      )
>>>> yes, we're.
>>> Ok, changed.
>>>>
>>>> please, use generics in 54,65 lines:
>>>>> 54     private static final List garbage = new ArrayList();
>>>>> 65             List stuff = new ArrayList();
>>>> and then, you won't have to use cast in line 95:
>>>>>  95         ArrayList stuff = ((ArrayList) garbage.get(garbage.size()
>>>>> - 1));
>>>>
>>> Done
>>>>>   26  * @key gc
>>>> why do you need this?
>>> Hm, used as common practice.
>>>>
>>>>>   64         for (int i = 0; i < 5; i++) {
>>>> magic number '5'
>>> Good point, changed
>>>>
>>>>>  61         int humonSize = Math.round(1f * PageSize);
>>>> I'd prefer '1.0f', but it's only my fad, it's not necessary to change.
>>>>
>>>> Thanks
>>>> Igor
>>>>
>>>> On 03/27/2014 04:37 PM, Andrey Zakharov wrote:
>>>>> Hi, here is updated webrev:
>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/
>>>>> Most probably I forgot TEST.groups again...
>>>>>
>>>>>
>>>>> On 26.03.2014 23:12, Igor Ignatyev wrote:
>>>>>> Hi Andrey,
>>>>>>
>>>>>> - I can't find MemoryUsagePrinter class in testlibrary[1]
>>>>> It is in webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/
>>>>>> - please replace string constant, which use in 
>>>>>> MemoryUsagePrinter, by
>>>>>> enum
>>>>>> - you forgot to remove commented line 53 Hi
>>>>> Done
>>>>>> - lines 79,82: why did you use
>>>>>> sun.management.ManagementFactoryHelper.getDiagnosticMXBean() instead
>>>>>> of
>>>>>> 'ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class)' 
>>>>>> ?
>>>>> Are we talking about this?
>>>>>              throw new RuntimeException(
>>>>>                      String.format("committed free heap size is 
>>>>> not less
>>>>> than committed full heap size, heap hasn't been shrunk?%n"
>>>>>                              + "%s = %s%n%s = %s",
>>>>>                              MinFreeRatioFlagName,
>>>>> ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class).
>>>>> getVMOption(MinFreeRatioFlagName).getValue(),
>>>>>                              MaxFreeRatioFlagName,
>>>>> ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class).
>>>>> getVMOption(MaxFreeRatioFlagName).getValue()
>>>>>                      )
>>>>>              );
>>>>>>
>>>>>> - just a nit: you again use extra spaces in some brackets:
>>>>>> 55,68,61,74,..
>>>>> Done
>>>>> Thanks.
>>>>>>
>>>>>> [1]
>>>>>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/file/tip/test/testlibrary/com/oracle/java/testlibrary 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Igor
>>>>>>
>>>>>> On 03/26/2014 11:02 PM, Andrey Zakharov wrote:
>>>>>>> Test to check, that if we allocate h1, h2 and h3 humongous 
>>>>>>> objects and
>>>>>>> free h1 and h2, after GC G1 shrinks the heap.
>>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037925/webrev/
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>
>>>>>>> This test used testlibrary MemoryUsagePrinter from
>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>
>>>
>

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

From jon.masamitsu at oracle.com  Tue Apr  1 21:49:17 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 01 Apr 2014 14:49:17 -0700
Subject: RFR(s): 8038461: Test
	gc/g1/TestStringDeduplicationMemoryUsage.java
	fails with unexpected memory usage
In-Reply-To: <D0508778-5D7A-4473-A646-22AEDF04085F@oracle.com>
References: <53357C14.3060902@oracle.com> <53392C28.9090402@oracle.com>
	<D0508778-5D7A-4473-A646-22AEDF04085F@oracle.com>
Message-ID: <533B345D.70902@oracle.com>

Per,

Is there a way you could get generateString() to return the
sum of the sizes of the strings (minus 1 string)?  Instead of the doing
the calculation of bytesSaved?

Jon

On 4/1/14 12:54 AM, Per Liden wrote:
> Thanks Stefan! Need one more Review.
>
> /Per
>
> On 31 Mar 2014, at 10:49, Stefan Johansson <stefan.johansson at oracle.com> wrote:
>
>> Looks good!
>>
>> Stefan
>>
>> On 2014-03-28 14:41, Per Liden wrote:
>>> Hi,
>>>
>>> Could I please have this test fix reviewed.
>>>
>>> Summary: The test in question tries to calculate the amount of memory saved when using string deduplication. The problem is that the JVM doing this calculation could be running without compressed class pointers when the JVM doing the actual string deduplication is running with compressed class pointers. When this happens the JVMs will have different views on the size of an array header, which in the end makes the calculation incorrect and the test thinks the deduplication failed. Exactly this situation happened in a nightly test run. This fix makes sure that the array header size of the JVM doing the deduplication is communicated to the JVM doing the memory savings calculation.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038461
>>> Webrev: http://cr.openjdk.java.net/~pliden/8038461/webrev.0/
>>>
>>> /Per
>>>



From igor.ignatyev at oracle.com  Wed Apr  2 09:07:18 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 02 Apr 2014 13:07:18 +0400
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533B252B.9080806@oracle.com>
References: <5332FA20.5070607@oracle.com>	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>	<53394053.2070502@oracle.com>
	<533955B0.7000601@oracle.com>	<533A6165.80704@oracle.com>
	<533A8141.2030608@oracle.com>	<533AB4F9.6090509@oracle.com>
	<533ABE29.30805@oracle.com> <533B252B.9080806@oracle.com>
Message-ID: <533BD346.4040107@oracle.com>

Jon,

> Given the current implementation of these tests, what will I need
> to do to understand what TestDynShrinkHeap is doing?

You'll have to open one more file -- TestShrinkHeap, and it's easy to 
understand since you see that TestDynShrinkHeap is a subclass of 
TestShrinkHeap. I offered to use inheritance, since my understanding is 
that we are going to write other tests w/ the same control flow, and for 
me in future it'll cost too much to maintain N tests w/ copy-pasted 
control flow.

But I understand your point and don't insist on using inheritance, as I 
said before:
> Since these tests are gc tests, it's up to you to decide how to write better.
I just want to avoid having tens tests w/ the almost same code, since 
changing something in them will be very hard.

Thanks,
Igor

On 04/02/2014 12:44 AM, Jon Masamitsu wrote:
> Igor,
>
> If I see a test failure of TestDynShrinkHeap, I need to understand
> what that test is doing.  My recent experience (nightly testing)
> tells me that I will easily be able to look at
> TestDynShrinkHeap.java but maybe not much
> more.
>
> Given the current implementation of these tests, what will I need
> to do to understand what TestDynShrinkHeap is doing?
>
> Jon
>
>
> On 4/1/14 6:24 AM, Igor Ignatyev wrote:
>> Erik/Jesper,
>>
>> g1/TestHumongousShrinkHeap, parallelScavenge/TestDynShrinkHeap are
>> test cases of TestShrinkHeap, so they suppose to share control flow,
>> or more precisely they shouldn't contain control-flow.
>>
>> let's say they just specify function in TestShrinkHeap:
>>> TestShrinkHeap {
>>>  Runnable eat;
>>>  Runnable free;
>>>  TestShrinkHeap(Runnable eat, Runnable free) { ... }
>>>  void test() {
>>>     System.gc();
>>>     MemoryUsagePrinter.printMemoryUsage("init");
>>>
>>>     eat.run();
>>>     MemoryUsagePrinter.printMemoryUsage("eaten");
>>>     MemoryUsage muFull =
>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>
>>>     free.run();
>>>     MemoryUsagePrinter.printMemoryUsage("free");
>>>     MemoryUsage muFree =
>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>
>>>     assertLessThan(muFree.getCommitted(), muFull.getCommitted(),
>>>                    ...));
>>>
>>>  }
>>> }
>>
>> then g1/TestHumongousShrinkHeap is
>> new TestShrinkHeap(
>> ()->{
>>> int HumongousObjectSize = Math.round(.9f * PAGE_SIZE);
>>>   51         System.out.println("Will allocate objects of size=" +
>>>   52 MemoryUsagePrinter.humanReadableByteCount(HumongousObjectSize,
>>> true));
>>>   53
>>>   54         for (int i = 0; i < PAGES_NUM; i++) {
>>>   55             ArrayList<byte[]> stuff = new ArrayList<>();
>>>   56             eatList(stuff, 100, HumongousObjectSize);
>>>   57             MemoryUsagePrinter.printMemoryUsage("eat #" + i);
>>>   58             garbage.add(stuff);
>>>   59         }
>> },
>> ()->{
>>>   63         // do not free last one list
>>>   64         garbage.subList(0, garbage.size() - 1).clear();
>>>   65
>>>   66         // do not free last one element from last list
>>>   67         ArrayList stuff = garbage.get(garbage.size() - 1);
>>>   68         stuff.subList(0, stuff.size() - 1).clear();
>>>   69         System.gc();
>> }
>>
>> from my point of view, it's quite simple to understand and maintain
>> (of course if we replace lambdas by method references), and it's much
>> easier to write add new test-cases and extend test's logic.
>>
>> however, it's just a question of code-style and preferences. Since
>> these tests are gc tests, it's up to you to decide how to write better.
>>
>> Igor
>>
>> On 04/01/2014 04:45 PM, Erik Helin wrote:
>>> On 2014-04-01 11:05, Andrey Zakharov wrote:
>>>> Hi, Erik. Thanks for comments.
>>>>
>>>> On 01.04.2014 10:49, Erik Helin wrote:
>>>>> Andrey,
>>>>>
>>>>> a couple of comments:
>>>>> - We do not use the @author tag in the tests
>>>>>   (if you've seen other tests have the @author tag, then that is a
>>>>> bug)
>>>> removed
>>>>> - I'm not a big fan of using inheritance for sharing code between
>>>>>   tests because it makes it very hard to open a test, e.g.
>>>>>   TestHumongousShrinkHeap.java, and see what it does.
>>>> Agreed, I'm too. But doubled code leads to harder maintenance.
>>>
>>> Duplicated code often leads to harder maintenance, but it is not the
>>> only thing making code hard to maintain. By using inheritance, you have
>>> moved the control flow from the test to another file. When I want to
>>> look at test test because it failed, I want to immediately see what it
>>> did. I do *not* want to traverse an inheritance hierarchy and build a
>>> mental model of how the control flows up and down in the inheritance
>>> hierarchy. It is very important that tests are explicit and clearly
>>> describe what they are testing.
>>>
>>> Looking at the code in TestShrinkHeap::test:
>>>
>>> public final void test() {
>>>     System.gc();
>>>     MemoryUsagePrinter.printMemoryUsage("init");
>>>
>>>     eat();
>>>     MemoryUsagePrinter.printMemoryUsage("eaten");
>>>     MemoryUsage muFull =
>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>
>>>     free();
>>>     MemoryUsagePrinter.printMemoryUsage("free");
>>>     MemoryUsage muFree =
>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>
>>>     assertLessThan(muFree.getCommitted(), muFull.getCommitted(),
>>>                    ...));
>>> }
>>>
>>> You can easily move the control flow back into tests and share code with
>>> utility classes, for example:
>>>
>>> public class TestHumongousShrinkHeap {
>>>      ....
>>>
>>>      private void eat() {
>>>          // old eat code
>>>          ShrinkHeapUtils.log("eat");
>>>      }
>>>
>>>      private void free() {
>>>         // old free code
>>>         ShrinkHeapUtils.log("free");
>>>      }
>>>
>>>      public final void test() {
>>>          System.gc();
>>>          ShrinkHeapUtils.log("init");
>>>
>>>          eat();
>>>          MemoryUsage full = ShrinkHeapUtils.getMemoryUsage();
>>>
>>>          free();
>>>          MemoryUsage free = ShrinkHeapUtils.getMemoryUsage();
>>>
>>>          ShrinkHeapUtils.assertLessThan(free, full);
>>>      }
>>> }
>>>
>>> Now you can move the code from TestShrinkHeap to ShrinkHeapUtils. You
>>> are now duplicating the call to System.gc(), the calls to eat and free,
>>> the log calls, the getMemoryUsage calls and the assert. That is nine
>>> lines of code.
>>>
>>> Duplicating nine lines of code and being able to see the flow in the
>>> test itself is better than sharing the nine lines of code and not being
>>> able to see the what test is doing.
>>>
>>> Thanks,
>>> Erik
>>>
>>>>>
>>>>>   The code you share in TestShrinkHeap is basically the check and the
>>>>>   control flow of the tests. I would prefer if you could move the
>>>>>   control flow (System.gc(), sample, eat, sample, free, check samples)
>>>>>   into the tests and then write helper functions for retrieving the
>>>>>   flag values.
>>>>>
>>>>>   As for the check, please use the assertions in
>>>>>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>>>>   throwing a RuntimeException.
>>>> Good point, changed.
>>>> Jesper, can we upload webrev.10 from attachment? Thanks.
>>>> I'm still need GC reviewers to approve push.
>>>>
>>>> Thanks.
>>>>>
>>>>> Thanks,
>>>>> Erik
>>>>>
>>>>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> New webrev uploaded.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>>>>
>>>>>> I'm not a Reviewer either so if you got Igor's blessing already, my
>>>>>> review won't be enough to push unfortunately.
>>>>>> /Jesper
>>>>>>
>>>>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>>>>> Hi,
>>>>>>> Jepser, here is updated webrev.09
>>>>>>> Thomas, Jesper can you review it as well?
>>>>>>> Thanks.
>>>>>>>
>>>>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>>>>> Andrey,
>>>>>>>>
>>>>>>>> 1. TEST.groups:
>>>>>>>> please update copyright year:
>>>>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All rights
>>>>>>>>> reserved.
>>>>>>>> should be
>>>>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates. All
>>>>>>>>> rights
>>>>>>>>> reserved.
>>>>>>>>
>>>>>>>> 2. TestShrinkHeap.java
>>>>>>>>>   22  */
>>>>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>>>>> add empty line between 22 and 23 as you do in all other files,
>>>>>>>>
>>>>>>>> otherwise it looks good to me.
>>>>>>>>
>>>>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in
>>>>>>>> 'Reviewed-by'
>>>>>>>> section )
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Igor
>>>>>>>>
>>>>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>>>>> Hi, team
>>>>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>>>>> Webrev uploaded:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>
>>>>>>>>>> /Jesper
>>>>>>>>> Thank you, Jesper.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>>>>> Hi! Here is webrev.08,
>>>>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>>>>
>>>>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>>>>
>>>>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>
>>>>>>>>>>>> 1. both tests:
>>>>>>>>>>>>>   48     public void eat() {
>>>>>>>>>>>>> 61     public void free() {
>>>>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>>>>  32  */
>>>>>>>>>>>>>  33 import com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>>>>> add empty line between these lines or remove empty line #32 in
>>>>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>>>>  62         //do not free last one list
>>>>>>>>>>>> space after '//'
>>>>>>>>>>>> 3. both tests:
>>>>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>>>>> after @bug you should specify product bug ids which can be
>>>>>>>>>>>> tested by
>>>>>>>>>>>> this
>>>>>>>>>>>> test. I guess 8016479 instead of 8037924, and 8036025/8037925.
>>>>>>>>>>>>
>>>>>>>>>>>> otherwise it looks good, thank you for your work and patience )
>>>>>>>>>>>>
>>>>>>>>>>>> Igor
>>>>>>>>>>>>
>>>>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>>
>>>>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>>>>> Igor, please, see comment below, everything uncommented is
>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()' 'TestShrinkHeap.gc()'?
>>>>>>>>>>>>>> I cut this out.
>>>>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for
>>>>>>>>>>>>>>> it --
>>>>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not sure is it applicable for me, because every time in
>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to
>>>>>>>>>>>>>>>>> review. It
>>>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>  45 public static byte[] temp;
>>>>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should have one
>>>>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> protected static final String MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>>>>> protected static final String MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() < muFull.getCommitted())) {
>>>>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>>>>       String.format("committed free heap size is not less
>>>>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>>>>> committed full heap size, heap hasn't been shrunk?%n%s =
>>>>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(),
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue()
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full GC");
>>>>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/
>>>>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string
>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry
>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary and
>>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 26  * @key gc
>>>>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc', please
>>>>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>>> I think that this is used for test execution - to
>>>>>>>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, so we
>>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct one is
>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string
>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry
>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>>>>   44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's not
>>>>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>>>   96 StringBuilder strb = new
>>>>>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than
>>>>>>>>>>>>>>>>>>>>>>>>> committed
>>>>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>>>>   97
>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>   99
>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>  101 throw new
>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>>>>  throw new
>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap size,
>>>>>>>>>>>>>>>>>>>>>>>> heap
>>>>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue));
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> bug:
>>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>


From per.liden at oracle.com  Wed Apr  2 10:10:50 2014
From: per.liden at oracle.com (Per Liden)
Date: Wed, 02 Apr 2014 12:10:50 +0200
Subject: RFR(s): 8038461: Test
	gc/g1/TestStringDeduplicationMemoryUsage.java
	fails with unexpected memory usage
In-Reply-To: <533B345D.70902@oracle.com>
References: <53357C14.3060902@oracle.com> <53392C28.9090402@oracle.com>
	<D0508778-5D7A-4473-A646-22AEDF04085F@oracle.com>
	<533B345D.70902@oracle.com>
Message-ID: <533BE22A.3000105@oracle.com>

Hi Jon,

On 04/01/2014 11:49 PM, Jon Masamitsu wrote:
> Per,
>
> Is there a way you could get generateString() to return the
> sum of the sizes of the strings (minus 1 string)?  Instead of the doing
> the calculation of bytesSaved?

Could you elaborate a bit, I'm not quite sure I understand what you 
mean. Is there something about the bytesSaved calculation you don't like?

Each MemoryUsageTest instance could of course return the sizes of all 
character arrays it has created (instead of just the array header size), 
is that what you're suggesting? There would still be a bytesSaved 
calculation inside testMemoryUsage() though, so I have a feeling that's 
not what you meant.

Note that generateString()/createStrings() has no real understanding of 
whether deduplication is enabled or not and they are also used by other 
tests, which don't care about sizes.

cheers,
/Per

>
> Jon
>
> On 4/1/14 12:54 AM, Per Liden wrote:
>> Thanks Stefan! Need one more Review.
>>
>> /Per
>>
>> On 31 Mar 2014, at 10:49, Stefan Johansson
>> <stefan.johansson at oracle.com> wrote:
>>
>>> Looks good!
>>>
>>> Stefan
>>>
>>> On 2014-03-28 14:41, Per Liden wrote:
>>>> Hi,
>>>>
>>>> Could I please have this test fix reviewed.
>>>>
>>>> Summary: The test in question tries to calculate the amount of
>>>> memory saved when using string deduplication. The problem is that
>>>> the JVM doing this calculation could be running without compressed
>>>> class pointers when the JVM doing the actual string deduplication is
>>>> running with compressed class pointers. When this happens the JVMs
>>>> will have different views on the size of an array header, which in
>>>> the end makes the calculation incorrect and the test thinks the
>>>> deduplication failed. Exactly this situation happened in a nightly
>>>> test run. This fix makes sure that the array header size of the JVM
>>>> doing the deduplication is communicated to the JVM doing the memory
>>>> savings calculation.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038461
>>>> Webrev: http://cr.openjdk.java.net/~pliden/8038461/webrev.0/
>>>>
>>>> /Per
>>>>
>



From stefan.johansson at oracle.com  Wed Apr  2 11:20:16 2014
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Wed, 02 Apr 2014 13:20:16 +0200
Subject: RFR: 8029186: regression-hotspot nightly failure:
	assert(FLAG_IS_DEFAULT(MaxNewSize) || MaxNewSize < MaxHeapSize) failed
In-Reply-To: <5332B096.6050409@oracle.com>
References: <5331A0D9.4060502@oracle.com> <5331AFC8.2060906@oracle.com>
	<5332B096.6050409@oracle.com>
Message-ID: <533BF270.7090104@oracle.com>

I got a second review from Jon Masamitsu, he had some comments and these 
have been fixed.

Here's an incremental webrev:
http://cr.openjdk.java.net/~sjohanss/8029186/webrev.01-02/

Here's the full change:
http://cr.openjdk.java.net/~sjohanss/8029186/webrev.02/

Thanks Jon and Jesper for reviewing this.

Cheers,
Stefan

On 2014-03-26 11:48, Stefan Johansson wrote:
> Thanks Jesper for looking at this.
>
> I actually found an issue myself when going over the code. The problem 
> is in initialize_flags for the TwoGenerationalPolicy, where I verify 
> that the desired new_size is within the allowed bounds. I realized 
> that I need to check against the flag MaxNewSize since the member 
> might not have been initialized yet. Below is the diff for the change 
> and an updated webrev can be found here:
> http://cr.openjdk.java.net/~sjohanss/8029186/webrev.01/
>
> ---
> @@ -422,7 +422,9 @@
>    if (FLAG_IS_CMDLINE(OldSize) && !FLAG_IS_CMDLINE(NewSize)) {
>      if (OldSize < _initial_heap_byte_size) {
>        size_t new_size = _initial_heap_byte_size - OldSize;
> -      if (new_size >= _min_gen0_size && new_size <= _max_gen0_size) {
> +      // Need to compare against the flag value for max since 
> _max_gen0_size
> +      // might not have been set yet.
> +      if (new_size >= _min_gen0_size && new_size <= MaxNewSize) {
>          FLAG_SET_ERGO(uintx, NewSize, new_size);
>          _initial_gen0_size = NewSize;
>        }
> ---
>
> Thanks,
> Stefan
>
> On 2014-03-25 17:33, Jesper Wilhelmsson wrote:
>> Ship it!
>> /Jesper
>>
>> Stefan Johansson skrev 25/3/14 16:29:
>>> Hi,
>>>
>>> Please review this fix for:
>>> https://bugs.openjdk.java.net/browse/JDK-8029186
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~sjohanss/8029186/webrev.00/
>>>
>>> Summary:
>>> There have been a lot of bugs due to corner cases with heap sizing 
>>> flags. This
>>> change strives to fix this particular problem and at the same time 
>>> somewhat
>>> simplify the collector policy. I've also added some assertions to 
>>> ensure that
>>> the sizing of the heap is more correct.
>>>
>>> Testing:
>>> * JPRT sanity and JTREG
>>> * Adhoc aurora run for tmtools tests
>>> * Script that verifies that we don't get assertions during startup 
>>> for different
>>> combinations of NewSize, MaxNewSize, OldSize, Xms and Xmx.
>>>
>>> Thanks,
>>> StefanJ
>



From thomas.schatzl at oracle.com  Wed Apr  2 14:23:51 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 02 Apr 2014 16:23:51 +0200
Subject: RFR (S): 8038930: G1CodeRootSet::test fails with
	assert(_num_chunks_handed_out == 0) failed: No elements must have been
	handed out yet
Message-ID: <1396448631.3183.14.camel@cirrus>

Hi all,

  can I have reviews for the following fix for a test case?

This test case does some basic code validation on recently introduced
code root memory management for G1 introduced recently (JDK-8035406).

It assumed that before running the test, no code root memory has been
handed out.

The problem is now, when running with -Xcomp, before the internal VM
tests (and this test) are run, it is likely that compiled code already
did some code root allocations.

So the test needs to be aware of that, and not assume that the number of
code root memory handed out is not zero.

This change fixes that assumption.

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

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

Testing:
jprt, manual invocation of test case with -Xcomp

Thanks,
  Thomas




From andrey.x.zakharov at oracle.com  Wed Apr  2 16:09:56 2014
From: andrey.x.zakharov at oracle.com (Andrey Zakharov)
Date: Wed, 02 Apr 2014 20:09:56 +0400
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533AB040.6000302@oracle.com>
References: <5332FA20.5070607@oracle.com>
	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>
	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>
	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>
	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>
	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>
	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>
	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>
	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>
	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>
	<53394053.2070502@oracle.com> <533955B0.7000601@oracle.com>
	<533A6165.80704@oracle.com> <533A8141.2030608@oracle.com>
	<533AB040.6000302@oracle.com>
Message-ID: <533C3654.7020801@oracle.com>

Here is version without hidden testflow:
http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.11/
Thanks.

On 01.04.2014 16:25, Jesper Wilhelmsson wrote:
> Uploaded:
>
> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.10/
>
> In general  would agree regarding avoiding duplicated code, but when 
> it comes to the control flow I agree with Erik. More hard to read code 
> leads to harder maintenance than duplicating a few lines of code.
> /Jesper
>
> Andrey Zakharov skrev 1/4/14 11:05:
>> Hi, Erik. Thanks for comments.
>>
>> On 01.04.2014 10:49, Erik Helin wrote:
>>> Andrey,
>>>
>>> a couple of comments:
>>> - We do not use the @author tag in the tests
>>>   (if you've seen other tests have the @author tag, then that is a bug)
>> removed
>>> - I'm not a big fan of using inheritance for sharing code between
>>>   tests because it makes it very hard to open a test, e.g.
>>>   TestHumongousShrinkHeap.java, and see what it does.
>> Agreed, I'm too. But doubled code leads to harder maintenance.
>>>
>>>   The code you share in TestShrinkHeap is basically the check and the
>>>   control flow of the tests. I would prefer if you could move the
>>>   control flow (System.gc(), sample, eat, sample, free, check samples)
>>>   into the tests and then write helper functions for retrieving the
>>>   flag values.
>>>
>>>   As for the check, please use the assertions in
>>>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>>   throwing a RuntimeException.
>> Good point, changed.
>> Jesper, can we upload webrev.10 from attachment? Thanks.
>> I'm still need GC reviewers to approve push.
>>
>> Thanks.
>>>
>>> Thanks,
>>> Erik
>>>
>>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>>> Hi,
>>>>
>>>> New webrev uploaded.
>>>>
>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>>
>>>> I'm not a Reviewer either so if you got Igor's blessing already, my
>>>> review won't be enough to push unfortunately.
>>>> /Jesper
>>>>
>>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>>> Hi,
>>>>> Jepser, here is updated webrev.09
>>>>> Thomas, Jesper can you review it as well?
>>>>> Thanks.
>>>>>
>>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>>> Andrey,
>>>>>>
>>>>>> 1. TEST.groups:
>>>>>> please update copyright year:
>>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All rights
>>>>>>> reserved.
>>>>>> should be
>>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates. All
>>>>>>> rights
>>>>>>> reserved.
>>>>>>
>>>>>> 2. TestShrinkHeap.java
>>>>>>>   22  */
>>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>>> add empty line between 22 and 23 as you do in all other files,
>>>>>>
>>>>>> otherwise it looks good to me.
>>>>>>
>>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in 
>>>>>> 'Reviewed-by'
>>>>>> section )
>>>>>>
>>>>>> Thanks,
>>>>>> Igor
>>>>>>
>>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>>> Hi, team
>>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>>> Webrev uploaded:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>
>>>>>>>> /Jesper
>>>>>>> Thank you, Jesper.
>>>>>>>
>>>>>>>>
>>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>>> Hi! Here is webrev.08,
>>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>>
>>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>>
>>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>>> Andrey,
>>>>>>>>>>
>>>>>>>>>> 1. both tests:
>>>>>>>>>>>   48     public void eat() {
>>>>>>>>>>> 61     public void free() {
>>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>>  32  */
>>>>>>>>>>>  33 import com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>>> add empty line between these lines or remove empty line #32 in
>>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>>  62         //do not free last one list
>>>>>>>>>> space after '//'
>>>>>>>>>> 3. both tests:
>>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>>> after @bug you should specify product bug ids which can be 
>>>>>>>>>> tested by
>>>>>>>>>> this
>>>>>>>>>> test. I guess 8016479 instead of 8037924, and 8036025/8037925.
>>>>>>>>>>
>>>>>>>>>> otherwise it looks good, thank you for your work and patience )
>>>>>>>>>>
>>>>>>>>>> Igor
>>>>>>>>>>
>>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>>
>>>>>>>>>>> /Jesper
>>>>>>>>>>>
>>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>>> Igor, please, see comment below, everything uncommented is 
>>>>>>>>>>>> done.
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()' 'TestShrinkHeap.gc()'?
>>>>>>>>>>>> I cut this out.
>>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for it --
>>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>>
>>>>>>>>>>>> Not sure is it applicable for me, because every time in 
>>>>>>>>>>>> feature
>>>>>>>>>>>> ticket
>>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>>> webrev: 
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to 
>>>>>>>>>>>>>>> review. It
>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>  45 public static byte[] temp;
>>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should have one
>>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> protected static final String MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>>> protected static final String MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() < muFull.getCommitted())) {
>>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>>       String.format("committed free heap size is not 
>>>>>>>>>>>>>>>> less than
>>>>>>>>>>>>>>>> committed full heap size, heap hasn't been shrunk?%n%s =
>>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(), 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue() 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full GC");
>>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/
>>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. 
>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary and 
>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 26  * @key gc
>>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc', 
>>>>>>>>>>>>>>>>>>>> please don't
>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>> I think that this is used for test execution - to 
>>>>>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, so 
>>>>>>>>>>>>>>>>>> we don't
>>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/ 
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct one is
>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/. 
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. 
>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>> 44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's not
>>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>> 96 StringBuilder strb = new 
>>>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than committed
>>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>>   97 
>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>   99 
>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>  101             throw new
>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>>  throw new RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap 
>>>>>>>>>>>>>>>>>>>>>> size, heap
>>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue)); 
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/ 
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/ 
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> bug: 
>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>



From vladimir.kempik at oracle.com  Wed Apr  2 16:17:37 2014
From: vladimir.kempik at oracle.com (Vladimir Kempik)
Date: Wed, 02 Apr 2014 20:17:37 +0400
Subject: Request for review: 8016302: Change type of the number of GC workers
	to unsigned int (2)
Message-ID: <533C3821.60005@oracle.com>

Hi all,

Could I have a couple of reviews for this change?

http://cr.openjdk.java.net/~vkempik/8016302/webrev.04/

In 7121618 variables representing GC workers (worker id, worker id 
offset) have been changed from int to unsigned int.

Since then, code reintroduced the use of int's for this type of 
variable; fixing this by aligning the code to use uints for ints.

Since last september the fix was updated for jdk9 and size_t was 
replaced with uint in
dirtyCardQueue.hpp,

   54 bool apply_closure(CardTableEntryClosure* cl,
   55                      bool consume = true,
   56                      size_t worker_i = 0);

   99   // The number of parallel ids that can be claimed to allow
collector or
  100   // mutator threads to do card-processing work.
  101   static size_t num_par_ids();

Thanks,
Vladimir



From igor.ignatyev at oracle.com  Wed Apr  2 16:23:16 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 02 Apr 2014 20:23:16 +0400
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533C3654.7020801@oracle.com>
References: <5332FA20.5070607@oracle.com>
	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>
	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>
	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>
	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>
	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>
	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>
	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>
	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>
	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>
	<53394053.2070502@oracle.com> <533955B0.7000601@oracle.com>
	<533A6165.80704@oracle.com> <533A8141.2030608@oracle.com>
	<533AB040.6000302@oracle.com> <533C3654.7020801@oracle.com>
Message-ID: <533C3974.5080803@oracle.com>

Andrey,

Why do test classes extend TestShrinkHeap?

Igor

On 04/02/2014 08:09 PM, Andrey Zakharov wrote:
> Here is version without hidden testflow:
> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.11/
> Thanks.
>
> On 01.04.2014 16:25, Jesper Wilhelmsson wrote:
>> Uploaded:
>>
>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.10/
>>
>> In general  would agree regarding avoiding duplicated code, but when
>> it comes to the control flow I agree with Erik. More hard to read code
>> leads to harder maintenance than duplicating a few lines of code.
>> /Jesper
>>
>> Andrey Zakharov skrev 1/4/14 11:05:
>>> Hi, Erik. Thanks for comments.
>>>
>>> On 01.04.2014 10:49, Erik Helin wrote:
>>>> Andrey,
>>>>
>>>> a couple of comments:
>>>> - We do not use the @author tag in the tests
>>>>   (if you've seen other tests have the @author tag, then that is a bug)
>>> removed
>>>> - I'm not a big fan of using inheritance for sharing code between
>>>>   tests because it makes it very hard to open a test, e.g.
>>>>   TestHumongousShrinkHeap.java, and see what it does.
>>> Agreed, I'm too. But doubled code leads to harder maintenance.
>>>>
>>>>   The code you share in TestShrinkHeap is basically the check and the
>>>>   control flow of the tests. I would prefer if you could move the
>>>>   control flow (System.gc(), sample, eat, sample, free, check samples)
>>>>   into the tests and then write helper functions for retrieving the
>>>>   flag values.
>>>>
>>>>   As for the check, please use the assertions in
>>>>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>>>   throwing a RuntimeException.
>>> Good point, changed.
>>> Jesper, can we upload webrev.10 from attachment? Thanks.
>>> I'm still need GC reviewers to approve push.
>>>
>>> Thanks.
>>>>
>>>> Thanks,
>>>> Erik
>>>>
>>>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>>>> Hi,
>>>>>
>>>>> New webrev uploaded.
>>>>>
>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>>>
>>>>> I'm not a Reviewer either so if you got Igor's blessing already, my
>>>>> review won't be enough to push unfortunately.
>>>>> /Jesper
>>>>>
>>>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>>>> Hi,
>>>>>> Jepser, here is updated webrev.09
>>>>>> Thomas, Jesper can you review it as well?
>>>>>> Thanks.
>>>>>>
>>>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>>>> Andrey,
>>>>>>>
>>>>>>> 1. TEST.groups:
>>>>>>> please update copyright year:
>>>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All rights
>>>>>>>> reserved.
>>>>>>> should be
>>>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates. All
>>>>>>>> rights
>>>>>>>> reserved.
>>>>>>>
>>>>>>> 2. TestShrinkHeap.java
>>>>>>>>   22  */
>>>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>>>> add empty line between 22 and 23 as you do in all other files,
>>>>>>>
>>>>>>> otherwise it looks good to me.
>>>>>>>
>>>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in
>>>>>>> 'Reviewed-by'
>>>>>>> section )
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Igor
>>>>>>>
>>>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>>>> Hi, team
>>>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>>>> Webrev uploaded:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>
>>>>>>>>> /Jesper
>>>>>>>> Thank you, Jesper.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>>>> Hi! Here is webrev.08,
>>>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>>>
>>>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>>>
>>>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>>>> Andrey,
>>>>>>>>>>>
>>>>>>>>>>> 1. both tests:
>>>>>>>>>>>>   48     public void eat() {
>>>>>>>>>>>> 61     public void free() {
>>>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>>>  32  */
>>>>>>>>>>>>  33 import com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>>>> add empty line between these lines or remove empty line #32 in
>>>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>>>  62         //do not free last one list
>>>>>>>>>>> space after '//'
>>>>>>>>>>> 3. both tests:
>>>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>>>> after @bug you should specify product bug ids which can be
>>>>>>>>>>> tested by
>>>>>>>>>>> this
>>>>>>>>>>> test. I guess 8016479 instead of 8037924, and 8036025/8037925.
>>>>>>>>>>>
>>>>>>>>>>> otherwise it looks good, thank you for your work and patience )
>>>>>>>>>>>
>>>>>>>>>>> Igor
>>>>>>>>>>>
>>>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>>>
>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>
>>>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>>>> Igor, please, see comment below, everything uncommented is
>>>>>>>>>>>>> done.
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()' 'TestShrinkHeap.gc()'?
>>>>>>>>>>>>> I cut this out.
>>>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for it --
>>>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Not sure is it applicable for me, because every time in
>>>>>>>>>>>>> feature
>>>>>>>>>>>>> ticket
>>>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to
>>>>>>>>>>>>>>>> review. It
>>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>  45 public static byte[] temp;
>>>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should have one
>>>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> protected static final String MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>>>> protected static final String MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() < muFull.getCommitted())) {
>>>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>>>       String.format("committed free heap size is not
>>>>>>>>>>>>>>>>> less than
>>>>>>>>>>>>>>>>> committed full heap size, heap hasn't been shrunk?%n%s =
>>>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(),
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue()
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full GC");
>>>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/
>>>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary and
>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 26  * @key gc
>>>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc',
>>>>>>>>>>>>>>>>>>>>> please don't
>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>> I think that this is used for test execution - to
>>>>>>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, so
>>>>>>>>>>>>>>>>>>> we don't
>>>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct one is
>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>>> 44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's not
>>>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>> 96 StringBuilder strb = new
>>>>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than committed
>>>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>>>   97
>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>   99
>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>  101             throw new
>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>>>  throw new RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap
>>>>>>>>>>>>>>>>>>>>>>> size, heap
>>>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue));
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> bug:
>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>
>


From jon.masamitsu at oracle.com  Wed Apr  2 16:28:07 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 02 Apr 2014 09:28:07 -0700
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533BD346.4040107@oracle.com>
References: <5332FA20.5070607@oracle.com>	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>	<53394053.2070502@oracle.com>
	<533955B0.7000601@oracle.com>	<533A6165.80704@oracle.com>
	<533A8141.2030608@oracle.com>	<533AB4F9.6090509@oracle.com>
	<533ABE29.30805@oracle.com> <533B252B.9080806@oracle.com>
	<533BD346.4040107@oracle.com>
Message-ID: <533C3A97.1090902@oracle.com>


On 4/2/14 2:07 AM, Igor Ignatyev wrote:
> Jon,
>
>> Given the current implementation of these tests, what will I need
>> to do to understand what TestDynShrinkHeap is doing?
>
> You'll have to open one more file -- TestShrinkHeap, and it's easy to 
> understand since you see that TestDynShrinkHeap is a subclass of 
> TestShrinkHeap. I offered to use inheritance, since my understanding 
> is that we are going to write other tests w/ the same control flow, 
> and for me in future it'll cost too much to maintain N tests w/ 
> copy-pasted control flow.

My problem in the past was that I could not find other
source files.  Will that be fixed?  I don't need to look
at the sources often so tend to forget where they are.
Actually, I don't think I've ever found the sources if
they were not in the nightly testing "dir" test directory.

>
> But I understand your point and don't insist on using inheritance, as 
> I said before:
>> Since these tests are gc tests, it's up to you to decide how to write 
>> better.
> I just want to avoid having tens tests w/ the almost same code, since 
> changing something in them will be very hard.
Avoiding the duplication would be nice.

I usually need to look at what the test is doing because
I'm having trouble reproducing the failure and want
to understand if tweaking the jvm flags would help
reproduce it.   This pushes work back to SQE but
if I only had to look at failures that had a reliable
reproducer, I would not need to look at the test sources.
That might just be the way I work though.

Maybe some way for me to search for source files.
Or some tool to assemble the source files into a
directory.

Jon

>
> Thanks,
> Igor
>
> On 04/02/2014 12:44 AM, Jon Masamitsu wrote:
>> Igor,
>>
>> If I see a test failure of TestDynShrinkHeap, I need to understand
>> what that test is doing.  My recent experience (nightly testing)
>> tells me that I will easily be able to look at
>> TestDynShrinkHeap.java but maybe not much
>> more.
>>
>> Given the current implementation of these tests, what will I need
>> to do to understand what TestDynShrinkHeap is doing?
>>
>> Jon
>>
>>
>> On 4/1/14 6:24 AM, Igor Ignatyev wrote:
>>> Erik/Jesper,
>>>
>>> g1/TestHumongousShrinkHeap, parallelScavenge/TestDynShrinkHeap are
>>> test cases of TestShrinkHeap, so they suppose to share control flow,
>>> or more precisely they shouldn't contain control-flow.
>>>
>>> let's say they just specify function in TestShrinkHeap:
>>>> TestShrinkHeap {
>>>>  Runnable eat;
>>>>  Runnable free;
>>>>  TestShrinkHeap(Runnable eat, Runnable free) { ... }
>>>>  void test() {
>>>>     System.gc();
>>>>     MemoryUsagePrinter.printMemoryUsage("init");
>>>>
>>>>     eat.run();
>>>>     MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>     MemoryUsage muFull =
>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>
>>>>     free.run();
>>>>     MemoryUsagePrinter.printMemoryUsage("free");
>>>>     MemoryUsage muFree =
>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>
>>>>     assertLessThan(muFree.getCommitted(), muFull.getCommitted(),
>>>>                    ...));
>>>>
>>>>  }
>>>> }
>>>
>>> then g1/TestHumongousShrinkHeap is
>>> new TestShrinkHeap(
>>> ()->{
>>>> int HumongousObjectSize = Math.round(.9f * PAGE_SIZE);
>>>>   51         System.out.println("Will allocate objects of size=" +
>>>>   52 MemoryUsagePrinter.humanReadableByteCount(HumongousObjectSize,
>>>> true));
>>>>   53
>>>>   54         for (int i = 0; i < PAGES_NUM; i++) {
>>>>   55             ArrayList<byte[]> stuff = new ArrayList<>();
>>>>   56             eatList(stuff, 100, HumongousObjectSize);
>>>>   57             MemoryUsagePrinter.printMemoryUsage("eat #" + i);
>>>>   58             garbage.add(stuff);
>>>>   59         }
>>> },
>>> ()->{
>>>>   63         // do not free last one list
>>>>   64         garbage.subList(0, garbage.size() - 1).clear();
>>>>   65
>>>>   66         // do not free last one element from last list
>>>>   67         ArrayList stuff = garbage.get(garbage.size() - 1);
>>>>   68         stuff.subList(0, stuff.size() - 1).clear();
>>>>   69         System.gc();
>>> }
>>>
>>> from my point of view, it's quite simple to understand and maintain
>>> (of course if we replace lambdas by method references), and it's much
>>> easier to write add new test-cases and extend test's logic.
>>>
>>> however, it's just a question of code-style and preferences. Since
>>> these tests are gc tests, it's up to you to decide how to write better.
>>>
>>> Igor
>>>
>>> On 04/01/2014 04:45 PM, Erik Helin wrote:
>>>> On 2014-04-01 11:05, Andrey Zakharov wrote:
>>>>> Hi, Erik. Thanks for comments.
>>>>>
>>>>> On 01.04.2014 10:49, Erik Helin wrote:
>>>>>> Andrey,
>>>>>>
>>>>>> a couple of comments:
>>>>>> - We do not use the @author tag in the tests
>>>>>>   (if you've seen other tests have the @author tag, then that is a
>>>>>> bug)
>>>>> removed
>>>>>> - I'm not a big fan of using inheritance for sharing code between
>>>>>>   tests because it makes it very hard to open a test, e.g.
>>>>>>   TestHumongousShrinkHeap.java, and see what it does.
>>>>> Agreed, I'm too. But doubled code leads to harder maintenance.
>>>>
>>>> Duplicated code often leads to harder maintenance, but it is not the
>>>> only thing making code hard to maintain. By using inheritance, you 
>>>> have
>>>> moved the control flow from the test to another file. When I want to
>>>> look at test test because it failed, I want to immediately see what it
>>>> did. I do *not* want to traverse an inheritance hierarchy and build a
>>>> mental model of how the control flows up and down in the inheritance
>>>> hierarchy. It is very important that tests are explicit and clearly
>>>> describe what they are testing.
>>>>
>>>> Looking at the code in TestShrinkHeap::test:
>>>>
>>>> public final void test() {
>>>>     System.gc();
>>>>     MemoryUsagePrinter.printMemoryUsage("init");
>>>>
>>>>     eat();
>>>>     MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>     MemoryUsage muFull =
>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>
>>>>     free();
>>>>     MemoryUsagePrinter.printMemoryUsage("free");
>>>>     MemoryUsage muFree =
>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>
>>>>     assertLessThan(muFree.getCommitted(), muFull.getCommitted(),
>>>>                    ...));
>>>> }
>>>>
>>>> You can easily move the control flow back into tests and share code 
>>>> with
>>>> utility classes, for example:
>>>>
>>>> public class TestHumongousShrinkHeap {
>>>>      ....
>>>>
>>>>      private void eat() {
>>>>          // old eat code
>>>>          ShrinkHeapUtils.log("eat");
>>>>      }
>>>>
>>>>      private void free() {
>>>>         // old free code
>>>>         ShrinkHeapUtils.log("free");
>>>>      }
>>>>
>>>>      public final void test() {
>>>>          System.gc();
>>>>          ShrinkHeapUtils.log("init");
>>>>
>>>>          eat();
>>>>          MemoryUsage full = ShrinkHeapUtils.getMemoryUsage();
>>>>
>>>>          free();
>>>>          MemoryUsage free = ShrinkHeapUtils.getMemoryUsage();
>>>>
>>>>          ShrinkHeapUtils.assertLessThan(free, full);
>>>>      }
>>>> }
>>>>
>>>> Now you can move the code from TestShrinkHeap to ShrinkHeapUtils. You
>>>> are now duplicating the call to System.gc(), the calls to eat and 
>>>> free,
>>>> the log calls, the getMemoryUsage calls and the assert. That is nine
>>>> lines of code.
>>>>
>>>> Duplicating nine lines of code and being able to see the flow in the
>>>> test itself is better than sharing the nine lines of code and not 
>>>> being
>>>> able to see the what test is doing.
>>>>
>>>> Thanks,
>>>> Erik
>>>>
>>>>>>
>>>>>>   The code you share in TestShrinkHeap is basically the check and 
>>>>>> the
>>>>>>   control flow of the tests. I would prefer if you could move the
>>>>>>   control flow (System.gc(), sample, eat, sample, free, check 
>>>>>> samples)
>>>>>>   into the tests and then write helper functions for retrieving the
>>>>>>   flag values.
>>>>>>
>>>>>>   As for the check, please use the assertions in
>>>>>>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>>>>>   throwing a RuntimeException.
>>>>> Good point, changed.
>>>>> Jesper, can we upload webrev.10 from attachment? Thanks.
>>>>> I'm still need GC reviewers to approve push.
>>>>>
>>>>> Thanks.
>>>>>>
>>>>>> Thanks,
>>>>>> Erik
>>>>>>
>>>>>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> New webrev uploaded.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>>>>>
>>>>>>> I'm not a Reviewer either so if you got Igor's blessing already, my
>>>>>>> review won't be enough to push unfortunately.
>>>>>>> /Jesper
>>>>>>>
>>>>>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>>>>>> Hi,
>>>>>>>> Jepser, here is updated webrev.09
>>>>>>>> Thomas, Jesper can you review it as well?
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>>>>>> Andrey,
>>>>>>>>>
>>>>>>>>> 1. TEST.groups:
>>>>>>>>> please update copyright year:
>>>>>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All 
>>>>>>>>>> rights
>>>>>>>>>> reserved.
>>>>>>>>> should be
>>>>>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates. 
>>>>>>>>>> All
>>>>>>>>>> rights
>>>>>>>>>> reserved.
>>>>>>>>>
>>>>>>>>> 2. TestShrinkHeap.java
>>>>>>>>>>   22  */
>>>>>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>>>>>> add empty line between 22 and 23 as you do in all other files,
>>>>>>>>>
>>>>>>>>> otherwise it looks good to me.
>>>>>>>>>
>>>>>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in
>>>>>>>>> 'Reviewed-by'
>>>>>>>>> section )
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Igor
>>>>>>>>>
>>>>>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>>>>>> Hi, team
>>>>>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>>>>>> Webrev uploaded:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>>
>>>>>>>>>>> /Jesper
>>>>>>>>>> Thank you, Jesper.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>>>>>> Hi! Here is webrev.08,
>>>>>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>>>>>
>>>>>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. both tests:
>>>>>>>>>>>>>>   48     public void eat() {
>>>>>>>>>>>>>> 61     public void free() {
>>>>>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>>>>>  32  */
>>>>>>>>>>>>>>  33 import 
>>>>>>>>>>>>>> com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>>>>>> add empty line between these lines or remove empty line 
>>>>>>>>>>>>> #32 in
>>>>>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>>>>>  62         //do not free last one list
>>>>>>>>>>>>> space after '//'
>>>>>>>>>>>>> 3. both tests:
>>>>>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>>>>>> after @bug you should specify product bug ids which can be
>>>>>>>>>>>>> tested by
>>>>>>>>>>>>> this
>>>>>>>>>>>>> test. I guess 8016479 instead of 8037924, and 
>>>>>>>>>>>>> 8036025/8037925.
>>>>>>>>>>>>>
>>>>>>>>>>>>> otherwise it looks good, thank you for your work and 
>>>>>>>>>>>>> patience )
>>>>>>>>>>>>>
>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>>>>>> Igor, please, see comment below, everything uncommented is
>>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()' 'TestShrinkHeap.gc()'?
>>>>>>>>>>>>>>> I cut this out.
>>>>>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for
>>>>>>>>>>>>>>>> it --
>>>>>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Not sure is it applicable for me, because every time in
>>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to
>>>>>>>>>>>>>>>>>> review. It
>>>>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>  45 public static byte[] temp;
>>>>>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should 
>>>>>>>>>>>>>>>>>>> have one
>>>>>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> protected static final String 
>>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>>>>>> protected static final String 
>>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage(); 
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage(); 
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() < 
>>>>>>>>>>>>>>>>>>> muFull.getCommitted())) {
>>>>>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>>>>>       String.format("committed free heap size is not 
>>>>>>>>>>>>>>>>>>> less
>>>>>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>>>>>> committed full heap size, heap hasn't been 
>>>>>>>>>>>>>>>>>>> shrunk?%n%s =
>>>>>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(), 
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue() 
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full GC");
>>>>>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/ 
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string
>>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. 
>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry
>>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary and
>>>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 26 * @key gc
>>>>>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc', 
>>>>>>>>>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>>>> I think that this is used for test execution - to
>>>>>>>>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, 
>>>>>>>>>>>>>>>>>>>>> so we
>>>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/ 
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct one is
>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/. 
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string
>>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. 
>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry
>>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>>>>>   44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's not
>>>>>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>>>>   96 StringBuilder strb = new
>>>>>>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than
>>>>>>>>>>>>>>>>>>>>>>>>>> committed
>>>>>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>>>>>   97
>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator")); 
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>   99
>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator")); 
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>  101 throw new
>>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>>>>>  throw new
>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap 
>>>>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>>>>> heap
>>>>>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue)); 
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/ 
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/ 
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> bug:
>>>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924 
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>
>>



From jon.masamitsu at oracle.com  Wed Apr  2 16:38:00 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 02 Apr 2014 09:38:00 -0700
Subject: RFR(s): 8038461: Test
	gc/g1/TestStringDeduplicationMemoryUsage.java
	fails with unexpected memory usage
In-Reply-To: <533BE22A.3000105@oracle.com>
References: <53357C14.3060902@oracle.com> <53392C28.9090402@oracle.com>
	<D0508778-5D7A-4473-A646-22AEDF04085F@oracle.com>
	<533B345D.70902@oracle.com> <533BE22A.3000105@oracle.com>
Message-ID: <533C3CE8.8000402@oracle.com>


On 4/2/14 3:10 AM, Per Liden wrote:
> Hi Jon,
>
> On 04/01/2014 11:49 PM, Jon Masamitsu wrote:
>> Per,
>>
>> Is there a way you could get generateString() to return the
>> sum of the sizes of the strings (minus 1 string)?  Instead of the doing
>> the calculation of bytesSaved?
>
> Could you elaborate a bit, I'm not quite sure I understand what you 
> mean. Is there something about the bytesSaved calculation you don't like?

The only thing about the calculation of bytesSaved is that I had to look at
it (to understand how it was being done).  If the test failed and I had to
debug the test, I would again have to look at it to understand that it
was right.

If I looked at generateString() and all it did was add up the sum of the
size of each string that it created, it would be easier to understand.
>
> Each MemoryUsageTest instance could of course return the sizes of all 
> character arrays it has created (instead of just the array header 
> size), is that what you're suggesting? There would still be a 
> bytesSaved calculation inside testMemoryUsage() though, so I have a 
> feeling that's not what you meant.
>
> Note that generateString()/createStrings() has no real understanding 
> of whether deduplication is enabled or not and they are also used by 
> other tests, which don't care about sizes.

If generateString() would return the sum of the sizes of the strings 
created,
the caller could figure out what it wanted to do with the number (for 
example
figure out how to decrement it to calculate the deduplication savings).

If this doesn't work here or would be too messy in any way to implement,
forget it.  The test looks right so you can consider it reviewed by me.

Jon

>
> cheers,
> /Per
>
>>
>> Jon
>>
>> On 4/1/14 12:54 AM, Per Liden wrote:
>>> Thanks Stefan! Need one more Review.
>>>
>>> /Per
>>>
>>> On 31 Mar 2014, at 10:49, Stefan Johansson
>>> <stefan.johansson at oracle.com> wrote:
>>>
>>>> Looks good!
>>>>
>>>> Stefan
>>>>
>>>> On 2014-03-28 14:41, Per Liden wrote:
>>>>> Hi,
>>>>>
>>>>> Could I please have this test fix reviewed.
>>>>>
>>>>> Summary: The test in question tries to calculate the amount of
>>>>> memory saved when using string deduplication. The problem is that
>>>>> the JVM doing this calculation could be running without compressed
>>>>> class pointers when the JVM doing the actual string deduplication is
>>>>> running with compressed class pointers. When this happens the JVMs
>>>>> will have different views on the size of an array header, which in
>>>>> the end makes the calculation incorrect and the test thinks the
>>>>> deduplication failed. Exactly this situation happened in a nightly
>>>>> test run. This fix makes sure that the array header size of the JVM
>>>>> doing the deduplication is communicated to the JVM doing the memory
>>>>> savings calculation.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038461
>>>>> Webrev: http://cr.openjdk.java.net/~pliden/8038461/webrev.0/
>>>>>
>>>>> /Per
>>>>>
>>
>



From jon.masamitsu at oracle.com  Wed Apr  2 16:39:46 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 02 Apr 2014 09:39:46 -0700
Subject: RFR: 8029186: regression-hotspot nightly failure:
	assert(FLAG_IS_DEFAULT(MaxNewSize) || MaxNewSize < MaxHeapSize) failed
In-Reply-To: <533BF270.7090104@oracle.com>
References: <5331A0D9.4060502@oracle.com>
	<5331AFC8.2060906@oracle.com>	<5332B096.6050409@oracle.com>
	<533BF270.7090104@oracle.com>
Message-ID: <533C3D52.8020609@oracle.com>


On 4/2/14 4:20 AM, Stefan Johansson wrote:
> I got a second review from Jon Masamitsu, he had some comments and 
> these have been fixed.
>
> Here's an incremental webrev:
> http://cr.openjdk.java.net/~sjohanss/8029186/webrev.01-02/
>
> Here's the full change:
> http://cr.openjdk.java.net/~sjohanss/8029186/webrev.02/
>
> Thanks Jon and Jesper for reviewing this.

Thanks.

Reviewed.

Jon

>
> Cheers,
> Stefan
>
> On 2014-03-26 11:48, Stefan Johansson wrote:
>> Thanks Jesper for looking at this.
>>
>> I actually found an issue myself when going over the code. The 
>> problem is in initialize_flags for the TwoGenerationalPolicy, where I 
>> verify that the desired new_size is within the allowed bounds. I 
>> realized that I need to check against the flag MaxNewSize since the 
>> member might not have been initialized yet. Below is the diff for the 
>> change and an updated webrev can be found here:
>> http://cr.openjdk.java.net/~sjohanss/8029186/webrev.01/
>>
>> ---
>> @@ -422,7 +422,9 @@
>>    if (FLAG_IS_CMDLINE(OldSize) && !FLAG_IS_CMDLINE(NewSize)) {
>>      if (OldSize < _initial_heap_byte_size) {
>>        size_t new_size = _initial_heap_byte_size - OldSize;
>> -      if (new_size >= _min_gen0_size && new_size <= _max_gen0_size) {
>> +      // Need to compare against the flag value for max since 
>> _max_gen0_size
>> +      // might not have been set yet.
>> +      if (new_size >= _min_gen0_size && new_size <= MaxNewSize) {
>>          FLAG_SET_ERGO(uintx, NewSize, new_size);
>>          _initial_gen0_size = NewSize;
>>        }
>> ---
>>
>> Thanks,
>> Stefan
>>
>> On 2014-03-25 17:33, Jesper Wilhelmsson wrote:
>>> Ship it!
>>> /Jesper
>>>
>>> Stefan Johansson skrev 25/3/14 16:29:
>>>> Hi,
>>>>
>>>> Please review this fix for:
>>>> https://bugs.openjdk.java.net/browse/JDK-8029186
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~sjohanss/8029186/webrev.00/
>>>>
>>>> Summary:
>>>> There have been a lot of bugs due to corner cases with heap sizing 
>>>> flags. This
>>>> change strives to fix this particular problem and at the same time 
>>>> somewhat
>>>> simplify the collector policy. I've also added some assertions to 
>>>> ensure that
>>>> the sizing of the heap is more correct.
>>>>
>>>> Testing:
>>>> * JPRT sanity and JTREG
>>>> * Adhoc aurora run for tmtools tests
>>>> * Script that verifies that we don't get assertions during startup 
>>>> for different
>>>> combinations of NewSize, MaxNewSize, OldSize, Xms and Xmx.
>>>>
>>>> Thanks,
>>>> StefanJ
>>
>



From jesper.wilhelmsson at oracle.com  Wed Apr  2 16:45:59 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 02 Apr 2014 18:45:59 +0200
Subject: RFR(XS): 8039089 - List verification enabled in product builds
Message-ID: <533C3EC7.8050800@oracle.com>

Hi,

This is a one-liner to stop ConcurrentMark::completeCleanup() from running list 
verification in product builds.

It is currently calling _cleanup_list.verify_list(). This will unconditionally 
run the verification, even in product builds. I replaced it with 
verify_optional() that only runs the verification code in debug builds.

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

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

Thanks,
/Jesper


From andrey.x.zakharov at oracle.com  Wed Apr  2 17:02:18 2014
From: andrey.x.zakharov at oracle.com (Andrey Zakharov)
Date: Wed, 02 Apr 2014 21:02:18 +0400
Subject: RFR 8037925: CMM Testing: an allocated humongous object at the
	end of the heap should not prevents shrinking the heap
In-Reply-To: <533B2DC9.5010903@oracle.com>
References: <53332456.5060407@oracle.com>
	<533326B8.4020407@oracle.com>	<53341B70.8070603@oracle.com>
	<5334A527.4090209@oracle.com>	<53357A9E.4000505@oracle.com>
	<53358125.8020803@oracle.com> <53367041.5060203@oracle.com>
	<533B2DC9.5010903@oracle.com>
Message-ID: <533C429A.2080005@oracle.com>

Hi, Jon
On 02.04.2014 01:21, Jon Masamitsu wrote:
> Seems like an out-of-memory (OOME) can be thrown here (or anywhere below
> this block of code).  Will an OOME be considered a pass, fail or
> test-not-run?
Yes, its really an question for me, from one point of view, we should 
catch OOM and move forward to exit(0),
from another point - such things should be handled by test harness. Test 
should have some @tag about 1G memory its used and harness should skip 
test and notify about this if machine memory is below needed.
Maybe there is another right way.



From jesper.wilhelmsson at oracle.com  Wed Apr  2 17:04:19 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 02 Apr 2014 19:04:19 +0200
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533C3A97.1090902@oracle.com>
References: <5332FA20.5070607@oracle.com>	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>	<53394053.2070502@oracle.com>
	<533955B0.7000601@oracle.com>	<533A6165.80704@oracle.com>
	<533A8141.2030608@oracle.com>	<533AB4F9.6090509@oracle.com>
	<533ABE29.30805@oracle.com> <533B252B.9080806@oracle.com>
	<533BD346.4040107@oracle.com> <533C3A97.1090902@oracle.com>
Message-ID: <533C4313.8030909@oracle.com>

Jon,

In this case I think finding the sources is as easy as we can wish for, since 
these are jtreg-tests and the sources are located in the hotspot repository 
(look in hotspot/test/).

However, I don't think the ease of finding the sources motivates splitting the 
control flow of the test over two source files. Your argument of being able to 
quickly see what the test is doing is more important imo.
/Jesper


Jon Masamitsu skrev 2/4/14 18:28:
>
> On 4/2/14 2:07 AM, Igor Ignatyev wrote:
>> Jon,
>>
>>> Given the current implementation of these tests, what will I need
>>> to do to understand what TestDynShrinkHeap is doing?
>>
>> You'll have to open one more file -- TestShrinkHeap, and it's easy to
>> understand since you see that TestDynShrinkHeap is a subclass of
>> TestShrinkHeap. I offered to use inheritance, since my understanding is that
>> we are going to write other tests w/ the same control flow, and for me in
>> future it'll cost too much to maintain N tests w/ copy-pasted control flow.
>
> My problem in the past was that I could not find other
> source files.  Will that be fixed?  I don't need to look
> at the sources often so tend to forget where they are.
> Actually, I don't think I've ever found the sources if
> they were not in the nightly testing "dir" test directory.
>
>>
>> But I understand your point and don't insist on using inheritance, as I said
>> before:
>>> Since these tests are gc tests, it's up to you to decide how to write better.
>> I just want to avoid having tens tests w/ the almost same code, since changing
>> something in them will be very hard.
> Avoiding the duplication would be nice.
>
> I usually need to look at what the test is doing because
> I'm having trouble reproducing the failure and want
> to understand if tweaking the jvm flags would help
> reproduce it.   This pushes work back to SQE but
> if I only had to look at failures that had a reliable
> reproducer, I would not need to look at the test sources.
> That might just be the way I work though.
>
> Maybe some way for me to search for source files.
> Or some tool to assemble the source files into a
> directory.
>
> Jon
>
>>
>> Thanks,
>> Igor
>>
>> On 04/02/2014 12:44 AM, Jon Masamitsu wrote:
>>> Igor,
>>>
>>> If I see a test failure of TestDynShrinkHeap, I need to understand
>>> what that test is doing.  My recent experience (nightly testing)
>>> tells me that I will easily be able to look at
>>> TestDynShrinkHeap.java but maybe not much
>>> more.
>>>
>>> Given the current implementation of these tests, what will I need
>>> to do to understand what TestDynShrinkHeap is doing?
>>>
>>> Jon
>>>
>>>
>>> On 4/1/14 6:24 AM, Igor Ignatyev wrote:
>>>> Erik/Jesper,
>>>>
>>>> g1/TestHumongousShrinkHeap, parallelScavenge/TestDynShrinkHeap are
>>>> test cases of TestShrinkHeap, so they suppose to share control flow,
>>>> or more precisely they shouldn't contain control-flow.
>>>>
>>>> let's say they just specify function in TestShrinkHeap:
>>>>> TestShrinkHeap {
>>>>>  Runnable eat;
>>>>>  Runnable free;
>>>>>  TestShrinkHeap(Runnable eat, Runnable free) { ... }
>>>>>  void test() {
>>>>>     System.gc();
>>>>>     MemoryUsagePrinter.printMemoryUsage("init");
>>>>>
>>>>>     eat.run();
>>>>>     MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>     MemoryUsage muFull =
>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>
>>>>>     free.run();
>>>>>     MemoryUsagePrinter.printMemoryUsage("free");
>>>>>     MemoryUsage muFree =
>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>
>>>>>     assertLessThan(muFree.getCommitted(), muFull.getCommitted(),
>>>>>                    ...));
>>>>>
>>>>>  }
>>>>> }
>>>>
>>>> then g1/TestHumongousShrinkHeap is
>>>> new TestShrinkHeap(
>>>> ()->{
>>>>> int HumongousObjectSize = Math.round(.9f * PAGE_SIZE);
>>>>>   51         System.out.println("Will allocate objects of size=" +
>>>>>   52 MemoryUsagePrinter.humanReadableByteCount(HumongousObjectSize,
>>>>> true));
>>>>>   53
>>>>>   54         for (int i = 0; i < PAGES_NUM; i++) {
>>>>>   55             ArrayList<byte[]> stuff = new ArrayList<>();
>>>>>   56             eatList(stuff, 100, HumongousObjectSize);
>>>>>   57             MemoryUsagePrinter.printMemoryUsage("eat #" + i);
>>>>>   58             garbage.add(stuff);
>>>>>   59         }
>>>> },
>>>> ()->{
>>>>>   63         // do not free last one list
>>>>>   64         garbage.subList(0, garbage.size() - 1).clear();
>>>>>   65
>>>>>   66         // do not free last one element from last list
>>>>>   67         ArrayList stuff = garbage.get(garbage.size() - 1);
>>>>>   68         stuff.subList(0, stuff.size() - 1).clear();
>>>>>   69         System.gc();
>>>> }
>>>>
>>>> from my point of view, it's quite simple to understand and maintain
>>>> (of course if we replace lambdas by method references), and it's much
>>>> easier to write add new test-cases and extend test's logic.
>>>>
>>>> however, it's just a question of code-style and preferences. Since
>>>> these tests are gc tests, it's up to you to decide how to write better.
>>>>
>>>> Igor
>>>>
>>>> On 04/01/2014 04:45 PM, Erik Helin wrote:
>>>>> On 2014-04-01 11:05, Andrey Zakharov wrote:
>>>>>> Hi, Erik. Thanks for comments.
>>>>>>
>>>>>> On 01.04.2014 10:49, Erik Helin wrote:
>>>>>>> Andrey,
>>>>>>>
>>>>>>> a couple of comments:
>>>>>>> - We do not use the @author tag in the tests
>>>>>>>   (if you've seen other tests have the @author tag, then that is a
>>>>>>> bug)
>>>>>> removed
>>>>>>> - I'm not a big fan of using inheritance for sharing code between
>>>>>>>   tests because it makes it very hard to open a test, e.g.
>>>>>>>   TestHumongousShrinkHeap.java, and see what it does.
>>>>>> Agreed, I'm too. But doubled code leads to harder maintenance.
>>>>>
>>>>> Duplicated code often leads to harder maintenance, but it is not the
>>>>> only thing making code hard to maintain. By using inheritance, you have
>>>>> moved the control flow from the test to another file. When I want to
>>>>> look at test test because it failed, I want to immediately see what it
>>>>> did. I do *not* want to traverse an inheritance hierarchy and build a
>>>>> mental model of how the control flows up and down in the inheritance
>>>>> hierarchy. It is very important that tests are explicit and clearly
>>>>> describe what they are testing.
>>>>>
>>>>> Looking at the code in TestShrinkHeap::test:
>>>>>
>>>>> public final void test() {
>>>>>     System.gc();
>>>>>     MemoryUsagePrinter.printMemoryUsage("init");
>>>>>
>>>>>     eat();
>>>>>     MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>     MemoryUsage muFull =
>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>
>>>>>     free();
>>>>>     MemoryUsagePrinter.printMemoryUsage("free");
>>>>>     MemoryUsage muFree =
>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>
>>>>>     assertLessThan(muFree.getCommitted(), muFull.getCommitted(),
>>>>>                    ...));
>>>>> }
>>>>>
>>>>> You can easily move the control flow back into tests and share code with
>>>>> utility classes, for example:
>>>>>
>>>>> public class TestHumongousShrinkHeap {
>>>>>      ....
>>>>>
>>>>>      private void eat() {
>>>>>          // old eat code
>>>>>          ShrinkHeapUtils.log("eat");
>>>>>      }
>>>>>
>>>>>      private void free() {
>>>>>         // old free code
>>>>>         ShrinkHeapUtils.log("free");
>>>>>      }
>>>>>
>>>>>      public final void test() {
>>>>>          System.gc();
>>>>>          ShrinkHeapUtils.log("init");
>>>>>
>>>>>          eat();
>>>>>          MemoryUsage full = ShrinkHeapUtils.getMemoryUsage();
>>>>>
>>>>>          free();
>>>>>          MemoryUsage free = ShrinkHeapUtils.getMemoryUsage();
>>>>>
>>>>>          ShrinkHeapUtils.assertLessThan(free, full);
>>>>>      }
>>>>> }
>>>>>
>>>>> Now you can move the code from TestShrinkHeap to ShrinkHeapUtils. You
>>>>> are now duplicating the call to System.gc(), the calls to eat and free,
>>>>> the log calls, the getMemoryUsage calls and the assert. That is nine
>>>>> lines of code.
>>>>>
>>>>> Duplicating nine lines of code and being able to see the flow in the
>>>>> test itself is better than sharing the nine lines of code and not being
>>>>> able to see the what test is doing.
>>>>>
>>>>> Thanks,
>>>>> Erik
>>>>>
>>>>>>>
>>>>>>>   The code you share in TestShrinkHeap is basically the check and the
>>>>>>>   control flow of the tests. I would prefer if you could move the
>>>>>>>   control flow (System.gc(), sample, eat, sample, free, check samples)
>>>>>>>   into the tests and then write helper functions for retrieving the
>>>>>>>   flag values.
>>>>>>>
>>>>>>>   As for the check, please use the assertions in
>>>>>>>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>>>>>>   throwing a RuntimeException.
>>>>>> Good point, changed.
>>>>>> Jesper, can we upload webrev.10 from attachment? Thanks.
>>>>>> I'm still need GC reviewers to approve push.
>>>>>>
>>>>>> Thanks.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Erik
>>>>>>>
>>>>>>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> New webrev uploaded.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>>>>>>
>>>>>>>> I'm not a Reviewer either so if you got Igor's blessing already, my
>>>>>>>> review won't be enough to push unfortunately.
>>>>>>>> /Jesper
>>>>>>>>
>>>>>>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>>>>>>> Hi,
>>>>>>>>> Jepser, here is updated webrev.09
>>>>>>>>> Thomas, Jesper can you review it as well?
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>>>>>>> Andrey,
>>>>>>>>>>
>>>>>>>>>> 1. TEST.groups:
>>>>>>>>>> please update copyright year:
>>>>>>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All rights
>>>>>>>>>>> reserved.
>>>>>>>>>> should be
>>>>>>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates. All
>>>>>>>>>>> rights
>>>>>>>>>>> reserved.
>>>>>>>>>>
>>>>>>>>>> 2. TestShrinkHeap.java
>>>>>>>>>>>   22  */
>>>>>>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>>>>>>> add empty line between 22 and 23 as you do in all other files,
>>>>>>>>>>
>>>>>>>>>> otherwise it looks good to me.
>>>>>>>>>>
>>>>>>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in
>>>>>>>>>> 'Reviewed-by'
>>>>>>>>>> section )
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Igor
>>>>>>>>>>
>>>>>>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>>>>>>> Hi, team
>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>>>>>>> Webrev uploaded:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>>>
>>>>>>>>>>>> /Jesper
>>>>>>>>>>> Thank you, Jesper.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>>>>>>> Hi! Here is webrev.08,
>>>>>>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. both tests:
>>>>>>>>>>>>>>>   48     public void eat() {
>>>>>>>>>>>>>>> 61     public void free() {
>>>>>>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>>>>>>  32  */
>>>>>>>>>>>>>>>  33 import com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>>>>>>> add empty line between these lines or remove empty line #32 in
>>>>>>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>>>>>>  62         //do not free last one list
>>>>>>>>>>>>>> space after '//'
>>>>>>>>>>>>>> 3. both tests:
>>>>>>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>>>>>>> after @bug you should specify product bug ids which can be
>>>>>>>>>>>>>> tested by
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> test. I guess 8016479 instead of 8037924, and 8036025/8037925.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> otherwise it looks good, thank you for your work and patience )
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>>>>>>> Igor, please, see comment below, everything uncommented is
>>>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()' 'TestShrinkHeap.gc()'?
>>>>>>>>>>>>>>>> I cut this out.
>>>>>>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for
>>>>>>>>>>>>>>>>> it --
>>>>>>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Not sure is it applicable for me, because every time in
>>>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to
>>>>>>>>>>>>>>>>>>> review. It
>>>>>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>  45 public static byte[] temp;
>>>>>>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should have one
>>>>>>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> protected static final String MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>>>>>>> protected static final String MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() < muFull.getCommitted())) {
>>>>>>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>>>>>>       String.format("committed free heap size is not less
>>>>>>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>>>>>>> committed full heap size, heap hasn't been shrunk?%n%s =
>>>>>>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(),
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue()
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full GC");
>>>>>>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/
>>>>>>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string
>>>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry
>>>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary and
>>>>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 26 * @key gc
>>>>>>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc', please
>>>>>>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>>>>> I think that this is used for test execution - to
>>>>>>>>>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, so we
>>>>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct one is
>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string
>>>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior. Sorry
>>>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>>>>>>   44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's not
>>>>>>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>>>>>   96 StringBuilder strb = new
>>>>>>>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than
>>>>>>>>>>>>>>>>>>>>>>>>>>> committed
>>>>>>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>>>>>>   97
>>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>>   99
>>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>>  101 throw new
>>>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>>>>>>  throw new
>>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap size,
>>>>>>>>>>>>>>>>>>>>>>>>>> heap
>>>>>>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue));
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> bug:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>
>


From jesper.wilhelmsson at oracle.com  Wed Apr  2 17:06:51 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 02 Apr 2014 19:06:51 +0200
Subject: RFR: 8029186: regression-hotspot nightly failure:
	assert(FLAG_IS_DEFAULT(MaxNewSize) || MaxNewSize < MaxHeapSize) failed
In-Reply-To: <533C3D52.8020609@oracle.com>
References: <5331A0D9.4060502@oracle.com>	<5331AFC8.2060906@oracle.com>	<5332B096.6050409@oracle.com>	<533BF270.7090104@oracle.com>
	<533C3D52.8020609@oracle.com>
Message-ID: <533C43AB.8090007@oracle.com>

Ship it!
/Jesper

Jon Masamitsu skrev 2/4/14 18:39:
>
> On 4/2/14 4:20 AM, Stefan Johansson wrote:
>> I got a second review from Jon Masamitsu, he had some comments and these have
>> been fixed.
>>
>> Here's an incremental webrev:
>> http://cr.openjdk.java.net/~sjohanss/8029186/webrev.01-02/
>>
>> Here's the full change:
>> http://cr.openjdk.java.net/~sjohanss/8029186/webrev.02/
>>
>> Thanks Jon and Jesper for reviewing this.
>
> Thanks.
>
> Reviewed.
>
> Jon
>
>>
>> Cheers,
>> Stefan
>>
>> On 2014-03-26 11:48, Stefan Johansson wrote:
>>> Thanks Jesper for looking at this.
>>>
>>> I actually found an issue myself when going over the code. The problem is in
>>> initialize_flags for the TwoGenerationalPolicy, where I verify that the
>>> desired new_size is within the allowed bounds. I realized that I need to
>>> check against the flag MaxNewSize since the member might not have been
>>> initialized yet. Below is the diff for the change and an updated webrev can
>>> be found here:
>>> http://cr.openjdk.java.net/~sjohanss/8029186/webrev.01/
>>>
>>> ---
>>> @@ -422,7 +422,9 @@
>>>    if (FLAG_IS_CMDLINE(OldSize) && !FLAG_IS_CMDLINE(NewSize)) {
>>>      if (OldSize < _initial_heap_byte_size) {
>>>        size_t new_size = _initial_heap_byte_size - OldSize;
>>> -      if (new_size >= _min_gen0_size && new_size <= _max_gen0_size) {
>>> +      // Need to compare against the flag value for max since _max_gen0_size
>>> +      // might not have been set yet.
>>> +      if (new_size >= _min_gen0_size && new_size <= MaxNewSize) {
>>>          FLAG_SET_ERGO(uintx, NewSize, new_size);
>>>          _initial_gen0_size = NewSize;
>>>        }
>>> ---
>>>
>>> Thanks,
>>> Stefan
>>>
>>> On 2014-03-25 17:33, Jesper Wilhelmsson wrote:
>>>> Ship it!
>>>> /Jesper
>>>>
>>>> Stefan Johansson skrev 25/3/14 16:29:
>>>>> Hi,
>>>>>
>>>>> Please review this fix for:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8029186
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~sjohanss/8029186/webrev.00/
>>>>>
>>>>> Summary:
>>>>> There have been a lot of bugs due to corner cases with heap sizing flags. This
>>>>> change strives to fix this particular problem and at the same time somewhat
>>>>> simplify the collector policy. I've also added some assertions to ensure that
>>>>> the sizing of the heap is more correct.
>>>>>
>>>>> Testing:
>>>>> * JPRT sanity and JTREG
>>>>> * Adhoc aurora run for tmtools tests
>>>>> * Script that verifies that we don't get assertions during startup for
>>>>> different
>>>>> combinations of NewSize, MaxNewSize, OldSize, Xms and Xmx.
>>>>>
>>>>> Thanks,
>>>>> StefanJ
>>>
>>
>


From andrey.x.zakharov at oracle.com  Wed Apr  2 17:17:01 2014
From: andrey.x.zakharov at oracle.com (Andrey Zakharov)
Date: Wed, 02 Apr 2014 21:17:01 +0400
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533C3974.5080803@oracle.com>
References: <5332FA20.5070607@oracle.com>
	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>
	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>
	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>
	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>
	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>
	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>
	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>
	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>
	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>
	<53394053.2070502@oracle.com> <533955B0.7000601@oracle.com>
	<533A6165.80704@oracle.com> <533A8141.2030608@oracle.com>
	<533AB040.6000302@oracle.com> <533C3654.7020801@oracle.com>
	<533C3974.5080803@oracle.com>
Message-ID: <533C460D.5020707@oracle.com>

Hi, here is not uploaded yet webrev with totally reverted inheritance.
Jesper, can you please upload to your space.
Thanks.


On 02.04.2014 20:23, Igor Ignatyev wrote:
> Andrey,
>
> Why do test classes extend TestShrinkHeap?
>
> Igor
>
> On 04/02/2014 08:09 PM, Andrey Zakharov wrote:
>> Here is version without hidden testflow:
>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.11/
>> Thanks.
>>
>> On 01.04.2014 16:25, Jesper Wilhelmsson wrote:
>>> Uploaded:
>>>
>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.10/
>>>
>>> In general  would agree regarding avoiding duplicated code, but when
>>> it comes to the control flow I agree with Erik. More hard to read code
>>> leads to harder maintenance than duplicating a few lines of code.
>>> /Jesper
>>>
>>> Andrey Zakharov skrev 1/4/14 11:05:
>>>> Hi, Erik. Thanks for comments.
>>>>
>>>> On 01.04.2014 10:49, Erik Helin wrote:
>>>>> Andrey,
>>>>>
>>>>> a couple of comments:
>>>>> - We do not use the @author tag in the tests
>>>>>   (if you've seen other tests have the @author tag, then that is a 
>>>>> bug)
>>>> removed
>>>>> - I'm not a big fan of using inheritance for sharing code between
>>>>>   tests because it makes it very hard to open a test, e.g.
>>>>>   TestHumongousShrinkHeap.java, and see what it does.
>>>> Agreed, I'm too. But doubled code leads to harder maintenance.
>>>>>
>>>>>   The code you share in TestShrinkHeap is basically the check and the
>>>>>   control flow of the tests. I would prefer if you could move the
>>>>>   control flow (System.gc(), sample, eat, sample, free, check 
>>>>> samples)
>>>>>   into the tests and then write helper functions for retrieving the
>>>>>   flag values.
>>>>>
>>>>>   As for the check, please use the assertions in
>>>>>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>>>>   throwing a RuntimeException.
>>>> Good point, changed.
>>>> Jesper, can we upload webrev.10 from attachment? Thanks.
>>>> I'm still need GC reviewers to approve push.
>>>>
>>>> Thanks.
>>>>>
>>>>> Thanks,
>>>>> Erik
>>>>>
>>>>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> New webrev uploaded.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>>>>
>>>>>> I'm not a Reviewer either so if you got Igor's blessing already, my
>>>>>> review won't be enough to push unfortunately.
>>>>>> /Jesper
>>>>>>
>>>>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>>>>> Hi,
>>>>>>> Jepser, here is updated webrev.09
>>>>>>> Thomas, Jesper can you review it as well?
>>>>>>> Thanks.
>>>>>>>
>>>>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>>>>> Andrey,
>>>>>>>>
>>>>>>>> 1. TEST.groups:
>>>>>>>> please update copyright year:
>>>>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All 
>>>>>>>>> rights
>>>>>>>>> reserved.
>>>>>>>> should be
>>>>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates. All
>>>>>>>>> rights
>>>>>>>>> reserved.
>>>>>>>>
>>>>>>>> 2. TestShrinkHeap.java
>>>>>>>>>   22  */
>>>>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>>>>> add empty line between 22 and 23 as you do in all other files,
>>>>>>>>
>>>>>>>> otherwise it looks good to me.
>>>>>>>>
>>>>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in
>>>>>>>> 'Reviewed-by'
>>>>>>>> section )
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Igor
>>>>>>>>
>>>>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>>>>> Hi, team
>>>>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>>>>> Webrev uploaded:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>
>>>>>>>>>> /Jesper
>>>>>>>>> Thank you, Jesper.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>>>>> Hi! Here is webrev.08,
>>>>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>>>>
>>>>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>>>>
>>>>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>
>>>>>>>>>>>> 1. both tests:
>>>>>>>>>>>>>   48     public void eat() {
>>>>>>>>>>>>> 61     public void free() {
>>>>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>>>>  32  */
>>>>>>>>>>>>>  33 import com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>>>>> add empty line between these lines or remove empty line #32 in
>>>>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>>>>  62         //do not free last one list
>>>>>>>>>>>> space after '//'
>>>>>>>>>>>> 3. both tests:
>>>>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>>>>> after @bug you should specify product bug ids which can be
>>>>>>>>>>>> tested by
>>>>>>>>>>>> this
>>>>>>>>>>>> test. I guess 8016479 instead of 8037924, and 8036025/8037925.
>>>>>>>>>>>>
>>>>>>>>>>>> otherwise it looks good, thank you for your work and 
>>>>>>>>>>>> patience )
>>>>>>>>>>>>
>>>>>>>>>>>> Igor
>>>>>>>>>>>>
>>>>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>>
>>>>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>>>>> Igor, please, see comment below, everything uncommented is
>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()' 'TestShrinkHeap.gc()'?
>>>>>>>>>>>>>> I cut this out.
>>>>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for 
>>>>>>>>>>>>>>> it --
>>>>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not sure is it applicable for me, because every time in
>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to
>>>>>>>>>>>>>>>>> review. It
>>>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>  45 public static byte[] temp;
>>>>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should have 
>>>>>>>>>>>>>>>>>> one
>>>>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> protected static final String MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>>>>> protected static final String MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage(); 
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage(); 
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() < 
>>>>>>>>>>>>>>>>>> muFull.getCommitted())) {
>>>>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>>>>       String.format("committed free heap size is not
>>>>>>>>>>>>>>>>>> less than
>>>>>>>>>>>>>>>>>> committed full heap size, heap hasn't been shrunk?%n%s =
>>>>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(), 
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue() 
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full GC");
>>>>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/
>>>>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string 
>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary and
>>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 26 * @key gc
>>>>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc',
>>>>>>>>>>>>>>>>>>>>>> please don't
>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>>> I think that this is used for test execution - to
>>>>>>>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, so
>>>>>>>>>>>>>>>>>>>> we don't
>>>>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/ 
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct one is
>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/. 
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string 
>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>>>> 44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's not
>>>>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>>> 96 StringBuilder strb = new
>>>>>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than 
>>>>>>>>>>>>>>>>>>>>>>>>> committed
>>>>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>>>>   97
>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator")); 
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>   99
>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator")); 
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>  101 throw new
>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>>>>  throw new 
>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap
>>>>>>>>>>>>>>>>>>>>>>>> size, heap
>>>>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue)); 
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/ 
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/ 
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> bug:
>>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8037924.tar.gz
Type: application/gzip
Size: 204745 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140402/ee6ca973/8037924.tar.gz>

From jesper.wilhelmsson at oracle.com  Wed Apr  2 17:46:04 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 02 Apr 2014 19:46:04 +0200
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533C460D.5020707@oracle.com>
References: <5332FA20.5070607@oracle.com>
	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>
	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>
	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>
	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>
	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>
	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>
	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>
	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>
	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>
	<53394053.2070502@oracle.com> <533955B0.7000601@oracle.com>
	<533A6165.80704@oracle.com> <533A8141.2030608@oracle.com>
	<533AB040.6000302@oracle.com> <533C3654.7020801@oracle.com>
	<533C3974.5080803@oracle.com> <533C460D.5020707@oracle.com>
Message-ID: <533C4CDC.3070307@oracle.com>

New webrev is uploaded here:

http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.12/

/Jesper

Andrey Zakharov skrev 2/4/14 19:17:
> Hi, here is not uploaded yet webrev with totally reverted inheritance.
> Jesper, can you please upload to your space.
> Thanks.
>
>
> On 02.04.2014 20:23, Igor Ignatyev wrote:
>> Andrey,
>>
>> Why do test classes extend TestShrinkHeap?
>>
>> Igor
>>
>> On 04/02/2014 08:09 PM, Andrey Zakharov wrote:
>>> Here is version without hidden testflow:
>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.11/
>>> Thanks.
>>>
>>> On 01.04.2014 16:25, Jesper Wilhelmsson wrote:
>>>> Uploaded:
>>>>
>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.10/
>>>>
>>>> In general  would agree regarding avoiding duplicated code, but when
>>>> it comes to the control flow I agree with Erik. More hard to read code
>>>> leads to harder maintenance than duplicating a few lines of code.
>>>> /Jesper
>>>>
>>>> Andrey Zakharov skrev 1/4/14 11:05:
>>>>> Hi, Erik. Thanks for comments.
>>>>>
>>>>> On 01.04.2014 10:49, Erik Helin wrote:
>>>>>> Andrey,
>>>>>>
>>>>>> a couple of comments:
>>>>>> - We do not use the @author tag in the tests
>>>>>>   (if you've seen other tests have the @author tag, then that is a bug)
>>>>> removed
>>>>>> - I'm not a big fan of using inheritance for sharing code between
>>>>>>   tests because it makes it very hard to open a test, e.g.
>>>>>>   TestHumongousShrinkHeap.java, and see what it does.
>>>>> Agreed, I'm too. But doubled code leads to harder maintenance.
>>>>>>
>>>>>>   The code you share in TestShrinkHeap is basically the check and the
>>>>>>   control flow of the tests. I would prefer if you could move the
>>>>>>   control flow (System.gc(), sample, eat, sample, free, check samples)
>>>>>>   into the tests and then write helper functions for retrieving the
>>>>>>   flag values.
>>>>>>
>>>>>>   As for the check, please use the assertions in
>>>>>>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>>>>>   throwing a RuntimeException.
>>>>> Good point, changed.
>>>>> Jesper, can we upload webrev.10 from attachment? Thanks.
>>>>> I'm still need GC reviewers to approve push.
>>>>>
>>>>> Thanks.
>>>>>>
>>>>>> Thanks,
>>>>>> Erik
>>>>>>
>>>>>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> New webrev uploaded.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>>>>>
>>>>>>> I'm not a Reviewer either so if you got Igor's blessing already, my
>>>>>>> review won't be enough to push unfortunately.
>>>>>>> /Jesper
>>>>>>>
>>>>>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>>>>>> Hi,
>>>>>>>> Jepser, here is updated webrev.09
>>>>>>>> Thomas, Jesper can you review it as well?
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>>>>>> Andrey,
>>>>>>>>>
>>>>>>>>> 1. TEST.groups:
>>>>>>>>> please update copyright year:
>>>>>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All rights
>>>>>>>>>> reserved.
>>>>>>>>> should be
>>>>>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates. All
>>>>>>>>>> rights
>>>>>>>>>> reserved.
>>>>>>>>>
>>>>>>>>> 2. TestShrinkHeap.java
>>>>>>>>>>   22  */
>>>>>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>>>>>> add empty line between 22 and 23 as you do in all other files,
>>>>>>>>>
>>>>>>>>> otherwise it looks good to me.
>>>>>>>>>
>>>>>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in
>>>>>>>>> 'Reviewed-by'
>>>>>>>>> section )
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Igor
>>>>>>>>>
>>>>>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>>>>>> Hi, team
>>>>>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>>>>>> Webrev uploaded:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>>
>>>>>>>>>>> /Jesper
>>>>>>>>>> Thank you, Jesper.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>>>>>> Hi! Here is webrev.08,
>>>>>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>>>>>
>>>>>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. both tests:
>>>>>>>>>>>>>>   48     public void eat() {
>>>>>>>>>>>>>> 61     public void free() {
>>>>>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>>>>>  32  */
>>>>>>>>>>>>>>  33 import com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>>>>>> add empty line between these lines or remove empty line #32 in
>>>>>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>>>>>  62         //do not free last one list
>>>>>>>>>>>>> space after '//'
>>>>>>>>>>>>> 3. both tests:
>>>>>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>>>>>> after @bug you should specify product bug ids which can be
>>>>>>>>>>>>> tested by
>>>>>>>>>>>>> this
>>>>>>>>>>>>> test. I guess 8016479 instead of 8037924, and 8036025/8037925.
>>>>>>>>>>>>>
>>>>>>>>>>>>> otherwise it looks good, thank you for your work and patience )
>>>>>>>>>>>>>
>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>>>>>> Igor, please, see comment below, everything uncommented is
>>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()' 'TestShrinkHeap.gc()'?
>>>>>>>>>>>>>>> I cut this out.
>>>>>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for it --
>>>>>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Not sure is it applicable for me, because every time in
>>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to
>>>>>>>>>>>>>>>>>> review. It
>>>>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>  45 public static byte[] temp;
>>>>>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should have one
>>>>>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> protected static final String MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>>>>>> protected static final String MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() < muFull.getCommitted())) {
>>>>>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>>>>>       String.format("committed free heap size is not
>>>>>>>>>>>>>>>>>>> less than
>>>>>>>>>>>>>>>>>>> committed full heap size, heap hasn't been shrunk?%n%s =
>>>>>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(),
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue()
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full GC");
>>>>>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/
>>>>>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary and
>>>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 26 * @key gc
>>>>>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc',
>>>>>>>>>>>>>>>>>>>>>>> please don't
>>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>>>> I think that this is used for test execution - to
>>>>>>>>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, so
>>>>>>>>>>>>>>>>>>>>> we don't
>>>>>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct one is
>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string constant
>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>>>>> 44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's not
>>>>>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>>>> 96 StringBuilder strb = new
>>>>>>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than committed
>>>>>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>>>>>   97
>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>   99
>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>  101 throw new
>>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>>>>>  throw new RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap
>>>>>>>>>>>>>>>>>>>>>>>>> size, heap
>>>>>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue));
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> bug:
>>>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>
>>>
>


From bengt.rutisson at oracle.com  Wed Apr  2 20:26:30 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 2 Apr 2014 22:26:30 +0200
Subject: RFR(XS): 8039089 - List verification enabled in product builds
In-Reply-To: <533C3EC7.8050800@oracle.com>
References: <533C3EC7.8050800@oracle.com>
Message-ID: <0A35EF0C-BD58-4581-80A9-DBF7F96CCA92@oracle.com>


Jesper,

Looks good. 

Thanks for fixing this!

Bengt

> 2 apr 2014 kl. 18:45 skrev Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com>:
> 
> Hi,
> 
> This is a one-liner to stop ConcurrentMark::completeCleanup() from running list verification in product builds.
> 
> It is currently calling _cleanup_list.verify_list(). This will unconditionally run the verification, even in product builds. I replaced it with verify_optional() that only runs the verification code in debug builds.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8039089
> 
> Webrev: http://cr.openjdk.java.net/~jwilhelm/8039089/webrev/
> 
> Thanks,
> /Jesper


From jwha at google.com  Wed Apr  2 21:00:13 2014
From: jwha at google.com (Jungwoo Ha)
Date: Wed, 2 Apr 2014 14:00:13 -0700
Subject: Synchronization between JNI & GC
Message-ID: <CA+n_jhiPnhZ59uFPzfU+ksPi1RGqiqtJ4jZ55GGp+Y-6wG3nug@mail.gmail.com>

Is there a good write up on how the synchronization happen between JNI and
GC?
I am looking at the NewGlobalRef code but it has assert statement like this:

assert(!Universe::heap()->is_gc_active(), "can't extend the root set during
GC");

But how is this enforced by the JNI code calling NewGlobalRef?

Thanks,
Jungwoo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140402/aee9a136/attachment.htm>

From rednaxelafx at gmail.com  Wed Apr  2 21:40:09 2014
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Wed, 2 Apr 2014 14:40:09 -0700
Subject: Synchronization between JNI & GC
In-Reply-To: <CA+n_jhiPnhZ59uFPzfU+ksPi1RGqiqtJ4jZ55GGp+Y-6wG3nug@mail.gmail.com>
References: <CA+n_jhiPnhZ59uFPzfU+ksPi1RGqiqtJ4jZ55GGp+Y-6wG3nug@mail.gmail.com>
Message-ID: <CA+cQ+tSnZfyzsxCU1Q0HCK5mj52cvt_pG+yY7fbnRFvav-_Q1g@mail.gmail.com>

Hi Jungwoo,

To my knowledge, the only way JNI synchronizes with GC in HotSpot is by the
means of the GC locker and safepoint checks upon entry to VM.

When JNI code enters a critical section (e.g. after
calling GetPrimitiveArrayCritical() but before calling
ReleasePrimitiveArrayCritical()), HotSpot will activate the GC locker,
meaning it does not allow a GC at the moment. If a GC is requested when the
GC locker is active, HotSpot will try to expand the heap to fulfill the
allocation request instead of doing a GC.
When JNI exits all critical sections, the GC locker is inactivated. If
there had been a GC request when the GC locker was active, then a major GC
will be started at GC locker inactivation time.
-XX:+GCLockerInvokesConcurrent overrides that behavior to start a
concurrent GC cycle instead of a full GC.

In the general case, JNI synchronizes with the GC by safepoints. When JNI
calls into the VM (via JNI Invocation API) or returns to the VM, there are
safepoint checks at the entry point, so that if a GC safepoint is active,
it shouldn't run past the safepoint until GC completes. That's how the
assert you mentioned could work.

BTW, Universe::heap()->is_gc_active() only checks if there's a
stop-the-world GC activity happening right now. It doesn't care about the
concurrent phases.

Hope it helps,
Kris


On Wed, Apr 2, 2014 at 2:00 PM, Jungwoo Ha <jwha at google.com> wrote:

> Is there a good write up on how the synchronization happen between JNI and
> GC?
> I am looking at the NewGlobalRef code but it has assert statement like
> this:
>
> assert(!Universe::heap()->is_gc_active(), "can't extend the root set
> during GC");
>
> But how is this enforced by the JNI code calling NewGlobalRef?
>
> Thanks,
> Jungwoo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140402/79209533/attachment.htm>

From jwha at google.com  Wed Apr  2 22:11:34 2014
From: jwha at google.com (Jungwoo Ha)
Date: Wed, 2 Apr 2014 15:11:34 -0700
Subject: Synchronization between JNI & GC
In-Reply-To: <CA+cQ+tSnZfyzsxCU1Q0HCK5mj52cvt_pG+yY7fbnRFvav-_Q1g@mail.gmail.com>
References: <CA+n_jhiPnhZ59uFPzfU+ksPi1RGqiqtJ4jZ55GGp+Y-6wG3nug@mail.gmail.com>
	<CA+cQ+tSnZfyzsxCU1Q0HCK5mj52cvt_pG+yY7fbnRFvav-_Q1g@mail.gmail.com>
Message-ID: <CA+n_jhjp_DDP3aDyZSnMFDvbsQg215jWkh15J_VQfYxSVeaM1w@mail.gmail.com>

Thanks a lot! It really helped! --Jungwoo


On Wed, Apr 2, 2014 at 2:40 PM, Krystal Mok <rednaxelafx at gmail.com> wrote:

> Hi Jungwoo,
>
> To my knowledge, the only way JNI synchronizes with GC in HotSpot is by
> the means of the GC locker and safepoint checks upon entry to VM.
>
> When JNI code enters a critical section (e.g. after
> calling GetPrimitiveArrayCritical() but before calling
> ReleasePrimitiveArrayCritical()), HotSpot will activate the GC locker,
> meaning it does not allow a GC at the moment. If a GC is requested when the
> GC locker is active, HotSpot will try to expand the heap to fulfill the
> allocation request instead of doing a GC.
> When JNI exits all critical sections, the GC locker is inactivated. If
> there had been a GC request when the GC locker was active, then a major GC
> will be started at GC locker inactivation time.
> -XX:+GCLockerInvokesConcurrent overrides that behavior to start a
> concurrent GC cycle instead of a full GC.
>
> In the general case, JNI synchronizes with the GC by safepoints. When JNI
> calls into the VM (via JNI Invocation API) or returns to the VM, there are
> safepoint checks at the entry point, so that if a GC safepoint is active,
> it shouldn't run past the safepoint until GC completes. That's how the
> assert you mentioned could work.
>
> BTW, Universe::heap()->is_gc_active() only checks if there's a
> stop-the-world GC activity happening right now. It doesn't care about the
> concurrent phases.
>
> Hope it helps,
> Kris
>
>
> On Wed, Apr 2, 2014 at 2:00 PM, Jungwoo Ha <jwha at google.com> wrote:
>
>> Is there a good write up on how the synchronization happen between JNI
>> and GC?
>> I am looking at the NewGlobalRef code but it has assert statement like
>> this:
>>
>> assert(!Universe::heap()->is_gc_active(), "can't extend the root set
>> during GC");
>>
>> But how is this enforced by the JNI code calling NewGlobalRef?
>>
>> Thanks,
>> Jungwoo
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140402/9c5ac519/attachment.htm>

From thomas.schatzl at oracle.com  Thu Apr  3 08:35:24 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 03 Apr 2014 10:35:24 +0200
Subject: RFR(XS): 8039089 - List verification enabled in product builds
In-Reply-To: <533C3EC7.8050800@oracle.com>
References: <533C3EC7.8050800@oracle.com>
Message-ID: <1396514124.3018.14.camel@cirrus>

Hi Jesper,

On Wed, 2014-04-02 at 18:45 +0200, Jesper Wilhelmsson wrote:
> Hi,
> 
> This is a one-liner to stop ConcurrentMark::completeCleanup() from running list 
> verification in product builds.
> 
> It is currently calling _cleanup_list.verify_list(). This will unconditionally 
> run the verification, even in product builds. I replaced it with 
> verify_optional() that only runs the verification code in debug builds.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8039089
> 
> Webrev: http://cr.openjdk.java.net/~jwilhelm/8039089/webrev/


  looks good.

Some request though, as it is somewhat related: HeapRegionSetBase::add()
and HeapRegionSetBase::remove() should assert on that the prev-pointers
of the doubly linked list should be NULL, not only the next pointer.

However the change is fine as is to me.

Thomas




From per.liden at oracle.com  Thu Apr  3 08:35:58 2014
From: per.liden at oracle.com (Per Liden)
Date: Thu, 03 Apr 2014 10:35:58 +0200
Subject: RFR(s): 8038461: Test
	gc/g1/TestStringDeduplicationMemoryUsage.java
	fails with unexpected memory usage
In-Reply-To: <533C3CE8.8000402@oracle.com>
References: <53357C14.3060902@oracle.com> <53392C28.9090402@oracle.com>
	<D0508778-5D7A-4473-A646-22AEDF04085F@oracle.com>
	<533B345D.70902@oracle.com> <533BE22A.3000105@oracle.com>
	<533C3CE8.8000402@oracle.com>
Message-ID: <533D1D6E.9060103@oracle.com>

Ok, thanks Jon!

/Per

On 04/02/2014 06:38 PM, Jon Masamitsu wrote:
>
> On 4/2/14 3:10 AM, Per Liden wrote:
>> Hi Jon,
>>
>> On 04/01/2014 11:49 PM, Jon Masamitsu wrote:
>>> Per,
>>>
>>> Is there a way you could get generateString() to return the
>>> sum of the sizes of the strings (minus 1 string)?  Instead of the doing
>>> the calculation of bytesSaved?
>>
>> Could you elaborate a bit, I'm not quite sure I understand what you
>> mean. Is there something about the bytesSaved calculation you don't like?
>
> The only thing about the calculation of bytesSaved is that I had to look at
> it (to understand how it was being done).  If the test failed and I had to
> debug the test, I would again have to look at it to understand that it
> was right.
>
> If I looked at generateString() and all it did was add up the sum of the
> size of each string that it created, it would be easier to understand.
>>
>> Each MemoryUsageTest instance could of course return the sizes of all
>> character arrays it has created (instead of just the array header
>> size), is that what you're suggesting? There would still be a
>> bytesSaved calculation inside testMemoryUsage() though, so I have a
>> feeling that's not what you meant.
>>
>> Note that generateString()/createStrings() has no real understanding
>> of whether deduplication is enabled or not and they are also used by
>> other tests, which don't care about sizes.
>
> If generateString() would return the sum of the sizes of the strings
> created,
> the caller could figure out what it wanted to do with the number (for
> example
> figure out how to decrement it to calculate the deduplication savings).
>
> If this doesn't work here or would be too messy in any way to implement,
> forget it.  The test looks right so you can consider it reviewed by me.
>
> Jon
>
>>
>> cheers,
>> /Per
>>
>>>
>>> Jon
>>>
>>> On 4/1/14 12:54 AM, Per Liden wrote:
>>>> Thanks Stefan! Need one more Review.
>>>>
>>>> /Per
>>>>
>>>> On 31 Mar 2014, at 10:49, Stefan Johansson
>>>> <stefan.johansson at oracle.com> wrote:
>>>>
>>>>> Looks good!
>>>>>
>>>>> Stefan
>>>>>
>>>>> On 2014-03-28 14:41, Per Liden wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Could I please have this test fix reviewed.
>>>>>>
>>>>>> Summary: The test in question tries to calculate the amount of
>>>>>> memory saved when using string deduplication. The problem is that
>>>>>> the JVM doing this calculation could be running without compressed
>>>>>> class pointers when the JVM doing the actual string deduplication is
>>>>>> running with compressed class pointers. When this happens the JVMs
>>>>>> will have different views on the size of an array header, which in
>>>>>> the end makes the calculation incorrect and the test thinks the
>>>>>> deduplication failed. Exactly this situation happened in a nightly
>>>>>> test run. This fix makes sure that the array header size of the JVM
>>>>>> doing the deduplication is communicated to the JVM doing the memory
>>>>>> savings calculation.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038461
>>>>>> Webrev: http://cr.openjdk.java.net/~pliden/8038461/webrev.0/
>>>>>>
>>>>>> /Per
>>>>>>
>>>
>>
>



From stefan.johansson at oracle.com  Thu Apr  3 09:41:05 2014
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 03 Apr 2014 11:41:05 +0200
Subject: RFR: 8029186: regression-hotspot nightly failure:
	assert(FLAG_IS_DEFAULT(MaxNewSize) || MaxNewSize < MaxHeapSize) failed
In-Reply-To: <533C43AB.8090007@oracle.com>
References: <5331A0D9.4060502@oracle.com>	<5331AFC8.2060906@oracle.com>	<5332B096.6050409@oracle.com>	<533BF270.7090104@oracle.com>	<533C3D52.8020609@oracle.com>
	<533C43AB.8090007@oracle.com>
Message-ID: <533D2CB1.6060604@oracle.com>

Thanks Jon and Jesper!
Stefan

On 2014-04-02 19:06, Jesper Wilhelmsson wrote:
> Ship it!
> /Jesper
>
> Jon Masamitsu skrev 2/4/14 18:39:
>>
>> On 4/2/14 4:20 AM, Stefan Johansson wrote:
>>> I got a second review from Jon Masamitsu, he had some comments and 
>>> these have
>>> been fixed.
>>>
>>> Here's an incremental webrev:
>>> http://cr.openjdk.java.net/~sjohanss/8029186/webrev.01-02/
>>>
>>> Here's the full change:
>>> http://cr.openjdk.java.net/~sjohanss/8029186/webrev.02/
>>>
>>> Thanks Jon and Jesper for reviewing this.
>>
>> Thanks.
>>
>> Reviewed.
>>
>> Jon
>>
>>>
>>> Cheers,
>>> Stefan
>>>
>>> On 2014-03-26 11:48, Stefan Johansson wrote:
>>>> Thanks Jesper for looking at this.
>>>>
>>>> I actually found an issue myself when going over the code. The 
>>>> problem is in
>>>> initialize_flags for the TwoGenerationalPolicy, where I verify that 
>>>> the
>>>> desired new_size is within the allowed bounds. I realized that I 
>>>> need to
>>>> check against the flag MaxNewSize since the member might not have been
>>>> initialized yet. Below is the diff for the change and an updated 
>>>> webrev can
>>>> be found here:
>>>> http://cr.openjdk.java.net/~sjohanss/8029186/webrev.01/
>>>>
>>>> ---
>>>> @@ -422,7 +422,9 @@
>>>>    if (FLAG_IS_CMDLINE(OldSize) && !FLAG_IS_CMDLINE(NewSize)) {
>>>>      if (OldSize < _initial_heap_byte_size) {
>>>>        size_t new_size = _initial_heap_byte_size - OldSize;
>>>> -      if (new_size >= _min_gen0_size && new_size <= _max_gen0_size) {
>>>> +      // Need to compare against the flag value for max since 
>>>> _max_gen0_size
>>>> +      // might not have been set yet.
>>>> +      if (new_size >= _min_gen0_size && new_size <= MaxNewSize) {
>>>>          FLAG_SET_ERGO(uintx, NewSize, new_size);
>>>>          _initial_gen0_size = NewSize;
>>>>        }
>>>> ---
>>>>
>>>> Thanks,
>>>> Stefan
>>>>
>>>> On 2014-03-25 17:33, Jesper Wilhelmsson wrote:
>>>>> Ship it!
>>>>> /Jesper
>>>>>
>>>>> Stefan Johansson skrev 25/3/14 16:29:
>>>>>> Hi,
>>>>>>
>>>>>> Please review this fix for:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8029186
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~sjohanss/8029186/webrev.00/
>>>>>>
>>>>>> Summary:
>>>>>> There have been a lot of bugs due to corner cases with heap 
>>>>>> sizing flags. This
>>>>>> change strives to fix this particular problem and at the same 
>>>>>> time somewhat
>>>>>> simplify the collector policy. I've also added some assertions to 
>>>>>> ensure that
>>>>>> the sizing of the heap is more correct.
>>>>>>
>>>>>> Testing:
>>>>>> * JPRT sanity and JTREG
>>>>>> * Adhoc aurora run for tmtools tests
>>>>>> * Script that verifies that we don't get assertions during 
>>>>>> startup for
>>>>>> different
>>>>>> combinations of NewSize, MaxNewSize, OldSize, Xms and Xmx.
>>>>>>
>>>>>> Thanks,
>>>>>> StefanJ
>>>>
>>>
>>



From thomas.schatzl at oracle.com  Thu Apr  3 10:00:38 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 03 Apr 2014 12:00:38 +0200
Subject: Request for review: 8016302: Change type of the number of GC
	workers to unsigned int (2)
In-Reply-To: <533C3821.60005@oracle.com>
References: <533C3821.60005@oracle.com>
Message-ID: <1396519238.3018.18.camel@cirrus>

Hi,

On Wed, 2014-04-02 at 20:17 +0400, Vladimir Kempik wrote:
> Hi all,
> 
> Could I have a couple of reviews for this change?
> 
> http://cr.openjdk.java.net/~vkempik/8016302/webrev.04/
> 

  looks good. I can also push the change.

Thomas




From jesper.wilhelmsson at oracle.com  Thu Apr  3 10:30:30 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 03 Apr 2014 12:30:30 +0200
Subject: Request for review: 8016302: Change type of the number of GC
	workers to unsigned int (2)
In-Reply-To: <533C3821.60005@oracle.com>
References: <533C3821.60005@oracle.com>
Message-ID: <533D3846.5090703@oracle.com>

Hi,

In concurrentG1Refine.cpp:63, could you use uint for i in that loop as well and 
change the termination condition to i != UINT_MAX as you have done in a few 
other places?

In g1GCPhaseTimes.cpp, g1HotCardCache.cpp and g1RemSet.cpp, why do you use 
UINT32_FORMAT, shouldn't it be just UINT_FORMAT?

Otherwise, looks good!
/Jesper


Vladimir Kempik skrev 2/4/14 18:17:
> Hi all,
>
> Could I have a couple of reviews for this change?
>
> http://cr.openjdk.java.net/~vkempik/8016302/webrev.04/
>
> In 7121618 variables representing GC workers (worker id, worker id offset) have
> been changed from int to unsigned int.
>
> Since then, code reintroduced the use of int's for this type of variable; fixing
> this by aligning the code to use uints for ints.
>
> Since last september the fix was updated for jdk9 and size_t was replaced with
> uint in
> dirtyCardQueue.hpp,
>
>    54 bool apply_closure(CardTableEntryClosure* cl,
>    55                      bool consume = true,
>    56                      size_t worker_i = 0);
>
>    99   // The number of parallel ids that can be claimed to allow
> collector or
>   100   // mutator threads to do card-processing work.
>   101   static size_t num_par_ids();
>
> Thanks,
> Vladimir
>


From jesper.wilhelmsson at oracle.com  Thu Apr  3 10:38:42 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 03 Apr 2014 12:38:42 +0200
Subject: RFR(XS): 8039089 - List verification enabled in product builds
In-Reply-To: <0A35EF0C-BD58-4581-80A9-DBF7F96CCA92@oracle.com>
References: <533C3EC7.8050800@oracle.com>
	<0A35EF0C-BD58-4581-80A9-DBF7F96CCA92@oracle.com>
Message-ID: <533D3A32.8070407@oracle.com>

Thanks for the review!
/Jesper

Bengt Rutisson skrev 2/4/14 22:26:
>
> Jesper,
>
> Looks good.
>
> Thanks for fixing this!
>
> Bengt
>
>> 2 apr 2014 kl. 18:45 skrev Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com>:
>>
>> Hi,
>>
>> This is a one-liner to stop ConcurrentMark::completeCleanup() from running list verification in product builds.
>>
>> It is currently calling _cleanup_list.verify_list(). This will unconditionally run the verification, even in product builds. I replaced it with verify_optional() that only runs the verification code in debug builds.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039089
>>
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8039089/webrev/
>>
>> Thanks,
>> /Jesper


From jesper.wilhelmsson at oracle.com  Thu Apr  3 10:52:07 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 03 Apr 2014 12:52:07 +0200
Subject: RFR(XS): 8039089 - List verification enabled in product builds
In-Reply-To: <1396514124.3018.14.camel@cirrus>
References: <533C3EC7.8050800@oracle.com> <1396514124.3018.14.camel@cirrus>
Message-ID: <533D3D57.6090900@oracle.com>

Thanks for reviewing!

I added the additional asserts. New webrev:

http://cr.openjdk.java.net/~jwilhelm/8039089/webrev.2/

/Jesper


Thomas Schatzl skrev 3/4/14 10:35:
> Hi Jesper,
>
> On Wed, 2014-04-02 at 18:45 +0200, Jesper Wilhelmsson wrote:
>> Hi,
>>
>> This is a one-liner to stop ConcurrentMark::completeCleanup() from running list
>> verification in product builds.
>>
>> It is currently calling _cleanup_list.verify_list(). This will unconditionally
>> run the verification, even in product builds. I replaced it with
>> verify_optional() that only runs the verification code in debug builds.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039089
>>
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8039089/webrev/
>
>
>    looks good.
>
> Some request though, as it is somewhat related: HeapRegionSetBase::add()
> and HeapRegionSetBase::remove() should assert on that the prev-pointers
> of the doubly linked list should be NULL, not only the next pointer.
>
> However the change is fine as is to me.
>
> Thomas
>
>


From per.liden at oracle.com  Thu Apr  3 11:15:12 2014
From: per.liden at oracle.com (Per Liden)
Date: Thu, 03 Apr 2014 13:15:12 +0200
Subject: RFR(s): 8037112: gc/g1/TestHumongousAllocInitialMark.java caused
	SIGSEGV
Message-ID: <533D42C0.8060306@oracle.com>

Hi,

Could I please have this bugfix reviewed.

Summary: G1's ConcurrentMarkThread tries to use the gclog_or_tty when 
the JVM is about to exit and the gclog_or_tty instance has been 
destroyed. To prevent this, the ConcurrentMarkThread needs to join the 
SuspendibleThreadSet before accessing gclog_or_tty.

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

Thanks!
/Per

Btw, I created a separate RFE, JDK-8039147, to do a little bit of 
cleanup of the SuspendibleThreadSet and how it's used. Will send that 
out as separate review request shortly.


From vladimir.kempik at oracle.com  Thu Apr  3 11:41:49 2014
From: vladimir.kempik at oracle.com (Vladimir Kempik)
Date: Thu, 03 Apr 2014 15:41:49 +0400
Subject: Request for review: 8016302: Change type of the number of GC
	workers to unsigned int (2)
In-Reply-To: <533D3846.5090703@oracle.com>
References: <533C3821.60005@oracle.com> <533D3846.5090703@oracle.com>
Message-ID: <533D48FD.60701@oracle.com>

Hello

I've used UINT32_FORMAT because:

1) previous format type for worker was INT32_FORMAT, when worker was int

2) there is no such thing as UINT_FORMAT,  there is only UINTX_FORMAT

Do you think UINTX_FORMAT is better than UINT32_FORMAT for this case ?

Thanks, Vladimir
On 03.04.2014 14:30, Jesper Wilhelmsson wrote:
> Hi,
>
> In concurrentG1Refine.cpp:63, could you use uint for i in that loop as 
> well and change the termination condition to i != UINT_MAX as you have 
> done in a few other places?
>
> In g1GCPhaseTimes.cpp, g1HotCardCache.cpp and g1RemSet.cpp, why do you 
> use UINT32_FORMAT, shouldn't it be just UINT_FORMAT?
>
> Otherwise, looks good!
> /Jesper
>
>
> Vladimir Kempik skrev 2/4/14 18:17:
>> Hi all,
>>
>> Could I have a couple of reviews for this change?
>>
>> http://cr.openjdk.java.net/~vkempik/8016302/webrev.04/
>>
>> In 7121618 variables representing GC workers (worker id, worker id 
>> offset) have
>> been changed from int to unsigned int.
>>
>> Since then, code reintroduced the use of int's for this type of 
>> variable; fixing
>> this by aligning the code to use uints for ints.
>>
>> Since last september the fix was updated for jdk9 and size_t was 
>> replaced with
>> uint in
>> dirtyCardQueue.hpp,
>>
>>    54 bool apply_closure(CardTableEntryClosure* cl,
>>    55                      bool consume = true,
>>    56                      size_t worker_i = 0);
>>
>>    99   // The number of parallel ids that can be claimed to allow
>> collector or
>>   100   // mutator threads to do card-processing work.
>>   101   static size_t num_par_ids();
>>
>> Thanks,
>> Vladimir
>>



From bengt.rutisson at oracle.com  Thu Apr  3 11:59:39 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 03 Apr 2014 13:59:39 +0200
Subject: RFR(XS): 8039089 - List verification enabled in product builds
In-Reply-To: <533D3D57.6090900@oracle.com>
References: <533C3EC7.8050800@oracle.com> <1396514124.3018.14.camel@cirrus>
	<533D3D57.6090900@oracle.com>
Message-ID: <533D4D2B.9040302@oracle.com>


On 2014-04-03 12:52, Jesper Wilhelmsson wrote:
> Thanks for reviewing!
>
> I added the additional asserts. New webrev:
>
> http://cr.openjdk.java.net/~jwilhelm/8039089/webrev.2/

Still looks good to me. :)

Bengt

>
> /Jesper
>
>
> Thomas Schatzl skrev 3/4/14 10:35:
>> Hi Jesper,
>>
>> On Wed, 2014-04-02 at 18:45 +0200, Jesper Wilhelmsson wrote:
>>> Hi,
>>>
>>> This is a one-liner to stop ConcurrentMark::completeCleanup() from 
>>> running list
>>> verification in product builds.
>>>
>>> It is currently calling _cleanup_list.verify_list(). This will 
>>> unconditionally
>>> run the verification, even in product builds. I replaced it with
>>> verify_optional() that only runs the verification code in debug builds.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039089
>>>
>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8039089/webrev/
>>
>>
>>    looks good.
>>
>> Some request though, as it is somewhat related: HeapRegionSetBase::add()
>> and HeapRegionSetBase::remove() should assert on that the prev-pointers
>> of the doubly linked list should be NULL, not only the next pointer.
>>
>> However the change is fine as is to me.
>>
>> Thomas
>>
>>



From jesper.wilhelmsson at oracle.com  Thu Apr  3 12:35:40 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 03 Apr 2014 14:35:40 +0200
Subject: Request for review: 8016302: Change type of the number of GC
	workers to unsigned int (2)
In-Reply-To: <533D48FD.60701@oracle.com>
References: <533C3821.60005@oracle.com> <533D3846.5090703@oracle.com>
	<533D48FD.60701@oracle.com>
Message-ID: <533D559C.6020209@oracle.com>

Hi,

It seems like UINT32_FORMAT is frequently used together with uint so leave it as is.
/Jesper

Vladimir Kempik skrev 3/4/14 13:41:
> Hello
>
> I've used UINT32_FORMAT because:
>
> 1) previous format type for worker was INT32_FORMAT, when worker was int
>
> 2) there is no such thing as UINT_FORMAT,  there is only UINTX_FORMAT
>
> Do you think UINTX_FORMAT is better than UINT32_FORMAT for this case ?
>
> Thanks, Vladimir
> On 03.04.2014 14:30, Jesper Wilhelmsson wrote:
>> Hi,
>>
>> In concurrentG1Refine.cpp:63, could you use uint for i in that loop as well
>> and change the termination condition to i != UINT_MAX as you have done in a
>> few other places?
>>
>> In g1GCPhaseTimes.cpp, g1HotCardCache.cpp and g1RemSet.cpp, why do you use
>> UINT32_FORMAT, shouldn't it be just UINT_FORMAT?
>>
>> Otherwise, looks good!
>> /Jesper
>>
>>
>> Vladimir Kempik skrev 2/4/14 18:17:
>>> Hi all,
>>>
>>> Could I have a couple of reviews for this change?
>>>
>>> http://cr.openjdk.java.net/~vkempik/8016302/webrev.04/
>>>
>>> In 7121618 variables representing GC workers (worker id, worker id offset) have
>>> been changed from int to unsigned int.
>>>
>>> Since then, code reintroduced the use of int's for this type of variable; fixing
>>> this by aligning the code to use uints for ints.
>>>
>>> Since last september the fix was updated for jdk9 and size_t was replaced with
>>> uint in
>>> dirtyCardQueue.hpp,
>>>
>>>    54 bool apply_closure(CardTableEntryClosure* cl,
>>>    55                      bool consume = true,
>>>    56                      size_t worker_i = 0);
>>>
>>>    99   // The number of parallel ids that can be claimed to allow
>>> collector or
>>>   100   // mutator threads to do card-processing work.
>>>   101   static size_t num_par_ids();
>>>
>>> Thanks,
>>> Vladimir
>>>
>


From thomas.schatzl at oracle.com  Thu Apr  3 12:40:00 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 03 Apr 2014 14:40:00 +0200
Subject: Request for review: 8016302: Change type of the number of GC
	workers to unsigned int (2)
In-Reply-To: <533D48FD.60701@oracle.com>
References: <533C3821.60005@oracle.com> <533D3846.5090703@oracle.com>
	<533D48FD.60701@oracle.com>
Message-ID: <1396528800.3018.22.camel@cirrus>

Hi,

On Thu, 2014-04-03 at 15:41 +0400, Vladimir Kempik wrote:
> Hello
> 
> I've used UINT32_FORMAT because:
> 
> 1) previous format type for worker was INT32_FORMAT, when worker was int
> 
> 2) there is no such thing as UINT_FORMAT,  there is only UINTX_FORMAT
> 
> Do you think UINTX_FORMAT is better than UINT32_FORMAT for this case ?

UINTX_FORMAT or uintx is an unsigned data type that has 32 or 64 bit
size depending on the processes' word size.

I think UINT32_FORMAT is correct here, and used elsewhere for uint
variables. Afaik uint is 32 bits on all platforms we use.

Thanks,
  Thomas




From stefan.karlsson at oracle.com  Thu Apr  3 12:38:06 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 03 Apr 2014 14:38:06 +0200
Subject: Request for review: 8016302: Change type of the number of GC
	workers to unsigned int (2)
In-Reply-To: <1396528800.3018.22.camel@cirrus>
References: <533C3821.60005@oracle.com>
	<533D3846.5090703@oracle.com>	<533D48FD.60701@oracle.com>
	<1396528800.3018.22.camel@cirrus>
Message-ID: <533D562E.6040500@oracle.com>


On 2014-04-03 14:40, Thomas Schatzl wrote:
> Hi,
>
> On Thu, 2014-04-03 at 15:41 +0400, Vladimir Kempik wrote:
>> Hello
>>
>> I've used UINT32_FORMAT because:
>>
>> 1) previous format type for worker was INT32_FORMAT, when worker was int
>>
>> 2) there is no such thing as UINT_FORMAT,  there is only UINTX_FORMAT
>>
>> Do you think UINTX_FORMAT is better than UINT32_FORMAT for this case ?
> UINTX_FORMAT or uintx is an unsigned data type that has 32 or 64 bit
> size depending on the processes' word size.
>
> I think UINT32_FORMAT is correct here, and used elsewhere for uint
> variables. Afaik uint is 32 bits on all platforms we use.

Why don't we just use %u?

thanks,
StefanK

>
> Thanks,
>    Thomas
>
>



From thomas.schatzl at oracle.com  Thu Apr  3 13:21:39 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 03 Apr 2014 15:21:39 +0200
Subject: Request for review: 8016302: Change type of the number of GC
	workers to unsigned int (2)
In-Reply-To: <533D562E.6040500@oracle.com>
References: <533C3821.60005@oracle.com> <533D3846.5090703@oracle.com>
	<533D48FD.60701@oracle.com> <1396528800.3018.22.camel@cirrus>
	<533D562E.6040500@oracle.com>
Message-ID: <1396531299.3018.37.camel@cirrus>

Hi,

On Thu, 2014-04-03 at 14:38 +0200, Stefan Karlsson wrote:
> On 2014-04-03 14:40, Thomas Schatzl wrote:
> > Hi,
> >
> > On Thu, 2014-04-03 at 15:41 +0400, Vladimir Kempik wrote:
> >> Hello
> >>
> >> I've used UINT32_FORMAT because:
> >>
> >> 1) previous format type for worker was INT32_FORMAT, when worker was int
> >>
> >> 2) there is no such thing as UINT_FORMAT,  there is only UINTX_FORMAT
> >>
> >> Do you think UINTX_FORMAT is better than UINT32_FORMAT for this case ?
> > UINTX_FORMAT or uintx is an unsigned data type that has 32 or 64 bit
> > size depending on the processes' word size.
> >
> > I think UINT32_FORMAT is correct here, and used elsewhere for uint
> > variables. Afaik uint is 32 bits on all platforms we use.
> 
> Why don't we just use %u?

  looking through the code, UINT32_FORMAT expands to %u always.

I do not know why it is specifically called UINT*32*_FORMAT, and why
there is no UINT_FORMAT.

Also I do not know why we do not use %(d/i/u) for int/uint variables - I
assume for uniformity with types and format specifiers that change
depending on word size or compiler (e.g. uintx, size_t).

It may also just be that I am completely wrong, and we should %u for
uints - this opinion with UINT32_FORMAT was formed by looking at other
hotspot code, which is, as you know, not exactly the perfect example for
uniform code :)

Thomas




From vladimir.kempik at oracle.com  Thu Apr  3 13:32:21 2014
From: vladimir.kempik at oracle.com (Vladimir Kempik)
Date: Thu, 03 Apr 2014 17:32:21 +0400
Subject: Request for review: 8016302: Change type of the number of GC
	workers to unsigned int (2)
In-Reply-To: <533D559C.6020209@oracle.com>
References: <533C3821.60005@oracle.com> <533D3846.5090703@oracle.com>
	<533D48FD.60701@oracle.com> <533D559C.6020209@oracle.com>
Message-ID: <533D62E5.5030908@oracle.com>

Hello

Updated webrev, for loop changed to use UINT_MAX

http://cr.openjdk.java.net/~vkempik/8016302/webrev.05/

Thanks.
Vladimir.

On 03.04.2014 16:35, Jesper Wilhelmsson wrote:
> Hi,
>
> It seems like UINT32_FORMAT is frequently used together with uint so 
> leave it as is.
> /Jesper
>
> Vladimir Kempik skrev 3/4/14 13:41:
>> Hello
>>
>> I've used UINT32_FORMAT because:
>>
>> 1) previous format type for worker was INT32_FORMAT, when worker was int
>>
>> 2) there is no such thing as UINT_FORMAT,  there is only UINTX_FORMAT
>>
>> Do you think UINTX_FORMAT is better than UINT32_FORMAT for this case ?
>>
>> Thanks, Vladimir
>> On 03.04.2014 14:30, Jesper Wilhelmsson wrote:
>>> Hi,
>>>
>>> In concurrentG1Refine.cpp:63, could you use uint for i in that loop 
>>> as well
>>> and change the termination condition to i != UINT_MAX as you have 
>>> done in a
>>> few other places?
>>>
>>> In g1GCPhaseTimes.cpp, g1HotCardCache.cpp and g1RemSet.cpp, why do 
>>> you use
>>> UINT32_FORMAT, shouldn't it be just UINT_FORMAT?
>>>
>>> Otherwise, looks good!
>>> /Jesper
>>>
>>>
>>> Vladimir Kempik skrev 2/4/14 18:17:
>>>> Hi all,
>>>>
>>>> Could I have a couple of reviews for this change?
>>>>
>>>> http://cr.openjdk.java.net/~vkempik/8016302/webrev.04/
>>>>
>>>> In 7121618 variables representing GC workers (worker id, worker id 
>>>> offset) have
>>>> been changed from int to unsigned int.
>>>>
>>>> Since then, code reintroduced the use of int's for this type of 
>>>> variable; fixing
>>>> this by aligning the code to use uints for ints.
>>>>
>>>> Since last september the fix was updated for jdk9 and size_t was 
>>>> replaced with
>>>> uint in
>>>> dirtyCardQueue.hpp,
>>>>
>>>>    54 bool apply_closure(CardTableEntryClosure* cl,
>>>>    55                      bool consume = true,
>>>>    56                      size_t worker_i = 0);
>>>>
>>>>    99   // The number of parallel ids that can be claimed to allow
>>>> collector or
>>>>   100   // mutator threads to do card-processing work.
>>>>   101   static size_t num_par_ids();
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>



From stefan.karlsson at oracle.com  Thu Apr  3 13:30:45 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 03 Apr 2014 15:30:45 +0200
Subject: Request for review: 8016302: Change type of the number of GC
	workers to unsigned int (2)
In-Reply-To: <1396531299.3018.37.camel@cirrus>
References: <533C3821.60005@oracle.com>
	<533D3846.5090703@oracle.com>		<533D48FD.60701@oracle.com>
	<1396528800.3018.22.camel@cirrus>	
	<533D562E.6040500@oracle.com> <1396531299.3018.37.camel@cirrus>
Message-ID: <533D6285.7090303@oracle.com>


On 2014-04-03 15:21, Thomas Schatzl wrote:
> Hi,
>
> On Thu, 2014-04-03 at 14:38 +0200, Stefan Karlsson wrote:
>> On 2014-04-03 14:40, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Thu, 2014-04-03 at 15:41 +0400, Vladimir Kempik wrote:
>>>> Hello
>>>>
>>>> I've used UINT32_FORMAT because:
>>>>
>>>> 1) previous format type for worker was INT32_FORMAT, when worker was int
>>>>
>>>> 2) there is no such thing as UINT_FORMAT,  there is only UINTX_FORMAT
>>>>
>>>> Do you think UINTX_FORMAT is better than UINT32_FORMAT for this case ?
>>> UINTX_FORMAT or uintx is an unsigned data type that has 32 or 64 bit
>>> size depending on the processes' word size.
>>>
>>> I think UINT32_FORMAT is correct here, and used elsewhere for uint
>>> variables. Afaik uint is 32 bits on all platforms we use.
>> Why don't we just use %u?
>    looking through the code, UINT32_FORMAT expands to %u always.
>
> I do not know why it is specifically called UINT*32*_FORMAT, and why
> there is no UINT_FORMAT.
>
> Also I do not know why we do not use %(d/i/u) for int/uint variables - I
> assume for uniformity with types and format specifiers that change
> depending on word size or compiler (e.g. uintx, size_t).
>
> It may also just be that I am completely wrong, and we should %u for
> uints - this opinion with UINT32_FORMAT was formed by looking at other
> hotspot code, which is, as you know, not exactly the perfect example for
> uniform code :)

We do use %u and %d.

Just some crude greping gives:

$ grep -r "%u" src/ | wc
     303    2441   35578

$ grep -r "UINT32_FORMAT" src/ | wc
      32     222    3589

$ grep -r "%d" src/ | wc
    3118   23214  337084

$ grep -r "INT32_FORMAT" src/ | wc
      71     517    7770

thanks,
StefanK

>
> Thomas
>
>



From jesper.wilhelmsson at oracle.com  Thu Apr  3 13:36:37 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 03 Apr 2014 15:36:37 +0200
Subject: Request for review: 8016302: Change type of the number of GC
	workers to unsigned int (2)
In-Reply-To: <533D62E5.5030908@oracle.com>
References: <533C3821.60005@oracle.com> <533D3846.5090703@oracle.com>
	<533D48FD.60701@oracle.com> <533D559C.6020209@oracle.com>
	<533D62E5.5030908@oracle.com>
Message-ID: <533D63E5.2010602@oracle.com>

Looks good!
/Jesper

Vladimir Kempik skrev 3/4/14 15:32:
> Hello
>
> Updated webrev, for loop changed to use UINT_MAX
>
> http://cr.openjdk.java.net/~vkempik/8016302/webrev.05/
>
> Thanks.
> Vladimir.
>
> On 03.04.2014 16:35, Jesper Wilhelmsson wrote:
>> Hi,
>>
>> It seems like UINT32_FORMAT is frequently used together with uint so leave it
>> as is.
>> /Jesper
>>
>> Vladimir Kempik skrev 3/4/14 13:41:
>>> Hello
>>>
>>> I've used UINT32_FORMAT because:
>>>
>>> 1) previous format type for worker was INT32_FORMAT, when worker was int
>>>
>>> 2) there is no such thing as UINT_FORMAT,  there is only UINTX_FORMAT
>>>
>>> Do you think UINTX_FORMAT is better than UINT32_FORMAT for this case ?
>>>
>>> Thanks, Vladimir
>>> On 03.04.2014 14:30, Jesper Wilhelmsson wrote:
>>>> Hi,
>>>>
>>>> In concurrentG1Refine.cpp:63, could you use uint for i in that loop as well
>>>> and change the termination condition to i != UINT_MAX as you have done in a
>>>> few other places?
>>>>
>>>> In g1GCPhaseTimes.cpp, g1HotCardCache.cpp and g1RemSet.cpp, why do you use
>>>> UINT32_FORMAT, shouldn't it be just UINT_FORMAT?
>>>>
>>>> Otherwise, looks good!
>>>> /Jesper
>>>>
>>>>
>>>> Vladimir Kempik skrev 2/4/14 18:17:
>>>>> Hi all,
>>>>>
>>>>> Could I have a couple of reviews for this change?
>>>>>
>>>>> http://cr.openjdk.java.net/~vkempik/8016302/webrev.04/
>>>>>
>>>>> In 7121618 variables representing GC workers (worker id, worker id offset)
>>>>> have
>>>>> been changed from int to unsigned int.
>>>>>
>>>>> Since then, code reintroduced the use of int's for this type of variable;
>>>>> fixing
>>>>> this by aligning the code to use uints for ints.
>>>>>
>>>>> Since last september the fix was updated for jdk9 and size_t was replaced with
>>>>> uint in
>>>>> dirtyCardQueue.hpp,
>>>>>
>>>>>    54 bool apply_closure(CardTableEntryClosure* cl,
>>>>>    55                      bool consume = true,
>>>>>    56                      size_t worker_i = 0);
>>>>>
>>>>>    99   // The number of parallel ids that can be claimed to allow
>>>>> collector or
>>>>>   100   // mutator threads to do card-processing work.
>>>>>   101   static size_t num_par_ids();
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>
>


From thomas.schatzl at oracle.com  Thu Apr  3 13:52:08 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 03 Apr 2014 15:52:08 +0200
Subject: Request for review: 8016302: Change type of the number of GC
	workers to unsigned int (2)
In-Reply-To: <533D6285.7090303@oracle.com>
References: <533C3821.60005@oracle.com> <533D3846.5090703@oracle.com>
	<533D48FD.60701@oracle.com> <1396528800.3018.22.camel@cirrus>
	<533D562E.6040500@oracle.com> <1396531299.3018.37.camel@cirrus>
	<533D6285.7090303@oracle.com>
Message-ID: <1396533128.5969.2.camel@cirrus>

Hi Stefan,

On Thu, 2014-04-03 at 15:30 +0200, Stefan Karlsson wrote:
> On 2014-04-03 15:21, Thomas Schatzl wrote:
> > Hi,
> >
> > On Thu, 2014-04-03 at 14:38 +0200, Stefan Karlsson wrote:
> >> On 2014-04-03 14:40, Thomas Schatzl wrote:
> >>> Hi,
> >>>
> >>> On Thu, 2014-04-03 at 15:41 +0400, Vladimir Kempik wrote:
>>[...]
> > It may also just be that I am completely wrong, and we should %u for
> > uints - this opinion with UINT32_FORMAT was formed by looking at other
> > hotspot code, which is, as you know, not exactly the perfect example for
> > uniform code :)
> 
> We do use %u and %d.
> 
> Just some crude greping gives:
> 
> $ grep -r "%u" src/ | wc
>      303    2441   35578
> 
> $ grep -r "UINT32_FORMAT" src/ | wc
>       32     222    3589
> 
> $ grep -r "%d" src/ | wc
>     3118   23214  337084
> 
> $ grep -r "INT32_FORMAT" src/ | wc
>       71     517    7770

Okay, I stand corrected.

Thanks,
  Thomas




From mikael.gerdin at oracle.com  Thu Apr  3 13:59:02 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 03 Apr 2014 15:59:02 +0200
Subject: RFR(s): 8037112: gc/g1/TestHumongousAllocInitialMark.java caused
	SIGSEGV
In-Reply-To: <533D42C0.8060306@oracle.com>
References: <533D42C0.8060306@oracle.com>
Message-ID: <3971356.DreSMqAOW1@mgerdin03>

Hi Per,

On Thursday 03 April 2014 13.15.12 Per Liden wrote:
> Hi,
> 
> Could I please have this bugfix reviewed.
> 
> Summary: G1's ConcurrentMarkThread tries to use the gclog_or_tty when
> the JVM is about to exit and the gclog_or_tty instance has been
> destroyed. To prevent this, the ConcurrentMarkThread needs to join the
> SuspendibleThreadSet before accessing gclog_or_tty.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8037112
> Webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.0/

While I realize that this code is still semantically correct I think it reads 
a bit strange. In my mind if we have a
if (...) {} else if (...) {} else {} block the checks in the "if" and "else 
if" should usually somehow related checks.

 282       if (!cm()->has_aborted()) {
 283         g1_policy->record_concurrent_mark_cleanup_completed();
 284       } else if (G1Log::fine()) {
 285         gclog_or_tty->date_stamp(PrintGCDateStamps);
 286         gclog_or_tty->stamp(PrintGCTimeStamps);
 287         gclog_or_tty->print_cr("[GC concurrent-mark-abort]");
 288       }

I would prefer if it was structured the other way around:
if (cm()->has_aborted()) {
	if (G1Log::fine()) { ... }
else {
	g1_policy->record_concurrent_mark_cleanup_completed();
}

The rest of the change looks good.

/Mikael

> 
> Thanks!
> /Per
> 
> Btw, I created a separate RFE, JDK-8039147, to do a little bit of
> cleanup of the SuspendibleThreadSet and how it's used. Will send that
> out as separate review request shortly.



From erik.helin at oracle.com  Thu Apr  3 13:56:55 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 03 Apr 2014 15:56:55 +0200
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533C4CDC.3070307@oracle.com>
References: <5332FA20.5070607@oracle.com>
	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>
	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>
	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>
	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>
	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>
	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>
	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>
	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>
	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>
	<53394053.2070502@oracle.com> <533955B0.7000601@oracle.com>
	<533A6165.80704@oracle.com> <533A8141.2030608@oracle.com>
	<533AB040.6000302@oracle.com> <533C3654.7020801@oracle.com>
	<533C3974.5080803@oracle.com> <533C460D.5020707@oracle.com>
	<533C4CDC.3070307@oracle.com>
Message-ID: <533D68A7.6090305@oracle.com>

Andrey,

even though you don't use inheritance, you can still share code. For 
example:

assertLessThan(muFree.getCommitted(), muFull.getCommitted(), String.format(
                 "committed free heap size is not less than committed 
full heap size, heap hasn't been shrunk?%n"
                 + "%s = %s%n%s = %s",
                 TestDynamicVMOption.MIN_FREE_RATIO_FLAG_NAME,
ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(TestDynamicVMOption.MIN_FREE_RATIO_FLAG_NAME).getValue(),
                 TestDynamicVMOption.MAX_FREE_RATIO_FLAG_NAME,
ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(TestDynamicVMOption.MAX_FREE_RATIO_FLAG_NAME).getValue()
         ));

can for example belong to the class test/gc/g1/ShrinkHeapUtils.java. I 
don't think ShrinkHeapUtils.java belongs to the testlibrary, since it is 
so far only be used by two GC tests. If more tests end up using it, we 
can "promote" it to the testlibrary so that other VM JTreg tests can 
benefit from it.

public class ShrinkHeapUtils {
     public void assertHeapIsSmaller(MemoryUsage muFree, MemoryUsage 
muFull) {
         assertLessThan(muFree.getCommitted(), muFull.getCommitted(), 
String.format(
                 "committed free heap size is not less than committed 
full heap size, heap hasn't been shrunk?%n"
                 + "%s = %s%n%s = %s",
                 TestDynamicVMOption.MIN_FREE_RATIO_FLAG_NAME,
ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(TestDynamicVMOption.MIN_FREE_RATIO_FLAG_NAME).getValue(),
                 TestDynamicVMOption.MAX_FREE_RATIO_FLAG_NAME,
ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(TestDynamicVMOption.MAX_FREE_RATIO_FLAG_NAME).getValue()
         ));
     }
}

You can also use the class introduced in your previous change, 
DynamicVMOptionChecker.java:

public class ShrinkHeapUtils {
     public void assertHeapIsSmaller(MemoryUsage muFree, MemoryUsage 
muFull) {
         DynamicVMOptionChecker minHeapFreeRatio =
             new DynamicVMOptionChecker("MinHeapFreeRatio");
         DynamicVMOptionChecker maxHeapFreeRatio =
             new DynamicVMOptionChecker("MaxHeapFreeRatio");

         assertLessThan(muFree.getCommitted(), muAfter.getCommitted(), 
String.format(
             "Committed free heap size is not less than committed full 
heap size, heap hasn't shrunk?%n" +
             "%s = %s%n%s = %s",
             minHeapFreeRatio.getName(),
             minHeapFreeRatio.getValue(),
             maxHeapFreeRatio.getName(),
             maxHeapFreeRatio.getValue()
         ));
     }
}

(Another change that might be worthwhile to do is renaming 
DynamicVMOptionChecker to DynamicVMOption to emphasize that is an 
utility class)

Do you agree with this?

Thanks,
Erik

On 2014-04-02 19:46, Jesper Wilhelmsson wrote:
> New webrev is uploaded here:
>
> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.12/
>
> /Jesper
>
> Andrey Zakharov skrev 2/4/14 19:17:
>> Hi, here is not uploaded yet webrev with totally reverted inheritance.
>> Jesper, can you please upload to your space.
>> Thanks.
>>
>>
>> On 02.04.2014 20:23, Igor Ignatyev wrote:
>>> Andrey,
>>>
>>> Why do test classes extend TestShrinkHeap?
>>>
>>> Igor
>>>
>>> On 04/02/2014 08:09 PM, Andrey Zakharov wrote:
>>>> Here is version without hidden testflow:
>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.11/
>>>> Thanks.
>>>>
>>>> On 01.04.2014 16:25, Jesper Wilhelmsson wrote:
>>>>> Uploaded:
>>>>>
>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.10/
>>>>>
>>>>> In general  would agree regarding avoiding duplicated code, but when
>>>>> it comes to the control flow I agree with Erik. More hard to read 
>>>>> code
>>>>> leads to harder maintenance than duplicating a few lines of code.
>>>>> /Jesper
>>>>>
>>>>> Andrey Zakharov skrev 1/4/14 11:05:
>>>>>> Hi, Erik. Thanks for comments.
>>>>>>
>>>>>> On 01.04.2014 10:49, Erik Helin wrote:
>>>>>>> Andrey,
>>>>>>>
>>>>>>> a couple of comments:
>>>>>>> - We do not use the @author tag in the tests
>>>>>>>   (if you've seen other tests have the @author tag, then that is 
>>>>>>> a bug)
>>>>>> removed
>>>>>>> - I'm not a big fan of using inheritance for sharing code between
>>>>>>>   tests because it makes it very hard to open a test, e.g.
>>>>>>>   TestHumongousShrinkHeap.java, and see what it does.
>>>>>> Agreed, I'm too. But doubled code leads to harder maintenance.
>>>>>>>
>>>>>>>   The code you share in TestShrinkHeap is basically the check 
>>>>>>> and the
>>>>>>>   control flow of the tests. I would prefer if you could move the
>>>>>>>   control flow (System.gc(), sample, eat, sample, free, check 
>>>>>>> samples)
>>>>>>>   into the tests and then write helper functions for retrieving the
>>>>>>>   flag values.
>>>>>>>
>>>>>>>   As for the check, please use the assertions in
>>>>>>>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>>>>>>   throwing a RuntimeException.
>>>>>> Good point, changed.
>>>>>> Jesper, can we upload webrev.10 from attachment? Thanks.
>>>>>> I'm still need GC reviewers to approve push.
>>>>>>
>>>>>> Thanks.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Erik
>>>>>>>
>>>>>>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> New webrev uploaded.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>>>>>>
>>>>>>>> I'm not a Reviewer either so if you got Igor's blessing 
>>>>>>>> already, my
>>>>>>>> review won't be enough to push unfortunately.
>>>>>>>> /Jesper
>>>>>>>>
>>>>>>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>>>>>>> Hi,
>>>>>>>>> Jepser, here is updated webrev.09
>>>>>>>>> Thomas, Jesper can you review it as well?
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>>>>>>> Andrey,
>>>>>>>>>>
>>>>>>>>>> 1. TEST.groups:
>>>>>>>>>> please update copyright year:
>>>>>>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All 
>>>>>>>>>>> rights
>>>>>>>>>>> reserved.
>>>>>>>>>> should be
>>>>>>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its 
>>>>>>>>>>> affiliates. All
>>>>>>>>>>> rights
>>>>>>>>>>> reserved.
>>>>>>>>>>
>>>>>>>>>> 2. TestShrinkHeap.java
>>>>>>>>>>>   22  */
>>>>>>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>>>>>>> add empty line between 22 and 23 as you do in all other files,
>>>>>>>>>>
>>>>>>>>>> otherwise it looks good to me.
>>>>>>>>>>
>>>>>>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in
>>>>>>>>>> 'Reviewed-by'
>>>>>>>>>> section )
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Igor
>>>>>>>>>>
>>>>>>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>>>>>>> Hi, team
>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>>>>>>> Webrev uploaded:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>>>
>>>>>>>>>>>> /Jesper
>>>>>>>>>>> Thank you, Jesper.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>>>>>>> Hi! Here is webrev.08,
>>>>>>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. both tests:
>>>>>>>>>>>>>>>   48     public void eat() {
>>>>>>>>>>>>>>> 61     public void free() {
>>>>>>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>>>>>>  32  */
>>>>>>>>>>>>>>>  33 import 
>>>>>>>>>>>>>>> com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>>>>>>> add empty line between these lines or remove empty line 
>>>>>>>>>>>>>> #32 in
>>>>>>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>>>>>>  62         //do not free last one list
>>>>>>>>>>>>>> space after '//'
>>>>>>>>>>>>>> 3. both tests:
>>>>>>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>>>>>>> after @bug you should specify product bug ids which can be
>>>>>>>>>>>>>> tested by
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> test. I guess 8016479 instead of 8037924, and 
>>>>>>>>>>>>>> 8036025/8037925.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> otherwise it looks good, thank you for your work and 
>>>>>>>>>>>>>> patience )
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>>>>>>> Igor, please, see comment below, everything uncommented is
>>>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()' 'TestShrinkHeap.gc()'?
>>>>>>>>>>>>>>>> I cut this out.
>>>>>>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API 
>>>>>>>>>>>>>>>>> for it --
>>>>>>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Not sure is it applicable for me, because every time in
>>>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to
>>>>>>>>>>>>>>>>>>> review. It
>>>>>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>  45 public static byte[] temp;
>>>>>>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should 
>>>>>>>>>>>>>>>>>>>> have one
>>>>>>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> protected static final String 
>>>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>>>>>>> protected static final String 
>>>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage(); 
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage(); 
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() < 
>>>>>>>>>>>>>>>>>>>> muFull.getCommitted())) {
>>>>>>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>>>>>> String.format("committed free heap size is not
>>>>>>>>>>>>>>>>>>>> less than
>>>>>>>>>>>>>>>>>>>> committed full heap size, heap hasn't been 
>>>>>>>>>>>>>>>>>>>> shrunk?%n%s =
>>>>>>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(), 
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue() 
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full GC");
>>>>>>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/ 
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string 
>>>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary and
>>>>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 26 * @key gc
>>>>>>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc',
>>>>>>>>>>>>>>>>>>>>>>>> please don't
>>>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>>>>> I think that this is used for test execution - to
>>>>>>>>>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, so
>>>>>>>>>>>>>>>>>>>>>> we don't
>>>>>>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/ 
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct one is
>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/. 
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string 
>>>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>>>>>> 44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's 
>>>>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>>>>> 96 StringBuilder strb = new
>>>>>>>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than 
>>>>>>>>>>>>>>>>>>>>>>>>>>> committed
>>>>>>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>>>>>>   97
>>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator")); 
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>>   99
>>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator")); 
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>>  101 throw new
>>>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>>>>>>  throw new 
>>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap
>>>>>>>>>>>>>>>>>>>>>>>>>> size, heap
>>>>>>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue)); 
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/ 
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/ 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> bug:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>
>>



From erik.helin at oracle.com  Thu Apr  3 13:57:53 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 03 Apr 2014 15:57:53 +0200
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533C4CDC.3070307@oracle.com>
References: <5332FA20.5070607@oracle.com>
	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>
	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>
	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>
	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>
	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>
	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>
	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>
	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>
	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>
	<53394053.2070502@oracle.com> <533955B0.7000601@oracle.com>
	<533A6165.80704@oracle.com> <533A8141.2030608@oracle.com>
	<533AB040.6000302@oracle.com> <533C3654.7020801@oracle.com>
	<533C3974.5080803@oracle.com> <533C460D.5020707@oracle.com>
	<533C4CDC.3070307@oracle.com>
Message-ID: <533D68E1.7000007@oracle.com>

Andrey,

is all the changes in this webrev part of the patch? The files in this 
change looks very similar to the files in
http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.04/ ?

Thanks,
Erik

On 2014-04-02 19:46, Jesper Wilhelmsson wrote:
> New webrev is uploaded here:
>
> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.12/
>
> /Jesper
>
> Andrey Zakharov skrev 2/4/14 19:17:
>> Hi, here is not uploaded yet webrev with totally reverted inheritance.
>> Jesper, can you please upload to your space.
>> Thanks.
>>
>>
>> On 02.04.2014 20:23, Igor Ignatyev wrote:
>>> Andrey,
>>>
>>> Why do test classes extend TestShrinkHeap?
>>>
>>> Igor
>>>
>>> On 04/02/2014 08:09 PM, Andrey Zakharov wrote:
>>>> Here is version without hidden testflow:
>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.11/
>>>> Thanks.
>>>>
>>>> On 01.04.2014 16:25, Jesper Wilhelmsson wrote:
>>>>> Uploaded:
>>>>>
>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.10/
>>>>>
>>>>> In general  would agree regarding avoiding duplicated code, but when
>>>>> it comes to the control flow I agree with Erik. More hard to read code
>>>>> leads to harder maintenance than duplicating a few lines of code.
>>>>> /Jesper
>>>>>
>>>>> Andrey Zakharov skrev 1/4/14 11:05:
>>>>>> Hi, Erik. Thanks for comments.
>>>>>>
>>>>>> On 01.04.2014 10:49, Erik Helin wrote:
>>>>>>> Andrey,
>>>>>>>
>>>>>>> a couple of comments:
>>>>>>> - We do not use the @author tag in the tests
>>>>>>>   (if you've seen other tests have the @author tag, then that is
>>>>>>> a bug)
>>>>>> removed
>>>>>>> - I'm not a big fan of using inheritance for sharing code between
>>>>>>>   tests because it makes it very hard to open a test, e.g.
>>>>>>>   TestHumongousShrinkHeap.java, and see what it does.
>>>>>> Agreed, I'm too. But doubled code leads to harder maintenance.
>>>>>>>
>>>>>>>   The code you share in TestShrinkHeap is basically the check and
>>>>>>> the
>>>>>>>   control flow of the tests. I would prefer if you could move the
>>>>>>>   control flow (System.gc(), sample, eat, sample, free, check
>>>>>>> samples)
>>>>>>>   into the tests and then write helper functions for retrieving the
>>>>>>>   flag values.
>>>>>>>
>>>>>>>   As for the check, please use the assertions in
>>>>>>>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>>>>>>   throwing a RuntimeException.
>>>>>> Good point, changed.
>>>>>> Jesper, can we upload webrev.10 from attachment? Thanks.
>>>>>> I'm still need GC reviewers to approve push.
>>>>>>
>>>>>> Thanks.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Erik
>>>>>>>
>>>>>>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> New webrev uploaded.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>>>>>>
>>>>>>>> I'm not a Reviewer either so if you got Igor's blessing already, my
>>>>>>>> review won't be enough to push unfortunately.
>>>>>>>> /Jesper
>>>>>>>>
>>>>>>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>>>>>>> Hi,
>>>>>>>>> Jepser, here is updated webrev.09
>>>>>>>>> Thomas, Jesper can you review it as well?
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>>>>>>> Andrey,
>>>>>>>>>>
>>>>>>>>>> 1. TEST.groups:
>>>>>>>>>> please update copyright year:
>>>>>>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All
>>>>>>>>>>> rights
>>>>>>>>>>> reserved.
>>>>>>>>>> should be
>>>>>>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates.
>>>>>>>>>>> All
>>>>>>>>>>> rights
>>>>>>>>>>> reserved.
>>>>>>>>>>
>>>>>>>>>> 2. TestShrinkHeap.java
>>>>>>>>>>>   22  */
>>>>>>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>>>>>>> add empty line between 22 and 23 as you do in all other files,
>>>>>>>>>>
>>>>>>>>>> otherwise it looks good to me.
>>>>>>>>>>
>>>>>>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in
>>>>>>>>>> 'Reviewed-by'
>>>>>>>>>> section )
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Igor
>>>>>>>>>>
>>>>>>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>>>>>>> Hi, team
>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>>>>>>> Webrev uploaded:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>>>
>>>>>>>>>>>> /Jesper
>>>>>>>>>>> Thank you, Jesper.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>>>>>>> Hi! Here is webrev.08,
>>>>>>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. both tests:
>>>>>>>>>>>>>>>   48     public void eat() {
>>>>>>>>>>>>>>> 61     public void free() {
>>>>>>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>>>>>>  32  */
>>>>>>>>>>>>>>>  33 import
>>>>>>>>>>>>>>> com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>>>>>>> add empty line between these lines or remove empty line
>>>>>>>>>>>>>> #32 in
>>>>>>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>>>>>>  62         //do not free last one list
>>>>>>>>>>>>>> space after '//'
>>>>>>>>>>>>>> 3. both tests:
>>>>>>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>>>>>>> after @bug you should specify product bug ids which can be
>>>>>>>>>>>>>> tested by
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> test. I guess 8016479 instead of 8037924, and
>>>>>>>>>>>>>> 8036025/8037925.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> otherwise it looks good, thank you for your work and
>>>>>>>>>>>>>> patience )
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>>>>>>> Igor, please, see comment below, everything uncommented is
>>>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()' 'TestShrinkHeap.gc()'?
>>>>>>>>>>>>>>>> I cut this out.
>>>>>>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for
>>>>>>>>>>>>>>>>> it --
>>>>>>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Not sure is it applicable for me, because every time in
>>>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to
>>>>>>>>>>>>>>>>>>> review. It
>>>>>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>  45 public static byte[] temp;
>>>>>>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should
>>>>>>>>>>>>>>>>>>>> have one
>>>>>>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> protected static final String
>>>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>>>>>>> protected static final String
>>>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() <
>>>>>>>>>>>>>>>>>>>> muFull.getCommitted())) {
>>>>>>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>>>>>>       String.format("committed free heap size is not
>>>>>>>>>>>>>>>>>>>> less than
>>>>>>>>>>>>>>>>>>>> committed full heap size, heap hasn't been
>>>>>>>>>>>>>>>>>>>> shrunk?%n%s =
>>>>>>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(),
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue()
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full GC");
>>>>>>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string
>>>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary and
>>>>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 26 * @key gc
>>>>>>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc',
>>>>>>>>>>>>>>>>>>>>>>>> please don't
>>>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>>>>> I think that this is used for test execution - to
>>>>>>>>>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, so
>>>>>>>>>>>>>>>>>>>>>> we don't
>>>>>>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct one is
>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string
>>>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>>>>>> 44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's not
>>>>>>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>>>>> 96 StringBuilder strb = new
>>>>>>>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than
>>>>>>>>>>>>>>>>>>>>>>>>>>> committed
>>>>>>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>>>>>>   97
>>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>>   99
>>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>>  101 throw new
>>>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>>>>>>  throw new
>>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap
>>>>>>>>>>>>>>>>>>>>>>>>>> size, heap
>>>>>>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue));
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> bug:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>
>>


From erik.helin at oracle.com  Thu Apr  3 14:01:52 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 03 Apr 2014 16:01:52 +0200
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533D68E1.7000007@oracle.com>
References: <5332FA20.5070607@oracle.com>	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>	<53394053.2070502@oracle.com>
	<533955B0.7000601@oracle.com>	<533A6165.80704@oracle.com>
	<533A8141.2030608@oracle.com>	<533AB040.6000302@oracle.com>
	<533C3654.7020801@oracle.com>	<533C3974.5080803@oracle.com>
	<533C460D.5020707@oracle.com>	<533C4CDC.3070307@oracle.com>
	<533D68E1.7000007@oracle.com>
Message-ID: <533D69D0.6060203@oracle.com>

Andrey, Igor,

maybe we should have a chat session on IM where can discuss this?

Thanks,
Erik

On 2014-04-03 15:57, Erik Helin wrote:
> Andrey,
>
> is all the changes in this webrev part of the patch? The files in this
> change looks very similar to the files in
> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.04/ ?
>
> Thanks,
> Erik
>
> On 2014-04-02 19:46, Jesper Wilhelmsson wrote:
>> New webrev is uploaded here:
>>
>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.12/
>>
>> /Jesper
>>
>> Andrey Zakharov skrev 2/4/14 19:17:
>>> Hi, here is not uploaded yet webrev with totally reverted inheritance.
>>> Jesper, can you please upload to your space.
>>> Thanks.
>>>
>>>
>>> On 02.04.2014 20:23, Igor Ignatyev wrote:
>>>> Andrey,
>>>>
>>>> Why do test classes extend TestShrinkHeap?
>>>>
>>>> Igor
>>>>
>>>> On 04/02/2014 08:09 PM, Andrey Zakharov wrote:
>>>>> Here is version without hidden testflow:
>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.11/
>>>>> Thanks.
>>>>>
>>>>> On 01.04.2014 16:25, Jesper Wilhelmsson wrote:
>>>>>> Uploaded:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.10/
>>>>>>
>>>>>> In general  would agree regarding avoiding duplicated code, but when
>>>>>> it comes to the control flow I agree with Erik. More hard to read
>>>>>> code
>>>>>> leads to harder maintenance than duplicating a few lines of code.
>>>>>> /Jesper
>>>>>>
>>>>>> Andrey Zakharov skrev 1/4/14 11:05:
>>>>>>> Hi, Erik. Thanks for comments.
>>>>>>>
>>>>>>> On 01.04.2014 10:49, Erik Helin wrote:
>>>>>>>> Andrey,
>>>>>>>>
>>>>>>>> a couple of comments:
>>>>>>>> - We do not use the @author tag in the tests
>>>>>>>>   (if you've seen other tests have the @author tag, then that is
>>>>>>>> a bug)
>>>>>>> removed
>>>>>>>> - I'm not a big fan of using inheritance for sharing code between
>>>>>>>>   tests because it makes it very hard to open a test, e.g.
>>>>>>>>   TestHumongousShrinkHeap.java, and see what it does.
>>>>>>> Agreed, I'm too. But doubled code leads to harder maintenance.
>>>>>>>>
>>>>>>>>   The code you share in TestShrinkHeap is basically the check and
>>>>>>>> the
>>>>>>>>   control flow of the tests. I would prefer if you could move the
>>>>>>>>   control flow (System.gc(), sample, eat, sample, free, check
>>>>>>>> samples)
>>>>>>>>   into the tests and then write helper functions for retrieving the
>>>>>>>>   flag values.
>>>>>>>>
>>>>>>>>   As for the check, please use the assertions in
>>>>>>>>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>>>>>>>   throwing a RuntimeException.
>>>>>>> Good point, changed.
>>>>>>> Jesper, can we upload webrev.10 from attachment? Thanks.
>>>>>>> I'm still need GC reviewers to approve push.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Erik
>>>>>>>>
>>>>>>>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> New webrev uploaded.
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>>>>>>>
>>>>>>>>> I'm not a Reviewer either so if you got Igor's blessing
>>>>>>>>> already, my
>>>>>>>>> review won't be enough to push unfortunately.
>>>>>>>>> /Jesper
>>>>>>>>>
>>>>>>>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>>>>>>>> Hi,
>>>>>>>>>> Jepser, here is updated webrev.09
>>>>>>>>>> Thomas, Jesper can you review it as well?
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>>>>>>>> Andrey,
>>>>>>>>>>>
>>>>>>>>>>> 1. TEST.groups:
>>>>>>>>>>> please update copyright year:
>>>>>>>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All
>>>>>>>>>>>> rights
>>>>>>>>>>>> reserved.
>>>>>>>>>>> should be
>>>>>>>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates.
>>>>>>>>>>>> All
>>>>>>>>>>>> rights
>>>>>>>>>>>> reserved.
>>>>>>>>>>>
>>>>>>>>>>> 2. TestShrinkHeap.java
>>>>>>>>>>>>   22  */
>>>>>>>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>>>>>>>> add empty line between 22 and 23 as you do in all other files,
>>>>>>>>>>>
>>>>>>>>>>> otherwise it looks good to me.
>>>>>>>>>>>
>>>>>>>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in
>>>>>>>>>>> 'Reviewed-by'
>>>>>>>>>>> section )
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Igor
>>>>>>>>>>>
>>>>>>>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>>>>>>>> Hi, team
>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>>>>>>>> Webrev uploaded:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Jesper
>>>>>>>>>>>> Thank you, Jesper.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>>>>>>>> Hi! Here is webrev.08,
>>>>>>>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. both tests:
>>>>>>>>>>>>>>>>   48     public void eat() {
>>>>>>>>>>>>>>>> 61     public void free() {
>>>>>>>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>>>>>>>  32  */
>>>>>>>>>>>>>>>>  33 import
>>>>>>>>>>>>>>>> com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>>>>>>>> add empty line between these lines or remove empty line
>>>>>>>>>>>>>>> #32 in
>>>>>>>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>>>>>>>  62         //do not free last one list
>>>>>>>>>>>>>>> space after '//'
>>>>>>>>>>>>>>> 3. both tests:
>>>>>>>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>>>>>>>> after @bug you should specify product bug ids which can be
>>>>>>>>>>>>>>> tested by
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>> test. I guess 8016479 instead of 8037924, and
>>>>>>>>>>>>>>> 8036025/8037925.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> otherwise it looks good, thank you for your work and
>>>>>>>>>>>>>>> patience )
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>>>>>>>> Igor, please, see comment below, everything uncommented is
>>>>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()' 'TestShrinkHeap.gc()'?
>>>>>>>>>>>>>>>>> I cut this out.
>>>>>>>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for
>>>>>>>>>>>>>>>>>> it --
>>>>>>>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Not sure is it applicable for me, because every time in
>>>>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to
>>>>>>>>>>>>>>>>>>>> review. It
>>>>>>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>  45 public static byte[] temp;
>>>>>>>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should
>>>>>>>>>>>>>>>>>>>>> have one
>>>>>>>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> protected static final String
>>>>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>>>>>>>> protected static final String
>>>>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() <
>>>>>>>>>>>>>>>>>>>>> muFull.getCommitted())) {
>>>>>>>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>>>>>>>       String.format("committed free heap size is not
>>>>>>>>>>>>>>>>>>>>> less than
>>>>>>>>>>>>>>>>>>>>> committed full heap size, heap hasn't been
>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s =
>>>>>>>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(),
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue()
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full GC");
>>>>>>>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string
>>>>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary and
>>>>>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 26 * @key gc
>>>>>>>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc',
>>>>>>>>>>>>>>>>>>>>>>>>> please don't
>>>>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>>>>>> I think that this is used for test execution - to
>>>>>>>>>>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, so
>>>>>>>>>>>>>>>>>>>>>>> we don't
>>>>>>>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct one is
>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string
>>>>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's
>>>>>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 96 StringBuilder strb = new
>>>>>>>>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than
>>>>>>>>>>>>>>>>>>>>>>>>>>>> committed
>>>>>>>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>>>>>>>   97
>>>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>   99
>>>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " = " +
>>>>>>>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>  101 throw new
>>>>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>>>>>>>  throw new
>>>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap
>>>>>>>>>>>>>>>>>>>>>>>>>>> size, heap
>>>>>>>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue));
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bug:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>
>>>


From stefan.karlsson at oracle.com  Fri Apr  4 07:59:45 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 04 Apr 2014 09:59:45 +0200
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when printing
	uints and ints in the GC code
Message-ID: <533E6671.9050803@oracle.com>

Please, review this patch to the GC code to change usages of 
UINT32_FORMAT and INT32_FORMAT to %u and %d when uints and ints are used.

While doing this change I found, and changed, a couple of places where 
we used UINT32_FORMAT to print variables that were less than 4 bytes.

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

thanks,
StefanK


From stefan.karlsson at oracle.com  Fri Apr  4 08:09:03 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 04 Apr 2014 10:09:03 +0200
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when
	printing uints and ints in the GC code
In-Reply-To: <533E6671.9050803@oracle.com>
References: <533E6671.9050803@oracle.com>
Message-ID: <533E689F.6020009@oracle.com>

On 2014-04-04 09:59, Stefan Karlsson wrote:
> Please, review this patch to the GC code to change usages of 
> UINT32_FORMAT and INT32_FORMAT to %u and %d when uints and ints are used.
>
> While doing this change I found, and changed, a couple of places where 
> we used UINT32_FORMAT to print variables that were less than 4 bytes.
>
> webrev: http://cr.openjdk.java.net/~stefank/8039244/webrev.00/

I unintentionally changed codeCache.cpp.

This webrev is without the fix to the compiler code:
http://cr.openjdk.java.net/~stefank/8039244/webrev.01/

thanks,
StefanK

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



From stefan.karlsson at oracle.com  Fri Apr  4 08:10:58 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 04 Apr 2014 10:10:58 +0200
Subject: Request for review: 8016302: Change type of the number of GC
	workers to unsigned int (2)
In-Reply-To: <533C3821.60005@oracle.com>
References: <533C3821.60005@oracle.com>
Message-ID: <533E6912.6000103@oracle.com>

I see that this change was pushed although I opposed the usage of 
UINT32_FORMAT, both online and offline:
http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/7901f4c9c3cc

I've sent out this review request to get rid of the incorrect usages of 
UINT32_FORMAT and INT32_FORMAT from the GC code:
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-April/009809.html

StefanK

On 2014-04-02 18:17, Vladimir Kempik wrote:
> Hi all,
>
> Could I have a couple of reviews for this change?
>
> http://cr.openjdk.java.net/~vkempik/8016302/webrev.04/
>
> In 7121618 variables representing GC workers (worker id, worker id 
> offset) have been changed from int to unsigned int.
>
> Since then, code reintroduced the use of int's for this type of 
> variable; fixing this by aligning the code to use uints for ints.
>
> Since last september the fix was updated for jdk9 and size_t was 
> replaced with uint in
> dirtyCardQueue.hpp,
>
>   54 bool apply_closure(CardTableEntryClosure* cl,
>   55                      bool consume = true,
>   56                      size_t worker_i = 0);
>
>   99   // The number of parallel ids that can be claimed to allow
> collector or
>  100   // mutator threads to do card-processing work.
>  101   static size_t num_par_ids();
>
> Thanks,
> Vladimir
>



From bengt.rutisson at oracle.com  Fri Apr  4 08:29:55 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 04 Apr 2014 10:29:55 +0200
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when
	printing uints and ints in the GC code
In-Reply-To: <533E689F.6020009@oracle.com>
References: <533E6671.9050803@oracle.com> <533E689F.6020009@oracle.com>
Message-ID: <533E6D83.6060607@oracle.com>


On 2014-04-04 10:09, Stefan Karlsson wrote:
> On 2014-04-04 09:59, Stefan Karlsson wrote:
>> Please, review this patch to the GC code to change usages of 
>> UINT32_FORMAT and INT32_FORMAT to %u and %d when uints and ints are 
>> used.
>>
>> While doing this change I found, and changed, a couple of places 
>> where we used UINT32_FORMAT to print variables that were less than 4 
>> bytes.
>>
>> webrev: http://cr.openjdk.java.net/~stefank/8039244/webrev.00/
>
> I unintentionally changed codeCache.cpp.
>
> This webrev is without the fix to the compiler code:
> http://cr.openjdk.java.net/~stefank/8039244/webrev.01/

Looks great! Thanks for fixing this Stefan.

Bengt

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



From thomas.schatzl at oracle.com  Fri Apr  4 09:00:11 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 04 Apr 2014 11:00:11 +0200
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when
	printing uints and ints in the GC code
In-Reply-To: <533E689F.6020009@oracle.com>
References: <533E6671.9050803@oracle.com> <533E689F.6020009@oracle.com>
Message-ID: <1396602011.2718.3.camel@cirrus>

Hi,

On Fri, 2014-04-04 at 10:09 +0200, Stefan Karlsson wrote:
> On 2014-04-04 09:59, Stefan Karlsson wrote:
> > Please, review this patch to the GC code to change usages of 
> > UINT32_FORMAT and INT32_FORMAT to %u and %d when uints and ints are used.
> >
> > While doing this change I found, and changed, a couple of places where 
> > we used UINT32_FORMAT to print variables that were less than 4 bytes.
> >
> > webrev: http://cr.openjdk.java.net/~stefank/8039244/webrev.00/
> 
> I unintentionally changed codeCache.cpp.
> 
> This webrev is without the fix to the compiler code:
> http://cr.openjdk.java.net/~stefank/8039244/webrev.01/

ScanRSClosure::printCard still uses *INT32_FORMAT for (u)ints. Also the
GC parts (symbol/string table iteration) of symbolTable.cpp still use
them.

Could you fix these occurrences too?

Thanks,
  Thomas



From jesper.wilhelmsson at oracle.com  Fri Apr  4 09:55:49 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Fri, 04 Apr 2014 11:55:49 +0200
Subject: Request for review: 8016302: Change type of the number of GC
	workers to unsigned int (2)
In-Reply-To: <533E6912.6000103@oracle.com>
References: <533C3821.60005@oracle.com> <533E6912.6000103@oracle.com>
Message-ID: <533E81A5.9000003@oracle.com>

Thanks for cleaning that up Stefan!
FWIW, I actually think this was the right way to do it, let this change go in 
without further delay and clean up all the UINT32_FORMAT usages in a separate patch.
/Jesper


Stefan Karlsson skrev 4/4/14 10:10:
> I see that this change was pushed although I opposed the usage of UINT32_FORMAT,
> both online and offline:
> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/7901f4c9c3cc
>
> I've sent out this review request to get rid of the incorrect usages of
> UINT32_FORMAT and INT32_FORMAT from the GC code:
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-April/009809.html
>
> StefanK
>
> On 2014-04-02 18:17, Vladimir Kempik wrote:
>> Hi all,
>>
>> Could I have a couple of reviews for this change?
>>
>> http://cr.openjdk.java.net/~vkempik/8016302/webrev.04/
>>
>> In 7121618 variables representing GC workers (worker id, worker id offset)
>> have been changed from int to unsigned int.
>>
>> Since then, code reintroduced the use of int's for this type of variable;
>> fixing this by aligning the code to use uints for ints.
>>
>> Since last september the fix was updated for jdk9 and size_t was replaced with
>> uint in
>> dirtyCardQueue.hpp,
>>
>>   54 bool apply_closure(CardTableEntryClosure* cl,
>>   55                      bool consume = true,
>>   56                      size_t worker_i = 0);
>>
>>   99   // The number of parallel ids that can be claimed to allow
>> collector or
>>  100   // mutator threads to do card-processing work.
>>  101   static size_t num_par_ids();
>>
>> Thanks,
>> Vladimir
>>
>


From stefan.karlsson at oracle.com  Fri Apr  4 10:48:17 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 04 Apr 2014 12:48:17 +0200
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when
	printing uints and ints in the GC code
In-Reply-To: <1396602011.2718.3.camel@cirrus>
References: <533E6671.9050803@oracle.com> <533E689F.6020009@oracle.com>
	<1396602011.2718.3.camel@cirrus>
Message-ID: <533E8DF1.7050204@oracle.com>


On 2014-04-04 11:00, Thomas Schatzl wrote:
> Hi,
>
> On Fri, 2014-04-04 at 10:09 +0200, Stefan Karlsson wrote:
>> On 2014-04-04 09:59, Stefan Karlsson wrote:
>>> Please, review this patch to the GC code to change usages of
>>> UINT32_FORMAT and INT32_FORMAT to %u and %d when uints and ints are used.
>>>
>>> While doing this change I found, and changed, a couple of places where
>>> we used UINT32_FORMAT to print variables that were less than 4 bytes.
>>>
>>> webrev: http://cr.openjdk.java.net/~stefank/8039244/webrev.00/
>> I unintentionally changed codeCache.cpp.
>>
>> This webrev is without the fix to the compiler code:
>> http://cr.openjdk.java.net/~stefank/8039244/webrev.01/
> ScanRSClosure::printCard still uses *INT32_FORMAT for (u)ints. Also the
> GC parts (symbol/string table iteration) of symbolTable.cpp still use
> them.
>
> Could you fix these occurrences too?

Sure:
http://cr.openjdk.java.net/~stefank/8039244/webrev.02/

thanks,
StefanK

>
> Thanks,
>    Thomas
>



From bengt.rutisson at oracle.com  Fri Apr  4 10:52:24 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 04 Apr 2014 12:52:24 +0200
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when
	printing uints and ints in the GC code
In-Reply-To: <533E8DF1.7050204@oracle.com>
References: <533E6671.9050803@oracle.com>
	<533E689F.6020009@oracle.com>	<1396602011.2718.3.camel@cirrus>
	<533E8DF1.7050204@oracle.com>
Message-ID: <533E8EE8.3010304@oracle.com>


On 2014-04-04 12:48, Stefan Karlsson wrote:
>
> On 2014-04-04 11:00, Thomas Schatzl wrote:
>> Hi,
>>
>> On Fri, 2014-04-04 at 10:09 +0200, Stefan Karlsson wrote:
>>> On 2014-04-04 09:59, Stefan Karlsson wrote:
>>>> Please, review this patch to the GC code to change usages of
>>>> UINT32_FORMAT and INT32_FORMAT to %u and %d when uints and ints are 
>>>> used.
>>>>
>>>> While doing this change I found, and changed, a couple of places where
>>>> we used UINT32_FORMAT to print variables that were less than 4 bytes.
>>>>
>>>> webrev: http://cr.openjdk.java.net/~stefank/8039244/webrev.00/
>>> I unintentionally changed codeCache.cpp.
>>>
>>> This webrev is without the fix to the compiler code:
>>> http://cr.openjdk.java.net/~stefank/8039244/webrev.01/
>> ScanRSClosure::printCard still uses *INT32_FORMAT for (u)ints. Also the
>> GC parts (symbol/string table iteration) of symbolTable.cpp still use
>> them.
>>
>> Could you fix these occurrences too?
>
> Sure:
> http://cr.openjdk.java.net/~stefank/8039244/webrev.02/

Still looks good to me.

Bengt

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



From stefan.karlsson at oracle.com  Fri Apr  4 10:58:36 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 04 Apr 2014 12:58:36 +0200
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when
	printing uints and ints in the GC code
In-Reply-To: <533E8EE8.3010304@oracle.com>
References: <533E6671.9050803@oracle.com>
	<533E689F.6020009@oracle.com>	<1396602011.2718.3.camel@cirrus>
	<533E8DF1.7050204@oracle.com> <533E8EE8.3010304@oracle.com>
Message-ID: <533E905C.1070806@oracle.com>


On 2014-04-04 12:52, Bengt Rutisson wrote:
>
> On 2014-04-04 12:48, Stefan Karlsson wrote:
>>
>> On 2014-04-04 11:00, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Fri, 2014-04-04 at 10:09 +0200, Stefan Karlsson wrote:
>>>> On 2014-04-04 09:59, Stefan Karlsson wrote:
>>>>> Please, review this patch to the GC code to change usages of
>>>>> UINT32_FORMAT and INT32_FORMAT to %u and %d when uints and ints 
>>>>> are used.
>>>>>
>>>>> While doing this change I found, and changed, a couple of places 
>>>>> where
>>>>> we used UINT32_FORMAT to print variables that were less than 4 bytes.
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~stefank/8039244/webrev.00/
>>>> I unintentionally changed codeCache.cpp.
>>>>
>>>> This webrev is without the fix to the compiler code:
>>>> http://cr.openjdk.java.net/~stefank/8039244/webrev.01/
>>> ScanRSClosure::printCard still uses *INT32_FORMAT for (u)ints. Also the
>>> GC parts (symbol/string table iteration) of symbolTable.cpp still use
>>> them.
>>>
>>> Could you fix these occurrences too?
>>
>> Sure:
>> http://cr.openjdk.java.net/~stefank/8039244/webrev.02/
>
> Still looks good to me.

Thanks, Bengt.

StefanK

>
> Bengt
>
>>
>> thanks,
>> StefanK
>>
>>>
>>> Thanks,
>>>    Thomas
>>>
>>
>



From thomas.schatzl at oracle.com  Fri Apr  4 11:12:41 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 04 Apr 2014 13:12:41 +0200
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when
	printing uints and ints in the GC code
In-Reply-To: <533E8DF1.7050204@oracle.com>
References: <533E6671.9050803@oracle.com> <533E689F.6020009@oracle.com>
	<1396602011.2718.3.camel@cirrus> <533E8DF1.7050204@oracle.com>
Message-ID: <1396609961.2718.10.camel@cirrus>

Hi,

On Fri, 2014-04-04 at 12:48 +0200, Stefan Karlsson wrote:
> On 2014-04-04 11:00, Thomas Schatzl wrote:
> > Hi,
> >
> > On Fri, 2014-04-04 at 10:09 +0200, Stefan Karlsson wrote:
> >> On 2014-04-04 09:59, Stefan Karlsson wrote:
> >>> Please, review this patch to the GC code to change usages of
> >>> UINT32_FORMAT and INT32_FORMAT to %u and %d when uints and ints are used.
> >>>
> >>> While doing this change I found, and changed, a couple of places where
> >>> we used UINT32_FORMAT to print variables that were less than 4 bytes.
> >>>
> >>> webrev: http://cr.openjdk.java.net/~stefank/8039244/webrev.00/
> >> I unintentionally changed codeCache.cpp.
> >>
> >> This webrev is without the fix to the compiler code:
> >> http://cr.openjdk.java.net/~stefank/8039244/webrev.01/
> > ScanRSClosure::printCard still uses *INT32_FORMAT for (u)ints. Also the
> > GC parts (symbol/string table iteration) of symbolTable.cpp still use
> > them.
> >
> > Could you fix these occurrences too?
> 
> Sure:
> http://cr.openjdk.java.net/~stefank/8039244/webrev.02/
> 

  looks good.

Thanks,
Thomas



From stefan.karlsson at oracle.com  Fri Apr  4 11:07:56 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 04 Apr 2014 13:07:56 +0200
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when
	printing uints and ints in the GC code
In-Reply-To: <1396609961.2718.10.camel@cirrus>
References: <533E6671.9050803@oracle.com> <533E689F.6020009@oracle.com>	
	<1396602011.2718.3.camel@cirrus> <533E8DF1.7050204@oracle.com>
	<1396609961.2718.10.camel@cirrus>
Message-ID: <533E928C.6010102@oracle.com>


On 2014-04-04 13:12, Thomas Schatzl wrote:
> Hi,
>
> On Fri, 2014-04-04 at 12:48 +0200, Stefan Karlsson wrote:
>> On 2014-04-04 11:00, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Fri, 2014-04-04 at 10:09 +0200, Stefan Karlsson wrote:
>>>> On 2014-04-04 09:59, Stefan Karlsson wrote:
>>>>> Please, review this patch to the GC code to change usages of
>>>>> UINT32_FORMAT and INT32_FORMAT to %u and %d when uints and ints are used.
>>>>>
>>>>> While doing this change I found, and changed, a couple of places where
>>>>> we used UINT32_FORMAT to print variables that were less than 4 bytes.
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~stefank/8039244/webrev.00/
>>>> I unintentionally changed codeCache.cpp.
>>>>
>>>> This webrev is without the fix to the compiler code:
>>>> http://cr.openjdk.java.net/~stefank/8039244/webrev.01/
>>> ScanRSClosure::printCard still uses *INT32_FORMAT for (u)ints. Also the
>>> GC parts (symbol/string table iteration) of symbolTable.cpp still use
>>> them.
>>>
>>> Could you fix these occurrences too?
>> Sure:
>> http://cr.openjdk.java.net/~stefank/8039244/webrev.02/
>>
>    looks good.

Thanks, Thomas.

StefanK

>
> Thanks,
> Thomas
>



From per.liden at oracle.com  Fri Apr  4 12:13:56 2014
From: per.liden at oracle.com (Per Liden)
Date: Fri, 04 Apr 2014 14:13:56 +0200
Subject: RFR(s): 8037112: gc/g1/TestHumongousAllocInitialMark.java caused
	SIGSEGV
In-Reply-To: <3971356.DreSMqAOW1@mgerdin03>
References: <533D42C0.8060306@oracle.com> <3971356.DreSMqAOW1@mgerdin03>
Message-ID: <533EA204.3090607@oracle.com>

Thanks Mikael!

Updated webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.1/

/Per

On 04/03/2014 03:59 PM, Mikael Gerdin wrote:
> Hi Per,
>
> On Thursday 03 April 2014 13.15.12 Per Liden wrote:
>> Hi,
>>
>> Could I please have this bugfix reviewed.
>>
>> Summary: G1's ConcurrentMarkThread tries to use the gclog_or_tty when
>> the JVM is about to exit and the gclog_or_tty instance has been
>> destroyed. To prevent this, the ConcurrentMarkThread needs to join the
>> SuspendibleThreadSet before accessing gclog_or_tty.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8037112
>> Webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.0/
>
> While I realize that this code is still semantically correct I think it reads
> a bit strange. In my mind if we have a
> if (...) {} else if (...) {} else {} block the checks in the "if" and "else
> if" should usually somehow related checks.
>
>   282       if (!cm()->has_aborted()) {
>   283         g1_policy->record_concurrent_mark_cleanup_completed();
>   284       } else if (G1Log::fine()) {
>   285         gclog_or_tty->date_stamp(PrintGCDateStamps);
>   286         gclog_or_tty->stamp(PrintGCTimeStamps);
>   287         gclog_or_tty->print_cr("[GC concurrent-mark-abort]");
>   288       }
>
> I would prefer if it was structured the other way around:
> if (cm()->has_aborted()) {
> 	if (G1Log::fine()) { ... }
> else {
> 	g1_policy->record_concurrent_mark_cleanup_completed();
> }
>
> The rest of the change looks good.
>
> /Mikael
>
>>
>> Thanks!
>> /Per
>>
>> Btw, I created a separate RFE, JDK-8039147, to do a little bit of
>> cleanup of the SuspendibleThreadSet and how it's used. Will send that
>> out as separate review request shortly.
>



From mikael.gerdin at oracle.com  Fri Apr  4 12:28:17 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 04 Apr 2014 14:28:17 +0200
Subject: RFR(s): 8037112: gc/g1/TestHumongousAllocInitialMark.java caused
	SIGSEGV
In-Reply-To: <533EA204.3090607@oracle.com>
References: <533D42C0.8060306@oracle.com> <3971356.DreSMqAOW1@mgerdin03>
	<533EA204.3090607@oracle.com>
Message-ID: <4063857.h91XTfINnv@mgerdin03>

Per,

On Friday 04 April 2014 14.13.56 Per Liden wrote:
> Thanks Mikael!
> 
> Updated webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.1/

Looks good.
/Mikael

> 
> /Per
> 
> On 04/03/2014 03:59 PM, Mikael Gerdin wrote:
> > Hi Per,
> > 
> > On Thursday 03 April 2014 13.15.12 Per Liden wrote:
> >> Hi,
> >> 
> >> Could I please have this bugfix reviewed.
> >> 
> >> Summary: G1's ConcurrentMarkThread tries to use the gclog_or_tty when
> >> the JVM is about to exit and the gclog_or_tty instance has been
> >> destroyed. To prevent this, the ConcurrentMarkThread needs to join the
> >> SuspendibleThreadSet before accessing gclog_or_tty.
> >> 
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8037112
> >> Webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.0/
> > 
> > While I realize that this code is still semantically correct I think it
> > reads a bit strange. In my mind if we have a
> > if (...) {} else if (...) {} else {} block the checks in the "if" and
> > "else
> > if" should usually somehow related checks.
> > 
> >   282       if (!cm()->has_aborted()) {
> >   283         g1_policy->record_concurrent_mark_cleanup_completed();
> >   284       } else if (G1Log::fine()) {
> >   285         gclog_or_tty->date_stamp(PrintGCDateStamps);
> >   286         gclog_or_tty->stamp(PrintGCTimeStamps);
> >   287         gclog_or_tty->print_cr("[GC concurrent-mark-abort]");
> >   288       }
> > 
> > I would prefer if it was structured the other way around:
> > if (cm()->has_aborted()) {
> > 
> > 	if (G1Log::fine()) { ... }
> > 
> > else {
> > 
> > 	g1_policy->record_concurrent_mark_cleanup_completed();
> > 
> > }
> > 
> > The rest of the change looks good.
> > 
> > /Mikael
> > 
> >> Thanks!
> >> /Per
> >> 
> >> Btw, I created a separate RFE, JDK-8039147, to do a little bit of
> >> cleanup of the SuspendibleThreadSet and how it's used. Will send that
> >> out as separate review request shortly.



From vladimir.kozlov at oracle.com  Fri Apr  4 15:58:31 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 04 Apr 2014 08:58:31 -0700
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when
	printing uints and ints in the GC code
In-Reply-To: <533E6671.9050803@oracle.com>
References: <533E6671.9050803@oracle.com>
Message-ID: <533ED6A7.2020403@oracle.com>

Stefan,

Could you explain more why you do this? Bug report does not explain why you need this.
The main reason we use *_FORMAT macros is because different platforms behave differently when we use normal format's 
specifiers.

Thanks,
Vladimir

On 4/4/14 12:59 AM, Stefan Karlsson wrote:
> Please, review this patch to the GC code to change usages of UINT32_FORMAT and INT32_FORMAT to %u and %d when uints and
> ints are used.
>
> While doing this change I found, and changed, a couple of places where we used UINT32_FORMAT to print variables that
> were less than 4 bytes.
>
> webrev: http://cr.openjdk.java.net/~stefank/8039244/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8039244
>
> thanks,
> StefanK


From per.liden at oracle.com  Fri Apr  4 16:14:37 2014
From: per.liden at oracle.com (Per Liden)
Date: Fri, 4 Apr 2014 18:14:37 +0200
Subject: RFR(s): 8037112: gc/g1/TestHumongousAllocInitialMark.java caused
	SIGSEGV
In-Reply-To: <4063857.h91XTfINnv@mgerdin03>
References: <533D42C0.8060306@oracle.com> <3971356.DreSMqAOW1@mgerdin03>
	<533EA204.3090607@oracle.com> <4063857.h91XTfINnv@mgerdin03>
Message-ID: <1F09BCB8-DE4D-4B97-AB63-06104BC6F0BD@oracle.com>

Hmm, I discovered a potential dead lock with this approach, so please hold reviews on this for now.

Sorry!
/Per

On 04 Apr 2014, at 14:28, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:

> Per,
> 
> On Friday 04 April 2014 14.13.56 Per Liden wrote:
>> Thanks Mikael!
>> 
>> Updated webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.1/
> 
> Looks good.
> /Mikael
> 
>> 
>> /Per
>> 
>> On 04/03/2014 03:59 PM, Mikael Gerdin wrote:
>>> Hi Per,
>>> 
>>> On Thursday 03 April 2014 13.15.12 Per Liden wrote:
>>>> Hi,
>>>> 
>>>> Could I please have this bugfix reviewed.
>>>> 
>>>> Summary: G1's ConcurrentMarkThread tries to use the gclog_or_tty when
>>>> the JVM is about to exit and the gclog_or_tty instance has been
>>>> destroyed. To prevent this, the ConcurrentMarkThread needs to join the
>>>> SuspendibleThreadSet before accessing gclog_or_tty.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8037112
>>>> Webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.0/
>>> 
>>> While I realize that this code is still semantically correct I think it
>>> reads a bit strange. In my mind if we have a
>>> if (...) {} else if (...) {} else {} block the checks in the "if" and
>>> "else
>>> if" should usually somehow related checks.
>>> 
>>>  282       if (!cm()->has_aborted()) {
>>>  283         g1_policy->record_concurrent_mark_cleanup_completed();
>>>  284       } else if (G1Log::fine()) {
>>>  285         gclog_or_tty->date_stamp(PrintGCDateStamps);
>>>  286         gclog_or_tty->stamp(PrintGCTimeStamps);
>>>  287         gclog_or_tty->print_cr("[GC concurrent-mark-abort]");
>>>  288       }
>>> 
>>> I would prefer if it was structured the other way around:
>>> if (cm()->has_aborted()) {
>>> 
>>> 	if (G1Log::fine()) { ... }
>>> 
>>> else {
>>> 
>>> 	g1_policy->record_concurrent_mark_cleanup_completed();
>>> 
>>> }
>>> 
>>> The rest of the change looks good.
>>> 
>>> /Mikael
>>> 
>>>> Thanks!
>>>> /Per
>>>> 
>>>> Btw, I created a separate RFE, JDK-8039147, to do a little bit of
>>>> cleanup of the SuspendibleThreadSet and how it's used. Will send that
>>>> out as separate review request shortly.
> 



From stefan.karlsson at oracle.com  Fri Apr  4 19:07:47 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 04 Apr 2014 21:07:47 +0200
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when
	printing uints and ints in the GC code
In-Reply-To: <533ED6A7.2020403@oracle.com>
References: <533E6671.9050803@oracle.com> <533ED6A7.2020403@oracle.com>
Message-ID: <533F0303.1000501@oracle.com>

Vladimir,

On 2014-04-04 17:58, Vladimir Kozlov wrote:
> Stefan,
>
> Could you explain more why you do this? Bug report does not explain 
> why you need this.
> The main reason we use *_FORMAT macros is because different platforms 
> behave differently when we use normal format's specifiers.

First, *INT32_FORMAT isn't technically correct for printing ints. Though 
I agree that it probably works for most (all?) platforms HotSpot is run on.

Second, and probably more important, we usually use %u and %d to print 
ints, not UINT32_FORMAT and INT32_FORMAT. By changing these few 
occurrences in the GC code our print code gets more uniform.

This is what you get if you grep after these format specifiers:

$ grep -r "%d\|%u" src/ | wc
     3209   24297  353527

$ grep -r "INT32_FORMAT" src/ | wc
       71     517    7841

$ grep -r "%d\|%u" src/share/vm/memory/ src/share/vm/gc_implementation/ | wc
      426    3274   55241

$ grep -r "INT32_FORMAT" src/share/vm/memory/ 
src/share/vm/gc_implementation/ | wc
       20     151    2603

thanks,
StefanK

>
> Thanks,
> Vladimir
>
> On 4/4/14 12:59 AM, Stefan Karlsson wrote:
>> Please, review this patch to the GC code to change usages of 
>> UINT32_FORMAT and INT32_FORMAT to %u and %d when uints and
>> ints are used.
>>
>> While doing this change I found, and changed, a couple of places 
>> where we used UINT32_FORMAT to print variables that
>> were less than 4 bytes.
>>
>> webrev: http://cr.openjdk.java.net/~stefank/8039244/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8039244
>>
>> thanks,
>> StefanK



From Peter.B.Kessler at Oracle.COM  Fri Apr  4 21:58:25 2014
From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler)
Date: Fri, 04 Apr 2014 14:58:25 -0700
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when
	printing uints and ints in the GC code
In-Reply-To: <533F0303.1000501@oracle.com>
References: <533E6671.9050803@oracle.com> <533ED6A7.2020403@oracle.com>
	<533F0303.1000501@oracle.com>
Message-ID: <533F2B01.30500@Oracle.COM>

On 04/04/14 12:07, Stefan Karlsson wrote:
> Vladimir,
>
> On 2014-04-04 17:58, Vladimir Kozlov wrote:
>> Stefan,
>>
>> Could you explain more why you do this? Bug report does not explain why you need this.
>> The main reason we use *_FORMAT macros is because different platforms behave differently when we use normal format's specifiers.
>
> First, *INT32_FORMAT isn't technically correct for printing ints. Though I agree that it probably works for most (all?) platforms HotSpot is run on.

If INT32_FORMAT and UINT32_FORMAT are not technically correct, then fix them.  That's a separate issue.  As Vladimir says, the whole point of those macros is to localize the changes needed to run on platforms where the native %d and %u don't work the way we expect them to.

> Second, and probably more important, we usually use %u and %d to print ints, not UINT32_FORMAT and INT32_FORMAT. By changing these few occurrences in the GC code our print code gets more uniform.
>
> This is what you get if you grep after these format specifiers:
>
> $ grep -r "%d\|%u" src/ | wc
>      3209   24297  353527
>
> $ grep -r "INT32_FORMAT" src/ | wc
>        71     517    7841
>
> $ grep -r "%d\|%u" src/share/vm/memory/ src/share/vm/gc_implementation/ | wc
>       426    3274   55241
>
> $ grep -r "INT32_FORMAT" src/share/vm/memory/ src/share/vm/gc_implementation/ | wc
>        20     151    2603

You don't seem to distinguish between code that uses native "int" and "unsigned int" types (loop counters in tracing code, generation numbers, region indexes, etc.) versus types that are the result of VM configuration (sizes, offsets, field offsets, or calculations we need to fit in 32 bits, etc.).

You don't seem to distinguish between debugging code that might have been thrown together without much thought versus logging code that we want to be consistent across platforms.

The other use of the *_FORMAT macros is for printing pointers, sizes, offsets, intx and uintx, jlong, etc.  It would be nice to be able to use *_FORMAT macros consistently, which is another argument for the whole family of them.

I agree that the types are not always used consistently in the HotSpot code.  But I'd rather we added information to the system rather than removing it.

I'm not a JDK-9 reviewer, so this is not a review.

			... peter

> thanks,
> StefanK
>
>>
>> Thanks,
>> Vladimir
>>
>> On 4/4/14 12:59 AM, Stefan Karlsson wrote:
>>> Please, review this patch to the GC code to change usages of UINT32_FORMAT and INT32_FORMAT to %u and %d when uints and
>>> ints are used.
>>>
>>> While doing this change I found, and changed, a couple of places where we used UINT32_FORMAT to print variables that
>>> were less than 4 bytes.
>>>
>>> webrev: http://cr.openjdk.java.net/~stefank/8039244/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8039244
>>>
>>> thanks,
>>> StefanK
>


From stefan.karlsson at oracle.com  Sat Apr  5 06:41:44 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Sat, 05 Apr 2014 08:41:44 +0200
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when
	printing uints and ints in the GC code
In-Reply-To: <533F2B01.30500@Oracle.COM>
References: <533E6671.9050803@oracle.com> <533ED6A7.2020403@oracle.com>
	<533F0303.1000501@oracle.com> <533F2B01.30500@Oracle.COM>
Message-ID: <533FA5A8.6080503@oracle.com>

On 2014-04-04 23:58, Peter B. Kessler wrote:
> On 04/04/14 12:07, Stefan Karlsson wrote:
>> Vladimir,
>>
>> On 2014-04-04 17:58, Vladimir Kozlov wrote:
>>> Stefan,
>>>
>>> Could you explain more why you do this? Bug report does not explain 
>>> why you need this.
>>> The main reason we use *_FORMAT macros is because different 
>>> platforms behave differently when we use normal format's specifiers.
>>
>> First, *INT32_FORMAT isn't technically correct for printing ints. 
>> Though I agree that it probably works for most (all?) platforms 
>> HotSpot is run on.
>
> If INT32_FORMAT and UINT32_FORMAT are not technically correct, then 
> fix them.  That's a separate issue.  As Vladimir says, the whole point 
> of those macros is to localize the changes needed to run on platforms 
> where the native %d and %u don't work the way we expect them to.

INT32_FORMAT should be used for int that are exactly 32 bits, e.g. 
jints. If we really want to use *_FORMAT to print ints, we should 
introduce a INT_FORMAT. But _that_ is a separate issue.

>
>> Second, and probably more important, we usually use %u and %d to 
>> print ints, not UINT32_FORMAT and INT32_FORMAT. By changing these few 
>> occurrences in the GC code our print code gets more uniform.
>>
>> This is what you get if you grep after these format specifiers:
>>
>> $ grep -r "%d\|%u" src/ | wc
>>      3209   24297  353527
>>
>> $ grep -r "INT32_FORMAT" src/ | wc
>>        71     517    7841
>>
>> $ grep -r "%d\|%u" src/share/vm/memory/ 
>> src/share/vm/gc_implementation/ | wc
>>       426    3274   55241
>>
>> $ grep -r "INT32_FORMAT" src/share/vm/memory/ 
>> src/share/vm/gc_implementation/ | wc
>>        20     151    2603
>
> You don't seem to distinguish between code that uses native "int" and 
> "unsigned int" types (loop counters in tracing code, generation 
> numbers, region indexes, etc.) versus types that are the result of VM 
> configuration (sizes, offsets, field offsets, or calculations we need 
> to fit in 32 bits, etc.).
>
> You don't seem to distinguish between debugging code that might have 
> been thrown together without much thought versus logging code that we 
> want to be consistent across platforms.

I just wanted to make a point that we really don't use UINT32_FORMAT and 
INT32_FORMAT to print 'unsigned int' and 'int'. There are extremely few 
instances that does, and they should have followed the style we already 
have in place to print ints.

Just take a look at one of the few gclog_or_tty->print_cr changes I did:

http://cr.openjdk.java.net/~stefank/8039244/webrev.02/src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp.frames.html

   432   if (G1TraceHeapRegionRememberedSet) {
  433     gclog_or_tty->print_cr("Table for [" PTR_FORMAT "...): card %d 
(cache = %d)",
  434                   hr()->bottom(), from_card,
  435                   FromCardCache::at((uint)tid, cur_hrs_ind));
  436   }

we already use %d in that method to print:

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

>
> The other use of the *_FORMAT macros is for printing pointers, sizes, 
> offsets, intx and uintx, jlong, etc.  It would be nice to be able to 
> use *_FORMAT macros consistently, which is another argument for the 
> whole family of them.

I don't argue against using them. I wouldn't go and use %p to print 
pointers, for example.

>
> I agree that the types are not always used consistently in the HotSpot 
> code.  But I'd rather we added information to the system rather than 
> removing it.

I want us to be consistent with our format specifier for the GC code 
(and hopefully for the entire HotSpot code base in the future).

Please start a new discussion if you want to setup a policy that HotSpot 
should use INT_FORMAT and UINT_FORMAT instead of %d and %u

StefanK

>
> I'm not a JDK-9 reviewer, so this is not a review.
>
>             ... peter
>
>> thanks,
>> StefanK
>>
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 4/4/14 12:59 AM, Stefan Karlsson wrote:
>>>> Please, review this patch to the GC code to change usages of 
>>>> UINT32_FORMAT and INT32_FORMAT to %u and %d when uints and
>>>> ints are used.
>>>>
>>>> While doing this change I found, and changed, a couple of places 
>>>> where we used UINT32_FORMAT to print variables that
>>>> were less than 4 bytes.
>>>>
>>>> webrev: http://cr.openjdk.java.net/~stefank/8039244/webrev.00/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8039244
>>>>
>>>> thanks,
>>>> StefanK
>>

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

From stefan.karlsson at oracle.com  Tue Apr  8 08:15:35 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 08 Apr 2014 10:15:35 +0200
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when
	printing uints and ints in the GC code
In-Reply-To: <533E6671.9050803@oracle.com>
References: <533E6671.9050803@oracle.com>
Message-ID: <5343B027.5030902@oracle.com>


On 2014-04-04 09:59, Stefan Karlsson wrote:
> Please, review this patch to the GC code to change usages of 
> UINT32_FORMAT and INT32_FORMAT to %u and %d when uints and ints are used.
>
> While doing this change I found, and changed, a couple of places where 
> we used UINT32_FORMAT to print variables that were less than 4 bytes.

This change is not strictly needed, since varargs methods will widen the 
types of the arguments. Thanks David Holmes for pointing this out.

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

I'm going to push the webrev.02 version now. I haven't heard back from 
all that commented on this thread, so if someone feels that this needs 
to be discussed more we can start a new discussion or open a new RFE.

thanks,
StefanK

>
> thanks,
> StefanK



From per.liden at oracle.com  Tue Apr  8 09:27:39 2014
From: per.liden at oracle.com (Per Liden)
Date: Tue, 08 Apr 2014 11:27:39 +0200
Subject: RFR(s): 8037112: gc/g1/TestHumongousAllocInitialMark.java caused
	SIGSEGV
In-Reply-To: <1F09BCB8-DE4D-4B97-AB63-06104BC6F0BD@oracle.com>
References: <533D42C0.8060306@oracle.com> <3971356.DreSMqAOW1@mgerdin03>
	<533EA204.3090607@oracle.com> <4063857.h91XTfINnv@mgerdin03>
	<1F09BCB8-DE4D-4B97-AB63-06104BC6F0BD@oracle.com>
Message-ID: <5343C10B.7060906@oracle.com>

Hi,

Here's an updated webrev which fixes the potential dead lock issue I 
found. I've taken a whole new approach to this problem. Instead of 
joining/leaving the STS as protection from shutdown I've added a 
CollectedHeap::stop() which is called in the shutdown paths (in 
before_exit()) to stop and take down the concurrent threads in a 
controlled manner. This feel like a much cleaner approach and less error 
prone as it doesn't require any future log printouts to be guarded by 
join/leave.

Webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.2/

cheers,
/Per

On 04/04/2014 06:14 PM, Per Liden wrote:
> Hmm, I discovered a potential dead lock with this approach, so please hold reviews on this for now.
>
> Sorry!
> /Per
>
> On 04 Apr 2014, at 14:28, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
>
>> Per,
>>
>> On Friday 04 April 2014 14.13.56 Per Liden wrote:
>>> Thanks Mikael!
>>>
>>> Updated webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.1/
>>
>> Looks good.
>> /Mikael
>>
>>>
>>> /Per
>>>
>>> On 04/03/2014 03:59 PM, Mikael Gerdin wrote:
>>>> Hi Per,
>>>>
>>>> On Thursday 03 April 2014 13.15.12 Per Liden wrote:
>>>>> Hi,
>>>>>
>>>>> Could I please have this bugfix reviewed.
>>>>>
>>>>> Summary: G1's ConcurrentMarkThread tries to use the gclog_or_tty when
>>>>> the JVM is about to exit and the gclog_or_tty instance has been
>>>>> destroyed. To prevent this, the ConcurrentMarkThread needs to join the
>>>>> SuspendibleThreadSet before accessing gclog_or_tty.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8037112
>>>>> Webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.0/
>>>>
>>>> While I realize that this code is still semantically correct I think it
>>>> reads a bit strange. In my mind if we have a
>>>> if (...) {} else if (...) {} else {} block the checks in the "if" and
>>>> "else
>>>> if" should usually somehow related checks.
>>>>
>>>>   282       if (!cm()->has_aborted()) {
>>>>   283         g1_policy->record_concurrent_mark_cleanup_completed();
>>>>   284       } else if (G1Log::fine()) {
>>>>   285         gclog_or_tty->date_stamp(PrintGCDateStamps);
>>>>   286         gclog_or_tty->stamp(PrintGCTimeStamps);
>>>>   287         gclog_or_tty->print_cr("[GC concurrent-mark-abort]");
>>>>   288       }
>>>>
>>>> I would prefer if it was structured the other way around:
>>>> if (cm()->has_aborted()) {
>>>>
>>>> 	if (G1Log::fine()) { ... }
>>>>
>>>> else {
>>>>
>>>> 	g1_policy->record_concurrent_mark_cleanup_completed();
>>>>
>>>> }
>>>>
>>>> The rest of the change looks good.
>>>>
>>>> /Mikael
>>>>
>>>>> Thanks!
>>>>> /Per
>>>>>
>>>>> Btw, I created a separate RFE, JDK-8039147, to do a little bit of
>>>>> cleanup of the SuspendibleThreadSet and how it's used. Will send that
>>>>> out as separate review request shortly.
>>
>



From per.liden at oracle.com  Tue Apr  8 11:32:23 2014
From: per.liden at oracle.com (Per Liden)
Date: Tue, 08 Apr 2014 13:32:23 +0200
Subject: RFR(M): 8039147: Cleanup SuspendibleThreadSet
Message-ID: <5343DE47.3080708@oracle.com>

Hi,

Here's a attempt to cleanup SuspendibleThreadSet that I'd like to get 
some reviews on.

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

Summary:

* The function of SuspendibleThreadSet is completely unchanged. Still 
does the same thing, same semantics, same users, etc.

* SuspendibleThreadSet is broken out from concurrentGCThread.hpp/cpp 
into separate files. The relation ship with ConcurrentGCThread is a bit 
artificial as SuspendibleThreadSet is used by other threads as well e.g. 
SharedHeap's FlexibleWorkGang.

* There's currently two ways of using SuspendibleThreadSet, depending on 
which context you're in; 1) through direct use of the static _sts member 
in ConcurrentGCThread and 2) via the static stsXXXX() functions exposed 
by ConcurrentGCThread. With this patch there's only one interface, which 
is exposed as static functions on the SuspendibleThreadSet class itself.

* I adjusted the names of some of the fields in SuspendibleThreadSet, 
which didn't quite make sense to me. For example, _async is now 
_nthreads since it's a counter of number of threads currently in the 
thread set.

* The should_yield() and yield() functions on ConcurrentGCThread (and 
it's subclasses) where removed, since they were never used. There was 
one exception here though, which was concurrentMarkThread::yield(), but 
it just does a direct call to SuspendibleThreadSet's yield() so that's 
just an useless indirection.

* SuspendibleThreadSetJoiner is introduced to replace code like this:

if (....) {
    _sts.join();
    <do something>
    _sts.leave();
}

with code like this:

if (....) {
    SuspendibleThreadSetJoiner sts;
    <do something>
}

cheers,
/Per


From staffan.larsen at oracle.com  Tue Apr  8 12:07:18 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 8 Apr 2014 14:07:18 +0200
Subject: RFR: 8038947 HotSpotDiagnosticMXBean/CheckOrigin.java 'NewSize'
	should have origin 'ERGONOMIC' but had 'DEFAULT'
Message-ID: <6B180B1F-9799-48B3-8B18-CCBE7F32FF6B@oracle.com>

This test verifies the origins of a couple of flags. One origin type is ERGONOMIC. The test used NewSize as an example flag that was set ergonomically by the JVM. It turns out that flag is not always set ergonomically. 

This change switches to use UseParNewGC as the ergonomic flag. This flag is set whenever UseConcMarkSweepGC is used.

webrev: http://cr.openjdk.java.net/~sla/8038947/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8038947

Thanks,
/Staffan

From vladimir.kozlov at oracle.com  Tue Apr  8 16:42:13 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 08 Apr 2014 09:42:13 -0700
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when
	printing uints and ints in the GC code
In-Reply-To: <5343B027.5030902@oracle.com>
References: <533E6671.9050803@oracle.com> <5343B027.5030902@oracle.com>
Message-ID: <534426E5.9010703@oracle.com>

So *_FORMAT are not broken (when used correctly). It is GC group's decision to use %d and %u in GC code. Right?
It is bad that different components of JVM will be inconsistent in this but it is your decision.

Thanks,
Vladimir

On 4/8/14 1:15 AM, Stefan Karlsson wrote:
>
> On 2014-04-04 09:59, Stefan Karlsson wrote:
>> Please, review this patch to the GC code to change usages of UINT32_FORMAT and INT32_FORMAT to %u and %d when uints
>> and ints are used.
>>
>> While doing this change I found, and changed, a couple of places where we used UINT32_FORMAT to print variables that
>> were less than 4 bytes.
>
> This change is not strictly needed, since varargs methods will widen the types of the arguments. Thanks David Holmes for
> pointing this out.
>
>>
>> webrev: http://cr.openjdk.java.net/~stefank/8039244/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8039244
>
> I'm going to push the webrev.02 version now. I haven't heard back from all that commented on this thread, so if someone
> feels that this needs to be discussed more we can start a new discussion or open a new RFE.
>
> thanks,
> StefanK
>
>>
>> thanks,
>> StefanK
>


From stefan.karlsson at oracle.com  Tue Apr  8 17:43:24 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 08 Apr 2014 19:43:24 +0200
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when
	printing uints and ints in the GC code
In-Reply-To: <534426E5.9010703@oracle.com>
References: <533E6671.9050803@oracle.com> <5343B027.5030902@oracle.com>
	<534426E5.9010703@oracle.com>
Message-ID: <5344353C.9000708@oracle.com>

On 2014-04-08 18:42, Vladimir Kozlov wrote:
> So *_FORMAT are not broken (when used correctly). 
> It is GC group's decision to use %d and %u in GC code. Right?
> It is bad that different components of JVM will be inconsistent in 
> this but it is your decision.
Just take a look at the compiler code. There are only ten usages of 
*INT32_FORMAT:

src//share/vm/code/codeCache.cpp:    st->print_cr(" total_blobs=" 
UINT32_FORMAT " nmethods=" UINT32_FORMAT
src//share/vm/code/codeCache.cpp:                 " adapters=" 
UINT32_FORMAT,
src//share/vm/code/codeCache.cpp:  st->print(" total_blobs='" 
UINT32_FORMAT "' nmethods='" UINT32_FORMAT "'"
src//share/vm/code/codeCache.cpp:            " adapters='" UINT32_FORMAT 
"' free_code_cache='" SIZE_FORMAT "'",

src//share/vm/code/nmethod.cpp:    tty->print_cr("*flushing nmethod 
%3d/" INTPTR_FORMAT ". Live blobs:" UINT32_FORMAT "/Free CodeCache:" 
SIZE_FORMAT "Kb",

src//share/vm/opto/callnode.cpp:    st->print(" %s%d]=#ScObj" 
INT32_FORMAT, msg, i, sco_n);
src//share/vm/opto/callnode.cpp:      st->print(" 
%s%d]=#"INT32_FORMAT,msg,i,t->is_int()->get_con());
src//share/vm/opto/callnode.cpp:      st->print("        # ScObj" 
INT32_FORMAT " ", i);

src//share/vm/runtime/deoptimization.cpp: tty->print_cr("  %40s: " 
UINT32_FORMAT " (%.1f%%)", name, r, (r * 100.0) / total);

and there is about 600 lines in the compiler code that use %d. To me 
these ten lines are what's inconsistent, not that the GC team has 
removed its few usages of *INT32_FORMAT.


For reference, these are _all_ usages of INT32_FORMAT and UINT32_FORMAT 
in the HotSpot code base.

$ grep -r "INT32_FORMAT" src/
src//os_cpu/bsd_zero/vm/os_bsd_zero.cpp:      "caught unhandled signal " 
INT32_FORMAT " at address " PTR_FORMAT;
src//os_cpu/bsd_zero/vm/os_bsd_zero.cpp: 
fatal(err_msg("pthread_stackseg_np failed with err = " INT32_FORMAT,
src//os_cpu/bsd_zero/vm/os_bsd_zero.cpp: 
fatal(err_msg("pthread_attr_init failed with err = " INT32_FORMAT, rslt));
src//os_cpu/bsd_zero/vm/os_bsd_zero.cpp: 
fatal(err_msg("pthread_attr_get_np failed with err = " INT32_FORMAT,
src//share/vm/code/codeCache.cpp:    st->print_cr(" total_blobs=" 
UINT32_FORMAT " nmethods=" UINT32_FORMAT
src//share/vm/code/codeCache.cpp:                 " adapters=" 
UINT32_FORMAT,
src//share/vm/code/codeCache.cpp:  st->print(" total_blobs='" 
UINT32_FORMAT "' nmethods='" UINT32_FORMAT "'"
src//share/vm/code/codeCache.cpp:            " adapters='" UINT32_FORMAT 
"' free_code_cache='" SIZE_FORMAT "'",
src//share/vm/code/nmethod.cpp:    tty->print_cr("*flushing nmethod 
%3d/" INTPTR_FORMAT ". Live blobs:" UINT32_FORMAT "/Free CodeCache:" 
SIZE_FORMAT "Kb",
src//share/vm/interpreter/bytecodeTracer.cpp:    st->print_cr(" " 
INT32_FORMAT, constants->int_at(i));
src//share/vm/interpreter/bytecodeTracer.cpp:      st->print_cr(" " 
INT32_FORMAT, get_byte());
src//share/vm/interpreter/bytecodeTracer.cpp:      st->print_cr(" " 
INT32_FORMAT, get_short());
src//share/vm/interpreter/bytecodeTracer.cpp: st->print_cr(" #%d " 
INT32_FORMAT, index, offset);
src//share/vm/interpreter/bytecodeTracer.cpp:        st->print(" %d " 
INT32_FORMAT " " INT32_FORMAT " ",
src//share/vm/interpreter/bytecodeTracer.cpp:          const char 
*format = first ? " %d:" INT32_FORMAT " (delta: %d)" :
src//share/vm/interpreter/bytecodeTracer.cpp: ", %d:" INT32_FORMAT " 
(delta: %d)";
src//share/vm/interpreter/bytecodeTracer.cpp:          const char 
*format = first ? " " INT32_FORMAT ":" INT32_FORMAT :
src//share/vm/interpreter/bytecodeTracer.cpp: ", " INT32_FORMAT ":" 
INT32_FORMAT ;
src//share/vm/opto/callnode.cpp:    st->print(" %s%d]=#ScObj" 
INT32_FORMAT, msg, i, sco_n);
src//share/vm/opto/callnode.cpp:      st->print(" 
%s%d]=#"INT32_FORMAT,msg,i,t->is_int()->get_con());
src//share/vm/opto/callnode.cpp:      st->print("        # ScObj" 
INT32_FORMAT " ", i);
src//share/vm/opto/type.cpp:    sprintf(buf, "min+" INT32_FORMAT, n - 
min_jint);
src//share/vm/opto/type.cpp:    sprintf(buf, "max-" INT32_FORMAT, 
max_jint - n);
src//share/vm/opto/type.cpp:    sprintf(buf, INT32_FORMAT, n);
src//share/vm/runtime/arguments.cpp:  jio_snprintf(buffer, bufsz, "1." 
UINT32_FORMAT, spec_version);
src//share/vm/runtime/deoptimization.cpp: tty->print_cr("  %40s: " 
UINT32_FORMAT " (%.1f%%)", name, r, (r * 100.0) / total);
src//share/vm/runtime/perfData.cpp:              " length = " 
INT32_FORMAT ","
src//share/vm/runtime/perfData.cpp:              " 
PerfMaxStringConstLength = " INT32_FORMAT "\n",
src//share/vm/runtime/perfData.cpp:   jio_snprintf(intbuf, 40, 
UINT32_FORMAT, instance);
src//share/vm/runtime/perfData.cpp:   jio_snprintf(intbuf, 40, 
UINT32_FORMAT, instance);
src//share/vm/runtime/perfMemory.cpp:              "  Overflow = " 
INT32_FORMAT " bytes"
src//share/vm/runtime/safepoint.cpp: 
INT32_FORMAT_W(8)INT32_FORMAT_W(11)INT32_FORMAT_W(15)
src//share/vm/runtime/safepoint.cpp: tty->print(INT32_FORMAT"         ", 
sstats->_page_armed);
src//share/vm/runtime/safepoint.cpp: tty->print_cr(INT32_FORMAT"   ", 
sstats->_nof_threads_hit_page_trap);
src//share/vm/trace/traceStream.hpp:    _st.print("%s = "UINT32_FORMAT, 
label, val);
src//share/vm/trace/traceStream.hpp:    _st.print("%s = "UINT32_FORMAT, 
label, val);
src//share/vm/trace/traceStream.hpp:    _st.print("%s = "INT32_FORMAT, 
label, val);
src//share/vm/trace/traceStream.hpp:    _st.print("%s = "UINT32_FORMAT, 
label, val);
src//share/vm/trace/traceStream.hpp:    _st.print("%s = "INT32_FORMAT, 
label, val);


I don't understand why you insist that I'm making things more inconsistent.


StefanK

>
> Thanks,
> Vladimir
>
> On 4/8/14 1:15 AM, Stefan Karlsson wrote:
>>
>> On 2014-04-04 09:59, Stefan Karlsson wrote:
>>> Please, review this patch to the GC code to change usages of 
>>> UINT32_FORMAT and INT32_FORMAT to %u and %d when uints
>>> and ints are used.
>>>
>>> While doing this change I found, and changed, a couple of places 
>>> where we used UINT32_FORMAT to print variables that
>>> were less than 4 bytes.
>>
>> This change is not strictly needed, since varargs methods will widen 
>> the types of the arguments. Thanks David Holmes for
>> pointing this out.
>>
>>>
>>> webrev: http://cr.openjdk.java.net/~stefank/8039244/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8039244
>>
>> I'm going to push the webrev.02 version now. I haven't heard back 
>> from all that commented on this thread, so if someone
>> feels that this needs to be discussed more we can start a new 
>> discussion or open a new RFE.
>>
>> thanks,
>> StefanK
>>
>>>
>>> thanks,
>>> StefanK
>>



From vladimir.kozlov at oracle.com  Tue Apr  8 22:16:21 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 08 Apr 2014 15:16:21 -0700
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when
	printing uints and ints in the GC code
In-Reply-To: <5344353C.9000708@oracle.com>
References: <533E6671.9050803@oracle.com> <5343B027.5030902@oracle.com>
	<534426E5.9010703@oracle.com> <5344353C.9000708@oracle.com>
Message-ID: <53447535.8070305@oracle.com>

Sorry, I had impression that we mostly use *INT32_FORMAT formats.
You are right and I am fine with your changes.

Thanks,
Vladimir

On 4/8/14 10:43 AM, Stefan Karlsson wrote:
> On 2014-04-08 18:42, Vladimir Kozlov wrote:
>> So *_FORMAT are not broken (when used correctly). It is GC group's
>> decision to use %d and %u in GC code. Right?
>> It is bad that different components of JVM will be inconsistent in
>> this but it is your decision.
> Just take a look at the compiler code. There are only ten usages of
> *INT32_FORMAT:
>
> src//share/vm/code/codeCache.cpp:    st->print_cr(" total_blobs="
> UINT32_FORMAT " nmethods=" UINT32_FORMAT
> src//share/vm/code/codeCache.cpp:                 " adapters="
> UINT32_FORMAT,
> src//share/vm/code/codeCache.cpp:  st->print(" total_blobs='"
> UINT32_FORMAT "' nmethods='" UINT32_FORMAT "'"
> src//share/vm/code/codeCache.cpp:            " adapters='" UINT32_FORMAT
> "' free_code_cache='" SIZE_FORMAT "'",
>
> src//share/vm/code/nmethod.cpp:    tty->print_cr("*flushing nmethod
> %3d/" INTPTR_FORMAT ". Live blobs:" UINT32_FORMAT "/Free CodeCache:"
> SIZE_FORMAT "Kb",
>
> src//share/vm/opto/callnode.cpp:    st->print(" %s%d]=#ScObj"
> INT32_FORMAT, msg, i, sco_n);
> src//share/vm/opto/callnode.cpp:      st->print("
> %s%d]=#"INT32_FORMAT,msg,i,t->is_int()->get_con());
> src//share/vm/opto/callnode.cpp:      st->print("        # ScObj"
> INT32_FORMAT " ", i);
>
> src//share/vm/runtime/deoptimization.cpp: tty->print_cr("  %40s: "
> UINT32_FORMAT " (%.1f%%)", name, r, (r * 100.0) / total);
>
> and there is about 600 lines in the compiler code that use %d. To me
> these ten lines are what's inconsistent, not that the GC team has
> removed its few usages of *INT32_FORMAT.
>
>
> For reference, these are _all_ usages of INT32_FORMAT and UINT32_FORMAT
> in the HotSpot code base.
>
> $ grep -r "INT32_FORMAT" src/
> src//os_cpu/bsd_zero/vm/os_bsd_zero.cpp:      "caught unhandled signal "
> INT32_FORMAT " at address " PTR_FORMAT;
> src//os_cpu/bsd_zero/vm/os_bsd_zero.cpp:
> fatal(err_msg("pthread_stackseg_np failed with err = " INT32_FORMAT,
> src//os_cpu/bsd_zero/vm/os_bsd_zero.cpp:
> fatal(err_msg("pthread_attr_init failed with err = " INT32_FORMAT, rslt));
> src//os_cpu/bsd_zero/vm/os_bsd_zero.cpp:
> fatal(err_msg("pthread_attr_get_np failed with err = " INT32_FORMAT,
> src//share/vm/code/codeCache.cpp:    st->print_cr(" total_blobs="
> UINT32_FORMAT " nmethods=" UINT32_FORMAT
> src//share/vm/code/codeCache.cpp:                 " adapters="
> UINT32_FORMAT,
> src//share/vm/code/codeCache.cpp:  st->print(" total_blobs='"
> UINT32_FORMAT "' nmethods='" UINT32_FORMAT "'"
> src//share/vm/code/codeCache.cpp:            " adapters='" UINT32_FORMAT
> "' free_code_cache='" SIZE_FORMAT "'",
> src//share/vm/code/nmethod.cpp:    tty->print_cr("*flushing nmethod
> %3d/" INTPTR_FORMAT ". Live blobs:" UINT32_FORMAT "/Free CodeCache:"
> SIZE_FORMAT "Kb",
> src//share/vm/interpreter/bytecodeTracer.cpp:    st->print_cr(" "
> INT32_FORMAT, constants->int_at(i));
> src//share/vm/interpreter/bytecodeTracer.cpp:      st->print_cr(" "
> INT32_FORMAT, get_byte());
> src//share/vm/interpreter/bytecodeTracer.cpp:      st->print_cr(" "
> INT32_FORMAT, get_short());
> src//share/vm/interpreter/bytecodeTracer.cpp: st->print_cr(" #%d "
> INT32_FORMAT, index, offset);
> src//share/vm/interpreter/bytecodeTracer.cpp:        st->print(" %d "
> INT32_FORMAT " " INT32_FORMAT " ",
> src//share/vm/interpreter/bytecodeTracer.cpp:          const char
> *format = first ? " %d:" INT32_FORMAT " (delta: %d)" :
> src//share/vm/interpreter/bytecodeTracer.cpp: ", %d:" INT32_FORMAT "
> (delta: %d)";
> src//share/vm/interpreter/bytecodeTracer.cpp:          const char
> *format = first ? " " INT32_FORMAT ":" INT32_FORMAT :
> src//share/vm/interpreter/bytecodeTracer.cpp: ", " INT32_FORMAT ":"
> INT32_FORMAT ;
> src//share/vm/opto/callnode.cpp:    st->print(" %s%d]=#ScObj"
> INT32_FORMAT, msg, i, sco_n);
> src//share/vm/opto/callnode.cpp:      st->print("
> %s%d]=#"INT32_FORMAT,msg,i,t->is_int()->get_con());
> src//share/vm/opto/callnode.cpp:      st->print("        # ScObj"
> INT32_FORMAT " ", i);
> src//share/vm/opto/type.cpp:    sprintf(buf, "min+" INT32_FORMAT, n -
> min_jint);
> src//share/vm/opto/type.cpp:    sprintf(buf, "max-" INT32_FORMAT,
> max_jint - n);
> src//share/vm/opto/type.cpp:    sprintf(buf, INT32_FORMAT, n);
> src//share/vm/runtime/arguments.cpp:  jio_snprintf(buffer, bufsz, "1."
> UINT32_FORMAT, spec_version);
> src//share/vm/runtime/deoptimization.cpp: tty->print_cr("  %40s: "
> UINT32_FORMAT " (%.1f%%)", name, r, (r * 100.0) / total);
> src//share/vm/runtime/perfData.cpp:              " length = "
> INT32_FORMAT ","
> src//share/vm/runtime/perfData.cpp:              "
> PerfMaxStringConstLength = " INT32_FORMAT "\n",
> src//share/vm/runtime/perfData.cpp:   jio_snprintf(intbuf, 40,
> UINT32_FORMAT, instance);
> src//share/vm/runtime/perfData.cpp:   jio_snprintf(intbuf, 40,
> UINT32_FORMAT, instance);
> src//share/vm/runtime/perfMemory.cpp:              "  Overflow = "
> INT32_FORMAT " bytes"
> src//share/vm/runtime/safepoint.cpp:
> INT32_FORMAT_W(8)INT32_FORMAT_W(11)INT32_FORMAT_W(15)
> src//share/vm/runtime/safepoint.cpp: tty->print(INT32_FORMAT"         ",
> sstats->_page_armed);
> src//share/vm/runtime/safepoint.cpp: tty->print_cr(INT32_FORMAT"   ",
> sstats->_nof_threads_hit_page_trap);
> src//share/vm/trace/traceStream.hpp:    _st.print("%s = "UINT32_FORMAT,
> label, val);
> src//share/vm/trace/traceStream.hpp:    _st.print("%s = "UINT32_FORMAT,
> label, val);
> src//share/vm/trace/traceStream.hpp:    _st.print("%s = "INT32_FORMAT,
> label, val);
> src//share/vm/trace/traceStream.hpp:    _st.print("%s = "UINT32_FORMAT,
> label, val);
> src//share/vm/trace/traceStream.hpp:    _st.print("%s = "INT32_FORMAT,
> label, val);
>
>
> I don't understand why you insist that I'm making things more inconsistent.
>
>
> StefanK
>
>>
>> Thanks,
>> Vladimir
>>
>> On 4/8/14 1:15 AM, Stefan Karlsson wrote:
>>>
>>> On 2014-04-04 09:59, Stefan Karlsson wrote:
>>>> Please, review this patch to the GC code to change usages of
>>>> UINT32_FORMAT and INT32_FORMAT to %u and %d when uints
>>>> and ints are used.
>>>>
>>>> While doing this change I found, and changed, a couple of places
>>>> where we used UINT32_FORMAT to print variables that
>>>> were less than 4 bytes.
>>>
>>> This change is not strictly needed, since varargs methods will widen
>>> the types of the arguments. Thanks David Holmes for
>>> pointing this out.
>>>
>>>>
>>>> webrev: http://cr.openjdk.java.net/~stefank/8039244/webrev.00/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8039244
>>>
>>> I'm going to push the webrev.02 version now. I haven't heard back
>>> from all that commented on this thread, so if someone
>>> feels that this needs to be discussed more we can start a new
>>> discussion or open a new RFE.
>>>
>>> thanks,
>>> StefanK
>>>
>>>>
>>>> thanks,
>>>> StefanK
>>>
>


From stefan.karlsson at oracle.com  Tue Apr  8 22:42:52 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 09 Apr 2014 00:42:52 +0200
Subject: RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when
	printing uints and ints in the GC code
In-Reply-To: <53447535.8070305@oracle.com>
References: <533E6671.9050803@oracle.com> <5343B027.5030902@oracle.com>
	<534426E5.9010703@oracle.com> <5344353C.9000708@oracle.com>
	<53447535.8070305@oracle.com>
Message-ID: <53447B6C.9000005@oracle.com>

On 2014-04-09 00:16, Vladimir Kozlov wrote:
> Sorry, I had impression that we mostly use *INT32_FORMAT formats.
> You are right and I am fine with your changes.

Thanks, Vladimir.

StefanK

>
> Thanks,
> Vladimir
>
> On 4/8/14 10:43 AM, Stefan Karlsson wrote:
>> On 2014-04-08 18:42, Vladimir Kozlov wrote:
>>> So *_FORMAT are not broken (when used correctly). It is GC group's
>>> decision to use %d and %u in GC code. Right?
>>> It is bad that different components of JVM will be inconsistent in
>>> this but it is your decision.
>> Just take a look at the compiler code. There are only ten usages of
>> *INT32_FORMAT:
>>
>> src//share/vm/code/codeCache.cpp:    st->print_cr(" total_blobs="
>> UINT32_FORMAT " nmethods=" UINT32_FORMAT
>> src//share/vm/code/codeCache.cpp:                 " adapters="
>> UINT32_FORMAT,
>> src//share/vm/code/codeCache.cpp:  st->print(" total_blobs='"
>> UINT32_FORMAT "' nmethods='" UINT32_FORMAT "'"
>> src//share/vm/code/codeCache.cpp:            " adapters='" UINT32_FORMAT
>> "' free_code_cache='" SIZE_FORMAT "'",
>>
>> src//share/vm/code/nmethod.cpp:    tty->print_cr("*flushing nmethod
>> %3d/" INTPTR_FORMAT ". Live blobs:" UINT32_FORMAT "/Free CodeCache:"
>> SIZE_FORMAT "Kb",
>>
>> src//share/vm/opto/callnode.cpp:    st->print(" %s%d]=#ScObj"
>> INT32_FORMAT, msg, i, sco_n);
>> src//share/vm/opto/callnode.cpp:      st->print("
>> %s%d]=#"INT32_FORMAT,msg,i,t->is_int()->get_con());
>> src//share/vm/opto/callnode.cpp:      st->print("        # ScObj"
>> INT32_FORMAT " ", i);
>>
>> src//share/vm/runtime/deoptimization.cpp: tty->print_cr(" %40s: "
>> UINT32_FORMAT " (%.1f%%)", name, r, (r * 100.0) / total);
>>
>> and there is about 600 lines in the compiler code that use %d. To me
>> these ten lines are what's inconsistent, not that the GC team has
>> removed its few usages of *INT32_FORMAT.
>>
>>
>> For reference, these are _all_ usages of INT32_FORMAT and UINT32_FORMAT
>> in the HotSpot code base.
>>
>> $ grep -r "INT32_FORMAT" src/
>> src//os_cpu/bsd_zero/vm/os_bsd_zero.cpp:      "caught unhandled signal "
>> INT32_FORMAT " at address " PTR_FORMAT;
>> src//os_cpu/bsd_zero/vm/os_bsd_zero.cpp:
>> fatal(err_msg("pthread_stackseg_np failed with err = " INT32_FORMAT,
>> src//os_cpu/bsd_zero/vm/os_bsd_zero.cpp:
>> fatal(err_msg("pthread_attr_init failed with err = " INT32_FORMAT, 
>> rslt));
>> src//os_cpu/bsd_zero/vm/os_bsd_zero.cpp:
>> fatal(err_msg("pthread_attr_get_np failed with err = " INT32_FORMAT,
>> src//share/vm/code/codeCache.cpp:    st->print_cr(" total_blobs="
>> UINT32_FORMAT " nmethods=" UINT32_FORMAT
>> src//share/vm/code/codeCache.cpp:                 " adapters="
>> UINT32_FORMAT,
>> src//share/vm/code/codeCache.cpp:  st->print(" total_blobs='"
>> UINT32_FORMAT "' nmethods='" UINT32_FORMAT "'"
>> src//share/vm/code/codeCache.cpp:            " adapters='" UINT32_FORMAT
>> "' free_code_cache='" SIZE_FORMAT "'",
>> src//share/vm/code/nmethod.cpp:    tty->print_cr("*flushing nmethod
>> %3d/" INTPTR_FORMAT ". Live blobs:" UINT32_FORMAT "/Free CodeCache:"
>> SIZE_FORMAT "Kb",
>> src//share/vm/interpreter/bytecodeTracer.cpp: st->print_cr(" "
>> INT32_FORMAT, constants->int_at(i));
>> src//share/vm/interpreter/bytecodeTracer.cpp: st->print_cr(" "
>> INT32_FORMAT, get_byte());
>> src//share/vm/interpreter/bytecodeTracer.cpp: st->print_cr(" "
>> INT32_FORMAT, get_short());
>> src//share/vm/interpreter/bytecodeTracer.cpp: st->print_cr(" #%d "
>> INT32_FORMAT, index, offset);
>> src//share/vm/interpreter/bytecodeTracer.cpp: st->print(" %d "
>> INT32_FORMAT " " INT32_FORMAT " ",
>> src//share/vm/interpreter/bytecodeTracer.cpp:          const char
>> *format = first ? " %d:" INT32_FORMAT " (delta: %d)" :
>> src//share/vm/interpreter/bytecodeTracer.cpp: ", %d:" INT32_FORMAT "
>> (delta: %d)";
>> src//share/vm/interpreter/bytecodeTracer.cpp:          const char
>> *format = first ? " " INT32_FORMAT ":" INT32_FORMAT :
>> src//share/vm/interpreter/bytecodeTracer.cpp: ", " INT32_FORMAT ":"
>> INT32_FORMAT ;
>> src//share/vm/opto/callnode.cpp:    st->print(" %s%d]=#ScObj"
>> INT32_FORMAT, msg, i, sco_n);
>> src//share/vm/opto/callnode.cpp:      st->print("
>> %s%d]=#"INT32_FORMAT,msg,i,t->is_int()->get_con());
>> src//share/vm/opto/callnode.cpp:      st->print("        # ScObj"
>> INT32_FORMAT " ", i);
>> src//share/vm/opto/type.cpp:    sprintf(buf, "min+" INT32_FORMAT, n -
>> min_jint);
>> src//share/vm/opto/type.cpp:    sprintf(buf, "max-" INT32_FORMAT,
>> max_jint - n);
>> src//share/vm/opto/type.cpp:    sprintf(buf, INT32_FORMAT, n);
>> src//share/vm/runtime/arguments.cpp:  jio_snprintf(buffer, bufsz, "1."
>> UINT32_FORMAT, spec_version);
>> src//share/vm/runtime/deoptimization.cpp: tty->print_cr(" %40s: "
>> UINT32_FORMAT " (%.1f%%)", name, r, (r * 100.0) / total);
>> src//share/vm/runtime/perfData.cpp:              " length = "
>> INT32_FORMAT ","
>> src//share/vm/runtime/perfData.cpp:              "
>> PerfMaxStringConstLength = " INT32_FORMAT "\n",
>> src//share/vm/runtime/perfData.cpp:   jio_snprintf(intbuf, 40,
>> UINT32_FORMAT, instance);
>> src//share/vm/runtime/perfData.cpp:   jio_snprintf(intbuf, 40,
>> UINT32_FORMAT, instance);
>> src//share/vm/runtime/perfMemory.cpp:              "  Overflow = "
>> INT32_FORMAT " bytes"
>> src//share/vm/runtime/safepoint.cpp:
>> INT32_FORMAT_W(8)INT32_FORMAT_W(11)INT32_FORMAT_W(15)
>> src//share/vm/runtime/safepoint.cpp: tty->print(INT32_FORMAT"         ",
>> sstats->_page_armed);
>> src//share/vm/runtime/safepoint.cpp: tty->print_cr(INT32_FORMAT"   ",
>> sstats->_nof_threads_hit_page_trap);
>> src//share/vm/trace/traceStream.hpp:    _st.print("%s = "UINT32_FORMAT,
>> label, val);
>> src//share/vm/trace/traceStream.hpp:    _st.print("%s = "UINT32_FORMAT,
>> label, val);
>> src//share/vm/trace/traceStream.hpp:    _st.print("%s = "INT32_FORMAT,
>> label, val);
>> src//share/vm/trace/traceStream.hpp:    _st.print("%s = "UINT32_FORMAT,
>> label, val);
>> src//share/vm/trace/traceStream.hpp:    _st.print("%s = "INT32_FORMAT,
>> label, val);
>>
>>
>> I don't understand why you insist that I'm making things more 
>> inconsistent.
>>
>>
>> StefanK
>>
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 4/8/14 1:15 AM, Stefan Karlsson wrote:
>>>>
>>>> On 2014-04-04 09:59, Stefan Karlsson wrote:
>>>>> Please, review this patch to the GC code to change usages of
>>>>> UINT32_FORMAT and INT32_FORMAT to %u and %d when uints
>>>>> and ints are used.
>>>>>
>>>>> While doing this change I found, and changed, a couple of places
>>>>> where we used UINT32_FORMAT to print variables that
>>>>> were less than 4 bytes.
>>>>
>>>> This change is not strictly needed, since varargs methods will widen
>>>> the types of the arguments. Thanks David Holmes for
>>>> pointing this out.
>>>>
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~stefank/8039244/webrev.00/
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8039244
>>>>
>>>> I'm going to push the webrev.02 version now. I haven't heard back
>>>> from all that commented on this thread, so if someone
>>>> feels that this needs to be discussed more we can start a new
>>>> discussion or open a new RFE.
>>>>
>>>> thanks,
>>>> StefanK
>>>>
>>>>>
>>>>> thanks,
>>>>> StefanK
>>>>
>>



From mikael.gerdin at oracle.com  Wed Apr  9 07:53:34 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 09 Apr 2014 09:53:34 +0200
Subject: RFR (S): 8038930: G1CodeRootSet::test fails with
	assert(_num_chunks_handed_out == 0) failed: No elements must
	have been handed out yet
In-Reply-To: <1396448631.3183.14.camel@cirrus>
References: <1396448631.3183.14.camel@cirrus>
Message-ID: <1946950.9cN2hhDCg1@mgerdin03>

Thomas,

On Wednesday 02 April 2014 16.23.51 Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews for the following fix for a test case?
> 
> This test case does some basic code validation on recently introduced
> code root memory management for G1 introduced recently (JDK-8035406).
> 
> It assumed that before running the test, no code root memory has been
> handed out.
> 
> The problem is now, when running with -Xcomp, before the internal VM
> tests (and this test) are run, it is likely that compiled code already
> did some code root allocations.
> 
> So the test needs to be aware of that, and not assume that the number of
> code root memory handed out is not zero.
> 
> This change fixes that assumption.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8038930
> 
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8038930/webrev/

Looks good.

/Mikael

> 
> Testing:
> jprt, manual invocation of test case with -Xcomp
> 
> Thanks,
>   Thomas



From thomas.schatzl at oracle.com  Wed Apr  9 10:02:45 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 09 Apr 2014 12:02:45 +0200
Subject: RFR (S): 8037344: Use the "next" field to iterate over fine
	remembered instead of using the hash table
In-Reply-To: <1394815316.2803.2.camel@cirrus>
References: <1394815316.2803.2.camel@cirrus>
Message-ID: <1397037765.2710.13.camel@cirrus>

Hi all,

  I have been notified that the webrev does not apply to the jdk9/hs-gc
repository any more.

Here is an updated version:
http://cr.openjdk.java.net/~tschatzl/8037344/webrev.1/

On Fri, 2014-03-14 at 17:41 +0100, Thomas Schatzl wrote:
> Hi all,
> 
>   could I have reviews for this small change that cleans up the
> HeapRegionRemSet-iterator?
> 
> The reason for this change is that in JDK-7182260 linked together all
> PerRegionTable data structure (representing parts of the fine remembered
> set) of a fine remembered set for a particular region. However the iterator still walks the hash table.
> 
> I took the opportunity to try to slightly improve the documentation of
> the HeapRegionRemSetIterator (comments) as the change changes the
> HeapRegionRemSetIterator interface already anyway.
> 
> A micro-benchmark that does nothing for every card indicates that
> iterating of the PRTs got a lot faster (mainly due to the less
> complicated check in HeapRegionRemSetIterator::fine_has_next() I assume) and is only a side-effect of the change.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8037344
> 
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8037344/webrev/
> 
> Testing:
> jprt, specjbb*, specjvm2008*, dacapo and other benchmarks having large
> remembered sets.
> 

Thanks,
  Thomas




From thomas.schatzl at oracle.com  Wed Apr  9 10:28:51 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 09 Apr 2014 12:28:51 +0200
Subject: RFR (XXS): 8039596: Remove HeapRegionRemSet::clear_incoming_entry()
Message-ID: <1397039331.2710.18.camel@cirrus>

Hi all,

  can I have reviews for the following cleanup that simply removes above
method?

It has not been used anywhere for apparently a long time, so it seems
somewhat out of date as it does not cover sparse entries.

This, depending on the caller which is not there any more, might not be
problematic, but nevertheless it does not seem useful to keep it any
longer.

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

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

Thanks,
  Thomas



From vladimir.kempik at oracle.com  Wed Apr  9 11:27:49 2014
From: vladimir.kempik at oracle.com (Vladimir Kempik)
Date: Wed, 09 Apr 2014 15:27:49 +0400
Subject: Request for review: 8016302: Change type of the number of GC
	workers to unsigned int (2)
In-Reply-To: <1396528800.3018.22.camel@cirrus>
References: <533C3821.60005@oracle.com> <533D3846.5090703@oracle.com>	
	<533D48FD.60701@oracle.com> <1396528800.3018.22.camel@cirrus>
Message-ID: <53452EB5.9040909@oracle.com>

Hello

With few modifications this patch can be backported to jdk7.

Do you think it worth to port it to jdk7?

Thanks. Vladimir.

On 03.04.2014 16:40, Thomas Schatzl wrote:
> Hi,
>
> On Thu, 2014-04-03 at 15:41 +0400, Vladimir Kempik wrote:
>> Hello
>>
>> I've used UINT32_FORMAT because:
>>
>> 1) previous format type for worker was INT32_FORMAT, when worker was int
>>
>> 2) there is no such thing as UINT_FORMAT,  there is only UINTX_FORMAT
>>
>> Do you think UINTX_FORMAT is better than UINT32_FORMAT for this case ?
> UINTX_FORMAT or uintx is an unsigned data type that has 32 or 64 bit
> size depending on the processes' word size.
>
> I think UINT32_FORMAT is correct here, and used elsewhere for uint
> variables. Afaik uint is 32 bits on all platforms we use.
>
> Thanks,
>    Thomas
>
>



From bengt.rutisson at oracle.com  Wed Apr  9 11:32:09 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 09 Apr 2014 13:32:09 +0200
Subject: RFR(M): 8039147: Cleanup SuspendibleThreadSet
In-Reply-To: <5343DE47.3080708@oracle.com>
References: <5343DE47.3080708@oracle.com>
Message-ID: <53452FB9.9080004@oracle.com>


Hi Per,

Nice cleanup. Looks good to me.

Bengt


On 2014-04-08 13:32, Per Liden wrote:
> Hi,
>
> Here's a attempt to cleanup SuspendibleThreadSet that I'd like to get 
> some reviews on.
>
> Webrev: http://cr.openjdk.java.net/~pliden/8039147/webrev.0/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8039147
>
> Summary:
>
> * The function of SuspendibleThreadSet is completely unchanged. Still 
> does the same thing, same semantics, same users, etc.
>
> * SuspendibleThreadSet is broken out from concurrentGCThread.hpp/cpp 
> into separate files. The relation ship with ConcurrentGCThread is a 
> bit artificial as SuspendibleThreadSet is used by other threads as 
> well e.g. SharedHeap's FlexibleWorkGang.
>
> * There's currently two ways of using SuspendibleThreadSet, depending 
> on which context you're in; 1) through direct use of the static _sts 
> member in ConcurrentGCThread and 2) via the static stsXXXX() functions 
> exposed by ConcurrentGCThread. With this patch there's only one 
> interface, which is exposed as static functions on the 
> SuspendibleThreadSet class itself.
>
> * I adjusted the names of some of the fields in SuspendibleThreadSet, 
> which didn't quite make sense to me. For example, _async is now 
> _nthreads since it's a counter of number of threads currently in the 
> thread set.
>
> * The should_yield() and yield() functions on ConcurrentGCThread (and 
> it's subclasses) where removed, since they were never used. There was 
> one exception here though, which was concurrentMarkThread::yield(), 
> but it just does a direct call to SuspendibleThreadSet's yield() so 
> that's just an useless indirection.
>
> * SuspendibleThreadSetJoiner is introduced to replace code like this:
>
> if (....) {
>    _sts.join();
>    <do something>
>    _sts.leave();
> }
>
> with code like this:
>
> if (....) {
>    SuspendibleThreadSetJoiner sts;
>    <do something>
> }
>
> cheers,
> /Per



From mikael.gerdin at oracle.com  Wed Apr  9 11:46:34 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 09 Apr 2014 13:46:34 +0200
Subject: RFR (S): 8037344: Use the "next" field to iterate over fine
	remembered instead of using the hash table
In-Reply-To: <1397037765.2710.13.camel@cirrus>
References: <1394815316.2803.2.camel@cirrus> <1397037765.2710.13.camel@cirrus>
Message-ID: <2052383.BEgzZ2NYJK@mgerdin03>

Hi Thomas,

On Wednesday 09 April 2014 12.02.45 Thomas Schatzl wrote:
> Hi all,
> 
>   I have been notified that the webrev does not apply to the jdk9/hs-gc
> repository any more.
> 
> Here is an updated version:
> http://cr.openjdk.java.net/~tschatzl/8037344/webrev.1/

Just to make sure that I follow the subtleties in the code here, you set 
_cur_region_cur_card to -1 here. Then when fine_has_next is called it computes 
_cur_region_cur_card + 1 to get 0 and calls _bm.get_next_one_offset?

1115 void HeapRegionRemSetIterator::switch_to_next_prt(PerRegionTable* prt) {
1116   assert(prt != NULL, "Cannot switch to NULL prt");
1117   _fine_cur_prt = prt;
1118 
1119   HeapWord* r_bot = _fine_cur_prt->hr()->bottom();
1120   _cur_region_card_offset = _bosa->index_for(r_bot);
1121 
1122   _cur_region_cur_card = (size_t)-1;
1123 }

The rest of the code change looks ok, but this code is really complex and I 
hope that you've tested this with verification enabled to catch any tricky 
bugs.

/Mikael

> 
> On Fri, 2014-03-14 at 17:41 +0100, Thomas Schatzl wrote:
> > Hi all,
> > 
> >   could I have reviews for this small change that cleans up the
> > 
> > HeapRegionRemSet-iterator?
> > 
> > The reason for this change is that in JDK-7182260 linked together all
> > PerRegionTable data structure (representing parts of the fine remembered
> > set) of a fine remembered set for a particular region. However the
> > iterator still walks the hash table.
> > 
> > I took the opportunity to try to slightly improve the documentation of
> > the HeapRegionRemSetIterator (comments) as the change changes the
> > HeapRegionRemSetIterator interface already anyway.
> > 
> > A micro-benchmark that does nothing for every card indicates that
> > iterating of the PRTs got a lot faster (mainly due to the less
> > complicated check in HeapRegionRemSetIterator::fine_has_next() I assume)
> > and is only a side-effect of the change.
> > 
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8037344
> > 
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8037344/webrev/
> > 
> > Testing:
> > jprt, specjbb*, specjvm2008*, dacapo and other benchmarks having large
> > remembered sets.
> 
> Thanks,
>   Thomas



From markus.gronlund at oracle.com  Wed Apr  9 12:04:03 2014
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Wed, 9 Apr 2014 05:04:03 -0700 (PDT)
Subject: RFR(S): 8039458: Ensure consistency of Monitor/Mutex lock
	acquisitions in relation to safepoint protocol
Message-ID: <dbc0067b-4738-40a4-ac26-0f973519e200@default>

Greetings,

?

Kindly asking for reviews for the following bug fix/enhancement

?

Webrev: http://cr.openjdk.java.net/~mgronlun/8039458/webrev01/ 

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

?

Problem:

?

VM code acquire Monitor/Mutex locks by respecting the correct lock order, which is enforced in debug builds (asserts). This is great.

?

However, you could be taking locks in the correct order and everything might work just fine during development and testing (even product) but depending on runtime circumstances (load/concurrency), the way the lock(s) was acquired, i.e. the lock acquisition mode, can lead to very hard to debug problems (hangs/deadlocks). This is primarily related to the lock acquisition mode option "Mutex::_no_safepoint_check_flag" by which you inform your intent to respect or not-respect the safepoint protocol during lock acquisition/ownership.


If a lock has already been acquired by a thread by passing the Mutex::_no_safepoint_check_flag to circumvent the safepoint protocol, the thread must *not* be allowed to attempt taking yet another lock on which it *might* block ( a lock which was not acquired by passing Mutex::_no_safepoint_check_flag in its acquisition operation), as such a lock would be participating in the safepoint protocol.

?

Today, doing this mistake will work just fine _if the lock is currently uncontended_ which it normally is in development/testing situations. However, once the lock then becomes contended (highly volatile pressured/concurrent product deployment) you might get the worst kind of issues to debug (hangs/deadlocks).

?

Naturally and as always, you have to very careful when you are taking locks using the Mutex::_no_safepoint_check_flag -however it can be very hard to determine what other code you can safely call once you are the owner of a Mutex::_no_safepoint_check_flag:ed lock ?- and ?today there is nothing but the developers attention to details that will find/help stay clear of this. I think we can do better here in enforcing some invariants in code for preempting potential deadlock prone situations.

?

Description:

?

Add debug assertions that enforce correct usages of the Mutex::_no_safepoint_check_flag when taking multiple locks.


This suggestion leverages much of the existing code targeting enforcement of lock ordering- this is a simple additive change to also add invariant checking on "lock acquisition mode".

?

Do note this primarily targets Java Threads running in the VM.

?

Also included code comment:

?

/* 
?* Ensure consistency of Monitor/Mutex lock acquisitions 
?* for Java Threads running inside the VM. 
?* 
?* If a thread has already acquired lock(s) using 
?* "Mutex::_no_safepoint_check_flag" (effectively going outside the 
?* safepoint protocol), the thread should be disallowed to acquire any 
?* additional lock which _is_ participating in the safepoint protocol. 
?* 
?* If a "safepoint protocol aware" lock is contended, and the thread entering 
?* is unable to "fast acquire" the lock using cas/try_spin, 
?* it will need to block/park. Blocking on a contended lock involves a 
?* state transition and a potential SafepointSynchronize::block() call. 
?* Transitioning to a blocked state still holding "Mutex::_no_safepoint_check_flag" 
?* acquired locks is allowed, but is *very* deadlock prone. 
?* 
?* The effect of allowing this state to happen without checking is subtle 
?* and hard to debug since a problem might only appear under heavy load and 
?* only in situations with increased concurrency levels (product builds). 
?* 
?*/

?

Testing:

Artificial code changes to MutexLocker and Mutex::_no_safepoint_check_flag on certain locks for detecting potential deadlock situations.

Speccjbb2005

Kitchensink

?

Thank you

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

From thomas.schatzl at oracle.com  Wed Apr  9 12:14:51 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 09 Apr 2014 14:14:51 +0200
Subject: RFR(M): 8039147: Cleanup SuspendibleThreadSet
In-Reply-To: <5343DE47.3080708@oracle.com>
References: <5343DE47.3080708@oracle.com>
Message-ID: <1397045691.2710.43.camel@cirrus>

Hi,

On Tue, 2014-04-08 at 13:32 +0200, Per Liden wrote:
> Hi,
> 
> Here's a attempt to cleanup SuspendibleThreadSet that I'd like to get 
> some reviews on.
> 
> Webrev: http://cr.openjdk.java.net/~pliden/8039147/webrev.0/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8039147

Comment,
 - is it possible to use an uint for anything that is used as a number
of threads? A negative amount of threads seems unusual, and we just
fixed other G1 code to use uints instead of ints everywhere for thread
ids and amounts.

 - I think STS_lock only needs to be initialized when UseG1GC is true.

 - the change removes the start/end messages when yielding during
refinement and G1TraceConcRefinement is true. They seem to be
interesting, more than the other messages enabled by this switch. I
would somewhat prefer to keep them, but I have no real strong opinion.

Otherwise looks good. Thanks for the cleanup.

Thanks,
  Thomas




From mikael.gerdin at oracle.com  Wed Apr  9 12:23:27 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 09 Apr 2014 14:23:27 +0200
Subject: RFR(M): 8039147: Cleanup SuspendibleThreadSet
In-Reply-To: <5343DE47.3080708@oracle.com>
References: <5343DE47.3080708@oracle.com>
Message-ID: <4356100.fWncPPeJ27@mgerdin03>

Per,

On Tuesday 08 April 2014 13.32.23 Per Liden wrote:
> Hi,
> 
> Here's a attempt to cleanup SuspendibleThreadSet that I'd like to get
> some reviews on.
> 
> Webrev: http://cr.openjdk.java.net/~pliden/8039147/webrev.0/

The comment at the top of suspendibleThreadSet.hpp mentions 
safepoint_synchronize() and safepoint_desyncrhonize() but you removed the 
prefix from these functions.

Otherwise the change looks good.

/Mikael

> Bug: https://bugs.openjdk.java.net/browse/JDK-8039147
> 
> Summary:
> 
> * The function of SuspendibleThreadSet is completely unchanged. Still
> does the same thing, same semantics, same users, etc.
> 
> * SuspendibleThreadSet is broken out from concurrentGCThread.hpp/cpp
> into separate files. The relation ship with ConcurrentGCThread is a bit
> artificial as SuspendibleThreadSet is used by other threads as well e.g.
> SharedHeap's FlexibleWorkGang.
> 
> * There's currently two ways of using SuspendibleThreadSet, depending on
> which context you're in; 1) through direct use of the static _sts member
> in ConcurrentGCThread and 2) via the static stsXXXX() functions exposed
> by ConcurrentGCThread. With this patch there's only one interface, which
> is exposed as static functions on the SuspendibleThreadSet class itself.
> 
> * I adjusted the names of some of the fields in SuspendibleThreadSet,
> which didn't quite make sense to me. For example, _async is now
> _nthreads since it's a counter of number of threads currently in the
> thread set.
> 
> * The should_yield() and yield() functions on ConcurrentGCThread (and
> it's subclasses) where removed, since they were never used. There was
> one exception here though, which was concurrentMarkThread::yield(), but
> it just does a direct call to SuspendibleThreadSet's yield() so that's
> just an useless indirection.
> 
> * SuspendibleThreadSetJoiner is introduced to replace code like this:
> 
> if (....) {
>     _sts.join();
>     <do something>
>     _sts.leave();
> }
> 
> with code like this:
> 
> if (....) {
>     SuspendibleThreadSetJoiner sts;
>     <do something>
> }
> 
> cheers,
> /Per



From mikael.gerdin at oracle.com  Wed Apr  9 12:26:57 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 09 Apr 2014 14:26:57 +0200
Subject: RFR (XXS): 8039596: Remove
	HeapRegionRemSet::clear_incoming_entry()
In-Reply-To: <1397039331.2710.18.camel@cirrus>
References: <1397039331.2710.18.camel@cirrus>
Message-ID: <1979952.h8ehgdTM4g@mgerdin03>

On Wednesday 09 April 2014 12.28.51 Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews for the following cleanup that simply removes above
> method?
> 
> It has not been used anywhere for apparently a long time, so it seems
> somewhat out of date as it does not cover sparse entries.
> 
> This, depending on the caller which is not there any more, might not be
> problematic, but nevertheless it does not seem useful to keep it any
> longer.
> 
> CR
> https://bugs.openjdk.java.net/browse/JDK-8039596
> 
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8039596/webrev/

Looks good.
/Mikael

> 
> Thanks,
>   Thomas



From thomas.schatzl at oracle.com  Wed Apr  9 12:34:06 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 09 Apr 2014 14:34:06 +0200
Subject: RFR (S): 8037344: Use the "next" field to iterate over fine
	remembered instead of using the hash table
In-Reply-To: <2052383.BEgzZ2NYJK@mgerdin03>
References: <1394815316.2803.2.camel@cirrus>
	<1397037765.2710.13.camel@cirrus> <2052383.BEgzZ2NYJK@mgerdin03>
Message-ID: <1397046846.2710.58.camel@cirrus>

Hi,

On Wed, 2014-04-09 at 13:46 +0200, Mikael Gerdin wrote:
> Hi Thomas,
> 
> On Wednesday 09 April 2014 12.02.45 Thomas Schatzl wrote:
> > Hi all,
> > 
> >   I have been notified that the webrev does not apply to the jdk9/hs-gc
> > repository any more.
> > 
> > Here is an updated version:
> > http://cr.openjdk.java.net/~tschatzl/8037344/webrev.1/
> 
> Just to make sure that I follow the subtleties in the code here, you set 
> _cur_region_cur_card to -1 here. Then when fine_has_next is called it computes 
> _cur_region_cur_card + 1 to get 0 and calls _bm.get_next_one_offset?

Exactly, this is to get the start condition right after switching from
coarse to fine entries or to the next fine PRT.
Get_next_one_offset() starts searching including the passed offset.

I will add a comment.

> 1115 void HeapRegionRemSetIterator::switch_to_next_prt(PerRegionTable* prt) {
> 1116   assert(prt != NULL, "Cannot switch to NULL prt");
> 1117   _fine_cur_prt = prt;
> 1118 
> 1119   HeapWord* r_bot = _fine_cur_prt->hr()->bottom();
> 1120   _cur_region_card_offset = _bosa->index_for(r_bot);
> 1121 
> 1122   _cur_region_cur_card = (size_t)-1;
> 1123 }
> 
> The rest of the code change looks ok, but this code is really complex and I 
> hope that you've tested this with verification enabled to catch any tricky 
> bugs.

It took me a while to get it completely right to pass various benchmarks
with verification. I do not exactly remember though what programs the
change has been tested with - however this change is part of my stack of
pending changes that is continuously used in developing new changes, so
in the last month or so it got a lot of implicit testing.

This testing includes the usual benchmarks, and bigapps containing
kitchensink 24h runs and such.

Overall the change simplifies the old code significantly imo, however I
agree that especially this iterator's interface complicates matters a
lot.

Thanks,
  Thomas




From mikael.gerdin at oracle.com  Wed Apr  9 12:37:20 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 09 Apr 2014 14:37:20 +0200
Subject: RFR (S): 8037344: Use the "next" field to iterate over fine
	remembered instead of using the hash table
In-Reply-To: <1397046846.2710.58.camel@cirrus>
References: <1394815316.2803.2.camel@cirrus> <2052383.BEgzZ2NYJK@mgerdin03>
	<1397046846.2710.58.camel@cirrus>
Message-ID: <1815925.qcRQHHumPe@mgerdin03>

On Wednesday 09 April 2014 14.34.06 Thomas Schatzl wrote:
> Hi,
> 
> On Wed, 2014-04-09 at 13:46 +0200, Mikael Gerdin wrote:
> > Hi Thomas,
> > 
> > On Wednesday 09 April 2014 12.02.45 Thomas Schatzl wrote:
> > > Hi all,
> > > 
> > >   I have been notified that the webrev does not apply to the jdk9/hs-gc
> > > 
> > > repository any more.
> > > 
> > > Here is an updated version:
> > > http://cr.openjdk.java.net/~tschatzl/8037344/webrev.1/
> > 
> > Just to make sure that I follow the subtleties in the code here, you set
> > _cur_region_cur_card to -1 here. Then when fine_has_next is called it
> > computes _cur_region_cur_card + 1 to get 0 and calls
> > _bm.get_next_one_offset?
> Exactly, this is to get the start condition right after switching from
> coarse to fine entries or to the next fine PRT.
> Get_next_one_offset() starts searching including the passed offset.
> 
> I will add a comment.

Thanks.

> 
> > 1115 void HeapRegionRemSetIterator::switch_to_next_prt(PerRegionTable*
> > prt) { 1116   assert(prt != NULL, "Cannot switch to NULL prt");
> > 1117   _fine_cur_prt = prt;
> > 1118
> > 1119   HeapWord* r_bot = _fine_cur_prt->hr()->bottom();
> > 1120   _cur_region_card_offset = _bosa->index_for(r_bot);
> > 1121
> > 1122   _cur_region_cur_card = (size_t)-1;
> > 1123 }
> > 
> > The rest of the code change looks ok, but this code is really complex and
> > I
> > hope that you've tested this with verification enabled to catch any tricky
> > bugs.
> 
> It took me a while to get it completely right to pass various benchmarks
> with verification. I do not exactly remember though what programs the
> change has been tested with - however this change is part of my stack of
> pending changes that is continuously used in developing new changes, so
> in the last month or so it got a lot of implicit testing.
> 
> This testing includes the usual benchmarks, and bigapps containing
> kitchensink 24h runs and such.

That's good. I think the only option for this code is to change it, test it 
and fix it if we break it.

> 
> Overall the change simplifies the old code significantly imo, however I
> agree that especially this iterator's interface complicates matters a
> lot.

Agreed.

/Mikael

> 
> Thanks,
>   Thomas



From per.liden at oracle.com  Wed Apr  9 13:01:31 2014
From: per.liden at oracle.com (Per Liden)
Date: Wed, 09 Apr 2014 15:01:31 +0200
Subject: RFR(M): 8039147: Cleanup SuspendibleThreadSet
In-Reply-To: <1397045691.2710.43.camel@cirrus>
References: <5343DE47.3080708@oracle.com> <1397045691.2710.43.camel@cirrus>
Message-ID: <534544AB.2080106@oracle.com>

Hi Thomas,

Thanks a lot, some comments below:

On 04/09/2014 02:14 PM, Thomas Schatzl wrote:
> Hi,
>
> On Tue, 2014-04-08 at 13:32 +0200, Per Liden wrote:
>> Hi,
>>
>> Here's a attempt to cleanup SuspendibleThreadSet that I'd like to get
>> some reviews on.
>>
>> Webrev: http://cr.openjdk.java.net/~pliden/8039147/webrev.0/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039147
>
> Comment,
>   - is it possible to use an uint for anything that is used as a number
> of threads? A negative amount of threads seems unusual, and we just
> fixed other G1 code to use uints instead of ints everywhere for thread
> ids and amounts.

Yep, will change to uint (and adjust the asserts which checks for 
negative values).

>
>   - I think STS_lock only needs to be initialized when UseG1GC is true.

It's true that it's only used by G1 today, but STS lives in shared and 
could in theory be used by any collector. If the lock initialization is 
moved under UseG1GC it also feels like STS itself should move into G1. 
But I'm not sure we want to do that as it's meant to be a collector 
agnostic class (we actually have an RFE saying CMS should use STS 
instead of it's own thing, not sure if that will ever happen). So, to be 
consistent I'd like to keep it as is. Objections?

>
>   - the change removes the start/end messages when yielding during
> refinement and G1TraceConcRefinement is true. They seem to be
> interesting, more than the other messages enabled by this switch. I
> would somewhat prefer to keep them, but I have no real strong opinion.

The yield() function in ConcurrentG1RefineThread was actually never 
used, so those messages would never have been seen, which is why I 
removed it.

Thanks!

/Per

>
> Otherwise looks good. Thanks for the cleanup.
>
> Thanks,
>    Thomas
>
>



From thomas.schatzl at oracle.com  Wed Apr  9 13:02:52 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 09 Apr 2014 15:02:52 +0200
Subject: RFR(M): 8039147: Cleanup SuspendibleThreadSet
In-Reply-To: <534544AB.2080106@oracle.com>
References: <5343DE47.3080708@oracle.com> <1397045691.2710.43.camel@cirrus>
	<534544AB.2080106@oracle.com>
Message-ID: <1397048572.2710.63.camel@cirrus>

Hi Per,

On Wed, 2014-04-09 at 15:01 +0200, Per Liden wrote:
> Hi Thomas,
> 
> Thanks a lot, some comments below:
> 
> On 04/09/2014 02:14 PM, Thomas Schatzl wrote:
> > Hi,
> >
> > On Tue, 2014-04-08 at 13:32 +0200, Per Liden wrote:
> >> Hi,
> >>
> >> Here's a attempt to cleanup SuspendibleThreadSet that I'd like to get
> >> some reviews on.
> >>
> >> Webrev: http://cr.openjdk.java.net/~pliden/8039147/webrev.0/
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8039147
> >
> > Comment,
> >   - is it possible to use an uint for anything that is used as a number
> > of threads? A negative amount of threads seems unusual, and we just
> > fixed other G1 code to use uints instead of ints everywhere for thread
> > ids and amounts.
> 
> Yep, will change to uint (and adjust the asserts which checks for 
> negative values).

Thanks.

> 
> >
> >   - I think STS_lock only needs to be initialized when UseG1GC is true.
> 
> It's true that it's only used by G1 today, but STS lives in shared and 
> could in theory be used by any collector. If the lock initialization is 
> moved under UseG1GC it also feels like STS itself should move into G1. 
> But I'm not sure we want to do that as it's meant to be a collector 
> agnostic class (we actually have an RFE saying CMS should use STS 
> instead of it's own thing, not sure if that will ever happen). So, to be 
> consistent I'd like to keep it as is. Objections?

No objections.

> >   - the change removes the start/end messages when yielding during
> > refinement and G1TraceConcRefinement is true. They seem to be
> > interesting, more than the other messages enabled by this switch. I
> > would somewhat prefer to keep them, but I have no real strong opinion.
> 
> The yield() function in ConcurrentG1RefineThread was actually never 
> used, so those messages would never have been seen, which is why I 
> removed it.

Okay :)

Thanks again,
Thomas




From thomas.schatzl at oracle.com  Wed Apr  9 13:05:21 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 09 Apr 2014 15:05:21 +0200
Subject: RFR (S): 8037344: Use the "next" field to iterate over fine
	remembered instead of using the hash table
In-Reply-To: <1815925.qcRQHHumPe@mgerdin03>
References: <1394815316.2803.2.camel@cirrus> <2052383.BEgzZ2NYJK@mgerdin03>
	<1397046846.2710.58.camel@cirrus> <1815925.qcRQHHumPe@mgerdin03>
Message-ID: <1397048721.2710.65.camel@cirrus>

Hi,

On Wed, 2014-04-09 at 14:37 +0200, Mikael Gerdin wrote:
> On Wednesday 09 April 2014 14.34.06 Thomas Schatzl wrote:
> > Hi,
> > 
> > On Wed, 2014-04-09 at 13:46 +0200, Mikael Gerdin wrote:
> > > Hi Thomas,
> > > 
> > > On Wednesday 09 April 2014 12.02.45 Thomas Schatzl wrote:
> > > > Hi all,
> > > > 
> > > >   I have been notified that the webrev does not apply to the jdk9/hs-gc
> > > > 
> > > > repository any more.
> > > > 
> > > > Here is an updated version:
> > > > http://cr.openjdk.java.net/~tschatzl/8037344/webrev.1/
> > > 
> > > Just to make sure that I follow the subtleties in the code here, you set
> > > _cur_region_cur_card to -1 here. Then when fine_has_next is called it
> > > computes _cur_region_cur_card + 1 to get 0 and calls
> > > _bm.get_next_one_offset?
> > Exactly, this is to get the start condition right after switching from
> > coarse to fine entries or to the next fine PRT.
> > Get_next_one_offset() starts searching including the passed offset.
> > 
> > I will add a comment.
> 
> Thanks.

Done in http://cr.openjdk.java.net/~tschatzl/8037344/webrev.2/

void HeapRegionRemSetIterator::switch_to_next_prt(PerRegionTable* prt) {
   assert(prt != NULL, "Cannot switch to NULL prt");
   _fine_cur_prt = prt;

   HeapWord* r_bot = _fine_cur_prt->hr()->bottom();
   _cur_region_card_offset = _bosa->index_for(r_bot);

+  // The bitmap scan for the PRT always scans from _cur_region_cur_card + 1.
+  // To avoid special-casing this start case, and not miss the first bitmap
+  // entry, initialize _cur_region_cur_card with -1 instead of 0.
   _cur_region_cur_card = (size_t)-1;
 }

Thanks,
Thomas



From yasuenag at gmail.com  Wed Apr  9 13:22:23 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Wed, 09 Apr 2014 22:22:23 +0900
Subject: -XX:MetaspaceSize is correct?
Message-ID: <5345498F.20904@gmail.com>

Hi all,

I checked initial metaspace size through jcmd PerfCounter.print .
However, it seems to be incorrect:

  - Java command:
   java -XX:-UseCompressedClassPointers -XX:+PrintFlagsFinal LongSleep

  - Output from -XX:+PrintFlagsFinal:
     uintx MetaspaceSize                             = 21807104                            {pd product}

  - Result of "PerfCounter.print"
sun.gc.metaspace.capacity=4194304
sun.gc.metaspace.maxCapacity=8388608
sun.gc.metaspace.minCapacity=0


I checked metaspace.cpp, initial size of metaspace is detected by
InitialBootClassLoaderMetaspaceSize.
However, description of MetaspaceSize in globals.hpp is
"Initial size of Metaspaces (in bytes)" .

Is description of MetaspaceSize is correct?
And this behavior is correct?

I have two plan for this mismatch:

  A) Change description of MetaspaceSize
   MetaspaceSize is used to HWM in metaspace.cpp .
   So we should change description for this behavior.
------------
diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
--- a/src/share/vm/runtime/globals.hpp  Fri Apr 04 10:04:44 2014 -0700
+++ b/src/share/vm/runtime/globals.hpp  Wed Apr 09 22:05:18 2014 +0900
@@ -3160,7 +3156,7 @@
            "non-daemon thread (in bytes)")                                   \
                                                                              \
    product_pd(uintx, MetaspaceSize,                                          \
-          "Initial size of Metaspaces (in bytes)")                          \
+          "Initial HWM of Metaspaces (in bytes)")                           \
                                                                              \
    product(uintx, MaxMetaspaceSize, max_uintx,                               \
            "Maximum size of Metaspaces (in bytes)")                          \
------------

  B) Remove InitialBootClassLoaderMetaspaceSize and use MetaspaceSize
   In currently, InitialBootClassLoaderMetaspaceSize is used to initialize
   metaspace.
   InitialBootClassLoaderMetaspaceSize is only to use for it.
   Thus we should remove this option and use MetaspaceSize to initialize
   metaspace.
------------
diff -r 48ce2e6e1add src/share/vm/memory/metaspace.cpp
--- a/src/share/vm/memory/metaspace.cpp Fri Apr 04 10:04:44 2014 -0700
+++ b/src/share/vm/memory/metaspace.cpp Wed Apr 09 22:05:18 2014 +0900
@@ -3172,7 +3172,7 @@
  #endif

      // Initialize these before initializing the VirtualSpaceList
-    _first_chunk_word_size = InitialBootClassLoaderMetaspaceSize / BytesPerWord;
+    _first_chunk_word_size = MetaspaceSize / BytesPerWord;
      _first_chunk_word_size = align_word_size_up(_first_chunk_word_size);
      // Make the first class chunk bigger than a medium chunk so it's not put
      // on the medium chunk list.   The next chunk will be small and progress
diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
--- a/src/share/vm/runtime/globals.hpp  Fri Apr 04 10:04:44 2014 -0700
+++ b/src/share/vm/runtime/globals.hpp  Wed Apr 09 22:05:18 2014 +0900
@@ -2333,10 +2333,6 @@
    develop(bool, TraceClassLoaderData, false,                                \
            "Trace class loader loader_data lifetime")                        \
                                                                              \
-  product(uintx, InitialBootClassLoaderMetaspaceSize,                       \
-          NOT_LP64(2200*K) LP64_ONLY(4*M),                                  \
-          "Initial size of the boot class loader data metaspace")           \
-                                                                            \
    product(bool, TraceGen0Time, false,                                       \
            "Trace accumulated time for Gen 0 collection")                    \
                                                                              \
------------

I prefer "B" .
Because, I guess many users think MetaspaceSize decides initial
metaspace size.

If my idea is correct, I will file this to JBS and upload patch to webrev.


Thanks,

Yasumasa



From per.liden at oracle.com  Wed Apr  9 13:36:49 2014
From: per.liden at oracle.com (Per Liden)
Date: Wed, 09 Apr 2014 15:36:49 +0200
Subject: RFR(M): 8039147: Cleanup SuspendibleThreadSet
In-Reply-To: <4356100.fWncPPeJ27@mgerdin03>
References: <5343DE47.3080708@oracle.com> <4356100.fWncPPeJ27@mgerdin03>
Message-ID: <53454CF1.1030805@oracle.com>

Hi,

Thanks Mikael, good catch! I found another comment in G1CollectedHeap 
which I also fixed. The updated webrev also includes the int->uint fix 
from Thomas comments:

http://cr.openjdk.java.net/~pliden/8039147/webrev.1/

Diff against previous webrev:

http://cr.openjdk.java.net/~pliden/8039147/webrev.1-diff_0vs1/

Thanks!
/Per

On 04/09/2014 02:23 PM, Mikael Gerdin wrote:
> Per,
>
> On Tuesday 08 April 2014 13.32.23 Per Liden wrote:
>> Hi,
>>
>> Here's a attempt to cleanup SuspendibleThreadSet that I'd like to get
>> some reviews on.
>>
>> Webrev: http://cr.openjdk.java.net/~pliden/8039147/webrev.0/
>
> The comment at the top of suspendibleThreadSet.hpp mentions
> safepoint_synchronize() and safepoint_desyncrhonize() but you removed the
> prefix from these functions.
>
> Otherwise the change looks good.
>
> /Mikael
>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039147
>>
>> Summary:
>>
>> * The function of SuspendibleThreadSet is completely unchanged. Still
>> does the same thing, same semantics, same users, etc.
>>
>> * SuspendibleThreadSet is broken out from concurrentGCThread.hpp/cpp
>> into separate files. The relation ship with ConcurrentGCThread is a bit
>> artificial as SuspendibleThreadSet is used by other threads as well e.g.
>> SharedHeap's FlexibleWorkGang.
>>
>> * There's currently two ways of using SuspendibleThreadSet, depending on
>> which context you're in; 1) through direct use of the static _sts member
>> in ConcurrentGCThread and 2) via the static stsXXXX() functions exposed
>> by ConcurrentGCThread. With this patch there's only one interface, which
>> is exposed as static functions on the SuspendibleThreadSet class itself.
>>
>> * I adjusted the names of some of the fields in SuspendibleThreadSet,
>> which didn't quite make sense to me. For example, _async is now
>> _nthreads since it's a counter of number of threads currently in the
>> thread set.
>>
>> * The should_yield() and yield() functions on ConcurrentGCThread (and
>> it's subclasses) where removed, since they were never used. There was
>> one exception here though, which was concurrentMarkThread::yield(), but
>> it just does a direct call to SuspendibleThreadSet's yield() so that's
>> just an useless indirection.
>>
>> * SuspendibleThreadSetJoiner is introduced to replace code like this:
>>
>> if (....) {
>>      _sts.join();
>>      <do something>
>>      _sts.leave();
>> }
>>
>> with code like this:
>>
>> if (....) {
>>      SuspendibleThreadSetJoiner sts;
>>      <do something>
>> }
>>
>> cheers,
>> /Per
>



From stefan.karlsson at oracle.com  Wed Apr  9 13:36:12 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 09 Apr 2014 15:36:12 +0200
Subject: 8039743: Use correct format specifier to print size_t values and
	pointers in the GC code
Message-ID: <53454CCC.8060802@oracle.com>

Hi all,

There are a number of occurrence in HotSpot that use %d and 0x%x to 
print size_t values and pointers. This is incorrect on platforms that 
have different type sizes for size_t and pointers compared to ints.

This patch only touches the GC code, but is based on an larger patch 
from Mikael Vidstedt.

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

thanks,
StefanK


From jon.masamitsu at oracle.com  Wed Apr  9 21:51:44 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 09 Apr 2014 14:51:44 -0700
Subject: -XX:MetaspaceSize is correct?
In-Reply-To: <5345498F.20904@gmail.com>
References: <5345498F.20904@gmail.com>
Message-ID: <5345C0F0.7020606@oracle.com>


On 04/09/2014 06:22 AM, Yasumasa Suenaga wrote:
> Hi all,
>
> I checked initial metaspace size through jcmd PerfCounter.print .
> However, it seems to be incorrect:
>
>  - Java command:
>   java -XX:-UseCompressedClassPointers -XX:+PrintFlagsFinal LongSleep
>
>  - Output from -XX:+PrintFlagsFinal:
>     uintx MetaspaceSize                             = 
> 21807104                            {pd product}
>
>  - Result of "PerfCounter.print"
> sun.gc.metaspace.capacity=4194304
> sun.gc.metaspace.maxCapacity=8388608
> sun.gc.metaspace.minCapacity=0
>
>
> I checked metaspace.cpp, initial size of metaspace is detected by
> InitialBootClassLoaderMetaspaceSize.
> However, description of MetaspaceSize in globals.hpp is
> "Initial size of Metaspaces (in bytes)" .
>
> Is description of MetaspaceSize is correct?

Description is not correct.

> And this behavior is correct?

Behavior is correct.

>
> I have two plan for this mismatch:
>
>  A) Change description of MetaspaceSize
>   MetaspaceSize is used to HWM in metaspace.cpp .
>   So we should change description for this behavior.
> ------------
> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
> --- a/src/share/vm/runtime/globals.hpp  Fri Apr 04 10:04:44 2014 -0700
> +++ b/src/share/vm/runtime/globals.hpp  Wed Apr 09 22:05:18 2014 +0900
> @@ -3160,7 +3156,7 @@
>            "non-daemon thread (in 
> bytes)")                                   \
> \
>    product_pd(uintx, 
> MetaspaceSize,                                          \
> -          "Initial size of Metaspaces (in 
> bytes)")                          \
> +          "Initial HWM of Metaspaces (in 
> bytes)")                           \

Explain what HWM is if you're going to use it.

> \
>    product(uintx, MaxMetaspaceSize, 
> max_uintx,                               \
>            "Maximum size of Metaspaces (in 
> bytes)")                          \
> ------------
>
>  B) Remove InitialBootClassLoaderMetaspaceSize and use MetaspaceSize
>   In currently, InitialBootClassLoaderMetaspaceSize is used to initialize
>   metaspace.
>   InitialBootClassLoaderMetaspaceSize is only to use for it.
>   Thus we should remove this option and use MetaspaceSize to initialize
>   metaspace.

InitialBootClassLoaderMetaspaceSize is an optimization.  It allows 
approximately
enough space for the system classes without repeated  allocations of 
Metaspaces.
Not everyone agrees with this optimization but I would like it kept.

> ------------
> diff -r 48ce2e6e1add src/share/vm/memory/metaspace.cpp
> --- a/src/share/vm/memory/metaspace.cpp Fri Apr 04 10:04:44 2014 -0700
> +++ b/src/share/vm/memory/metaspace.cpp Wed Apr 09 22:05:18 2014 +0900
> @@ -3172,7 +3172,7 @@
>  #endif
>
>      // Initialize these before initializing the VirtualSpaceList
> -    _first_chunk_word_size = InitialBootClassLoaderMetaspaceSize / 
> BytesPerWord;
> +    _first_chunk_word_size = MetaspaceSize / BytesPerWord;
>      _first_chunk_word_size = align_word_size_up(_first_chunk_word_size);
>      // Make the first class chunk bigger than a medium chunk so it's 
> not put
>      // on the medium chunk list.   The next chunk will be small and 
> progress
> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
> --- a/src/share/vm/runtime/globals.hpp  Fri Apr 04 10:04:44 2014 -0700
> +++ b/src/share/vm/runtime/globals.hpp  Wed Apr 09 22:05:18 2014 +0900
> @@ -2333,10 +2333,6 @@
>    develop(bool, TraceClassLoaderData, 
> false,                                \
>            "Trace class loader loader_data 
> lifetime")                        \
> \
> -  product(uintx, 
> InitialBootClassLoaderMetaspaceSize,                       \
> -          NOT_LP64(2200*K) 
> LP64_ONLY(4*M),                                  \
> -          "Initial size of the boot class loader data 
> metaspace")           \
> - \
>    product(bool, TraceGen0Time, 
> false,                                       \
>            "Trace accumulated time for Gen 0 
> collection")                    \
> \
> ------------
>
> I prefer "B" .
> Because, I guess many users think MetaspaceSize decides initial
> metaspace size.
>
> If my idea is correct, I will file this to JBS and upload patch to 
> webrev.

Please only correct the description of MetaspaceSize.

Jon

>
>
> Thanks,
>
> Yasumasa
>



From jon.masamitsu at oracle.com  Wed Apr  9 22:42:42 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 09 Apr 2014 15:42:42 -0700
Subject: 8039743: Use correct format specifier to print size_t values
	and pointers in the GC code
In-Reply-To: <53454CCC.8060802@oracle.com>
References: <53454CCC.8060802@oracle.com>
Message-ID: <5345CCE2.4020306@oracle.com>

http://cr.openjdk.java.net/~stefank/8039743/webrev.00/src/share/vm/memory/defNewGeneration.cpp.udiff.html

-    gclog_or_tty->print(" (promotion failure size = " SIZE_FORMAT ") ",
+    gclog_or_tty->print(" (promotion failure size = %u) ",
                          old->size());


size() returning an int, did you want %d instead of %u?

Rest looks good.

Jon

On 04/09/2014 06:36 AM, Stefan Karlsson wrote:
> Hi all,
>
> There are a number of occurrence in HotSpot that use %d and 0x%x to 
> print size_t values and pointers. This is incorrect on platforms that 
> have different type sizes for size_t and pointers compared to ints.
>
> This patch only touches the GC code, but is based on an larger patch 
> from Mikael Vidstedt.
>
> http://cr.openjdk.java.net/~stefank/8039743/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8039743
>
> thanks,
> StefanK



From yasuenag at gmail.com  Thu Apr 10 03:37:16 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Thu, 10 Apr 2014 12:37:16 +0900
Subject: -XX:MetaspaceSize is correct?
In-Reply-To: <5345C0F0.7020606@oracle.com>
References: <5345498F.20904@gmail.com>
	<5345C0F0.7020606@oracle.com>
Message-ID: <CAGFVN2Bmt0=w5sQ-m5qrBFvPcO2UmkPh1AGY5uskbUFRGfQ98g@mail.gmail.com>

Hi Jon,
Thank you for replying.

I filed this issue as JDK-8039867: Incorrect description: -XX:MetaspaceSize .

I attached a patch to this entry.
I will upload webrev later.


Thanks,

Yasumasa



2014-04-10 6:51 GMT+09:00, Jon Masamitsu <jon.masamitsu at oracle.com>:
>
> On 04/09/2014 06:22 AM, Yasumasa Suenaga wrote:
>> Hi all,
>>
>> I checked initial metaspace size through jcmd PerfCounter.print .
>> However, it seems to be incorrect:
>>
>>  - Java command:
>>   java -XX:-UseCompressedClassPointers -XX:+PrintFlagsFinal LongSleep
>>
>>  - Output from -XX:+PrintFlagsFinal:
>>     uintx MetaspaceSize                             =
>> 21807104                            {pd product}
>>
>>  - Result of "PerfCounter.print"
>> sun.gc.metaspace.capacity=4194304
>> sun.gc.metaspace.maxCapacity=8388608
>> sun.gc.metaspace.minCapacity=0
>>
>>
>> I checked metaspace.cpp, initial size of metaspace is detected by
>> InitialBootClassLoaderMetaspaceSize.
>> However, description of MetaspaceSize in globals.hpp is
>> "Initial size of Metaspaces (in bytes)" .
>>
>> Is description of MetaspaceSize is correct?
>
> Description is not correct.
>
>> And this behavior is correct?
>
> Behavior is correct.
>
>>
>> I have two plan for this mismatch:
>>
>>  A) Change description of MetaspaceSize
>>   MetaspaceSize is used to HWM in metaspace.cpp .
>>   So we should change description for this behavior.
>> ------------
>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>> --- a/src/share/vm/runtime/globals.hpp  Fri Apr 04 10:04:44 2014 -0700
>> +++ b/src/share/vm/runtime/globals.hpp  Wed Apr 09 22:05:18 2014 +0900
>> @@ -3160,7 +3156,7 @@
>>            "non-daemon thread (in
>> bytes)")                                   \
>> \
>>    product_pd(uintx,
>> MetaspaceSize,                                          \
>> -          "Initial size of Metaspaces (in
>> bytes)")                          \
>> +          "Initial HWM of Metaspaces (in
>> bytes)")                           \
>
> Explain what HWM is if you're going to use it.
>
>> \
>>    product(uintx, MaxMetaspaceSize,
>> max_uintx,                               \
>>            "Maximum size of Metaspaces (in
>> bytes)")                          \
>> ------------
>>
>>  B) Remove InitialBootClassLoaderMetaspaceSize and use MetaspaceSize
>>   In currently, InitialBootClassLoaderMetaspaceSize is used to initialize
>>   metaspace.
>>   InitialBootClassLoaderMetaspaceSize is only to use for it.
>>   Thus we should remove this option and use MetaspaceSize to initialize
>>   metaspace.
>
> InitialBootClassLoaderMetaspaceSize is an optimization.  It allows
> approximately
> enough space for the system classes without repeated  allocations of
> Metaspaces.
> Not everyone agrees with this optimization but I would like it kept.
>
>> ------------
>> diff -r 48ce2e6e1add src/share/vm/memory/metaspace.cpp
>> --- a/src/share/vm/memory/metaspace.cpp Fri Apr 04 10:04:44 2014 -0700
>> +++ b/src/share/vm/memory/metaspace.cpp Wed Apr 09 22:05:18 2014 +0900
>> @@ -3172,7 +3172,7 @@
>>  #endif
>>
>>      // Initialize these before initializing the VirtualSpaceList
>> -    _first_chunk_word_size = InitialBootClassLoaderMetaspaceSize /
>> BytesPerWord;
>> +    _first_chunk_word_size = MetaspaceSize / BytesPerWord;
>>      _first_chunk_word_size = align_word_size_up(_first_chunk_word_size);
>>      // Make the first class chunk bigger than a medium chunk so it's
>> not put
>>      // on the medium chunk list.   The next chunk will be small and
>> progress
>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>> --- a/src/share/vm/runtime/globals.hpp  Fri Apr 04 10:04:44 2014 -0700
>> +++ b/src/share/vm/runtime/globals.hpp  Wed Apr 09 22:05:18 2014 +0900
>> @@ -2333,10 +2333,6 @@
>>    develop(bool, TraceClassLoaderData,
>> false,                                \
>>            "Trace class loader loader_data
>> lifetime")                        \
>> \
>> -  product(uintx,
>> InitialBootClassLoaderMetaspaceSize,                       \
>> -          NOT_LP64(2200*K)
>> LP64_ONLY(4*M),                                  \
>> -          "Initial size of the boot class loader data
>> metaspace")           \
>> - \
>>    product(bool, TraceGen0Time,
>> false,                                       \
>>            "Trace accumulated time for Gen 0
>> collection")                    \
>> \
>> ------------
>>
>> I prefer "B" .
>> Because, I guess many users think MetaspaceSize decides initial
>> metaspace size.
>>
>> If my idea is correct, I will file this to JBS and upload patch to
>> webrev.
>
> Please only correct the description of MetaspaceSize.
>
> Jon
>
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>
>


From stefan.karlsson at oracle.com  Thu Apr 10 05:43:41 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 10 Apr 2014 07:43:41 +0200
Subject: 8039743: Use correct format specifier to print size_t values
	and pointers in the GC code
In-Reply-To: <5345CCE2.4020306@oracle.com>
References: <53454CCC.8060802@oracle.com> <5345CCE2.4020306@oracle.com>
Message-ID: <53462F8D.1070200@oracle.com>

On 2014-04-10 00:42, Jon Masamitsu wrote:
> http://cr.openjdk.java.net/~stefank/8039743/webrev.00/src/share/vm/memory/defNewGeneration.cpp.udiff.html 
>
>
> -    gclog_or_tty->print(" (promotion failure size = " SIZE_FORMAT ") ",
> +    gclog_or_tty->print(" (promotion failure size = %u) ",
>                          old->size());
>
>
> size() returning an int, did you want %d instead of %u?

OK. I'll change it to %d.

>
> Rest looks good.

Thanks for reviewing!

StefanK

>
> Jon
>
> On 04/09/2014 06:36 AM, Stefan Karlsson wrote:
>> Hi all,
>>
>> There are a number of occurrence in HotSpot that use %d and 0x%x to 
>> print size_t values and pointers. This is incorrect on platforms that 
>> have different type sizes for size_t and pointers compared to ints.
>>
>> This patch only touches the GC code, but is based on an larger patch 
>> from Mikael Vidstedt.
>>
>> http://cr.openjdk.java.net/~stefank/8039743/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8039743
>>
>> thanks,
>> StefanK
>



From david.holmes at oracle.com  Thu Apr 10 10:00:10 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 10 Apr 2014 20:00:10 +1000
Subject: RFR(S): 8039458: Ensure consistency of Monitor/Mutex lock
	acquisitions in relation to safepoint protocol
In-Reply-To: <dbc0067b-4738-40a4-ac26-0f973519e200@default>
References: <dbc0067b-4738-40a4-ac26-0f973519e200@default>
Message-ID: <53466BAA.4060809@oracle.com>

Hi Markus,

Not sure about the need to set _acquired_with_no_safepoint_check = false 
in unlock, but otherwise this looks okay to me. You only need to check 
the most recently acquired lock, because when you acquired it you would 
have checked the previously acquired lock and so forth.

The double negation, !_acquired_with_no_safepoint_check, does make this 
a little hard to think about. :)

I think you may need some additional test coverage to see if this is 
going to expose existing potentially broken behaviour.

Thanks,
David

On 9/04/2014 10:04 PM, Markus Gr?nlund wrote:
> Greetings,
>
> Kindly asking for reviews for the following bug fix/enhancement
>
> Webrev: http://cr.openjdk.java.net/~mgronlun/8039458/webrev01/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8039458
>
> Problem:
>
> VM code acquire Monitor/Mutex locks by respecting the correct lock
> order, which is enforced in debug builds (asserts). This is great.
>
> However, you could be taking locks in the correct order and everything
> might work just fine during development and testing (even product) but
> depending on runtime circumstances (load/concurrency), the way the
> lock(s) was acquired, i.e. the lock acquisition /mode/, can lead to very
> hard to debug problems (hangs/deadlocks). This is primarily related to
> the lock acquisition mode option ?Mutex::_no_safepoint_check_flag? by
> which you inform your intent to respect or not-respect the safepoint
> protocol during lock acquisition/ownership.
>
>
> If a lock has already been acquired by a thread by passing the
> Mutex::_no_safepoint_check_flag to circumvent the safepoint protocol,
> the thread must *not* be allowed to attempt taking yet another lock on
> which it *might* block ( a lock which was not acquired by passing
> Mutex::_no_safepoint_check_flag in its acquisition operation), as such a
> lock would be participating in the safepoint protocol.
>
> Today, doing this mistake will work just fine _/if the lock is currently
> uncontended_ /which it normally is in development/testing situations*.*
> However, once the lock then becomes contended (highly volatile
> pressured/concurrent product deployment) you might get the worst kind of
> issues to debug (hangs/deadlocks).
>
> Naturally and as always, you have to very careful when you are taking
> locks using the Mutex::_no_safepoint_check_flag ?however it can be very
> hard to determine what other code you can safely call once you are the
> owner of a Mutex::_no_safepoint_check_flag:ed lock  - and  today there
> is nothing but the developers attention to details that will find/help
> stay clear of this. I think we can do better here in enforcing some
> invariants in code for preempting potential deadlock prone situations.
>
> Description:
>
> Add debug assertions that enforce correct usages of the
> Mutex::_no_safepoint_check_flag when taking multiple locks.
>
>
> This suggestion leverages much of the existing code targeting
> enforcement of lock ordering- this is a simple additive change to also
> add invariant checking on "lock acquisition mode".
>
> Do note this primarily targets Java Threads running in the VM.
>
> Also included code comment:
>
> /*
>   * Ensure consistency of Monitor/Mutex lock acquisitions
>   * for Java Threads running inside the VM.
>   *
>   * If a thread has already acquired lock(s) using
>   * "Mutex::_no_safepoint_check_flag" (effectively going outside the
>   * safepoint protocol), the thread should be disallowed to acquire any
>   * additional lock which _is_ participating in the safepoint protocol.
>   *
>   * If a "safepoint protocol aware" lock is contended, and the thread
> entering
>   * is unable to "fast acquire" the lock using cas/try_spin,
>   * it will need to block/park. Blocking on a contended lock involves a
>   * state transition and a potential SafepointSynchronize::block() call.
>   * Transitioning to a blocked state still holding
> "Mutex::_no_safepoint_check_flag"
>   * acquired locks is allowed, but is *very* deadlock prone.
>   *
>   * The effect of allowing this state to happen without checking is subtle
>   * and hard to debug since a problem might only appear under heavy load
> and
>   * only in situations with increased concurrency levels (product builds).
> *
>   */
>
> Testing:
>
> Artificial code changes to MutexLocker and
> Mutex::_no_safepoint_check_flag on certain locks for detecting potential
> deadlock situations.
>
> Speccjbb2005
>
> Kitchensink
>
> Thank you
>
> Markus
>


From erik.helin at oracle.com  Thu Apr 10 12:09:55 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 10 Apr 2014 14:09:55 +0200
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <533D69D0.6060203@oracle.com>
References: <5332FA20.5070607@oracle.com>	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>	<53394053.2070502@oracle.com>	<533955B0.7000601@oracle.com>	<533A6165.80704@oracle.com>	<533A8141.2030608@oracle.com>	<533AB040.6000302@oracle.com>	<533C3654.7020801@oracle.com>	<533C3974.5080803@oracle.com>	<533C460D.5020707@oracle.com>	<533C4CDC.3070307@oracle.com>	<533D68E1.7000007@oracle.com>
	<533D69D0.6060203@oracle.com>
Message-ID: <53468A13.2010709@oracle.com>

Ok,

here is a new patch made by Andrey:

http://cr.openjdk.java.net/~ehelin/8037924/webrev.13/

The new patch is now only for JDK-8037924, this patch does not fix 
JDK-8037925 (a separate patch will be sent out for that).

This patch makes no changes to the testlibrary, it only introduces the 
new test. Please note that there already an issue filed for cleaning up 
some of the duplication in these tests:
https://bugs.openjdk.java.net/browse/JDK-8039489

Thanks,
Erik

On 2014-04-03 16:01, Erik Helin wrote:
> Andrey, Igor,
>
> maybe we should have a chat session on IM where can discuss this?
>
> Thanks,
> Erik
>
> On 2014-04-03 15:57, Erik Helin wrote:
>> Andrey,
>>
>> is all the changes in this webrev part of the patch? The files in this
>> change looks very similar to the files in
>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.04/ ?
>>
>> Thanks,
>> Erik
>>
>> On 2014-04-02 19:46, Jesper Wilhelmsson wrote:
>>> New webrev is uploaded here:
>>>
>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.12/
>>>
>>> /Jesper
>>>
>>> Andrey Zakharov skrev 2/4/14 19:17:
>>>> Hi, here is not uploaded yet webrev with totally reverted inheritance.
>>>> Jesper, can you please upload to your space.
>>>> Thanks.
>>>>
>>>>
>>>> On 02.04.2014 20:23, Igor Ignatyev wrote:
>>>>> Andrey,
>>>>>
>>>>> Why do test classes extend TestShrinkHeap?
>>>>>
>>>>> Igor
>>>>>
>>>>> On 04/02/2014 08:09 PM, Andrey Zakharov wrote:
>>>>>> Here is version without hidden testflow:
>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.11/
>>>>>> Thanks.
>>>>>>
>>>>>> On 01.04.2014 16:25, Jesper Wilhelmsson wrote:
>>>>>>> Uploaded:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.10/
>>>>>>>
>>>>>>> In general  would agree regarding avoiding duplicated code, but when
>>>>>>> it comes to the control flow I agree with Erik. More hard to read
>>>>>>> code
>>>>>>> leads to harder maintenance than duplicating a few lines of code.
>>>>>>> /Jesper
>>>>>>>
>>>>>>> Andrey Zakharov skrev 1/4/14 11:05:
>>>>>>>> Hi, Erik. Thanks for comments.
>>>>>>>>
>>>>>>>> On 01.04.2014 10:49, Erik Helin wrote:
>>>>>>>>> Andrey,
>>>>>>>>>
>>>>>>>>> a couple of comments:
>>>>>>>>> - We do not use the @author tag in the tests
>>>>>>>>>   (if you've seen other tests have the @author tag, then that is
>>>>>>>>> a bug)
>>>>>>>> removed
>>>>>>>>> - I'm not a big fan of using inheritance for sharing code between
>>>>>>>>>   tests because it makes it very hard to open a test, e.g.
>>>>>>>>>   TestHumongousShrinkHeap.java, and see what it does.
>>>>>>>> Agreed, I'm too. But doubled code leads to harder maintenance.
>>>>>>>>>
>>>>>>>>>   The code you share in TestShrinkHeap is basically the check and
>>>>>>>>> the
>>>>>>>>>   control flow of the tests. I would prefer if you could move the
>>>>>>>>>   control flow (System.gc(), sample, eat, sample, free, check
>>>>>>>>> samples)
>>>>>>>>>   into the tests and then write helper functions for retrieving
>>>>>>>>> the
>>>>>>>>>   flag values.
>>>>>>>>>
>>>>>>>>>   As for the check, please use the assertions in
>>>>>>>>>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>>>>>>>>   throwing a RuntimeException.
>>>>>>>> Good point, changed.
>>>>>>>> Jesper, can we upload webrev.10 from attachment? Thanks.
>>>>>>>> I'm still need GC reviewers to approve push.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Erik
>>>>>>>>>
>>>>>>>>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> New webrev uploaded.
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>>>>>>>>
>>>>>>>>>> I'm not a Reviewer either so if you got Igor's blessing
>>>>>>>>>> already, my
>>>>>>>>>> review won't be enough to push unfortunately.
>>>>>>>>>> /Jesper
>>>>>>>>>>
>>>>>>>>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>>>>>>>>> Hi,
>>>>>>>>>>> Jepser, here is updated webrev.09
>>>>>>>>>>> Thomas, Jesper can you review it as well?
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>
>>>>>>>>>>>> 1. TEST.groups:
>>>>>>>>>>>> please update copyright year:
>>>>>>>>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All
>>>>>>>>>>>>> rights
>>>>>>>>>>>>> reserved.
>>>>>>>>>>>> should be
>>>>>>>>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates.
>>>>>>>>>>>>> All
>>>>>>>>>>>>> rights
>>>>>>>>>>>>> reserved.
>>>>>>>>>>>>
>>>>>>>>>>>> 2. TestShrinkHeap.java
>>>>>>>>>>>>>   22  */
>>>>>>>>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>>>>>>>>> add empty line between 22 and 23 as you do in all other files,
>>>>>>>>>>>>
>>>>>>>>>>>> otherwise it looks good to me.
>>>>>>>>>>>>
>>>>>>>>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in
>>>>>>>>>>>> 'Reviewed-by'
>>>>>>>>>>>> section )
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Igor
>>>>>>>>>>>>
>>>>>>>>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>> Hi, team
>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>>>>>>>>> Webrev uploaded:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>> Thank you, Jesper.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>>>>>>>>> Hi! Here is webrev.08,
>>>>>>>>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1. both tests:
>>>>>>>>>>>>>>>>>   48     public void eat() {
>>>>>>>>>>>>>>>>> 61     public void free() {
>>>>>>>>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>>>>>>>>  32  */
>>>>>>>>>>>>>>>>>  33 import
>>>>>>>>>>>>>>>>> com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>>>>>>>>> add empty line between these lines or remove empty line
>>>>>>>>>>>>>>>> #32 in
>>>>>>>>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>>>>>>>>  62         //do not free last one list
>>>>>>>>>>>>>>>> space after '//'
>>>>>>>>>>>>>>>> 3. both tests:
>>>>>>>>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>>>>>>>>> after @bug you should specify product bug ids which can be
>>>>>>>>>>>>>>>> tested by
>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>> test. I guess 8016479 instead of 8037924, and
>>>>>>>>>>>>>>>> 8036025/8037925.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> otherwise it looks good, thank you for your work and
>>>>>>>>>>>>>>>> patience )
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>>>>>>>>> Igor, please, see comment below, everything
>>>>>>>>>>>>>>>>>> uncommented is
>>>>>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()'
>>>>>>>>>>>>>>>>>>> 'TestShrinkHeap.gc()'?
>>>>>>>>>>>>>>>>>> I cut this out.
>>>>>>>>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for
>>>>>>>>>>>>>>>>>>> it --
>>>>>>>>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Not sure is it applicable for me, because every time in
>>>>>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to
>>>>>>>>>>>>>>>>>>>>> review. It
>>>>>>>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>  45 public static byte[] temp;
>>>>>>>>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should
>>>>>>>>>>>>>>>>>>>>>> have one
>>>>>>>>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> protected static final String
>>>>>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>>>>>>>>> protected static final String
>>>>>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() <
>>>>>>>>>>>>>>>>>>>>>> muFull.getCommitted())) {
>>>>>>>>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>>>>>>>>       String.format("committed free heap size is not
>>>>>>>>>>>>>>>>>>>>>> less than
>>>>>>>>>>>>>>>>>>>>>> committed full heap size, heap hasn't been
>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s =
>>>>>>>>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(),
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue()
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full
>>>>>>>>>>>>>>>>>>>>>> GC");
>>>>>>>>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full GC");
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary
>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 26 * @key gc
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc',
>>>>>>>>>>>>>>>>>>>>>>>>>> please don't
>>>>>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>>>>>>> I think that this is used for test execution - to
>>>>>>>>>>>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>>>>>>>>> All test related to "gc" are located in test/gc, so
>>>>>>>>>>>>>>>>>>>>>>>> we don't
>>>>>>>>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>> one is
>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's
>>>>>>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 96 StringBuilder strb = new
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> committed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   97
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " =
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> " +
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   99
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " =
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> " +
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  101 throw new
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>  throw new
>>>>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap
>>>>>>>>>>>>>>>>>>>>>>>>>>>> size, heap
>>>>>>>>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect dynamic
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bug:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>


From erik.helin at oracle.com  Thu Apr 10 12:13:07 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 10 Apr 2014 14:13:07 +0200
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <53468A13.2010709@oracle.com>
References: <5332FA20.5070607@oracle.com>	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>	<53394053.2070502@oracle.com>	<533955B0.7000601@oracle.com>	<533A6165.80704@oracle.com>	<533A8141.2030608@oracle.com>	<533AB040.6000302@oracle.com>	<533C3654.7020801@oracle.com>	<533C3974.5080803@oracle.com>	<533C460D.5020707@oracle.com>	<533C4CDC.3070307@oracle.com>	<533D68E1.7000007@oracle.com>	<533D69D0.6060203@oracle.com>
	<53468A13.2010709@oracle.com>
Message-ID: <53468AD3.8020908@oracle.com>

Given that the issue for cleaning up these tests exist, is assigned and 
is already being worked on, I think this patch is ok.

Erik

On 2014-04-10 14:09, Erik Helin wrote:
> Ok,
>
> here is a new patch made by Andrey:
>
> http://cr.openjdk.java.net/~ehelin/8037924/webrev.13/
>
> The new patch is now only for JDK-8037924, this patch does not fix
> JDK-8037925 (a separate patch will be sent out for that).
>
> This patch makes no changes to the testlibrary, it only introduces the
> new test. Please note that there already an issue filed for cleaning up
> some of the duplication in these tests:
> https://bugs.openjdk.java.net/browse/JDK-8039489
>
> Thanks,
> Erik
>
> On 2014-04-03 16:01, Erik Helin wrote:
>> Andrey, Igor,
>>
>> maybe we should have a chat session on IM where can discuss this?
>>
>> Thanks,
>> Erik
>>
>> On 2014-04-03 15:57, Erik Helin wrote:
>>> Andrey,
>>>
>>> is all the changes in this webrev part of the patch? The files in this
>>> change looks very similar to the files in
>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.04/ ?
>>>
>>> Thanks,
>>> Erik
>>>
>>> On 2014-04-02 19:46, Jesper Wilhelmsson wrote:
>>>> New webrev is uploaded here:
>>>>
>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.12/
>>>>
>>>> /Jesper
>>>>
>>>> Andrey Zakharov skrev 2/4/14 19:17:
>>>>> Hi, here is not uploaded yet webrev with totally reverted inheritance.
>>>>> Jesper, can you please upload to your space.
>>>>> Thanks.
>>>>>
>>>>>
>>>>> On 02.04.2014 20:23, Igor Ignatyev wrote:
>>>>>> Andrey,
>>>>>>
>>>>>> Why do test classes extend TestShrinkHeap?
>>>>>>
>>>>>> Igor
>>>>>>
>>>>>> On 04/02/2014 08:09 PM, Andrey Zakharov wrote:
>>>>>>> Here is version without hidden testflow:
>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.11/
>>>>>>> Thanks.
>>>>>>>
>>>>>>> On 01.04.2014 16:25, Jesper Wilhelmsson wrote:
>>>>>>>> Uploaded:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.10/
>>>>>>>>
>>>>>>>> In general  would agree regarding avoiding duplicated code, but
>>>>>>>> when
>>>>>>>> it comes to the control flow I agree with Erik. More hard to read
>>>>>>>> code
>>>>>>>> leads to harder maintenance than duplicating a few lines of code.
>>>>>>>> /Jesper
>>>>>>>>
>>>>>>>> Andrey Zakharov skrev 1/4/14 11:05:
>>>>>>>>> Hi, Erik. Thanks for comments.
>>>>>>>>>
>>>>>>>>> On 01.04.2014 10:49, Erik Helin wrote:
>>>>>>>>>> Andrey,
>>>>>>>>>>
>>>>>>>>>> a couple of comments:
>>>>>>>>>> - We do not use the @author tag in the tests
>>>>>>>>>>   (if you've seen other tests have the @author tag, then that is
>>>>>>>>>> a bug)
>>>>>>>>> removed
>>>>>>>>>> - I'm not a big fan of using inheritance for sharing code between
>>>>>>>>>>   tests because it makes it very hard to open a test, e.g.
>>>>>>>>>>   TestHumongousShrinkHeap.java, and see what it does.
>>>>>>>>> Agreed, I'm too. But doubled code leads to harder maintenance.
>>>>>>>>>>
>>>>>>>>>>   The code you share in TestShrinkHeap is basically the check and
>>>>>>>>>> the
>>>>>>>>>>   control flow of the tests. I would prefer if you could move the
>>>>>>>>>>   control flow (System.gc(), sample, eat, sample, free, check
>>>>>>>>>> samples)
>>>>>>>>>>   into the tests and then write helper functions for retrieving
>>>>>>>>>> the
>>>>>>>>>>   flag values.
>>>>>>>>>>
>>>>>>>>>>   As for the check, please use the assertions in
>>>>>>>>>>   testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>>>>>>>>>   throwing a RuntimeException.
>>>>>>>>> Good point, changed.
>>>>>>>>> Jesper, can we upload webrev.10 from attachment? Thanks.
>>>>>>>>> I'm still need GC reviewers to approve push.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Erik
>>>>>>>>>>
>>>>>>>>>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> New webrev uploaded.
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>>>>>>>>>
>>>>>>>>>>> I'm not a Reviewer either so if you got Igor's blessing
>>>>>>>>>>> already, my
>>>>>>>>>>> review won't be enough to push unfortunately.
>>>>>>>>>>> /Jesper
>>>>>>>>>>>
>>>>>>>>>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> Jepser, here is updated webrev.09
>>>>>>>>>>>> Thomas, Jesper can you review it as well?
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. TEST.groups:
>>>>>>>>>>>>> please update copyright year:
>>>>>>>>>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All
>>>>>>>>>>>>>> rights
>>>>>>>>>>>>>> reserved.
>>>>>>>>>>>>> should be
>>>>>>>>>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its affiliates.
>>>>>>>>>>>>>> All
>>>>>>>>>>>>>> rights
>>>>>>>>>>>>>> reserved.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2. TestShrinkHeap.java
>>>>>>>>>>>>>>   22  */
>>>>>>>>>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>>>>>>>>>> add empty line between 22 and 23 as you do in all other files,
>>>>>>>>>>>>>
>>>>>>>>>>>>> otherwise it looks good to me.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in
>>>>>>>>>>>>> 'Reviewed-by'
>>>>>>>>>>>>> section )
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>> Hi, team
>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>>>>>>>>>> Webrev uploaded:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>>> Thank you, Jesper.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>>>>>>>>>> Hi! Here is webrev.08,
>>>>>>>>>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1. both tests:
>>>>>>>>>>>>>>>>>>   48     public void eat() {
>>>>>>>>>>>>>>>>>> 61     public void free() {
>>>>>>>>>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>>>>>>>>>  32  */
>>>>>>>>>>>>>>>>>>  33 import
>>>>>>>>>>>>>>>>>> com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>>>>>>>>>> add empty line between these lines or remove empty line
>>>>>>>>>>>>>>>>> #32 in
>>>>>>>>>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>>>>>>>>>  62         //do not free last one list
>>>>>>>>>>>>>>>>> space after '//'
>>>>>>>>>>>>>>>>> 3. both tests:
>>>>>>>>>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>>>>>>>>>> after @bug you should specify product bug ids which can be
>>>>>>>>>>>>>>>>> tested by
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> test. I guess 8016479 instead of 8037924, and
>>>>>>>>>>>>>>>>> 8036025/8037925.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> otherwise it looks good, thank you for your work and
>>>>>>>>>>>>>>>>> patience )
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>>>>>>>>>> Igor, please, see comment below, everything
>>>>>>>>>>>>>>>>>>> uncommented is
>>>>>>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()'
>>>>>>>>>>>>>>>>>>>> 'TestShrinkHeap.gc()'?
>>>>>>>>>>>>>>>>>>> I cut this out.
>>>>>>>>>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox API for
>>>>>>>>>>>>>>>>>>>> it --
>>>>>>>>>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Not sure is it applicable for me, because every time in
>>>>>>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to
>>>>>>>>>>>>>>>>>>>>>> review. It
>>>>>>>>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>>  45 public static byte[] temp;
>>>>>>>>>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' and
>>>>>>>>>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should
>>>>>>>>>>>>>>>>>>>>>>> have one
>>>>>>>>>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> protected static final String
>>>>>>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>>>>>>>>>> protected static final String
>>>>>>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() <
>>>>>>>>>>>>>>>>>>>>>>> muFull.getCommitted())) {
>>>>>>>>>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>>>>>>>>>       String.format("committed free heap size is not
>>>>>>>>>>>>>>>>>>>>>>> less than
>>>>>>>>>>>>>>>>>>>>>>> committed full heap size, heap hasn't been
>>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s =
>>>>>>>>>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(),
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue()
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full
>>>>>>>>>>>>>>>>>>>>>>> GC");
>>>>>>>>>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full
>>>>>>>>>>>>>>>>>>>>>>> GC");
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary
>>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 26 * @key gc
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc',
>>>>>>>>>>>>>>>>>>>>>>>>>>> please don't
>>>>>>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>>>>>>>> I think that this is used for test execution - to
>>>>>>>>>>>>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>>>>>>>>>> All test related to "gc" are located in
>>>>>>>>>>>>>>>>>>>>>>>>> test/gc, so
>>>>>>>>>>>>>>>>>>>>>>>>> we don't
>>>>>>>>>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> one is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, it's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 96 StringBuilder strb = new
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> committed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   97
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " =
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> " +
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   99
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator"));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " =
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> " +
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  101 throw new
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  throw new
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full heap
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> size, heap
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string constants:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dynamic
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bug:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>


From yasuenag at gmail.com  Thu Apr 10 12:20:38 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Thu, 10 Apr 2014 21:20:38 +0900
Subject: -XX:MetaspaceSize is correct?
In-Reply-To: <CAGFVN2Bmt0=w5sQ-m5qrBFvPcO2UmkPh1AGY5uskbUFRGfQ98g@mail.gmail.com>
References: <5345498F.20904@gmail.com>	<5345C0F0.7020606@oracle.com>
	<CAGFVN2Bmt0=w5sQ-m5qrBFvPcO2UmkPh1AGY5uskbUFRGfQ98g@mail.gmail.com>
Message-ID: <53468C96.6080107@gmail.com>

I uploaded webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8039867/webrev.00/

Please review and sponsoring!


Yasumasa


On 04/10/2014 12:37 PM, Yasumasa Suenaga wrote:
> Hi Jon,
> Thank you for replying.
>
> I filed this issue as JDK-8039867: Incorrect description: -XX:MetaspaceSize .
>
> I attached a patch to this entry.
> I will upload webrev later.
>
>
> Thanks,
>
> Yasumasa
>
>
>
> 2014-04-10 6:51 GMT+09:00, Jon Masamitsu <jon.masamitsu at oracle.com>:
>> On 04/09/2014 06:22 AM, Yasumasa Suenaga wrote:
>>> Hi all,
>>>
>>> I checked initial metaspace size through jcmd PerfCounter.print .
>>> However, it seems to be incorrect:
>>>
>>>   - Java command:
>>>    java -XX:-UseCompressedClassPointers -XX:+PrintFlagsFinal LongSleep
>>>
>>>   - Output from -XX:+PrintFlagsFinal:
>>>      uintx MetaspaceSize                             =
>>> 21807104                            {pd product}
>>>
>>>   - Result of "PerfCounter.print"
>>> sun.gc.metaspace.capacity=4194304
>>> sun.gc.metaspace.maxCapacity=8388608
>>> sun.gc.metaspace.minCapacity=0
>>>
>>>
>>> I checked metaspace.cpp, initial size of metaspace is detected by
>>> InitialBootClassLoaderMetaspaceSize.
>>> However, description of MetaspaceSize in globals.hpp is
>>> "Initial size of Metaspaces (in bytes)" .
>>>
>>> Is description of MetaspaceSize is correct?
>> Description is not correct.
>>
>>> And this behavior is correct?
>> Behavior is correct.
>>
>>> I have two plan for this mismatch:
>>>
>>>   A) Change description of MetaspaceSize
>>>    MetaspaceSize is used to HWM in metaspace.cpp .
>>>    So we should change description for this behavior.
>>> ------------
>>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>>> --- a/src/share/vm/runtime/globals.hpp  Fri Apr 04 10:04:44 2014 -0700
>>> +++ b/src/share/vm/runtime/globals.hpp  Wed Apr 09 22:05:18 2014 +0900
>>> @@ -3160,7 +3156,7 @@
>>>             "non-daemon thread (in
>>> bytes)")                                   \
>>> \
>>>     product_pd(uintx,
>>> MetaspaceSize,                                          \
>>> -          "Initial size of Metaspaces (in
>>> bytes)")                          \
>>> +          "Initial HWM of Metaspaces (in
>>> bytes)")                           \
>> Explain what HWM is if you're going to use it.
>>
>>> \
>>>     product(uintx, MaxMetaspaceSize,
>>> max_uintx,                               \
>>>             "Maximum size of Metaspaces (in
>>> bytes)")                          \
>>> ------------
>>>
>>>   B) Remove InitialBootClassLoaderMetaspaceSize and use MetaspaceSize
>>>    In currently, InitialBootClassLoaderMetaspaceSize is used to initialize
>>>    metaspace.
>>>    InitialBootClassLoaderMetaspaceSize is only to use for it.
>>>    Thus we should remove this option and use MetaspaceSize to initialize
>>>    metaspace.
>> InitialBootClassLoaderMetaspaceSize is an optimization.  It allows
>> approximately
>> enough space for the system classes without repeated  allocations of
>> Metaspaces.
>> Not everyone agrees with this optimization but I would like it kept.
>>
>>> ------------
>>> diff -r 48ce2e6e1add src/share/vm/memory/metaspace.cpp
>>> --- a/src/share/vm/memory/metaspace.cpp Fri Apr 04 10:04:44 2014 -0700
>>> +++ b/src/share/vm/memory/metaspace.cpp Wed Apr 09 22:05:18 2014 +0900
>>> @@ -3172,7 +3172,7 @@
>>>   #endif
>>>
>>>       // Initialize these before initializing the VirtualSpaceList
>>> -    _first_chunk_word_size = InitialBootClassLoaderMetaspaceSize /
>>> BytesPerWord;
>>> +    _first_chunk_word_size = MetaspaceSize / BytesPerWord;
>>>       _first_chunk_word_size = align_word_size_up(_first_chunk_word_size);
>>>       // Make the first class chunk bigger than a medium chunk so it's
>>> not put
>>>       // on the medium chunk list.   The next chunk will be small and
>>> progress
>>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>>> --- a/src/share/vm/runtime/globals.hpp  Fri Apr 04 10:04:44 2014 -0700
>>> +++ b/src/share/vm/runtime/globals.hpp  Wed Apr 09 22:05:18 2014 +0900
>>> @@ -2333,10 +2333,6 @@
>>>     develop(bool, TraceClassLoaderData,
>>> false,                                \
>>>             "Trace class loader loader_data
>>> lifetime")                        \
>>> \
>>> -  product(uintx,
>>> InitialBootClassLoaderMetaspaceSize,                       \
>>> -          NOT_LP64(2200*K)
>>> LP64_ONLY(4*M),                                  \
>>> -          "Initial size of the boot class loader data
>>> metaspace")           \
>>> - \
>>>     product(bool, TraceGen0Time,
>>> false,                                       \
>>>             "Trace accumulated time for Gen 0
>>> collection")                    \
>>> \
>>> ------------
>>>
>>> I prefer "B" .
>>> Because, I guess many users think MetaspaceSize decides initial
>>> metaspace size.
>>>
>>> If my idea is correct, I will file this to JBS and upload patch to
>>> webrev.
>> Please only correct the description of MetaspaceSize.
>>
>> Jon
>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>



From erik.helin at oracle.com  Thu Apr 10 12:22:22 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 10 Apr 2014 14:22:22 +0200
Subject: RFR 8037925: CMM Testing: an allocated humongous object at the
	end of the heap should not prevents shrinking the heap
In-Reply-To: <533C429A.2080005@oracle.com>
References: <53332456.5060407@oracle.com>	<533326B8.4020407@oracle.com>	<53341B70.8070603@oracle.com>	<5334A527.4090209@oracle.com>	<53357A9E.4000505@oracle.com>	<53358125.8020803@oracle.com>
	<53367041.5060203@oracle.com>	<533B2DC9.5010903@oracle.com>
	<533C429A.2080005@oracle.com>
Message-ID: <53468CFE.2040800@oracle.com>

Andrey has updated the patch:

http://cr.openjdk.java.net/~ehelin/8037925/webrev.06/

The new patch does no longer change the testlibrary. There is already an 
issue filed for fixing these tests and the previous testlibrary changes: 
https://bugs.openjdk.java.net/browse/JDK-8039489.

Thanks,
Erik

On 2014-04-02 19:02, Andrey Zakharov wrote:
> Hi, Jon
> On 02.04.2014 01:21, Jon Masamitsu wrote:
>> Seems like an out-of-memory (OOME) can be thrown here (or anywhere below
>> this block of code).  Will an OOME be considered a pass, fail or
>> test-not-run?
> Yes, its really an question for me, from one point of view, we should
> catch OOM and move forward to exit(0),
> from another point - such things should be handled by test harness. Test
> should have some @tag about 1G memory its used and harness should skip
> test and notify about this if machine memory is below needed.
> Maybe there is another right way.
>


From stefan.johansson at oracle.com  Thu Apr 10 12:29:01 2014
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 10 Apr 2014 14:29:01 +0200
Subject: 8039743: Use correct format specifier to print size_t values
	and pointers in the GC code
In-Reply-To: <53462F8D.1070200@oracle.com>
References: <53454CCC.8060802@oracle.com> <5345CCE2.4020306@oracle.com>
	<53462F8D.1070200@oracle.com>
Message-ID: <53468E8D.4030608@oracle.com>

Change looks good!

Thanks,
Stefan

On 2014-04-10 07:43, Stefan Karlsson wrote:
> On 2014-04-10 00:42, Jon Masamitsu wrote:
>> http://cr.openjdk.java.net/~stefank/8039743/webrev.00/src/share/vm/memory/defNewGeneration.cpp.udiff.html 
>>
>>
>> -    gclog_or_tty->print(" (promotion failure size = " SIZE_FORMAT ") ",
>> +    gclog_or_tty->print(" (promotion failure size = %u) ",
>>                          old->size());
>>
>>
>> size() returning an int, did you want %d instead of %u?
>
> OK. I'll change it to %d.
>
>>
>> Rest looks good.
>
> Thanks for reviewing!
>
> StefanK
>
>>
>> Jon
>>
>> On 04/09/2014 06:36 AM, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> There are a number of occurrence in HotSpot that use %d and 0x%x to 
>>> print size_t values and pointers. This is incorrect on platforms 
>>> that have different type sizes for size_t and pointers compared to 
>>> ints.
>>>
>>> This patch only touches the GC code, but is based on an larger patch 
>>> from Mikael Vidstedt.
>>>
>>> http://cr.openjdk.java.net/~stefank/8039743/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8039743
>>>
>>> thanks,
>>> StefanK
>>
>



From erik.helin at oracle.com  Thu Apr 10 12:25:31 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 10 Apr 2014 14:25:31 +0200
Subject: RFR 8037925: CMM Testing: an allocated humongous object at the
	end of the heap should not prevents shrinking the heap
In-Reply-To: <53468CFE.2040800@oracle.com>
References: <53332456.5060407@oracle.com>	<533326B8.4020407@oracle.com>	<53341B70.8070603@oracle.com>	<5334A527.4090209@oracle.com>	<53357A9E.4000505@oracle.com>	<53358125.8020803@oracle.com>	<53367041.5060203@oracle.com>	<533B2DC9.5010903@oracle.com>	<533C429A.2080005@oracle.com>
	<53468CFE.2040800@oracle.com>
Message-ID: <53468DBB.3050504@oracle.com>

Given that the cleanup issue exists and is being worked on, I'm fine 
with this patch.

Thanks,
Erik

On 2014-04-10 14:22, Erik Helin wrote:
> Andrey has updated the patch:
>
> http://cr.openjdk.java.net/~ehelin/8037925/webrev.06/
>
> The new patch does no longer change the testlibrary. There is already an
> issue filed for fixing these tests and the previous testlibrary changes:
> https://bugs.openjdk.java.net/browse/JDK-8039489.
>
> Thanks,
> Erik
>
> On 2014-04-02 19:02, Andrey Zakharov wrote:
>> Hi, Jon
>> On 02.04.2014 01:21, Jon Masamitsu wrote:
>>> Seems like an out-of-memory (OOME) can be thrown here (or anywhere below
>>> this block of code).  Will an OOME be considered a pass, fail or
>>> test-not-run?
>> Yes, its really an question for me, from one point of view, we should
>> catch OOM and move forward to exit(0),
>> from another point - such things should be handled by test harness. Test
>> should have some @tag about 1G memory its used and harness should skip
>> test and notify about this if machine memory is below needed.
>> Maybe there is another right way.
>>


From stefan.karlsson at oracle.com  Thu Apr 10 12:39:09 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 10 Apr 2014 14:39:09 +0200
Subject: 8039743: Use correct format specifier to print size_t values
	and pointers in the GC code
In-Reply-To: <53468E8D.4030608@oracle.com>
References: <53454CCC.8060802@oracle.com>
	<5345CCE2.4020306@oracle.com>	<53462F8D.1070200@oracle.com>
	<53468E8D.4030608@oracle.com>
Message-ID: <534690ED.50103@oracle.com>


On 2014-04-10 14:29, Stefan Johansson wrote:
> Change looks good!

Thanks, Johansson.

StefanK

>
> Thanks,
> Stefan
>
> On 2014-04-10 07:43, Stefan Karlsson wrote:
>> On 2014-04-10 00:42, Jon Masamitsu wrote:
>>> http://cr.openjdk.java.net/~stefank/8039743/webrev.00/src/share/vm/memory/defNewGeneration.cpp.udiff.html 
>>>
>>>
>>> -    gclog_or_tty->print(" (promotion failure size = " SIZE_FORMAT 
>>> ") ",
>>> +    gclog_or_tty->print(" (promotion failure size = %u) ",
>>>                          old->size());
>>>
>>>
>>> size() returning an int, did you want %d instead of %u?
>>
>> OK. I'll change it to %d.
>>
>>>
>>> Rest looks good.
>>
>> Thanks for reviewing!
>>
>> StefanK
>>
>>>
>>> Jon
>>>
>>> On 04/09/2014 06:36 AM, Stefan Karlsson wrote:
>>>> Hi all,
>>>>
>>>> There are a number of occurrence in HotSpot that use %d and 0x%x to 
>>>> print size_t values and pointers. This is incorrect on platforms 
>>>> that have different type sizes for size_t and pointers compared to 
>>>> ints.
>>>>
>>>> This patch only touches the GC code, but is based on an larger 
>>>> patch from Mikael Vidstedt.
>>>>
>>>> http://cr.openjdk.java.net/~stefank/8039743/webrev.00/
>>>> https://bugs.openjdk.java.net/browse/JDK-8039743
>>>>
>>>> thanks,
>>>> StefanK
>>>
>>
>



From thomas.schatzl at oracle.com  Thu Apr 10 12:44:50 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 10 Apr 2014 14:44:50 +0200
Subject: RFR 8037925: CMM Testing: an allocated humongous object at the
	end of the heap should not prevents shrinking the heap
In-Reply-To: <53468CFE.2040800@oracle.com>
References: <53332456.5060407@oracle.com>	<533326B8.4020407@oracle.com>
	<53341B70.8070603@oracle.com>	<5334A527.4090209@oracle.com>
	<53357A9E.4000505@oracle.com>	<53358125.8020803@oracle.com>
	<53367041.5060203@oracle.com>	<533B2DC9.5010903@oracle.com>
	<533C429A.2080005@oracle.com> <53468CFE.2040800@oracle.com>
Message-ID: <1397133890.2748.36.camel@cirrus>

Hi,

On Thu, 2014-04-10 at 14:22 +0200, Erik Helin wrote:
> Andrey has updated the patch:
> 
> http://cr.openjdk.java.net/~ehelin/8037925/webrev.06/
> 
> The new patch does no longer change the testlibrary. There is already an 
> issue filed for fixing these tests and the previous testlibrary changes: 
> https://bugs.openjdk.java.net/browse/JDK-8039489.

  comments:

- please remove the -Xloggc parameter in the @run parameter. JTreg
automatically catches all log output into known per-test log files.

- a better summary could be: "Verify that heap shrinks after GC in the
presence of fragmentation due to humongous objects". I do not understand
the existing summary.

Otherwise looks okay.

Thanks,
  Thomas




From per.liden at oracle.com  Thu Apr 10 13:34:03 2014
From: per.liden at oracle.com (Per Liden)
Date: Thu, 10 Apr 2014 15:34:03 +0200
Subject: RFR(s): 8037112: gc/g1/TestHumongousAllocInitialMark.java caused
	SIGSEGV
In-Reply-To: <5343C10B.7060906@oracle.com>
References: <533D42C0.8060306@oracle.com> <3971356.DreSMqAOW1@mgerdin03>
	<533EA204.3090607@oracle.com> <4063857.h91XTfINnv@mgerdin03>
	<1F09BCB8-DE4D-4B97-AB63-06104BC6F0BD@oracle.com>
	<5343C10B.7060906@oracle.com>
Message-ID: <53469DCB.8030501@oracle.com>

Bengt reviewed this off-line and had one comment, which was that we 
should also stop G1's string dedup thread if it's running. The dedup 
thread is not affected by the original problem so stopping it is 
strictly not needed, but for completness we still want to do it.

Updated webrev:
http://cr.openjdk.java.net/~pliden/8037112/webrev.3/

Diff against previous webrev:
http://cr.openjdk.java.net/~pliden/8037112/webrev.3-diff_2vs3/

/Per

On 04/08/2014 11:27 AM, Per Liden wrote:
> Hi,
>
> Here's an updated webrev which fixes the potential dead lock issue I
> found. I've taken a whole new approach to this problem. Instead of
> joining/leaving the STS as protection from shutdown I've added a
> CollectedHeap::stop() which is called in the shutdown paths (in
> before_exit()) to stop and take down the concurrent threads in a
> controlled manner. This feel like a much cleaner approach and less error
> prone as it doesn't require any future log printouts to be guarded by
> join/leave.
>
> Webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.2/
>
> cheers,
> /Per
>
> On 04/04/2014 06:14 PM, Per Liden wrote:
>> Hmm, I discovered a potential dead lock with this approach, so please
>> hold reviews on this for now.
>>
>> Sorry!
>> /Per
>>
>> On 04 Apr 2014, at 14:28, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
>>
>>> Per,
>>>
>>> On Friday 04 April 2014 14.13.56 Per Liden wrote:
>>>> Thanks Mikael!
>>>>
>>>> Updated webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.1/
>>>
>>> Looks good.
>>> /Mikael
>>>
>>>>
>>>> /Per
>>>>
>>>> On 04/03/2014 03:59 PM, Mikael Gerdin wrote:
>>>>> Hi Per,
>>>>>
>>>>> On Thursday 03 April 2014 13.15.12 Per Liden wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Could I please have this bugfix reviewed.
>>>>>>
>>>>>> Summary: G1's ConcurrentMarkThread tries to use the gclog_or_tty when
>>>>>> the JVM is about to exit and the gclog_or_tty instance has been
>>>>>> destroyed. To prevent this, the ConcurrentMarkThread needs to join
>>>>>> the
>>>>>> SuspendibleThreadSet before accessing gclog_or_tty.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8037112
>>>>>> Webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.0/
>>>>>
>>>>> While I realize that this code is still semantically correct I
>>>>> think it
>>>>> reads a bit strange. In my mind if we have a
>>>>> if (...) {} else if (...) {} else {} block the checks in the "if" and
>>>>> "else
>>>>> if" should usually somehow related checks.
>>>>>
>>>>>   282       if (!cm()->has_aborted()) {
>>>>>   283         g1_policy->record_concurrent_mark_cleanup_completed();
>>>>>   284       } else if (G1Log::fine()) {
>>>>>   285         gclog_or_tty->date_stamp(PrintGCDateStamps);
>>>>>   286         gclog_or_tty->stamp(PrintGCTimeStamps);
>>>>>   287         gclog_or_tty->print_cr("[GC concurrent-mark-abort]");
>>>>>   288       }
>>>>>
>>>>> I would prefer if it was structured the other way around:
>>>>> if (cm()->has_aborted()) {
>>>>>
>>>>>     if (G1Log::fine()) { ... }
>>>>>
>>>>> else {
>>>>>
>>>>>     g1_policy->record_concurrent_mark_cleanup_completed();
>>>>>
>>>>> }
>>>>>
>>>>> The rest of the change looks good.
>>>>>
>>>>> /Mikael
>>>>>
>>>>>> Thanks!
>>>>>> /Per
>>>>>>
>>>>>> Btw, I created a separate RFE, JDK-8039147, to do a little bit of
>>>>>> cleanup of the SuspendibleThreadSet and how it's used. Will send that
>>>>>> out as separate review request shortly.
>>>
>>
>



From thomas.schatzl at oracle.com  Thu Apr 10 14:00:59 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 10 Apr 2014 16:00:59 +0200
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags
	allows to shrink the heap when using ParallelGC
In-Reply-To: <53468A13.2010709@oracle.com>
References: <5332FA20.5070607@oracle.com>	<53341CC0.8090509@oracle.com>
	<5334A639.6050205@oracle.com>	<53357B26.4080707@oracle.com>
	<53357DAC.70607@oracle.com>	<533581D3.3010808@oracle.com>
	<53359517.3070305@oracle.com>	<53366F67.4080409@oracle.com>
	<5336800A.2090506@oracle.com>	<5336BA50.30700@oracle.com>
	<5336E8AE.4030302@oracle.com>	<5336EFF4.1070605@oracle.com>
	<533725B7.8090209@oracle.com>	<53374769.70909@oracle.com>
	<53374A1C.9070509@oracle.com>	<5337CFE1.5040603@oracle.com>
	<53385D10.40506@oracle.com>	<53390C1F.9030400@oracle.com>
	<53393256.8090406@oracle.com>	<53394053.2070502@oracle.com>
	<533955B0.7000601@oracle.com>	<533A6165.80704@oracle.com>
	<533A8141.2030608@oracle.com>	<533AB040.6000302@oracle.com>
	<533C3654.7020801@oracle.com>	<533C3974.5080803@oracle.com>
	<533C460D.5020707@oracle.com>	<533C4CDC.3070307@oracle.com>
	<533D68E1.7000007@oracle.com> <533D69D0.6060203@oracle.com>
	<53468A13.2010709@oracle.com>
Message-ID: <1397138459.2748.63.camel@cirrus>

Hi,

On Thu, 2014-04-10 at 14:09 +0200, Erik Helin wrote:
> Ok,
> 
> here is a new patch made by Andrey:
> 
> http://cr.openjdk.java.net/~ehelin/8037924/webrev.13/
> 
> The new patch is now only for JDK-8037924, this patch does not fix 
> JDK-8037925 (a separate patch will be sent out for that).

Some comments:

  - please do not add an -Xloggc command line parameter to the @run tag;
jtreg automatically creates a log file for each test case (and prints
stdout contents to the console with the right switches).

  - suggestion for the summary: "Verify that the heap shrinks after full
GC according to the current values of the Min/MaxHeapFreeRatio flags".

  - there is this "fixup" of the MaxHeapFreeRatio value from 100 to 95.
Could you remove that, it's very brittle: a value of 100 is a valid
input value, and what about values from 96 to 99?

 - typo: "array halfed" -> "array halved"

Other than that it looks okay.

Looking forward to the cleanups.

Thomas




From bengt.rutisson at oracle.com  Thu Apr 10 14:12:57 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 10 Apr 2014 16:12:57 +0200
Subject: RFR(s): 8037112: gc/g1/TestHumongousAllocInitialMark.java caused
	SIGSEGV
In-Reply-To: <53469DCB.8030501@oracle.com>
References: <533D42C0.8060306@oracle.com>
	<3971356.DreSMqAOW1@mgerdin03>	<533EA204.3090607@oracle.com>
	<4063857.h91XTfINnv@mgerdin03>	<1F09BCB8-DE4D-4B97-AB63-06104BC6F0BD@oracle.com>	<5343C10B.7060906@oracle.com>
	<53469DCB.8030501@oracle.com>
Message-ID: <5346A6E9.4010505@oracle.com>


Hi Per,

On 2014-04-10 15:34, Per Liden wrote:
> Bengt reviewed this off-line and had one comment, which was that we 
> should also stop G1's string dedup thread if it's running. The dedup 
> thread is not affected by the original problem so stopping it is 
> strictly not needed, but for completness we still want to do it.
>
> Updated webrev:
> http://cr.openjdk.java.net/~pliden/8037112/webrev.3/
>
> Diff against previous webrev:
> http://cr.openjdk.java.net/~pliden/8037112/webrev.3-diff_2vs3/

Looks good.

Bengt

>
> /Per
>
> On 04/08/2014 11:27 AM, Per Liden wrote:
>> Hi,
>>
>> Here's an updated webrev which fixes the potential dead lock issue I
>> found. I've taken a whole new approach to this problem. Instead of
>> joining/leaving the STS as protection from shutdown I've added a
>> CollectedHeap::stop() which is called in the shutdown paths (in
>> before_exit()) to stop and take down the concurrent threads in a
>> controlled manner. This feel like a much cleaner approach and less error
>> prone as it doesn't require any future log printouts to be guarded by
>> join/leave.
>>
>> Webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.2/
>>
>> cheers,
>> /Per
>>
>> On 04/04/2014 06:14 PM, Per Liden wrote:
>>> Hmm, I discovered a potential dead lock with this approach, so please
>>> hold reviews on this for now.
>>>
>>> Sorry!
>>> /Per
>>>
>>> On 04 Apr 2014, at 14:28, Mikael Gerdin <mikael.gerdin at oracle.com> 
>>> wrote:
>>>
>>>> Per,
>>>>
>>>> On Friday 04 April 2014 14.13.56 Per Liden wrote:
>>>>> Thanks Mikael!
>>>>>
>>>>> Updated webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.1/
>>>>
>>>> Looks good.
>>>> /Mikael
>>>>
>>>>>
>>>>> /Per
>>>>>
>>>>> On 04/03/2014 03:59 PM, Mikael Gerdin wrote:
>>>>>> Hi Per,
>>>>>>
>>>>>> On Thursday 03 April 2014 13.15.12 Per Liden wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Could I please have this bugfix reviewed.
>>>>>>>
>>>>>>> Summary: G1's ConcurrentMarkThread tries to use the gclog_or_tty 
>>>>>>> when
>>>>>>> the JVM is about to exit and the gclog_or_tty instance has been
>>>>>>> destroyed. To prevent this, the ConcurrentMarkThread needs to join
>>>>>>> the
>>>>>>> SuspendibleThreadSet before accessing gclog_or_tty.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8037112
>>>>>>> Webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.0/
>>>>>>
>>>>>> While I realize that this code is still semantically correct I
>>>>>> think it
>>>>>> reads a bit strange. In my mind if we have a
>>>>>> if (...) {} else if (...) {} else {} block the checks in the "if" 
>>>>>> and
>>>>>> "else
>>>>>> if" should usually somehow related checks.
>>>>>>
>>>>>>   282       if (!cm()->has_aborted()) {
>>>>>>   283 g1_policy->record_concurrent_mark_cleanup_completed();
>>>>>>   284       } else if (G1Log::fine()) {
>>>>>>   285 gclog_or_tty->date_stamp(PrintGCDateStamps);
>>>>>>   286         gclog_or_tty->stamp(PrintGCTimeStamps);
>>>>>>   287         gclog_or_tty->print_cr("[GC concurrent-mark-abort]");
>>>>>>   288       }
>>>>>>
>>>>>> I would prefer if it was structured the other way around:
>>>>>> if (cm()->has_aborted()) {
>>>>>>
>>>>>>     if (G1Log::fine()) { ... }
>>>>>>
>>>>>> else {
>>>>>>
>>>>>> g1_policy->record_concurrent_mark_cleanup_completed();
>>>>>>
>>>>>> }
>>>>>>
>>>>>> The rest of the change looks good.
>>>>>>
>>>>>> /Mikael
>>>>>>
>>>>>>> Thanks!
>>>>>>> /Per
>>>>>>>
>>>>>>> Btw, I created a separate RFE, JDK-8039147, to do a little bit of
>>>>>>> cleanup of the SuspendibleThreadSet and how it's used. Will send 
>>>>>>> that
>>>>>>> out as separate review request shortly.
>>>>
>>>
>>
>



From bengt.rutisson at oracle.com  Thu Apr 10 14:14:43 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 10 Apr 2014 16:14:43 +0200
Subject: RFR(M): 8039147: Cleanup SuspendibleThreadSet
In-Reply-To: <53454CF1.1030805@oracle.com>
References: <5343DE47.3080708@oracle.com> <4356100.fWncPPeJ27@mgerdin03>
	<53454CF1.1030805@oracle.com>
Message-ID: <5346A753.5040008@oracle.com>


On 2014-04-09 15:36, Per Liden wrote:
> Hi,
>
> Thanks Mikael, good catch! I found another comment in G1CollectedHeap 
> which I also fixed. The updated webrev also includes the int->uint fix 
> from Thomas comments:
>
> http://cr.openjdk.java.net/~pliden/8039147/webrev.1/
>
> Diff against previous webrev:
>
> http://cr.openjdk.java.net/~pliden/8039147/webrev.1-diff_0vs1/

Still looks good to me.

Bengt

>
> Thanks!
> /Per
>
> On 04/09/2014 02:23 PM, Mikael Gerdin wrote:
>> Per,
>>
>> On Tuesday 08 April 2014 13.32.23 Per Liden wrote:
>>> Hi,
>>>
>>> Here's a attempt to cleanup SuspendibleThreadSet that I'd like to get
>>> some reviews on.
>>>
>>> Webrev: http://cr.openjdk.java.net/~pliden/8039147/webrev.0/
>>
>> The comment at the top of suspendibleThreadSet.hpp mentions
>> safepoint_synchronize() and safepoint_desyncrhonize() but you removed 
>> the
>> prefix from these functions.
>>
>> Otherwise the change looks good.
>>
>> /Mikael
>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039147
>>>
>>> Summary:
>>>
>>> * The function of SuspendibleThreadSet is completely unchanged. Still
>>> does the same thing, same semantics, same users, etc.
>>>
>>> * SuspendibleThreadSet is broken out from concurrentGCThread.hpp/cpp
>>> into separate files. The relation ship with ConcurrentGCThread is a bit
>>> artificial as SuspendibleThreadSet is used by other threads as well 
>>> e.g.
>>> SharedHeap's FlexibleWorkGang.
>>>
>>> * There's currently two ways of using SuspendibleThreadSet, 
>>> depending on
>>> which context you're in; 1) through direct use of the static _sts 
>>> member
>>> in ConcurrentGCThread and 2) via the static stsXXXX() functions exposed
>>> by ConcurrentGCThread. With this patch there's only one interface, 
>>> which
>>> is exposed as static functions on the SuspendibleThreadSet class 
>>> itself.
>>>
>>> * I adjusted the names of some of the fields in SuspendibleThreadSet,
>>> which didn't quite make sense to me. For example, _async is now
>>> _nthreads since it's a counter of number of threads currently in the
>>> thread set.
>>>
>>> * The should_yield() and yield() functions on ConcurrentGCThread (and
>>> it's subclasses) where removed, since they were never used. There was
>>> one exception here though, which was concurrentMarkThread::yield(), but
>>> it just does a direct call to SuspendibleThreadSet's yield() so that's
>>> just an useless indirection.
>>>
>>> * SuspendibleThreadSetJoiner is introduced to replace code like this:
>>>
>>> if (....) {
>>>      _sts.join();
>>>      <do something>
>>>      _sts.leave();
>>> }
>>>
>>> with code like this:
>>>
>>> if (....) {
>>>      SuspendibleThreadSetJoiner sts;
>>>      <do something>
>>> }
>>>
>>> cheers,
>>> /Per
>>
>



From stefan.karlsson at oracle.com  Thu Apr 10 19:25:23 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 10 Apr 2014 21:25:23 +0200
Subject: RFR: 8039957: Replace the last few %p usages with PTR_FORMAT in the
	GC code
Message-ID: <5346F023.3010408@oracle.com>

Please, review this small patch the GC code to replace the last few 
usages of %p with PTR_FORMAT.

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

One of the instances used %p to print a size_t. I decided to cast the 
value to pointer instead of using SIZE_FORMAT. I'll be happy to change 
it to SIZE_FORMAT or SIZE_FORMAT_HEX if anyone cares and has an opinion 
about this unused piece of code. :)

thanks,
StefanK


From jesper.wilhelmsson at oracle.com  Thu Apr 10 22:42:04 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Fri, 11 Apr 2014 00:42:04 +0200
Subject: RFR: 8039957: Replace the last few %p usages with PTR_FORMAT
	in the GC code
In-Reply-To: <5346F023.3010408@oracle.com>
References: <5346F023.3010408@oracle.com>
Message-ID: <53471E3C.10508@oracle.com>

Hi Stefan,

Thanks for cleaning this up!

Not that I care too much about the particular code in question, but I think it 
is weird to print a size_t using PTR_FORMAT. I assume it is done to get a hex 
format of the number, if so I'd prefer a SIZE_FORMAT_HEX if such a format 
specifier exists. (If not, and you intent to add it I would prefer 
SIZE_HEX_FORMAT.) The risk of using PTR_FORMAT is that people might find it and 
think it is the way to get hex formated size_t.

Apart for that it looks good!
/Jesper

Stefan Karlsson skrev 10/4/14 21:25:
> Please, review this small patch the GC code to replace the last few usages of %p
> with PTR_FORMAT.
>
> http://cr.openjdk.java.net/~stefank/8039957/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8039957
>
> One of the instances used %p to print a size_t. I decided to cast the value to
> pointer instead of using SIZE_FORMAT. I'll be happy to change it to SIZE_FORMAT
> or SIZE_FORMAT_HEX if anyone cares and has an opinion about this unused piece of
> code. :)
>
> thanks,
> StefanK


From stefan.karlsson at oracle.com  Fri Apr 11 05:48:26 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 11 Apr 2014 07:48:26 +0200
Subject: RFR: 8039957: Replace the last few %p usages with PTR_FORMAT
	in the GC code
In-Reply-To: <53471E3C.10508@oracle.com>
References: <5346F023.3010408@oracle.com> <53471E3C.10508@oracle.com>
Message-ID: <5347822A.1090308@oracle.com>

On 2014-04-11 00:42, Jesper Wilhelmsson wrote:
> Hi Stefan,
>
> Thanks for cleaning this up!
>
> Not that I care too much about the particular code in question, but I 
> think it is weird to print a size_t using PTR_FORMAT. I assume it is 
> done to get a hex format of the number, if so I'd prefer a 
> SIZE_FORMAT_HEX if such a format specifier exists. (If not, and you 
> intent to add it I would prefer SIZE_HEX_FORMAT.) The risk of using 
> PTR_FORMAT is that people might find it and think it is the way to get 
> hex formated size_t.

Yes, I agree. Unless someone complains I'll change it to SIZE_FORMAT_HEX.

>
> Apart for that it looks good!

Thanks for the review.

StefanK

> /Jesper
>
> Stefan Karlsson skrev 10/4/14 21:25:
>> Please, review this small patch the GC code to replace the last few 
>> usages of %p
>> with PTR_FORMAT.
>>
>> http://cr.openjdk.java.net/~stefank/8039957/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8039957
>>
>> One of the instances used %p to print a size_t. I decided to cast the 
>> value to
>> pointer instead of using SIZE_FORMAT. I'll be happy to change it to 
>> SIZE_FORMAT
>> or SIZE_FORMAT_HEX if anyone cares and has an opinion about this 
>> unused piece of
>> code. :)
>>
>> thanks,
>> StefanK



From thomas.schatzl at oracle.com  Fri Apr 11 07:43:08 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 11 Apr 2014 09:43:08 +0200
Subject: RFR(M): 8039147: Cleanup SuspendibleThreadSet
In-Reply-To: <53454CF1.1030805@oracle.com>
References: <5343DE47.3080708@oracle.com> <4356100.fWncPPeJ27@mgerdin03>
	<53454CF1.1030805@oracle.com>
Message-ID: <1397202188.2710.0.camel@cirrus>

Hi,

On Wed, 2014-04-09 at 15:36 +0200, Per Liden wrote:
> Hi,
> 
> Thanks Mikael, good catch! I found another comment in G1CollectedHeap 
> which I also fixed. The updated webrev also includes the int->uint fix 
> from Thomas comments:
> 
> http://cr.openjdk.java.net/~pliden/8039147/webrev.1/
> 
> Diff against previous webrev:
> 
> http://cr.openjdk.java.net/~pliden/8039147/webrev.1-diff_0vs1/
> 

Looks good. Thanks.

Thomas



From mikael.gerdin at oracle.com  Fri Apr 11 07:57:59 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 11 Apr 2014 09:57:59 +0200
Subject: RFR(s): 8037112: gc/g1/TestHumongousAllocInitialMark.java caused
	SIGSEGV
In-Reply-To: <53469DCB.8030501@oracle.com>
References: <533D42C0.8060306@oracle.com> <5343C10B.7060906@oracle.com>
	<53469DCB.8030501@oracle.com>
Message-ID: <2838015.HQXmQ0ygUm@mgerdin03>

Per,

On Thursday 10 April 2014 15.34.03 Per Liden wrote:
> Bengt reviewed this off-line and had one comment, which was that we
> should also stop G1's string dedup thread if it's running. The dedup
> thread is not affected by the original problem so stopping it is
> strictly not needed, but for completness we still want to do it.
> 
> Updated webrev:
> http://cr.openjdk.java.net/~pliden/8037112/webrev.3/

The change looks good to me.
/Mikael

> 
> Diff against previous webrev:
> http://cr.openjdk.java.net/~pliden/8037112/webrev.3-diff_2vs3/
> 
> /Per
> 
> On 04/08/2014 11:27 AM, Per Liden wrote:
> > Hi,
> > 
> > Here's an updated webrev which fixes the potential dead lock issue I
> > found. I've taken a whole new approach to this problem. Instead of
> > joining/leaving the STS as protection from shutdown I've added a
> > CollectedHeap::stop() which is called in the shutdown paths (in
> > before_exit()) to stop and take down the concurrent threads in a
> > controlled manner. This feel like a much cleaner approach and less error
> > prone as it doesn't require any future log printouts to be guarded by
> > join/leave.
> > 
> > Webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.2/
> > 
> > cheers,
> > /Per
> > 
> > On 04/04/2014 06:14 PM, Per Liden wrote:
> >> Hmm, I discovered a potential dead lock with this approach, so please
> >> hold reviews on this for now.
> >> 
> >> Sorry!
> >> /Per
> >> 
> >> On 04 Apr 2014, at 14:28, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
> >>> Per,
> >>> 
> >>> On Friday 04 April 2014 14.13.56 Per Liden wrote:
> >>>> Thanks Mikael!
> >>>> 
> >>>> Updated webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.1/
> >>> 
> >>> Looks good.
> >>> /Mikael
> >>> 
> >>>> /Per
> >>>> 
> >>>> On 04/03/2014 03:59 PM, Mikael Gerdin wrote:
> >>>>> Hi Per,
> >>>>> 
> >>>>> On Thursday 03 April 2014 13.15.12 Per Liden wrote:
> >>>>>> Hi,
> >>>>>> 
> >>>>>> Could I please have this bugfix reviewed.
> >>>>>> 
> >>>>>> Summary: G1's ConcurrentMarkThread tries to use the gclog_or_tty when
> >>>>>> the JVM is about to exit and the gclog_or_tty instance has been
> >>>>>> destroyed. To prevent this, the ConcurrentMarkThread needs to join
> >>>>>> the
> >>>>>> SuspendibleThreadSet before accessing gclog_or_tty.
> >>>>>> 
> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8037112
> >>>>>> Webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.0/
> >>>>> 
> >>>>> While I realize that this code is still semantically correct I
> >>>>> think it
> >>>>> reads a bit strange. In my mind if we have a
> >>>>> if (...) {} else if (...) {} else {} block the checks in the "if" and
> >>>>> "else
> >>>>> if" should usually somehow related checks.
> >>>>> 
> >>>>>   282       if (!cm()->has_aborted()) {
> >>>>>   283         g1_policy->record_concurrent_mark_cleanup_completed();
> >>>>>   284       } else if (G1Log::fine()) {
> >>>>>   285         gclog_or_tty->date_stamp(PrintGCDateStamps);
> >>>>>   286         gclog_or_tty->stamp(PrintGCTimeStamps);
> >>>>>   287         gclog_or_tty->print_cr("[GC concurrent-mark-abort]");
> >>>>>   288       }
> >>>>> 
> >>>>> I would prefer if it was structured the other way around:
> >>>>> if (cm()->has_aborted()) {
> >>>>> 
> >>>>>     if (G1Log::fine()) { ... }
> >>>>> 
> >>>>> else {
> >>>>> 
> >>>>>     g1_policy->record_concurrent_mark_cleanup_completed();
> >>>>> 
> >>>>> }
> >>>>> 
> >>>>> The rest of the change looks good.
> >>>>> 
> >>>>> /Mikael
> >>>>> 
> >>>>>> Thanks!
> >>>>>> /Per
> >>>>>> 
> >>>>>> Btw, I created a separate RFE, JDK-8039147, to do a little bit of
> >>>>>> cleanup of the SuspendibleThreadSet and how it's used. Will send that
> >>>>>> out as separate review request shortly.



From mikael.gerdin at oracle.com  Fri Apr 11 07:59:03 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 11 Apr 2014 09:59:03 +0200
Subject: RFR(M): 8039147: Cleanup SuspendibleThreadSet
In-Reply-To: <53454CF1.1030805@oracle.com>
References: <5343DE47.3080708@oracle.com> <4356100.fWncPPeJ27@mgerdin03>
	<53454CF1.1030805@oracle.com>
Message-ID: <1542701.vmUZZNLSSc@mgerdin03>

Per,

On Wednesday 09 April 2014 15.36.49 Per Liden wrote:
> Hi,
> 
> Thanks Mikael, good catch! I found another comment in G1CollectedHeap
> which I also fixed. The updated webrev also includes the int->uint fix
> from Thomas comments:
> 
> http://cr.openjdk.java.net/~pliden/8039147/webrev.1/

Looks good.
/Mikael

> 
> Diff against previous webrev:
> 
> http://cr.openjdk.java.net/~pliden/8039147/webrev.1-diff_0vs1/
> 
> Thanks!
> /Per
> 
> On 04/09/2014 02:23 PM, Mikael Gerdin wrote:
> > Per,
> > 
> > On Tuesday 08 April 2014 13.32.23 Per Liden wrote:
> >> Hi,
> >> 
> >> Here's a attempt to cleanup SuspendibleThreadSet that I'd like to get
> >> some reviews on.
> >> 
> >> Webrev: http://cr.openjdk.java.net/~pliden/8039147/webrev.0/
> > 
> > The comment at the top of suspendibleThreadSet.hpp mentions
> > safepoint_synchronize() and safepoint_desyncrhonize() but you removed the
> > prefix from these functions.
> > 
> > Otherwise the change looks good.
> > 
> > /Mikael
> > 
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8039147
> >> 
> >> Summary:
> >> 
> >> * The function of SuspendibleThreadSet is completely unchanged. Still
> >> does the same thing, same semantics, same users, etc.
> >> 
> >> * SuspendibleThreadSet is broken out from concurrentGCThread.hpp/cpp
> >> into separate files. The relation ship with ConcurrentGCThread is a bit
> >> artificial as SuspendibleThreadSet is used by other threads as well e.g.
> >> SharedHeap's FlexibleWorkGang.
> >> 
> >> * There's currently two ways of using SuspendibleThreadSet, depending on
> >> which context you're in; 1) through direct use of the static _sts member
> >> in ConcurrentGCThread and 2) via the static stsXXXX() functions exposed
> >> by ConcurrentGCThread. With this patch there's only one interface, which
> >> is exposed as static functions on the SuspendibleThreadSet class itself.
> >> 
> >> * I adjusted the names of some of the fields in SuspendibleThreadSet,
> >> which didn't quite make sense to me. For example, _async is now
> >> _nthreads since it's a counter of number of threads currently in the
> >> thread set.
> >> 
> >> * The should_yield() and yield() functions on ConcurrentGCThread (and
> >> it's subclasses) where removed, since they were never used. There was
> >> one exception here though, which was concurrentMarkThread::yield(), but
> >> it just does a direct call to SuspendibleThreadSet's yield() so that's
> >> just an useless indirection.
> >> 
> >> * SuspendibleThreadSetJoiner is introduced to replace code like this:
> >> 
> >> if (....) {
> >> 
> >>      _sts.join();
> >>      <do something>
> >>      _sts.leave();
> >> 
> >> }
> >> 
> >> with code like this:
> >> 
> >> if (....) {
> >> 
> >>      SuspendibleThreadSetJoiner sts;
> >>      <do something>
> >> 
> >> }
> >> 
> >> cheers,
> >> /Per



From stefan.johansson at oracle.com  Fri Apr 11 08:12:50 2014
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Fri, 11 Apr 2014 10:12:50 +0200
Subject: RFR: 8039957: Replace the last few %p usages with PTR_FORMAT
	in the GC code
In-Reply-To: <5347822A.1090308@oracle.com>
References: <5346F023.3010408@oracle.com> <53471E3C.10508@oracle.com>
	<5347822A.1090308@oracle.com>
Message-ID: <5347A402.9010601@oracle.com>

Looks good Stefan,

On 2014-04-11 07:48, Stefan Karlsson wrote:
> On 2014-04-11 00:42, Jesper Wilhelmsson wrote:
>> Hi Stefan,
>>
>> Thanks for cleaning this up!
>>
>> Not that I care too much about the particular code in question, but I 
>> think it is weird to print a size_t using PTR_FORMAT. I assume it is 
>> done to get a hex format of the number, if so I'd prefer a 
>> SIZE_FORMAT_HEX if such a format specifier exists. (If not, and you 
>> intent to add it I would prefer SIZE_HEX_FORMAT.) The risk of using 
>> PTR_FORMAT is that people might find it and think it is the way to 
>> get hex formated size_t.
>
> Yes, I agree. Unless someone complains I'll change it to SIZE_FORMAT_HEX.
+1

StefanJ
>
>>
>> Apart for that it looks good!
>
> Thanks for the review.
>
> StefanK
>
>> /Jesper
>>
>> Stefan Karlsson skrev 10/4/14 21:25:
>>> Please, review this small patch the GC code to replace the last few 
>>> usages of %p
>>> with PTR_FORMAT.
>>>
>>> http://cr.openjdk.java.net/~stefank/8039957/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8039957
>>>
>>> One of the instances used %p to print a size_t. I decided to cast 
>>> the value to
>>> pointer instead of using SIZE_FORMAT. I'll be happy to change it to 
>>> SIZE_FORMAT
>>> or SIZE_FORMAT_HEX if anyone cares and has an opinion about this 
>>> unused piece of
>>> code. :)
>>>
>>> thanks,
>>> StefanK
>



From per.liden at oracle.com  Fri Apr 11 08:29:56 2014
From: per.liden at oracle.com (Per Liden)
Date: Fri, 11 Apr 2014 10:29:56 +0200
Subject: RFR(M): 8039147: Cleanup SuspendibleThreadSet
In-Reply-To: <1542701.vmUZZNLSSc@mgerdin03>
References: <5343DE47.3080708@oracle.com> <4356100.fWncPPeJ27@mgerdin03>
	<53454CF1.1030805@oracle.com> <1542701.vmUZZNLSSc@mgerdin03>
Message-ID: <5347A804.7080601@oracle.com>

Thanks Bengt, Thomas and Mikael!

/Per

On 04/11/2014 09:59 AM, Mikael Gerdin wrote:
> Per,
>
> On Wednesday 09 April 2014 15.36.49 Per Liden wrote:
>> Hi,
>>
>> Thanks Mikael, good catch! I found another comment in G1CollectedHeap
>> which I also fixed. The updated webrev also includes the int->uint fix
>> from Thomas comments:
>>
>> http://cr.openjdk.java.net/~pliden/8039147/webrev.1/
>
> Looks good.
> /Mikael
>
>>
>> Diff against previous webrev:
>>
>> http://cr.openjdk.java.net/~pliden/8039147/webrev.1-diff_0vs1/
>>
>> Thanks!
>> /Per
>>
>> On 04/09/2014 02:23 PM, Mikael Gerdin wrote:
>>> Per,
>>>
>>> On Tuesday 08 April 2014 13.32.23 Per Liden wrote:
>>>> Hi,
>>>>
>>>> Here's a attempt to cleanup SuspendibleThreadSet that I'd like to get
>>>> some reviews on.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~pliden/8039147/webrev.0/
>>>
>>> The comment at the top of suspendibleThreadSet.hpp mentions
>>> safepoint_synchronize() and safepoint_desyncrhonize() but you removed the
>>> prefix from these functions.
>>>
>>> Otherwise the change looks good.
>>>
>>> /Mikael
>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039147
>>>>
>>>> Summary:
>>>>
>>>> * The function of SuspendibleThreadSet is completely unchanged. Still
>>>> does the same thing, same semantics, same users, etc.
>>>>
>>>> * SuspendibleThreadSet is broken out from concurrentGCThread.hpp/cpp
>>>> into separate files. The relation ship with ConcurrentGCThread is a bit
>>>> artificial as SuspendibleThreadSet is used by other threads as well e.g.
>>>> SharedHeap's FlexibleWorkGang.
>>>>
>>>> * There's currently two ways of using SuspendibleThreadSet, depending on
>>>> which context you're in; 1) through direct use of the static _sts member
>>>> in ConcurrentGCThread and 2) via the static stsXXXX() functions exposed
>>>> by ConcurrentGCThread. With this patch there's only one interface, which
>>>> is exposed as static functions on the SuspendibleThreadSet class itself.
>>>>
>>>> * I adjusted the names of some of the fields in SuspendibleThreadSet,
>>>> which didn't quite make sense to me. For example, _async is now
>>>> _nthreads since it's a counter of number of threads currently in the
>>>> thread set.
>>>>
>>>> * The should_yield() and yield() functions on ConcurrentGCThread (and
>>>> it's subclasses) where removed, since they were never used. There was
>>>> one exception here though, which was concurrentMarkThread::yield(), but
>>>> it just does a direct call to SuspendibleThreadSet's yield() so that's
>>>> just an useless indirection.
>>>>
>>>> * SuspendibleThreadSetJoiner is introduced to replace code like this:
>>>>
>>>> if (....) {
>>>>
>>>>       _sts.join();
>>>>       <do something>
>>>>       _sts.leave();
>>>>
>>>> }
>>>>
>>>> with code like this:
>>>>
>>>> if (....) {
>>>>
>>>>       SuspendibleThreadSetJoiner sts;
>>>>       <do something>
>>>>
>>>> }
>>>>
>>>> cheers,
>>>> /Per
>



From per.liden at oracle.com  Fri Apr 11 08:30:59 2014
From: per.liden at oracle.com (Per Liden)
Date: Fri, 11 Apr 2014 10:30:59 +0200
Subject: RFR(s): 8037112: gc/g1/TestHumongousAllocInitialMark.java caused
	SIGSEGV
In-Reply-To: <2838015.HQXmQ0ygUm@mgerdin03>
References: <533D42C0.8060306@oracle.com> <5343C10B.7060906@oracle.com>
	<53469DCB.8030501@oracle.com> <2838015.HQXmQ0ygUm@mgerdin03>
Message-ID: <5347A843.3050501@oracle.com>

Thanks Bengt, thanks Mikael!

/Per

On 04/11/2014 09:57 AM, Mikael Gerdin wrote:
> Per,
>
> On Thursday 10 April 2014 15.34.03 Per Liden wrote:
>> Bengt reviewed this off-line and had one comment, which was that we
>> should also stop G1's string dedup thread if it's running. The dedup
>> thread is not affected by the original problem so stopping it is
>> strictly not needed, but for completness we still want to do it.
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~pliden/8037112/webrev.3/
>
> The change looks good to me.
> /Mikael
>
>>
>> Diff against previous webrev:
>> http://cr.openjdk.java.net/~pliden/8037112/webrev.3-diff_2vs3/
>>
>> /Per
>>
>> On 04/08/2014 11:27 AM, Per Liden wrote:
>>> Hi,
>>>
>>> Here's an updated webrev which fixes the potential dead lock issue I
>>> found. I've taken a whole new approach to this problem. Instead of
>>> joining/leaving the STS as protection from shutdown I've added a
>>> CollectedHeap::stop() which is called in the shutdown paths (in
>>> before_exit()) to stop and take down the concurrent threads in a
>>> controlled manner. This feel like a much cleaner approach and less error
>>> prone as it doesn't require any future log printouts to be guarded by
>>> join/leave.
>>>
>>> Webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.2/
>>>
>>> cheers,
>>> /Per
>>>
>>> On 04/04/2014 06:14 PM, Per Liden wrote:
>>>> Hmm, I discovered a potential dead lock with this approach, so please
>>>> hold reviews on this for now.
>>>>
>>>> Sorry!
>>>> /Per
>>>>
>>>> On 04 Apr 2014, at 14:28, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
>>>>> Per,
>>>>>
>>>>> On Friday 04 April 2014 14.13.56 Per Liden wrote:
>>>>>> Thanks Mikael!
>>>>>>
>>>>>> Updated webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.1/
>>>>>
>>>>> Looks good.
>>>>> /Mikael
>>>>>
>>>>>> /Per
>>>>>>
>>>>>> On 04/03/2014 03:59 PM, Mikael Gerdin wrote:
>>>>>>> Hi Per,
>>>>>>>
>>>>>>> On Thursday 03 April 2014 13.15.12 Per Liden wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Could I please have this bugfix reviewed.
>>>>>>>>
>>>>>>>> Summary: G1's ConcurrentMarkThread tries to use the gclog_or_tty when
>>>>>>>> the JVM is about to exit and the gclog_or_tty instance has been
>>>>>>>> destroyed. To prevent this, the ConcurrentMarkThread needs to join
>>>>>>>> the
>>>>>>>> SuspendibleThreadSet before accessing gclog_or_tty.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8037112
>>>>>>>> Webrev: http://cr.openjdk.java.net/~pliden/8037112/webrev.0/
>>>>>>>
>>>>>>> While I realize that this code is still semantically correct I
>>>>>>> think it
>>>>>>> reads a bit strange. In my mind if we have a
>>>>>>> if (...) {} else if (...) {} else {} block the checks in the "if" and
>>>>>>> "else
>>>>>>> if" should usually somehow related checks.
>>>>>>>
>>>>>>>    282       if (!cm()->has_aborted()) {
>>>>>>>    283         g1_policy->record_concurrent_mark_cleanup_completed();
>>>>>>>    284       } else if (G1Log::fine()) {
>>>>>>>    285         gclog_or_tty->date_stamp(PrintGCDateStamps);
>>>>>>>    286         gclog_or_tty->stamp(PrintGCTimeStamps);
>>>>>>>    287         gclog_or_tty->print_cr("[GC concurrent-mark-abort]");
>>>>>>>    288       }
>>>>>>>
>>>>>>> I would prefer if it was structured the other way around:
>>>>>>> if (cm()->has_aborted()) {
>>>>>>>
>>>>>>>      if (G1Log::fine()) { ... }
>>>>>>>
>>>>>>> else {
>>>>>>>
>>>>>>>      g1_policy->record_concurrent_mark_cleanup_completed();
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> The rest of the change looks good.
>>>>>>>
>>>>>>> /Mikael
>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> /Per
>>>>>>>>
>>>>>>>> Btw, I created a separate RFE, JDK-8039147, to do a little bit of
>>>>>>>> cleanup of the SuspendibleThreadSet and how it's used. Will send that
>>>>>>>> out as separate review request shortly.
>



From andrey.x.zakharov at oracle.com  Fri Apr 11 09:18:00 2014
From: andrey.x.zakharov at oracle.com (Andrey Zakharov)
Date: Fri, 11 Apr 2014 13:18:00 +0400
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <53468AD3.8020908@oracle.com>
References: <5332FA20.5070607@oracle.com>	<53341CC0.8090509@oracle.com>	<5334A639.6050205@oracle.com>	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>	<53394053.2070502@oracle.com>	<533955B0.7000601@oracle.com>	<533A6165.80704@oracle.com>	<533A8141.2030608@oracle.com>	<533AB040.6000302@oracle.com>	<533C3654.7020801@oracle.com>	<533C3974.5080803@oracle.com>	<533C460D.5020707@oracle.com>	<533C4CDC.3070307@oracle.com>	<533D68E1.7000007@oracle.com>	<533D69D0.6060203@oracle.com>
	<53468A13.2010709@oracle.com> <53468AD3.8020908@oracle.com>
Message-ID: <5347B348.3040704@oracle.com>

Hi.
Here is updated webrevs
http://cr.openjdk.java.net/~iignatyev/anzakharov/8037924/webrev.14/ 
<http://cr.openjdk.java.net/%7Eiignatyev/anzakharov/8037924/webrev.14/>
http://cr.openjdk.java.net/~iignatyev/anzakharov/8037925/webrev.07/ 
<http://cr.openjdk.java.net/%7Eiignatyev/anzakharov/8037925/webrev.07/>

Thanks.


On 10.04.2014 16:13, Erik Helin wrote:
> Given that the issue for cleaning up these tests exist, is assigned 
> and is already being worked on, I think this patch is ok.
>
> Erik
>
> On 2014-04-10 14:09, Erik Helin wrote:
>> Ok,
>>
>> here is a new patch made by Andrey:
>>
>> http://cr.openjdk.java.net/~ehelin/8037924/webrev.13/
>>
>> The new patch is now only for JDK-8037924, this patch does not fix
>> JDK-8037925 (a separate patch will be sent out for that).
>>
>> This patch makes no changes to the testlibrary, it only introduces the
>> new test. Please note that there already an issue filed for cleaning up
>> some of the duplication in these tests:
>> https://bugs.openjdk.java.net/browse/JDK-8039489
>>
>> Thanks,
>> Erik
>>
>> On 2014-04-03 16:01, Erik Helin wrote:
>>> Andrey, Igor,
>>>
>>> maybe we should have a chat session on IM where can discuss this?
>>>
>>> Thanks,
>>> Erik
>>>
>>> On 2014-04-03 15:57, Erik Helin wrote:
>>>> Andrey,
>>>>
>>>> is all the changes in this webrev part of the patch? The files in this
>>>> change looks very similar to the files in
>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.04/ ?
>>>>
>>>> Thanks,
>>>> Erik
>>>>
>>>> On 2014-04-02 19:46, Jesper Wilhelmsson wrote:
>>>>> New webrev is uploaded here:
>>>>>
>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.12/
>>>>>
>>>>> /Jesper
>>>>>
>>>>> Andrey Zakharov skrev 2/4/14 19:17:
>>>>>> Hi, here is not uploaded yet webrev with totally reverted 
>>>>>> inheritance.
>>>>>> Jesper, can you please upload to your space.
>>>>>> Thanks.
>>>>>>
>>>>>>
>>>>>> On 02.04.2014 20:23, Igor Ignatyev wrote:
>>>>>>> Andrey,
>>>>>>>
>>>>>>> Why do test classes extend TestShrinkHeap?
>>>>>>>
>>>>>>> Igor
>>>>>>>
>>>>>>> On 04/02/2014 08:09 PM, Andrey Zakharov wrote:
>>>>>>>> Here is version without hidden testflow:
>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.11/
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> On 01.04.2014 16:25, Jesper Wilhelmsson wrote:
>>>>>>>>> Uploaded:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.10/
>>>>>>>>>
>>>>>>>>> In general  would agree regarding avoiding duplicated code, but
>>>>>>>>> when
>>>>>>>>> it comes to the control flow I agree with Erik. More hard to read
>>>>>>>>> code
>>>>>>>>> leads to harder maintenance than duplicating a few lines of code.
>>>>>>>>> /Jesper
>>>>>>>>>
>>>>>>>>> Andrey Zakharov skrev 1/4/14 11:05:
>>>>>>>>>> Hi, Erik. Thanks for comments.
>>>>>>>>>>
>>>>>>>>>> On 01.04.2014 10:49, Erik Helin wrote:
>>>>>>>>>>> Andrey,
>>>>>>>>>>>
>>>>>>>>>>> a couple of comments:
>>>>>>>>>>> - We do not use the @author tag in the tests
>>>>>>>>>>>   (if you've seen other tests have the @author tag, then 
>>>>>>>>>>> that is
>>>>>>>>>>> a bug)
>>>>>>>>>> removed
>>>>>>>>>>> - I'm not a big fan of using inheritance for sharing code 
>>>>>>>>>>> between
>>>>>>>>>>>   tests because it makes it very hard to open a test, e.g.
>>>>>>>>>>>   TestHumongousShrinkHeap.java, and see what it does.
>>>>>>>>>> Agreed, I'm too. But doubled code leads to harder maintenance.
>>>>>>>>>>>
>>>>>>>>>>>   The code you share in TestShrinkHeap is basically the 
>>>>>>>>>>> check and
>>>>>>>>>>> the
>>>>>>>>>>>   control flow of the tests. I would prefer if you could 
>>>>>>>>>>> move the
>>>>>>>>>>>   control flow (System.gc(), sample, eat, sample, free, check
>>>>>>>>>>> samples)
>>>>>>>>>>>   into the tests and then write helper functions for retrieving
>>>>>>>>>>> the
>>>>>>>>>>>   flag values.
>>>>>>>>>>>
>>>>>>>>>>>   As for the check, please use the assertions in
>>>>>>>>>>> testlibrary/com/oracle/java/testlibrary/Asserts.java instead of
>>>>>>>>>>>   throwing a RuntimeException.
>>>>>>>>>> Good point, changed.
>>>>>>>>>> Jesper, can we upload webrev.10 from attachment? Thanks.
>>>>>>>>>> I'm still need GC reviewers to approve push.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Erik
>>>>>>>>>>>
>>>>>>>>>>> On 2014-03-31 13:46, Jesper Wilhelmsson wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> New webrev uploaded.
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.09/
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not a Reviewer either so if you got Igor's blessing
>>>>>>>>>>>> already, my
>>>>>>>>>>>> review won't be enough to push unfortunately.
>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>
>>>>>>>>>>>> Andrey Zakharov skrev 31/3/14 12:15:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>> Jepser, here is updated webrev.09
>>>>>>>>>>>>> Thomas, Jesper can you review it as well?
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 31.03.2014 13:16, Igor Ignatyev wrote:
>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. TEST.groups:
>>>>>>>>>>>>>> please update copyright year:
>>>>>>>>>>>>>>>   2 # Copyright (c) 2013, Oracle and/or its affiliates. All
>>>>>>>>>>>>>>> rights
>>>>>>>>>>>>>>> reserved.
>>>>>>>>>>>>>> should be
>>>>>>>>>>>>>>>   2 # Copyright (c) 2013, 2014, Oracle and/or its 
>>>>>>>>>>>>>>> affiliates.
>>>>>>>>>>>>>>> All
>>>>>>>>>>>>>>> rights
>>>>>>>>>>>>>>> reserved.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. TestShrinkHeap.java
>>>>>>>>>>>>>>>   22  */
>>>>>>>>>>>>>>>   23 package com.oracle.java.testlibrary.gc;
>>>>>>>>>>>>>> add empty line between 22 and 23 as you do in all other 
>>>>>>>>>>>>>> files,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> otherwise it looks good to me.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Keep in mind I'm not a Reviewer, but I can be mentioned in
>>>>>>>>>>>>>> 'Reviewed-by'
>>>>>>>>>>>>>> section )
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 03/31/2014 10:33 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>> Hi, team
>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 30.03.2014 22:06, Jesper Wilhelmsson wrote:
>>>>>>>>>>>>>>>> Webrev uploaded:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.08/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>>>> Thank you, Jesper.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Andrey Zakharov skrev 30/3/14 10:03:
>>>>>>>>>>>>>>>>> Hi! Here is webrev.08,
>>>>>>>>>>>>>>>>> Jesper, can you upload it? Thanks!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Igor, thanks for well detailed review!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 30.03.2014 02:33, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1. both tests:
>>>>>>>>>>>>>>>>>>>   48 public void eat() {
>>>>>>>>>>>>>>>>>>> 61     public void free() {
>>>>>>>>>>>>>>>>>> change visibility of concrete methods to protected
>>>>>>>>>>>>>>>>>> 2. TestHumongousShrinkHeap
>>>>>>>>>>>>>>>>>>>  32  */
>>>>>>>>>>>>>>>>>>>  33 import
>>>>>>>>>>>>>>>>>>> com.oracle.java.testlibrary.gc.MemoryUsagePrinter;
>>>>>>>>>>>>>>>>>> add empty line between these lines or remove empty line
>>>>>>>>>>>>>>>>>> #32 in
>>>>>>>>>>>>>>>>>> TestDynShrinkHeap
>>>>>>>>>>>>>>>>>>>  62 //do not free last one list
>>>>>>>>>>>>>>>>>> space after '//'
>>>>>>>>>>>>>>>>>> 3. both tests:
>>>>>>>>>>>>>>>>>>>   26  * @bug 8037924
>>>>>>>>>>>>>>>>>>>   26  * @bug 8037925
>>>>>>>>>>>>>>>>>> after @bug you should specify product bug ids which 
>>>>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>>>> tested by
>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> test. I guess 8016479 instead of 8037924, and
>>>>>>>>>>>>>>>>>> 8036025/8037925.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> otherwise it looks good, thank you for your work and
>>>>>>>>>>>>>>>>>> patience )
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 03/30/2014 02:21 AM, Jesper Wilhelmsson wrote:
>>>>>>>>>>>>>>>>>>> Hi, New webrev in place:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.07/
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Andrey Zakharov skrev 29/3/14 20:57:
>>>>>>>>>>>>>>>>>>>> Hi, here updated webrev.
>>>>>>>>>>>>>>>>>>>> Jesper, can you, please, upload it to your webspace.
>>>>>>>>>>>>>>>>>>>> Igor, please, see comment below, everything
>>>>>>>>>>>>>>>>>>>> uncommented is
>>>>>>>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 29.03.2014 20:08, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>> why isn't 'TestDynShrinkHeap.gc()'
>>>>>>>>>>>>>>>>>>>>> 'TestShrinkHeap.gc()'?
>>>>>>>>>>>>>>>>>>>> I cut this out.
>>>>>>>>>>>>>>>>>>>>> 5. if you need assured fullGC, we have WhiteBox 
>>>>>>>>>>>>>>>>>>>>> API for
>>>>>>>>>>>>>>>>>>>>> it --
>>>>>>>>>>>>>>>>>>>>> s.h.WhiteBox.fullGC()
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Not sure is it applicable for me, because every 
>>>>>>>>>>>>>>>>>>>> time in
>>>>>>>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>>>>>> descriptions I see "System.gc()", so... let it be.
>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 03/29/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>> Hi, team!
>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.06/ 
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> bug: 
>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924
>>>>>>>>>>>>>>>>>>>>>> bug: 
>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037925
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 29.03.2014 16:19, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>> Hi, Igor, here is just non-uploaded attachment to
>>>>>>>>>>>>>>>>>>>>>>> review. It
>>>>>>>>>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>>>>>>>>>> upload later.
>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 29.03.2014 12:10, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>>>  45 public static byte[] temp;
>>>>>>>>>>>>>>>>>>>>>>>> unused field
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> it looks like 'g1/TestHumongousShrinkHeap.java' 
>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>> 'parallelScavenge/TestDynShrinkHeap.java' should
>>>>>>>>>>>>>>>>>>>>>>>> have one
>>>>>>>>>>>>>>>>>>>>>>>> super
>>>>>>>>>>>>>>>>>>>>>>>> class,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> abstract class TestDyn {
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> protected static final String
>>>>>>>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>>>>>>> "MinHeapFreeRatio";
>>>>>>>>>>>>>>>>>>>>>>>> protected static final String
>>>>>>>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME =
>>>>>>>>>>>>>>>>>>>>>>>> "MaxHeapFreeRatio";
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> protected abstract void eat();
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> protected abstract void free();
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> public final void test() {
>>>>>>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("init");
>>>>>>>>>>>>>>>>>>>>>>>>   eat();
>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("eaten");
>>>>>>>>>>>>>>>>>>>>>>>>   MemoryUsage muFull =
>>>>>>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage(); 
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>   free();
>>>>>>>>>>>>>>>>>>>>>>>>   MemoryUsage muFree =
>>>>>>>>>>>>>>>>>>>>>>>> ManagementFactory.getMemoryMXBean().getHeapMemoryUsage(); 
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>   if (!(muFree.getCommitted() <
>>>>>>>>>>>>>>>>>>>>>>>> muFull.getCommitted())) {
>>>>>>>>>>>>>>>>>>>>>>>>     throw new RuntimeException(
>>>>>>>>>>>>>>>>>>>>>>>> String.format("committed free heap size is not
>>>>>>>>>>>>>>>>>>>>>>>> less than
>>>>>>>>>>>>>>>>>>>>>>>> committed full heap size, heap hasn't been
>>>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s =
>>>>>>>>>>>>>>>>>>>>>>>> %s%n%s =
>>>>>>>>>>>>>>>>>>>>>>>> %s",
>>>>>>>>>>>>>>>>>>>>>>>> MIN_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MIN_FREE_RATIO_FLAG_NAME).getValue(), 
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> MAX_FREE_RATIO_FLAG_NAME,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption(MAX_FREE_RATIO_FLAG_NAME).getValue() 
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>               )
>>>>>>>>>>>>>>>>>>>>>>>>       );
>>>>>>>>>>>>>>>>>>>>>>>>   }
>>>>>>>>>>>>>>>>>>>>>>>>   gc();
>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("done");
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> public static void gc() {
>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("before full
>>>>>>>>>>>>>>>>>>>>>>>> GC");
>>>>>>>>>>>>>>>>>>>>>>>>   System.gc();
>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter.printMemoryUsage("after full
>>>>>>>>>>>>>>>>>>>>>>>> GC");
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 03/29/2014 10:59 AM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.05/ 
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Any comments are welcome.
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 19:28, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 06:06 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 17:48, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please remove class 'Labels', it's unnecessary
>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>>>>>>>>> decrease
>>>>>>>>>>>>>>>>>>>>>>>>>>>> readability.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 26 * @key gc
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> why do you need this?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hm, used as common practice.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> if you don't understand meaning of '@key gc',
>>>>>>>>>>>>>>>>>>>>>>>>>>>> please don't
>>>>>>>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>>>>>>>>> I think that this is used for test execution 
>>>>>>>>>>>>>>>>>>>>>>>>>>> - to
>>>>>>>>>>>>>>>>>>>>>>>>>>> execute
>>>>>>>>>>>>>>>>>>>>>>>>>>> all test
>>>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>>> relates to "gc" for example.
>>>>>>>>>>>>>>>>>>>>>>>>>> All test related to "gc" are located in
>>>>>>>>>>>>>>>>>>>>>>>>>> test/gc, so
>>>>>>>>>>>>>>>>>>>>>>>>>> we don't
>>>>>>>>>>>>>>>>>>>>>>>>>> need it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> otherwise it looks good.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 03/28/2014 05:37 PM, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, here is updated webrev:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.04/ 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 28.03.2014 02:29, Igor Ignatyev wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrey,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you've placed the wrong link, the correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> one is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev.02/. 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And as I said in 8037925:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You don't need to use enum here and string
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (Labels.*) in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap. I've mistakenly think 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> String argument to change its own behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> extra
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MemoryUsagePrinter:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 44 float freeratio = 1f - (float)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getUsed() /
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> memusage.getCommitted();
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'd prefer '1.0f', but it's only my fad, 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TestDynShrinkHeap:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 96 StringBuilder strb = new
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> StringBuilder("committed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> heap size under pressure is not less than
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> committed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> full heap
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> size,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> heap hasn't been shrunk?");
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   97
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator")); 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   98 strb.append(MinFreeRatioFlagName + " =
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> " +
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> minHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   99
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strb.append(System.getProperty("line.separator")); 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  100 strb.append(MaxFreeRatioFlagName + " =
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> " +
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maxHeapFreeValue);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  101 throw new
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(strb.toString());
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it can be replaced by:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  throw new
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> RuntimeException(String.format("committed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> heap size
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pressure is not less than committed full 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> heap
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> size, heap
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hasn't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> shrunk?%n%s=%d%n%s=%n",MinFreeRatioFlagName,minHeapFreeValue,MaxFreeRatioFlagName,maxHeapFreeValue)); 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but it's also not necessary.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 03/27/2014 04:42 PM, Andrey Zakharov 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Here is updated webrev with string 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> constants:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037925/webrev.02/ 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 26.03.2014 20:02, Andrey Zakharov wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Test to check that ParallelGC respect
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dynamic
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> change of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MaxFreeRatio
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and shrinks heap.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jwilhelm/8037924/webrev/ 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bug:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8037924 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>

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

From andrey.x.zakharov at oracle.com  Fri Apr 11 09:18:44 2014
From: andrey.x.zakharov at oracle.com (Andrey Zakharov)
Date: Fri, 11 Apr 2014 13:18:44 +0400
Subject: RFR 8037925: CMM Testing: an allocated humongous object at the
	end of the heap should not prevents shrinking the heap
In-Reply-To: <53468DBB.3050504@oracle.com>
References: <53332456.5060407@oracle.com>	<533326B8.4020407@oracle.com>	<53341B70.8070603@oracle.com>	<5334A527.4090209@oracle.com>	<53357A9E.4000505@oracle.com>	<53358125.8020803@oracle.com>	<53367041.5060203@oracle.com>	<533B2DC9.5010903@oracle.com>	<533C429A.2080005@oracle.com>
	<53468CFE.2040800@oracle.com> <53468DBB.3050504@oracle.com>
Message-ID: <5347B374.8070905@oracle.com>

Hi.
Here is updated webrevs
http://cr.openjdk.java.net/~iignatyev/anzakharov/8037924/webrev.14/ 
<http://cr.openjdk.java.net/%7Eiignatyev/anzakharov/8037924/webrev.14/>
http://cr.openjdk.java.net/~iignatyev/anzakharov/8037925/webrev.07/ 
<http://cr.openjdk.java.net/%7Eiignatyev/anzakharov/8037925/webrev.07/>

Thanks.

On 10.04.2014 16:25, Erik Helin wrote:
> Given that the cleanup issue exists and is being worked on, I'm fine 
> with this patch.
>
> Thanks,
> Erik
>
> On 2014-04-10 14:22, Erik Helin wrote:
>> Andrey has updated the patch:
>>
>> http://cr.openjdk.java.net/~ehelin/8037925/webrev.06/
>>
>> The new patch does no longer change the testlibrary. There is already an
>> issue filed for fixing these tests and the previous testlibrary changes:
>> https://bugs.openjdk.java.net/browse/JDK-8039489.
>>
>> Thanks,
>> Erik
>>
>> On 2014-04-02 19:02, Andrey Zakharov wrote:
>>> Hi, Jon
>>> On 02.04.2014 01:21, Jon Masamitsu wrote:
>>>> Seems like an out-of-memory (OOME) can be thrown here (or anywhere 
>>>> below
>>>> this block of code).  Will an OOME be considered a pass, fail or
>>>> test-not-run?
>>> Yes, its really an question for me, from one point of view, we should
>>> catch OOM and move forward to exit(0),
>>> from another point - such things should be handled by test harness. 
>>> Test
>>> should have some @tag about 1G memory its used and harness should skip
>>> test and notify about this if machine memory is below needed.
>>> Maybe there is another right way.
>>>

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

From thomas.schatzl at oracle.com  Fri Apr 11 10:05:51 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 11 Apr 2014 12:05:51 +0200
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags
	allows to shrink the heap when using ParallelGC
In-Reply-To: <5347B348.3040704@oracle.com>
References: <5332FA20.5070607@oracle.com>	<53341CC0.8090509@oracle.com>
	<5334A639.6050205@oracle.com>	<53357B26.4080707@oracle.com>
	<53357DAC.70607@oracle.com>	<533581D3.3010808@oracle.com>
	<53359517.3070305@oracle.com>	<53366F67.4080409@oracle.com>
	<5336800A.2090506@oracle.com>	<5336BA50.30700@oracle.com>
	<5336E8AE.4030302@oracle.com>	<5336EFF4.1070605@oracle.com>
	<533725B7.8090209@oracle.com>	<53374769.70909@oracle.com>
	<53374A1C.9070509@oracle.com>	<5337CFE1.5040603@oracle.com>
	<53385D10.40506@oracle.com>	<53390C1F.9030400@oracle.com>
	<53393256.8090406@oracle.com>	<53394053.2070502@oracle.com>
	<533955B0.7000601@oracle.com>	<533A6165.80704@oracle.com>
	<533A8141.2030608@oracle.com>	<533AB040.6000302@oracle.com>
	<533C3654.7020801@oracle.com>	<533C3974.5080803@oracle.com>
	<533C460D.5020707@oracle.com>	<533C4CDC.3070307@oracle.com>
	<533D68E1.7000007@oracle.com>	<533D69D0.6060203@oracle.com>
	<53468A13.2010709@oracle.com> <53468AD3.8020908@oracle.com>
	<5347B348.3040704@oracle.com>
Message-ID: <1397210751.2710.25.camel@cirrus>

Hi,

On Fri, 2014-04-11 at 13:18 +0400, Andrey Zakharov wrote:
> Hi.
> Here is updated webrevs
> http://cr.openjdk.java.net/~iignatyev/anzakharov/8037924/webrev.14/

Good.

> http://cr.openjdk.java.net/~iignatyev/anzakharov/8037925/webrev.07/

Could you fix the summary for this change as well? I do not need a
re-review for this change.

Other than that, looks good.

Thanks,
  Thomas




From thomas.schatzl at oracle.com  Fri Apr 11 10:37:58 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 11 Apr 2014 12:37:58 +0200
Subject: RFR (S): JDK-8028710: G1 does not retire allocation buffers after
	reference processing work
Message-ID: <1397212678.2710.40.camel@cirrus>

Hi all,

  can I have some reviews for the following bugfix?

When doing parallel reference processing, its allocation buffers are not
retired. This causes problems with the not-retired buffer being wrongly
formatted (however I could not trigger a bug because of that since that
area does not contain live objects, and G1 always uses one of the
liveness bitmaps for walking the heap).

Further, and typically more importantly, it inflates the PLAB sizes as
the space wasted by these buffers (typically a lot compared to the
actually number of copied bytes) is not accounted for when PLAB resizing
occurs.

You may notice that this CR adds the check that the PLABs must be
retired (in G1ParGCAllocBuffer::~G1ParGCAllocBuffer): this is because
when the problem had been identified, there has been one, which was part
of JDK-6976350. That change has been reverted since though.

The change further fixes a few areas which lead to that issue: first
G1ParGCAllocBuffer hides but not overrides the set_buf() and retire()
methods, which, when the latter is called via
ParGCAllocBuffer::flush_stats_and_retire() leads to a call of the wrong
retire() method. So the _retired member of G1ParGCAllocBuffer is never
set to true.
So these two methods were made virtual in ParGCAllocBuffer.

Another issue fixed is that the initial value of _retired should be
true, as buffers are assigned lazily.

Finally, to avoid missing calls to
ParGCAllocBuffer::retire_alloc_buffers(), I put the call to it into the
destructor of G1ParScanThreadState so that it does not need to be called
manually any more (which means that its visibility changed to private).

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

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

Testing:
no perf regressions on any standard benchmark without parallel reference
processing with g1 and pargc on a few platforms, jprt

Thanks,
Thomas



From erik.helin at oracle.com  Fri Apr 11 10:37:28 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Fri, 11 Apr 2014 12:37:28 +0200
Subject: RFR 8037924: CMM Testing: Check Min/MaxHeapFreeRatio flags allows
	to shrink the heap when using ParallelGC
In-Reply-To: <1397210751.2710.25.camel@cirrus>
References: <5332FA20.5070607@oracle.com>	<5334A639.6050205@oracle.com>	<53357B26.4080707@oracle.com>	<53357DAC.70607@oracle.com>	<533581D3.3010808@oracle.com>	<53359517.3070305@oracle.com>	<53366F67.4080409@oracle.com>	<5336800A.2090506@oracle.com>	<5336BA50.30700@oracle.com>	<5336E8AE.4030302@oracle.com>	<5336EFF4.1070605@oracle.com>	<533725B7.8090209@oracle.com>	<53374769.70909@oracle.com>	<53374A1C.9070509@oracle.com>	<5337CFE1.5040603@oracle.com>	<53385D10.40506@oracle.com>	<53390C1F.9030400@oracle.com>	<53393256.8090406@oracle.com>	<53394053.2070502@oracle.com>	<533955B0.7000601@oracle.com>	<533A6165.80704@oracle.com>	<533A8141.2030608@oracle.com>	<533AB040.6000302@oracle.com>	<533C3654.7020801@oracle.com>	<533C3974.5080803@oracle.com>	<533C460D.5020707@oracle.com>	<533C4CDC.3070307@oracle.com>	<533D68E1.7000007@oracle.com>	<533D69D0.6060203@oracle.com>	<53468A13.2010709@oracle.com>
	<53468AD3.8020908@oracle.com>	<5347B348.3040704@oracle.com>
	<1397210751.2710.25.camel@c! irrus>
Message-ID: <5347C5E8.7080602@oracle.com>

On 2014-04-11 12:05, Thomas Schatzl wrote:
> Hi,
>
> On Fri, 2014-04-11 at 13:18 +0400, Andrey Zakharov wrote:
>> Hi.
>> Here is updated webrevs
>> http://cr.openjdk.java.net/~iignatyev/anzakharov/8037924/webrev.14/
>
> Good.

I'm also ok with this change.

>> http://cr.openjdk.java.net/~iignatyev/anzakharov/8037925/webrev.07/
>
> Could you fix the summary for this change as well? I do not need a
> re-review for this change.
>
> Other than that, looks good.

When you have addressed Thomas comment, I'm also ok with this change.

Thanks,
Erik

> Thanks,
>    Thomas
>
>


From thomas.schatzl at oracle.com  Fri Apr 11 10:53:51 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 11 Apr 2014 12:53:51 +0200
Subject: RFR (M): 8019342: G1: High "Other" time most likely due to card
	redirtying
Message-ID: <1397213631.2710.51.camel@cirrus>

Hi all,

  can I have a few reviews for the following change that parallelizes
card redirtying and improves log output?

On a few applications card redirtying time is very large, taking tens of
ms. Investigation showed that there are no really clever ways to avoid
this work when keeping the current way of handling not-redirtied cards
except parallelizing it.

I.e. the ideas referred to in the CR
(https://bugs.openjdk.java.net/browse/JDK-8019342?focusedCommentId=13346944&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13346944) do not yield any good results to make it worth implementing these suggestions.

This CR implements parallelization by putting this work into an
AbstractGangTask and do the work in parallel; for that I added a
par_apply_closure_to_all_completed_buffers() method in
DirtyCardQueueSet, claiming work on a per chunk basis. This yields
(almost) linear speedup.

Logging code has been improved to show the number of cards processed per
thread too.

Note that there is still some code duplication with iterating over the
DCQS during verification: that will be fixed in a followup CR.

Also, at some point I will merge the various "Other" gangtasks into a
single one to avoid startup/shutdown costs in another CR.

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

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

Testing:
jprt, common benchmarks

Thanks,
  Thomas




From thomas.schatzl at oracle.com  Fri Apr 11 11:33:06 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 11 Apr 2014 13:33:06 +0200
Subject: RFR (M): 8019342: G1: High "Other" time most likely due to card
	redirtying
In-Reply-To: <1397213631.2710.51.camel@cirrus>
References: <1397213631.2710.51.camel@cirrus>
Message-ID: <1397215986.2710.52.camel@cirrus>

Hi all,

  just adding the CRs for the proposed follow-up changes:

On Fri, 2014-04-11 at 12:53 +0200, Thomas Schatzl wrote:
> Hi all,
> 
>   can I have a few reviews for the following change that parallelizes
> card redirtying and improves log output?
> 
> On a few applications card redirtying time is very large, taking tens of
> ms. Investigation showed that there are no really clever ways to avoid
> this work when keeping the current way of handling not-redirtied cards
> except parallelizing it.
> 
> I.e. the ideas referred to in the CR
> (https://bugs.openjdk.java.net/browse/JDK-8019342?focusedCommentId=13346944&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13346944) do not yield any good results to make it worth implementing these suggestions.
> 
> This CR implements parallelization by putting this work into an
> AbstractGangTask and do the work in parallel; for that I added a
> par_apply_closure_to_all_completed_buffers() method in
> DirtyCardQueueSet, claiming work on a per chunk basis. This yields
> (almost) linear speedup.
> 
> Logging code has been improved to show the number of cards processed per
> thread too.
> 
> Note that there is still some code duplication with iterating over the
> DCQS during verification: that will be fixed in a followup CR.

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

> 
> Also, at some point I will merge the various "Other" gangtasks into a
> single one to avoid startup/shutdown costs in another CR.

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

Thanks,
  Thomas



From jon.masamitsu at oracle.com  Fri Apr 11 15:54:41 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 11 Apr 2014 08:54:41 -0700
Subject: RFR: 8039957: Replace the last few %p usages with PTR_FORMAT
	in the GC code
In-Reply-To: <5346F023.3010408@oracle.com>
References: <5346F023.3010408@oracle.com>
Message-ID: <53481041.6040609@oracle.com>

http://cr.openjdk.java.net/~stefank/8039957/webrev.00/src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp.udiff.html

This results in the same output as the original code

+             "  _end: " PTR_FORMAT "  _hard_end: " PTR_FORMAT "_retained: %c"


but do you want a space before "_retained:"

Rest looks good.

Reviewed.

Jon

On 4/10/2014 12:25 PM, Stefan Karlsson wrote:
> Please, review this small patch the GC code to replace the last few 
> usages of %p with PTR_FORMAT.
>
> http://cr.openjdk.java.net/~stefank/8039957/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8039957
>
> One of the instances used %p to print a size_t. I decided to cast the 
> value to pointer instead of using SIZE_FORMAT. I'll be happy to change 
> it to SIZE_FORMAT or SIZE_FORMAT_HEX if anyone cares and has an 
> opinion about this unused piece of code. :)
>
> thanks,
> StefanK



From stefan.karlsson at oracle.com  Fri Apr 11 15:57:40 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 11 Apr 2014 17:57:40 +0200
Subject: RFR: 8039957: Replace the last few %p usages with PTR_FORMAT
	in the GC code
In-Reply-To: <53481041.6040609@oracle.com>
References: <5346F023.3010408@oracle.com> <53481041.6040609@oracle.com>
Message-ID: <534810F4.50000@oracle.com>

On 2014-04-11 17:54, Jon Masamitsu wrote:
> http://cr.openjdk.java.net/~stefank/8039957/webrev.00/src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp.udiff.html 
>
>
> This results in the same output as the original code
>
> +             "  _end: " PTR_FORMAT "  _hard_end: " PTR_FORMAT 
> "_retained: %c"
>
>
> but do you want a space before "_retained:"

I'll add a space.

>
> Rest looks good.
>
> Reviewed.

Thanks.

StefanK

>
> Jon
>
> On 4/10/2014 12:25 PM, Stefan Karlsson wrote:
>> Please, review this small patch the GC code to replace the last few 
>> usages of %p with PTR_FORMAT.
>>
>> http://cr.openjdk.java.net/~stefank/8039957/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8039957
>>
>> One of the instances used %p to print a size_t. I decided to cast the 
>> value to pointer instead of using SIZE_FORMAT. I'll be happy to 
>> change it to SIZE_FORMAT or SIZE_FORMAT_HEX if anyone cares and has 
>> an opinion about this unused piece of code. :)
>>
>> thanks,
>> StefanK
>



From bengt.rutisson at oracle.com  Mon Apr 14 07:34:14 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 14 Apr 2014 09:34:14 +0200
Subject: RFR (XS): 8027553 - Change the in_cset_fast_test functionality
	to use the G1BiasedArray abstraction
In-Reply-To: <1394789131.2789.15.camel@cirrus>
References: <1394789131.2789.15.camel@cirrus>
Message-ID: <534B8F76.5070601@oracle.com>


Hi Thomas,

Looks good.

One minor question. In the two places where we call 
clear_cset_fast_test() we have this comment.

         // Clear the _cset_fast_test bitmap in anticipation of adding
         // regions to the incremental collection set for the next
         // evacuation pause.
         clear_cset_fast_test();

Strictly speaking _cset_fast_test is not a bitmap anymore. On the other 
hand conceptually it is is, so maybe the comment is still ok. But then 
again, I am not sure we need this comment at all. From the name of the 
method it is pretty clear what the method does and from the placement of 
it I think the reason is pretty natural. I would be fine with just 
removing these two comments.

Anyway, I'm fine with the change as it is. If you want to do something 
about the comment thats fine too.

Reviewed. :)

Bengt


On 2014-03-14 10:25, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for the following small change? It cleans up the
> in_cset_fast_test functionality to use the G1BiasedMappedArray
> abstraction introduced long ago.
>
> This removes lots of clutter in the code caused by lots of explanation
> that is part of the G1BiasedMappedArray class description, manual
> management and asserts all handled by that class.
>
> It is intentional to name the class handling the in_cset_fast_test type
> G1FastCSetBiasedMappedArray, and not e.g. BoolBiasedMappedArray. The
> plan is to extend its use for "JDK-8027959: Investigate early
> reclamation of large objects in G1".
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8027553/webrev/
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8027553
>
> Testing:
> jprt
>
> Thanks,
>    Thomas
>



From bengt.rutisson at oracle.com  Mon Apr 14 08:13:50 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 14 Apr 2014 10:13:50 +0200
Subject: RFR (S): 8037344: Use the "next" field to iterate over fine
	remembered instead of using the hash table
In-Reply-To: <1397048721.2710.65.camel@cirrus>
References: <1394815316.2803.2.camel@cirrus>
	<2052383.BEgzZ2NYJK@mgerdin03>	<1397046846.2710.58.camel@cirrus>
	<1815925.qcRQHHumPe@mgerdin03> <1397048721.2710.65.camel@cirrus>
Message-ID: <534B98BE.80307@oracle.com>


Hi Thomas,

Looks good. Nice work!

A couple of minor nits:

Both _cur_region_cur_cards and HeapRegion::CardsPerRegion are size_t, so 
there are a few unnecessary casts in the code I think:

1058   _cur_region_cur_card((size_t)HeapRegion::CardsPerRegion),

1095   if (_cur_region_cur_card == (size_t)HeapRegion::CardsPerRegion) {

I think the message for this assert is a bit strange.

1107   guarantee(_cur_region_cur_card < HeapRegion::CardsPerRegion, 
"card index must be within heap");

We are not verifying that the card index is within the heap. It is 
verifying that the current card is within a heap region.

Actually this raises another question. The name _cur_region_cur_card 
lead me to believe that the region was somehow encoded in this value, 
but it seems to only be the current card index (for the region that we 
have stored in _finc_cur_prt). How about changing the name to just 
_cur_card? Not sure it is better. I just got confused by the name, but I 
do realize that the intent is that it is the current card index for the 
regions we are iterating over.

The method switch_to_next_prt() actually don't step to the next or 
verify that it is switching to the next PRT. Can we rename it to just 
switch_to_prt() ?

Thanks,
Bengt





On 2014-04-09 15:05, Thomas Schatzl wrote:
> Hi,
>
> On Wed, 2014-04-09 at 14:37 +0200, Mikael Gerdin wrote:
>> On Wednesday 09 April 2014 14.34.06 Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Wed, 2014-04-09 at 13:46 +0200, Mikael Gerdin wrote:
>>>> Hi Thomas,
>>>>
>>>> On Wednesday 09 April 2014 12.02.45 Thomas Schatzl wrote:
>>>>> Hi all,
>>>>>
>>>>>    I have been notified that the webrev does not apply to the jdk9/hs-gc
>>>>>
>>>>> repository any more.
>>>>>
>>>>> Here is an updated version:
>>>>> http://cr.openjdk.java.net/~tschatzl/8037344/webrev.1/
>>>> Just to make sure that I follow the subtleties in the code here, you set
>>>> _cur_region_cur_card to -1 here. Then when fine_has_next is called it
>>>> computes _cur_region_cur_card + 1 to get 0 and calls
>>>> _bm.get_next_one_offset?
>>> Exactly, this is to get the start condition right after switching from
>>> coarse to fine entries or to the next fine PRT.
>>> Get_next_one_offset() starts searching including the passed offset.
>>>
>>> I will add a comment.
>> Thanks.
> Done in http://cr.openjdk.java.net/~tschatzl/8037344/webrev.2/
>
> void HeapRegionRemSetIterator::switch_to_next_prt(PerRegionTable* prt) {
>     assert(prt != NULL, "Cannot switch to NULL prt");
>     _fine_cur_prt = prt;
>
>     HeapWord* r_bot = _fine_cur_prt->hr()->bottom();
>     _cur_region_card_offset = _bosa->index_for(r_bot);
>
> +  // The bitmap scan for the PRT always scans from _cur_region_cur_card + 1.
> +  // To avoid special-casing this start case, and not miss the first bitmap
> +  // entry, initialize _cur_region_cur_card with -1 instead of 0.
>     _cur_region_cur_card = (size_t)-1;
>   }
>
> Thanks,
> Thomas
>



From bengt.rutisson at oracle.com  Mon Apr 14 08:18:10 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 14 Apr 2014 10:18:10 +0200
Subject: RFR (XXS): 8039596: Remove
	HeapRegionRemSet::clear_incoming_entry()
In-Reply-To: <1397039331.2710.18.camel@cirrus>
References: <1397039331.2710.18.camel@cirrus>
Message-ID: <534B99C2.4090509@oracle.com>


On 2014-04-09 12:28, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for the following cleanup that simply removes above
> method?
>
> It has not been used anywhere for apparently a long time, so it seems
> somewhat out of date as it does not cover sparse entries.
>
> This, depending on the caller which is not there any more, might not be
> problematic, but nevertheless it does not seem useful to keep it any
> longer.
>
> CR
> https://bugs.openjdk.java.net/browse/JDK-8039596
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8039596/webrev/

Looks good.

Thanks,
Bengt

>
> Thanks,
>    Thomas
>



From thomas.schatzl at oracle.com  Mon Apr 14 08:33:52 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 14 Apr 2014 10:33:52 +0200
Subject: RFR (S): 8038930: G1CodeRootSet::test fails with
	assert(_num_chunks_handed_out == 0) failed: No elements must have been
	handed out yet
In-Reply-To: <1396448631.3183.14.camel@cirrus>
References: <1396448631.3183.14.camel@cirrus>
Message-ID: <1397464432.2708.6.camel@cirrus>

Hi all,

On Wed, 2014-04-02 at 16:23 +0200, Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews for the following fix for a test case?

  Bengt found a race situation where the test fails when compilation is
running while the test is run.

Instead of trying to find a way to synchronize the test with the
compiler, I changed the code to allow multiple code root chunk free
lists - the test uses one separate from the global one, so there are no
more synchronization problems, and the original change to remember the
number of already allocated code root chunks is superfluous too.

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

Here is a new webrev:
http://cr.openjdk.java.net/~tschatzl/8038930/webrev.1/

Testing:
Failing test with -Xcomp, jprt

> This test case does some basic code validation on recently introduced
> code root memory management for G1 introduced recently (JDK-8035406).
> 
> It assumed that before running the test, no code root memory has been
> handed out.
> 
> The problem is now, when running with -Xcomp, before the internal VM
> tests (and this test) are run, it is likely that compiled code already
> did some code root allocations.
> 
> So the test needs to be aware of that, and not assume that the number of
> code root memory handed out is not zero.
> 
> This change fixes that assumption.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8038930
> 
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8038930/webrev/
> 
> Testing:
> jprt, manual invocation of test case with -Xcomp

Thanks,
 Thomas





From thomas.schatzl at oracle.com  Mon Apr 14 08:36:02 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 14 Apr 2014 10:36:02 +0200
Subject: RFR (XS): 8027553 - Change the in_cset_fast_test functionality
	to use the G1BiasedArray abstraction
In-Reply-To: <534B8F76.5070601@oracle.com>
References: <1394789131.2789.15.camel@cirrus> <534B8F76.5070601@oracle.com>
Message-ID: <1397464562.2708.8.camel@cirrus>

Hi Bengt,

On Mon, 2014-04-14 at 09:34 +0200, Bengt Rutisson wrote:
> Hi Thomas,
> 
> Looks good.

Thanks.

> 
> One minor question. In the two places where we call 
> clear_cset_fast_test() we have this comment.
> 
>          // Clear the _cset_fast_test bitmap in anticipation of adding
>          // regions to the incremental collection set for the next
>          // evacuation pause.
>          clear_cset_fast_test();
> 
> Strictly speaking _cset_fast_test is not a bitmap anymore. On the other 
> hand conceptually it is is, so maybe the comment is still ok. But then 
> again, I am not sure we need this comment at all. From the name of the 
> method it is pretty clear what the method does and from the placement of 
> it I think the reason is pretty natural. I would be fine with just 
> removing these two comments.

I removed the comments, new webrev at:

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

Incremental webrev:
http://cr.openjdk.java.net/~tschatzl/8027553/webrev.1.diff/

Thanks,
  Thomas



From thomas.schatzl at oracle.com  Mon Apr 14 08:36:39 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 14 Apr 2014 10:36:39 +0200
Subject: RFR (XXS): 8039596: Remove
	HeapRegionRemSet::clear_incoming_entry()
In-Reply-To: <534B99C2.4090509@oracle.com>
References: <1397039331.2710.18.camel@cirrus> <534B99C2.4090509@oracle.com>
Message-ID: <1397464599.2708.9.camel@cirrus>

Hi,

On Mon, 2014-04-14 at 10:18 +0200, Bengt Rutisson wrote:
> On 2014-04-09 12:28, Thomas Schatzl wrote:
> > Hi all,
> >
> >    can I have reviews for the following cleanup that simply removes above
> > method?
> >
> > It has not been used anywhere for apparently a long time, so it seems
> > somewhat out of date as it does not cover sparse entries.
> >
> > This, depending on the caller which is not there any more, might not be
> > problematic, but nevertheless it does not seem useful to keep it any
> > longer.
> >
> > CR
> > https://bugs.openjdk.java.net/browse/JDK-8039596
> >
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8039596/webrev/
> 
> Looks good.

Thanks for the review,
  Thomas




From bengt.rutisson at oracle.com  Mon Apr 14 08:43:37 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 14 Apr 2014 10:43:37 +0200
Subject: RFR (S): JDK-8028710: G1 does not retire allocation buffers after
	reference processing work
In-Reply-To: <1397212678.2710.40.camel@cirrus>
References: <1397212678.2710.40.camel@cirrus>
Message-ID: <534B9FB9.5030108@oracle.com>


Hi Thomas,

Nice change. Looks good.

Moving retire_alloc_buffers() to the destructor of G1ParScanThreadState 
is nice, but has the side effect that in 
G1CollectedHeap::process_discovered_references() the time to retire the 
alloc buffers is not included anymore in the reference processing time 
reported by that method. I guess this time is bounded and hopefully 
short, but do you think it could be an issue?

I assume you had to change the initial value of _retired in 
G1ParGCAllocBuffer from false to true because of the assert in 
~G1ParGCAllocBuffer(). Can you elaborate a bit on why we create a 
G1ParGCAllocBuffer without using and retiring it? Basically, why is the 
initial value for _retired not false?

Nice that there were no performance impact of making the methods in 
ParGCAllocBuffer virtual.

Thanks,
Bengt

On 2014-04-11 12:37, Thomas Schatzl wrote:
> Hi all,
>
>    can I have some reviews for the following bugfix?
>
> When doing parallel reference processing, its allocation buffers are not
> retired. This causes problems with the not-retired buffer being wrongly
> formatted (however I could not trigger a bug because of that since that
> area does not contain live objects, and G1 always uses one of the
> liveness bitmaps for walking the heap).
>
> Further, and typically more importantly, it inflates the PLAB sizes as
> the space wasted by these buffers (typically a lot compared to the
> actually number of copied bytes) is not accounted for when PLAB resizing
> occurs.
>
> You may notice that this CR adds the check that the PLABs must be
> retired (in G1ParGCAllocBuffer::~G1ParGCAllocBuffer): this is because
> when the problem had been identified, there has been one, which was part
> of JDK-6976350. That change has been reverted since though.
>
> The change further fixes a few areas which lead to that issue: first
> G1ParGCAllocBuffer hides but not overrides the set_buf() and retire()
> methods, which, when the latter is called via
> ParGCAllocBuffer::flush_stats_and_retire() leads to a call of the wrong
> retire() method. So the _retired member of G1ParGCAllocBuffer is never
> set to true.
> So these two methods were made virtual in ParGCAllocBuffer.
>
> Another issue fixed is that the initial value of _retired should be
> true, as buffers are assigned lazily.
>
> Finally, to avoid missing calls to
> ParGCAllocBuffer::retire_alloc_buffers(), I put the call to it into the
> destructor of G1ParScanThreadState so that it does not need to be called
> manually any more (which means that its visibility changed to private).
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8028710/webrev/
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8028710
>
> Testing:
> no perf regressions on any standard benchmark without parallel reference
> processing with g1 and pargc on a few platforms, jprt
>
> Thanks,
> Thomas
>



From bengt.rutisson at oracle.com  Mon Apr 14 08:49:02 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 14 Apr 2014 10:49:02 +0200
Subject: RFR (XS): 8027553 - Change the in_cset_fast_test functionality
	to use the G1BiasedArray abstraction
In-Reply-To: <1397464562.2708.8.camel@cirrus>
References: <1394789131.2789.15.camel@cirrus> <534B8F76.5070601@oracle.com>
	<1397464562.2708.8.camel@cirrus>
Message-ID: <534BA0FE.5000403@oracle.com>


On 2014-04-14 10:36, Thomas Schatzl wrote:
> Hi Bengt,
>
> On Mon, 2014-04-14 at 09:34 +0200, Bengt Rutisson wrote:
>> Hi Thomas,
>>
>> Looks good.
> Thanks.
>
>> One minor question. In the two places where we call
>> clear_cset_fast_test() we have this comment.
>>
>>           // Clear the _cset_fast_test bitmap in anticipation of adding
>>           // regions to the incremental collection set for the next
>>           // evacuation pause.
>>           clear_cset_fast_test();
>>
>> Strictly speaking _cset_fast_test is not a bitmap anymore. On the other
>> hand conceptually it is is, so maybe the comment is still ok. But then
>> again, I am not sure we need this comment at all. From the name of the
>> method it is pretty clear what the method does and from the placement of
>> it I think the reason is pretty natural. I would be fine with just
>> removing these two comments.
> I removed the comments, new webrev at:
>
> http://cr.openjdk.java.net/~tschatzl/8027553/webrev.1/
>
> Incremental webrev:
> http://cr.openjdk.java.net/~tschatzl/8027553/webrev.1.diff/

Looks good.

Bengt

>
> Thanks,
>    Thomas
>



From thomas.schatzl at oracle.com  Mon Apr 14 09:08:23 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 14 Apr 2014 11:08:23 +0200
Subject: RFR (S): 8037344: Use the "next" field to iterate over fine
	remembered instead of using the hash table
In-Reply-To: <534B98BE.80307@oracle.com>
References: <1394815316.2803.2.camel@cirrus> <2052383.BEgzZ2NYJK@mgerdin03>
	<1397046846.2710.58.camel@cirrus> <1815925.qcRQHHumPe@mgerdin03>
	<1397048721.2710.65.camel@cirrus> <534B98BE.80307@oracle.com>
Message-ID: <1397466503.2708.11.camel@cirrus>

Hi Bengt,

On Mon, 2014-04-14 at 10:13 +0200, Bengt Rutisson wrote:
> Hi Thomas,
> 
> Looks good. Nice work!
> 
> A couple of minor nits:
> 
> Both _cur_region_cur_cards and HeapRegion::CardsPerRegion are size_t, so 
> there are a few unnecessary casts in the code I think:
> 
> 1058   _cur_region_cur_card((size_t)HeapRegion::CardsPerRegion),
> 
> 1095   if (_cur_region_cur_card == (size_t)HeapRegion::CardsPerRegion) {
> 
> I think the message for this assert is a bit strange.
> 
> 1107   guarantee(_cur_region_cur_card < HeapRegion::CardsPerRegion, 
> "card index must be within heap");
> 
> We are not verifying that the card index is within the heap. It is 
> verifying that the current card is within a heap region.

All fixed.

> Actually this raises another question. The name _cur_region_cur_card 
> lead me to believe that the region was somehow encoded in this value, 
> but it seems to only be the current card index (for the region that we 
> have stored in _finc_cur_prt). How about changing the name to just 
> _cur_card? Not sure it is better. I just got confused by the name, but I 
> do realize that the intent is that it is the current card index for the 
> regions we are iterating over.

I renamed it to _cur_card_in_prt. Note that a PRT corresponds to a
single region at this time, so the original does not sound too far
fetched.

> The method switch_to_next_prt() actually don't step to the next or 
> verify that it is switching to the next PRT. Can we rename it to just 
> switch_to_prt() ?

Done.

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

Incremental webrev:
http://cr.openjdk.java.net/~tschatzl/8037344/webrev.3.diff/

Thanks,
  Thomas



From thomas.schatzl at oracle.com  Mon Apr 14 09:53:49 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 14 Apr 2014 11:53:49 +0200
Subject: RFR (S): JDK-8028710: G1 does not retire allocation buffers
	after reference processing work
In-Reply-To: <534B9FB9.5030108@oracle.com>
References: <1397212678.2710.40.camel@cirrus> <534B9FB9.5030108@oracle.com>
Message-ID: <1397469229.2708.24.camel@cirrus>

Hi,

On Mon, 2014-04-14 at 10:43 +0200, Bengt Rutisson wrote:
> Hi Thomas,
> 
> Nice change. Looks good.

Thanks.

> Moving retire_alloc_buffers() to the destructor of G1ParScanThreadState 
> is nice, but has the side effect that in 
> G1CollectedHeap::process_discovered_references() the time to retire the 
> alloc buffers is not included anymore in the reference processing time 
> reported by that method. I guess this time is bounded and hopefully 
> short, but do you think it could be an issue?

Retiring an allocation buffer does two things: adding a few values to
statistics (wasted space), and inserting the filler block into the heap.

I do not expect either to be very expensive.

Also, I would like to remove use of separate allocation buffers for the
different gc phases at some point: it is very expensive in terms of
memory usage to size them the same in phases that have a different
allocation behavior.

Particularly in the soft-reference processing phase, very often only a
few objects are kept alive, although G1 sizes the buffer to the same
size as for the actual evacuation phase which has comparatively much
more survivors.

I will probably create a CR for that.

> I assume you had to change the initial value of _retired in 
> G1ParGCAllocBuffer from false to true because of the assert in 
> ~G1ParGCAllocBuffer(). Can you elaborate a bit on why we create a 
> G1ParGCAllocBuffer without using and retiring it? Basically, why is the 
> initial value for _retired not false?

We may create G1ParGCAllocBuffers for G1ParScanThreadState instances
that never allocate anything, e.g. if there are no survivors in the
first GC phase, or if reference processing does not keep alive any
objects (or there were no soft references in the first place).

As for initializing _retired to true, this follows from retire() setting
_retired to this value. I.e. the initial state of G1ParGCAllocBuffers
should be exactly the same state as after retirement.

> Nice that there were no performance impact of making the methods in 
> ParGCAllocBuffer virtual.

That also is true for making allocate() virtual btw - this might be
handy in the future.

Thanks,
  Thomas




From thomas.schatzl at oracle.com  Mon Apr 14 09:59:52 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 14 Apr 2014 11:59:52 +0200
Subject: RFR(S): JDK-8040002: Clean up code and code duplication in
	re-diryting cards for verification
Message-ID: <1397469592.2708.28.camel@cirrus>

Hi all,

  can I have reviews for the following short cleanup? While implementing
8019342 I found that there is some opportunity to clean up code in the
various card closures in G1.

There is some code duplication, and the verification card closure code
still assumes the presence of a perm gen. There are also some hardcoded
card table values for clean/dirty cards.

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

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

Testing:
jprt

Thanks,
  Thomas




From bengt.rutisson at oracle.com  Mon Apr 14 11:53:47 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 14 Apr 2014 13:53:47 +0200
Subject: RFR (S): JDK-8028710: G1 does not retire allocation buffers after
	reference processing work
In-Reply-To: <1397469229.2708.24.camel@cirrus>
References: <1397212678.2710.40.camel@cirrus> <534B9FB9.5030108@oracle.com>
	<1397469229.2708.24.camel@cirrus>
Message-ID: <534BCC4B.8070209@oracle.com>


Hi Thomas,

On 2014-04-14 11:53, Thomas Schatzl wrote:
> Hi,
>
> On Mon, 2014-04-14 at 10:43 +0200, Bengt Rutisson wrote:
>> Hi Thomas,
>>
>> Nice change. Looks good.
> Thanks.
>
>> Moving retire_alloc_buffers() to the destructor of G1ParScanThreadState
>> is nice, but has the side effect that in
>> G1CollectedHeap::process_discovered_references() the time to retire the
>> alloc buffers is not included anymore in the reference processing time
>> reported by that method. I guess this time is bounded and hopefully
>> short, but do you think it could be an issue?
> Retiring an allocation buffer does two things: adding a few values to
> statistics (wasted space), and inserting the filler block into the heap.
>
> I do not expect either to be very expensive.
>
> Also, I would like to remove use of separate allocation buffers for the
> different gc phases at some point: it is very expensive in terms of
> memory usage to size them the same in phases that have a different
> allocation behavior.
>
> Particularly in the soft-reference processing phase, very often only a
> few objects are kept alive, although G1 sizes the buffer to the same
> size as for the actual evacuation phase which has comparatively much
> more survivors.
>
> I will probably create a CR for that.

Sounds good to file a CR for that. Good idea.

>
>> I assume you had to change the initial value of _retired in
>> G1ParGCAllocBuffer from false to true because of the assert in
>> ~G1ParGCAllocBuffer(). Can you elaborate a bit on why we create a
>> G1ParGCAllocBuffer without using and retiring it? Basically, why is the
>> initial value for _retired not false?
> We may create G1ParGCAllocBuffers for G1ParScanThreadState instances
> that never allocate anything, e.g. if there are no survivors in the
> first GC phase, or if reference processing does not keep alive any
> objects (or there were no soft references in the first place).
>
> As for initializing _retired to true, this follows from retire() setting
> _retired to this value. I.e. the initial state of G1ParGCAllocBuffers
> should be exactly the same state as after retirement.

OK. Makes sense. Thanks for the extra information.

>
>> Nice that there were no performance impact of making the methods in
>> ParGCAllocBuffer virtual.
> That also is true for making allocate() virtual btw - this might be
> handy in the future.

Right :)

Ship it!
Bengt

>
> Thanks,
>    Thomas
>
>



From bengt.rutisson at oracle.com  Mon Apr 14 11:57:36 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 14 Apr 2014 13:57:36 +0200
Subject: RFR (S): 8037344: Use the "next" field to iterate over fine
	remembered instead of using the hash table
In-Reply-To: <1397466503.2708.11.camel@cirrus>
References: <1394815316.2803.2.camel@cirrus>
	<2052383.BEgzZ2NYJK@mgerdin03>		<1397046846.2710.58.camel@cirrus>
	<1815925.qcRQHHumPe@mgerdin03>	
	<1397048721.2710.65.camel@cirrus> <534B98BE.80307@oracle.com>
	<1397466503.2708.11.camel@cirrus>
Message-ID: <534BCD30.9020207@oracle.com>


Hi Thomas,

Thanks for fixing all of the minor things.

New webrev looks good!

Bengt


On 2014-04-14 11:08, Thomas Schatzl wrote:
> Hi Bengt,
>
> On Mon, 2014-04-14 at 10:13 +0200, Bengt Rutisson wrote:
>> Hi Thomas,
>>
>> Looks good. Nice work!
>>
>> A couple of minor nits:
>>
>> Both _cur_region_cur_cards and HeapRegion::CardsPerRegion are size_t, so
>> there are a few unnecessary casts in the code I think:
>>
>> 1058   _cur_region_cur_card((size_t)HeapRegion::CardsPerRegion),
>>
>> 1095   if (_cur_region_cur_card == (size_t)HeapRegion::CardsPerRegion) {
>>
>> I think the message for this assert is a bit strange.
>>
>> 1107   guarantee(_cur_region_cur_card < HeapRegion::CardsPerRegion,
>> "card index must be within heap");
>>
>> We are not verifying that the card index is within the heap. It is
>> verifying that the current card is within a heap region.
> All fixed.
>
>> Actually this raises another question. The name _cur_region_cur_card
>> lead me to believe that the region was somehow encoded in this value,
>> but it seems to only be the current card index (for the region that we
>> have stored in _finc_cur_prt). How about changing the name to just
>> _cur_card? Not sure it is better. I just got confused by the name, but I
>> do realize that the intent is that it is the current card index for the
>> regions we are iterating over.
> I renamed it to _cur_card_in_prt. Note that a PRT corresponds to a
> single region at this time, so the original does not sound too far
> fetched.
>
>> The method switch_to_next_prt() actually don't step to the next or
>> verify that it is switching to the next PRT. Can we rename it to just
>> switch_to_prt() ?
> Done.
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8037344/webrev.3/
>
> Incremental webrev:
> http://cr.openjdk.java.net/~tschatzl/8037344/webrev.3.diff/
>
> Thanks,
>    Thomas
>



From bengt.rutisson at oracle.com  Mon Apr 14 13:27:58 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 14 Apr 2014 15:27:58 +0200
Subject: RFR (M): 8019342: G1: High "Other" time most likely due to card
	redirtying
In-Reply-To: <1397215986.2710.52.camel@cirrus>
References: <1397213631.2710.51.camel@cirrus> <1397215986.2710.52.camel@cirrus>
Message-ID: <534BE25E.9070408@oracle.com>


Hi Thomas,

Looks good.

A couple of minor things:

You made apply_closure_to_all_completed_buffers() and 
par_apply_closure_to_all_completed_buffers() take the closure they 
should apply as a parameter instead of looking it up in the _closure 
instance variable. I like this a lot better, but why did you keep the 
_closure instance variable for other methods 
(iterate_closure_all_threads() and mut_process_buffer()). It would have 
been nice to have the same pattern for all methods. If it is difficult 
to change the others to take a closure as parameter I think I would 
prefer to revert the apply methods to also use the instance variable.

Not strictly related to your change, but it would make it easier to 
understand you change:
In G1CollectedHeap::check_ct_logs_at_safepoint() we start out by doing:
   DirtyCardQueueSet& dcqs = JavaThread::dirty_card_queue_set();
But in that method we still use JavaThread::dirty_card_queue_set() 
explicitly twice. It would be nice to replace these calls with dcqs to 
make it clear that it is the same instance.

These two formatting changes are unrelated to your other changes:

dirtyCardQueue.cpp:  165 BufferNode* 
DirtyCardQueueSet::get_completed_buffer(int stop_at) {
g1CollectedHeap.cpp:  173  YoungList::YoungList(G1CollectedHeap* g1h) :

I would prefer to leave those out.

Thanks,
Bengt


On 2014-04-11 13:33, Thomas Schatzl wrote:
> Hi all,
>
>    just adding the CRs for the proposed follow-up changes:
>
> On Fri, 2014-04-11 at 12:53 +0200, Thomas Schatzl wrote:
>> Hi all,
>>
>>    can I have a few reviews for the following change that parallelizes
>> card redirtying and improves log output?
>>
>> On a few applications card redirtying time is very large, taking tens of
>> ms. Investigation showed that there are no really clever ways to avoid
>> this work when keeping the current way of handling not-redirtied cards
>> except parallelizing it.
>>
>> I.e. the ideas referred to in the CR
>> (https://bugs.openjdk.java.net/browse/JDK-8019342?focusedCommentId=13346944&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13346944) do not yield any good results to make it worth implementing these suggestions.
>>
>> This CR implements parallelization by putting this work into an
>> AbstractGangTask and do the work in parallel; for that I added a
>> par_apply_closure_to_all_completed_buffers() method in
>> DirtyCardQueueSet, claiming work on a per chunk basis. This yields
>> (almost) linear speedup.
>>
>> Logging code has been improved to show the number of cards processed per
>> thread too.
>>
>> Note that there is still some code duplication with iterating over the
>> DCQS during verification: that will be fixed in a followup CR.
> https://bugs.openjdk.java.net/browse/JDK-8040002
>
>> Also, at some point I will merge the various "Other" gangtasks into a
>> single one to avoid startup/shutdown costs in another CR.
> https://bugs.openjdk.java.net/browse/JDK-8040006
>
> Thanks,
>    Thomas
>



From andrey.x.zakharov at oracle.com  Mon Apr 14 14:54:16 2014
From: andrey.x.zakharov at oracle.com (Andrey Zakharov)
Date: Mon, 14 Apr 2014 18:54:16 +0400
Subject: RFR 8037925: CMM Testing: an allocated humongous object at the
	end of the heap should not prevents shrinking the heap
In-Reply-To: <53468DBB.3050504@oracle.com>
References: <53332456.5060407@oracle.com>	<533326B8.4020407@oracle.com>	<53341B70.8070603@oracle.com>	<5334A527.4090209@oracle.com>	<53357A9E.4000505@oracle.com>	<53358125.8020803@oracle.com>	<53367041.5060203@oracle.com>	<533B2DC9.5010903@oracle.com>	<533C429A.2080005@oracle.com>
	<53468CFE.2040800@oracle.com> <53468DBB.3050504@oracle.com>
Message-ID: <534BF698.3020104@oracle.com>

Hi, team.

webrev: http://cr.openjdk.java.net/~iignatyev/anzakharov/8037925/webrev.09/
Updated summary.
Thanks.


On 10.04.2014 16:25, Erik Helin wrote:
> Given that the cleanup issue exists and is being worked on, I'm fine 
> with this patch.
>
> Thanks,
> Erik
>
> On 2014-04-10 14:22, Erik Helin wrote:
>> Andrey has updated the patch:
>>
>> http://cr.openjdk.java.net/~ehelin/8037925/webrev.06/
>>
>> The new patch does no longer change the testlibrary. There is already an
>> issue filed for fixing these tests and the previous testlibrary changes:
>> https://bugs.openjdk.java.net/browse/JDK-8039489.
>>
>> Thanks,
>> Erik
>>
>> On 2014-04-02 19:02, Andrey Zakharov wrote:
>>> Hi, Jon
>>> On 02.04.2014 01:21, Jon Masamitsu wrote:
>>>> Seems like an out-of-memory (OOME) can be thrown here (or anywhere 
>>>> below
>>>> this block of code).  Will an OOME be considered a pass, fail or
>>>> test-not-run?
>>> Yes, its really an question for me, from one point of view, we should
>>> catch OOM and move forward to exit(0),
>>> from another point - such things should be handled by test harness. 
>>> Test
>>> should have some @tag about 1G memory its used and harness should skip
>>> test and notify about this if machine memory is below needed.
>>> Maybe there is another right way.
>>>



From bengt.rutisson at oracle.com  Mon Apr 14 14:56:45 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 14 Apr 2014 16:56:45 +0200
Subject: RFR (S): 8038930: G1CodeRootSet::test fails with
	assert(_num_chunks_handed_out
	== 0) failed: No elements must have been handed out yet
In-Reply-To: <1397464432.2708.6.camel@cirrus>
References: <1396448631.3183.14.camel@cirrus> <1397464432.2708.6.camel@cirrus>
Message-ID: <534BF72D.3050408@oracle.com>


Hi Thomas,

On 4/14/14 10:33 AM, Thomas Schatzl wrote:
> Hi all,
>
> On Wed, 2014-04-02 at 16:23 +0200, Thomas Schatzl wrote:
>> Hi all,
>>
>>    can I have reviews for the following fix for a test case?
>    Bengt found a race situation where the test fails when compilation is
> running while the test is run.
>
> Instead of trying to find a way to synchronize the test with the
> compiler, I changed the code to allow multiple code root chunk free
> lists - the test uses one separate from the global one, so there are no
> more synchronization problems, and the original change to remember the
> number of already allocated code root chunks is superfluous too.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8038930
>
> Here is a new webrev:
> http://cr.openjdk.java.net/~tschatzl/8038930/webrev.1/

This looks good to me.

I think I would have preferred passing exposing 
G1CodeRootSet::_default_chunk_manager and explicitly passing that when 
initializing HeapRegionRemSet::_code_roots rather than having the 
special treatment of the default value NULL in the G1CodeRootSet 
constructor. I'll leave it to you to decide.

Otherwise it looks good.

Thanks,
Bengt


>
> Testing:
> Failing test with -Xcomp, jprt
>
>> This test case does some basic code validation on recently introduced
>> code root memory management for G1 introduced recently (JDK-8035406).
>>
>> It assumed that before running the test, no code root memory has been
>> handed out.
>>
>> The problem is now, when running with -Xcomp, before the internal VM
>> tests (and this test) are run, it is likely that compiled code already
>> did some code root allocations.
>>
>> So the test needs to be aware of that, and not assume that the number of
>> code root memory handed out is not zero.
>>
>> This change fixes that assumption.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8038930
>>
>> Webrev:
>> http://cr.openjdk.java.net/~tschatzl/8038930/webrev/
>>
>> Testing:
>> jprt, manual invocation of test case with -Xcomp
> Thanks,
>   Thomas
>
>
>

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

From bengt.rutisson at oracle.com  Mon Apr 14 15:24:16 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 14 Apr 2014 17:24:16 +0200
Subject: Request for review: 8038265: CMS: enable time based triggering
	of concurrent cycles
In-Reply-To: <1666248.tj7xVnjxql@mgerdin03>
References: <1DDCA93502632C4DA22E9EE199CE907C015FAA93A0@SE002593.cs.commerzbank.com>	<N3AW5D$6641B558048C64803233A598D2C464DA@frajt.eu>
	<1666248.tj7xVnjxql@mgerdin03>
Message-ID: <534BFDA0.9090803@oracle.com>


Hi Michal,

I think the change looks good modulo the comments that Mikael has. If 
you fix those I can help you with a new webrev and then push this change.

Thanks,
Bengt


On 2014-04-01 11:52, Mikael Gerdin wrote:
> Hi Michal,
>
> On Monday 31 March 2014 14.32.01 Michal Frajt wrote:
>> Hi all,could you please review the following change we prepared together
>> with Bengt? The change adds new CMSTriggerInterval flag which allows to
>> invoke CMS collections periodically. The periodically running CMS
>> collections are helping us with replacing the deprecated incremental CMS
>> collector. We believe it might be useful for other customers currently
>> using the CMS in the incremental mode.Bugs:
>> https://bugs.openjdk.java.net/browse/JDK-8038265
>>
>> Webrev:
>> http://cr.openjdk.java.net/~brutisso/8038265/webrev.00/
> If the addition of this functionality helps you replace iCMS then that's
> great! I think this code change is simple and easy to understand.
>
> I just have some small (mostly stylistic) comments:
>
> 	The other time output in PrintCMSInitiationStatistics seems to use 	
> 	%3.7f as the format specifier instead of %g.
>
> 1515     gclog_or_tty->print_cr("cms_time_since_begin=%g",
> stats().cms_time_since_begin());
> 1516     gclog_or_tty->print_cr("cms_time_since_end=%g",
> stats().cms_time_since_end());
>
>
> 	The HotSpot style is to have a space between if and the opening brace,
> 	can you please change the if here:
>
> 1588     if(stats().cms_time_since_begin() >= (CMSTriggerInterval / ((double)
> MILLIUNITS))) {
> 1589       if (Verbose && PrintGCDetails) {
>
> 	And here:
>
> 1590         if(stats().valid()) {
>
> 	We usually align the parameters on the second line with the opening 	
> 	brace on the function call, something like:
>
> gclog_or_tty->print_cr(foo, bar,
>                         stats().baz());
>
> 1591           gclog_or_tty->print_cr("CMSCollector: collect because of
> trigger interval (time since last begin %g secs)",
> 1592             stats().cms_time_since_begin());
> 1593         } else {
>
> 	You pass in cms_time_since_begin() but don't actually use that value 	
> 	in the else branch.
>
> 1594           gclog_or_tty->print_cr("CMSCollector: collect because of
> trigger interval (first collection)",
> 1595             stats().cms_time_since_begin());
> 1596         }
> 1597       }
>
> /Mikael
>
>
>> Thanks,
>> Michal



From thomas.schatzl at oracle.com  Mon Apr 14 15:51:38 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 14 Apr 2014 17:51:38 +0200
Subject: RFR 8037925: CMM Testing: an allocated humongous object at the
	end of the heap should not prevents shrinking the heap
In-Reply-To: <534BF698.3020104@oracle.com>
References: <53332456.5060407@oracle.com>	<533326B8.4020407@oracle.com>
	<53341B70.8070603@oracle.com>	<5334A527.4090209@oracle.com>
	<53357A9E.4000505@oracle.com>	<53358125.8020803@oracle.com>
	<53367041.5060203@oracle.com>	<533B2DC9.5010903@oracle.com>
	<533C429A.2080005@oracle.com> <53468CFE.2040800@oracle.com>
	<53468DBB.3050504@oracle.com> <534BF698.3020104@oracle.com>
Message-ID: <1397490698.2722.2.camel@cirrus>

Hi,

On Mon, 2014-04-14 at 18:54 +0400, Andrey Zakharov wrote:
> Hi, team.
> 
> webrev: http://cr.openjdk.java.net/~iignatyev/anzakharov/8037925/webrev.09/
> Updated summary.
> Thanks.

  looks okay.

Thanks,
  Thomas



From thomas.schatzl at oracle.com  Mon Apr 14 15:59:28 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 14 Apr 2014 17:59:28 +0200
Subject: RFR (S): JDK-8028710: G1 does not retire allocation buffers
	after reference processing work
In-Reply-To: <534BCC4B.8070209@oracle.com>
References: <1397212678.2710.40.camel@cirrus> <534B9FB9.5030108@oracle.com>
	<1397469229.2708.24.camel@cirrus> <534BCC4B.8070209@oracle.com>
Message-ID: <1397491168.2722.4.camel@cirrus>

Hi Bengt,

  thanks for the review.

On Mon, 2014-04-14 at 13:53 +0200, Bengt Rutisson wrote:
> Hi Thomas,
> 
> On 2014-04-14 11:53, Thomas Schatzl wrote:
> > [...]
> > Also, I would like to remove use of separate allocation buffers for the
> > different gc phases at some point: it is very expensive in terms of
> > memory usage to size them the same in phases that have a different
> > allocation behavior.
> >
> > Particularly in the soft-reference processing phase, very often only a
> > few objects are kept alive, although G1 sizes the buffer to the same
> > size as for the actual evacuation phase which has comparatively much
> > more survivors.
> >
> > I will probably create a CR for that.
> 
> Sounds good to file a CR for that. Good idea.

I added JDK-8040162 to track this.

Thanks,
Thomas




From thomas.schatzl at oracle.com  Mon Apr 14 15:59:59 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 14 Apr 2014 17:59:59 +0200
Subject: RFR (S): 8037344: Use the "next" field to iterate over fine
	remembered instead of using the hash table
In-Reply-To: <534BCD30.9020207@oracle.com>
References: <1394815316.2803.2.camel@cirrus> <2052383.BEgzZ2NYJK@mgerdin03>
	<1397046846.2710.58.camel@cirrus> <1815925.qcRQHHumPe@mgerdin03>
	<1397048721.2710.65.camel@cirrus> <534B98BE.80307@oracle.com>
	<1397466503.2708.11.camel@cirrus> <534BCD30.9020207@oracle.com>
Message-ID: <1397491199.2722.5.camel@cirrus>

Hi,

On Mon, 2014-04-14 at 13:57 +0200, Bengt Rutisson wrote:
> Hi Thomas,
> 
> Thanks for fixing all of the minor things.
> 
> New webrev looks good!

  no problem, thank you for the review.

Thomas



From jon.masamitsu at oracle.com  Mon Apr 14 22:58:28 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 14 Apr 2014 15:58:28 -0700
Subject: -XX:MetaspaceSize is correct?
In-Reply-To: <53468C96.6080107@gmail.com>
References: <5345498F.20904@gmail.com>	<5345C0F0.7020606@oracle.com>
	<CAGFVN2Bmt0=w5sQ-m5qrBFvPcO2UmkPh1AGY5uskbUFRGfQ98g@mail.gmail.com>
	<53468C96.6080107@gmail.com>
Message-ID: <534C6814.4050202@oracle.com>

Yasumasa,

It's hard to describe what this parameter is in a single
sentence.  "high-water-mark" doesn't mean much unless
you know about how it is used in the GC.   Although
"initial" is not right in the description, "minimum" might
be closer to a good description.  I'm really not sure.

Jon

On 04/10/2014 05:20 AM, Yasumasa Suenaga wrote:
> I uploaded webrev:
> http://cr.openjdk.java.net/~ysuenaga/JDK-8039867/webrev.00/
>
> Please review and sponsoring!
>
>
> Yasumasa
>
>
> On 04/10/2014 12:37 PM, Yasumasa Suenaga wrote:
>> Hi Jon,
>> Thank you for replying.
>>
>> I filed this issue as JDK-8039867: Incorrect description: 
>> -XX:MetaspaceSize .
>>
>> I attached a patch to this entry.
>> I will upload webrev later.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>>
>> 2014-04-10 6:51 GMT+09:00, Jon Masamitsu <jon.masamitsu at oracle.com>:
>>> On 04/09/2014 06:22 AM, Yasumasa Suenaga wrote:
>>>> Hi all,
>>>>
>>>> I checked initial metaspace size through jcmd PerfCounter.print .
>>>> However, it seems to be incorrect:
>>>>
>>>>   - Java command:
>>>>    java -XX:-UseCompressedClassPointers -XX:+PrintFlagsFinal LongSleep
>>>>
>>>>   - Output from -XX:+PrintFlagsFinal:
>>>>      uintx MetaspaceSize                             =
>>>> 21807104                            {pd product}
>>>>
>>>>   - Result of "PerfCounter.print"
>>>> sun.gc.metaspace.capacity=4194304
>>>> sun.gc.metaspace.maxCapacity=8388608
>>>> sun.gc.metaspace.minCapacity=0
>>>>
>>>>
>>>> I checked metaspace.cpp, initial size of metaspace is detected by
>>>> InitialBootClassLoaderMetaspaceSize.
>>>> However, description of MetaspaceSize in globals.hpp is
>>>> "Initial size of Metaspaces (in bytes)" .
>>>>
>>>> Is description of MetaspaceSize is correct?
>>> Description is not correct.
>>>
>>>> And this behavior is correct?
>>> Behavior is correct.
>>>
>>>> I have two plan for this mismatch:
>>>>
>>>>   A) Change description of MetaspaceSize
>>>>    MetaspaceSize is used to HWM in metaspace.cpp .
>>>>    So we should change description for this behavior.
>>>> ------------
>>>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>>>> --- a/src/share/vm/runtime/globals.hpp  Fri Apr 04 10:04:44 2014 -0700
>>>> +++ b/src/share/vm/runtime/globals.hpp  Wed Apr 09 22:05:18 2014 +0900
>>>> @@ -3160,7 +3156,7 @@
>>>>             "non-daemon thread (in
>>>> bytes)")                                   \
>>>> \
>>>>     product_pd(uintx,
>>>> MetaspaceSize,                                          \
>>>> -          "Initial size of Metaspaces (in
>>>> bytes)")                          \
>>>> +          "Initial HWM of Metaspaces (in
>>>> bytes)")                           \
>>> Explain what HWM is if you're going to use it.
>>>
>>>> \
>>>>     product(uintx, MaxMetaspaceSize,
>>>> max_uintx,                               \
>>>>             "Maximum size of Metaspaces (in
>>>> bytes)")                          \
>>>> ------------
>>>>
>>>>   B) Remove InitialBootClassLoaderMetaspaceSize and use MetaspaceSize
>>>>    In currently, InitialBootClassLoaderMetaspaceSize is used to 
>>>> initialize
>>>>    metaspace.
>>>>    InitialBootClassLoaderMetaspaceSize is only to use for it.
>>>>    Thus we should remove this option and use MetaspaceSize to 
>>>> initialize
>>>>    metaspace.
>>> InitialBootClassLoaderMetaspaceSize is an optimization.  It allows
>>> approximately
>>> enough space for the system classes without repeated allocations of
>>> Metaspaces.
>>> Not everyone agrees with this optimization but I would like it kept.
>>>
>>>> ------------
>>>> diff -r 48ce2e6e1add src/share/vm/memory/metaspace.cpp
>>>> --- a/src/share/vm/memory/metaspace.cpp Fri Apr 04 10:04:44 2014 -0700
>>>> +++ b/src/share/vm/memory/metaspace.cpp Wed Apr 09 22:05:18 2014 +0900
>>>> @@ -3172,7 +3172,7 @@
>>>>   #endif
>>>>
>>>>       // Initialize these before initializing the VirtualSpaceList
>>>> -    _first_chunk_word_size = InitialBootClassLoaderMetaspaceSize /
>>>> BytesPerWord;
>>>> +    _first_chunk_word_size = MetaspaceSize / BytesPerWord;
>>>>       _first_chunk_word_size = 
>>>> align_word_size_up(_first_chunk_word_size);
>>>>       // Make the first class chunk bigger than a medium chunk so it's
>>>> not put
>>>>       // on the medium chunk list.   The next chunk will be small and
>>>> progress
>>>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>>>> --- a/src/share/vm/runtime/globals.hpp  Fri Apr 04 10:04:44 2014 -0700
>>>> +++ b/src/share/vm/runtime/globals.hpp  Wed Apr 09 22:05:18 2014 +0900
>>>> @@ -2333,10 +2333,6 @@
>>>>     develop(bool, TraceClassLoaderData,
>>>> false,                                \
>>>>             "Trace class loader loader_data
>>>> lifetime")                        \
>>>> \
>>>> -  product(uintx,
>>>> InitialBootClassLoaderMetaspaceSize,                       \
>>>> -          NOT_LP64(2200*K)
>>>> LP64_ONLY(4*M),                                  \
>>>> -          "Initial size of the boot class loader data
>>>> metaspace")           \
>>>> - \
>>>>     product(bool, TraceGen0Time,
>>>> false,                                       \
>>>>             "Trace accumulated time for Gen 0
>>>> collection")                    \
>>>> \
>>>> ------------
>>>>
>>>> I prefer "B" .
>>>> Because, I guess many users think MetaspaceSize decides initial
>>>> metaspace size.
>>>>
>>>> If my idea is correct, I will file this to JBS and upload patch to
>>>> webrev.
>>> Please only correct the description of MetaspaceSize.
>>>
>>> Jon
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>
>



From yasuenag at gmail.com  Tue Apr 15 03:48:40 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 15 Apr 2014 12:48:40 +0900
Subject: -XX:MetaspaceSize is correct?
In-Reply-To: <534C6814.4050202@oracle.com>
References: <5345498F.20904@gmail.com> <5345C0F0.7020606@oracle.com>
	<CAGFVN2Bmt0=w5sQ-m5qrBFvPcO2UmkPh1AGY5uskbUFRGfQ98g@mail.gmail.com>
	<53468C96.6080107@gmail.com> <534C6814.4050202@oracle.com>
Message-ID: <CAGFVN2DOW3aSqwNL2hMvQ4yj5CsD9reRjAhN2MfC46Nvue-Dxw@mail.gmail.com>

Jon,

I agree with you.

MetaspaceSize is used as minimum value when JVM shrink capacity in
MetaspaceGC::compute_new_size() .
So I will change description to "minimum" and upload new webrev.


Yasumasa

2014-04-15 7:58 GMT+09:00, Jon Masamitsu <jon.masamitsu at oracle.com>:
> Yasumasa,
>
> It's hard to describe what this parameter is in a single
> sentence.  "high-water-mark" doesn't mean much unless
> you know about how it is used in the GC.   Although
> "initial" is not right in the description, "minimum" might
> be closer to a good description.  I'm really not sure.
>
> Jon
>
> On 04/10/2014 05:20 AM, Yasumasa Suenaga wrote:
>> I uploaded webrev:
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8039867/webrev.00/
>>
>> Please review and sponsoring!
>>
>>
>> Yasumasa
>>
>>
>> On 04/10/2014 12:37 PM, Yasumasa Suenaga wrote:
>>> Hi Jon,
>>> Thank you for replying.
>>>
>>> I filed this issue as JDK-8039867: Incorrect description:
>>> -XX:MetaspaceSize .
>>>
>>> I attached a patch to this entry.
>>> I will upload webrev later.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>>
>>> 2014-04-10 6:51 GMT+09:00, Jon Masamitsu <jon.masamitsu at oracle.com>:
>>>> On 04/09/2014 06:22 AM, Yasumasa Suenaga wrote:
>>>>> Hi all,
>>>>>
>>>>> I checked initial metaspace size through jcmd PerfCounter.print .
>>>>> However, it seems to be incorrect:
>>>>>
>>>>>   - Java command:
>>>>>    java -XX:-UseCompressedClassPointers -XX:+PrintFlagsFinal LongSleep
>>>>>
>>>>>   - Output from -XX:+PrintFlagsFinal:
>>>>>      uintx MetaspaceSize                             =
>>>>> 21807104                            {pd product}
>>>>>
>>>>>   - Result of "PerfCounter.print"
>>>>> sun.gc.metaspace.capacity=4194304
>>>>> sun.gc.metaspace.maxCapacity=8388608
>>>>> sun.gc.metaspace.minCapacity=0
>>>>>
>>>>>
>>>>> I checked metaspace.cpp, initial size of metaspace is detected by
>>>>> InitialBootClassLoaderMetaspaceSize.
>>>>> However, description of MetaspaceSize in globals.hpp is
>>>>> "Initial size of Metaspaces (in bytes)" .
>>>>>
>>>>> Is description of MetaspaceSize is correct?
>>>> Description is not correct.
>>>>
>>>>> And this behavior is correct?
>>>> Behavior is correct.
>>>>
>>>>> I have two plan for this mismatch:
>>>>>
>>>>>   A) Change description of MetaspaceSize
>>>>>    MetaspaceSize is used to HWM in metaspace.cpp .
>>>>>    So we should change description for this behavior.
>>>>> ------------
>>>>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>>>>> --- a/src/share/vm/runtime/globals.hpp  Fri Apr 04 10:04:44 2014 -0700
>>>>> +++ b/src/share/vm/runtime/globals.hpp  Wed Apr 09 22:05:18 2014 +0900
>>>>> @@ -3160,7 +3156,7 @@
>>>>>             "non-daemon thread (in
>>>>> bytes)")                                   \
>>>>> \
>>>>>     product_pd(uintx,
>>>>> MetaspaceSize,                                          \
>>>>> -          "Initial size of Metaspaces (in
>>>>> bytes)")                          \
>>>>> +          "Initial HWM of Metaspaces (in
>>>>> bytes)")                           \
>>>> Explain what HWM is if you're going to use it.
>>>>
>>>>> \
>>>>>     product(uintx, MaxMetaspaceSize,
>>>>> max_uintx,                               \
>>>>>             "Maximum size of Metaspaces (in
>>>>> bytes)")                          \
>>>>> ------------
>>>>>
>>>>>   B) Remove InitialBootClassLoaderMetaspaceSize and use MetaspaceSize
>>>>>    In currently, InitialBootClassLoaderMetaspaceSize is used to
>>>>> initialize
>>>>>    metaspace.
>>>>>    InitialBootClassLoaderMetaspaceSize is only to use for it.
>>>>>    Thus we should remove this option and use MetaspaceSize to
>>>>> initialize
>>>>>    metaspace.
>>>> InitialBootClassLoaderMetaspaceSize is an optimization.  It allows
>>>> approximately
>>>> enough space for the system classes without repeated allocations of
>>>> Metaspaces.
>>>> Not everyone agrees with this optimization but I would like it kept.
>>>>
>>>>> ------------
>>>>> diff -r 48ce2e6e1add src/share/vm/memory/metaspace.cpp
>>>>> --- a/src/share/vm/memory/metaspace.cpp Fri Apr 04 10:04:44 2014 -0700
>>>>> +++ b/src/share/vm/memory/metaspace.cpp Wed Apr 09 22:05:18 2014 +0900
>>>>> @@ -3172,7 +3172,7 @@
>>>>>   #endif
>>>>>
>>>>>       // Initialize these before initializing the VirtualSpaceList
>>>>> -    _first_chunk_word_size = InitialBootClassLoaderMetaspaceSize /
>>>>> BytesPerWord;
>>>>> +    _first_chunk_word_size = MetaspaceSize / BytesPerWord;
>>>>>       _first_chunk_word_size =
>>>>> align_word_size_up(_first_chunk_word_size);
>>>>>       // Make the first class chunk bigger than a medium chunk so it's
>>>>> not put
>>>>>       // on the medium chunk list.   The next chunk will be small and
>>>>> progress
>>>>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>>>>> --- a/src/share/vm/runtime/globals.hpp  Fri Apr 04 10:04:44 2014 -0700
>>>>> +++ b/src/share/vm/runtime/globals.hpp  Wed Apr 09 22:05:18 2014 +0900
>>>>> @@ -2333,10 +2333,6 @@
>>>>>     develop(bool, TraceClassLoaderData,
>>>>> false,                                \
>>>>>             "Trace class loader loader_data
>>>>> lifetime")                        \
>>>>> \
>>>>> -  product(uintx,
>>>>> InitialBootClassLoaderMetaspaceSize,                       \
>>>>> -          NOT_LP64(2200*K)
>>>>> LP64_ONLY(4*M),                                  \
>>>>> -          "Initial size of the boot class loader data
>>>>> metaspace")           \
>>>>> - \
>>>>>     product(bool, TraceGen0Time,
>>>>> false,                                       \
>>>>>             "Trace accumulated time for Gen 0
>>>>> collection")                    \
>>>>> \
>>>>> ------------
>>>>>
>>>>> I prefer "B" .
>>>>> Because, I guess many users think MetaspaceSize decides initial
>>>>> metaspace size.
>>>>>
>>>>> If my idea is correct, I will file this to JBS and upload patch to
>>>>> webrev.
>>>> Please only correct the description of MetaspaceSize.
>>>>
>>>> Jon
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>>
>>>>
>>
>
>


From thomas.schatzl at oracle.com  Tue Apr 15 10:06:22 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 15 Apr 2014 12:06:22 +0200
Subject: RFR (M): 8019342: G1: High "Other" time most likely due to card
	redirtying
In-Reply-To: <534BE25E.9070408@oracle.com>
References: <1397213631.2710.51.camel@cirrus>
	<1397215986.2710.52.camel@cirrus> <534BE25E.9070408@oracle.com>
Message-ID: <1397556382.2724.26.camel@cirrus>

Hi,

On Mon, 2014-04-14 at 15:27 +0200, Bengt Rutisson wrote:
> Hi Thomas,
> 
> Looks good.
> 
> A couple of minor things:
> 
> You made apply_closure_to_all_completed_buffers() and 
> par_apply_closure_to_all_completed_buffers() take the closure they 
> should apply as a parameter instead of looking it up in the _closure 
> instance variable. I like this a lot better, but why did you keep the 
> _closure instance variable for other methods 
> (iterate_closure_all_threads() and mut_process_buffer()). It would have 
> been nice to have the same pattern for all methods. If it is difficult 
> to change the others to take a closure as parameter I think I would 
> prefer to revert the apply methods to also use the instance variable.

I fixed that by making all methods use a closure parameter.
Mut_process_buffer() still uses the "internal" closure (renamed
_mut_process_closure) as it is called by the Java threads in a static
context, so you cannot really avoid having this member around.

_mut_process_closure is also passed in the DCQS constructor, and cannot
be set any more.

> 
> Not strictly related to your change, but it would make it easier to 
> understand you change:
> In G1CollectedHeap::check_ct_logs_at_safepoint() we start out by doing:
>    DirtyCardQueueSet& dcqs = JavaThread::dirty_card_queue_set();
> But in that method we still use JavaThread::dirty_card_queue_set() 
> explicitly twice. It would be nice to replace these calls with dcqs to 
> make it clear that it is the same instance.

Done.

> 
> These two formatting changes are unrelated to your other changes:
> 
> dirtyCardQueue.cpp:  165 BufferNode* 
> DirtyCardQueueSet::get_completed_buffer(int stop_at) {
> g1CollectedHeap.cpp:  173  YoungList::YoungList(G1CollectedHeap* g1h) :
> 
> I would prefer to leave those out.

Done.

New webrev at:
http://cr.openjdk.java.net/~tschatzl/8019342/webrev.1

Diff to previous (containing the changes due to the closure passing):
http://cr.openjdk.java.net/~tschatzl/8019342/webrev.1.diff

Testing:
jprt

Thanks,
  THomas





From thomas.schatzl at oracle.com  Tue Apr 15 10:23:50 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 15 Apr 2014 12:23:50 +0200
Subject: RFR (S): 8038930: G1CodeRootSet::test fails with
	assert(_num_chunks_handed_out == 0) failed: No elements must have been
	handed out yet
In-Reply-To: <534BF72D.3050408@oracle.com>
References: <1396448631.3183.14.camel@cirrus>
	<1397464432.2708.6.camel@cirrus> <534BF72D.3050408@oracle.com>
Message-ID: <1397557430.2724.33.camel@cirrus>

Hi,

On Mon, 2014-04-14 at 16:56 +0200, Bengt Rutisson wrote:
> 
> Hi Thomas,
> On 4/14/14 10:33 AM, Thomas Schatzl wrote:
> > Hi all,
> > 
> > On Wed, 2014-04-02 at 16:23 +0200, Thomas Schatzl wrote:
> > > Hi all,
> > > 
> > >   can I have reviews for the following fix for a test case?
> >   Bengt found a race situation where the test fails when compilation is
> > running while the test is run.
> > 
> > Instead of trying to find a way to synchronize the test with the
> > compiler, I changed the code to allow multiple code root chunk free
> > lists - the test uses one separate from the global one, so there are no
> > more synchronization problems, and the original change to remember the
> > number of already allocated code root chunks is superfluous too.
> > 
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8038930
> > 
> > Here is a new webrev:
> > http://cr.openjdk.java.net/~tschatzl/8038930/webrev.1/
> 
> This looks good to me.
> 
> I think I would have preferred passing exposing
> G1CodeRootSet::_default_chunk_manager and explicitly passing that when
> initializing HeapRegionRemSet::_code_roots rather than having the
> special treatment of the default value NULL in the G1CodeRootSet
> constructor. I'll leave it to you to decide.

This would require me to make the default chunk manager public. I want
to avoid that. Passing that reference would be the only valid use, no
other uses of this reference are desired.

If nobody else objects, I would like to keep the code as is.

> Otherwise it looks good.

Thanks,
  Thomas




From thomas.schatzl at oracle.com  Tue Apr 15 10:42:13 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 15 Apr 2014 12:42:13 +0200
Subject: RFR(S): JDK-8040002: Clean up code and code duplication in
	re-diryting cards for verification
In-Reply-To: <1397469592.2708.28.camel@cirrus>
References: <1397469592.2708.28.camel@cirrus>
Message-ID: <1397558533.2724.42.camel@cirrus>

Hi all,

  due to changes to 8019342: G1: High "Other" time most likely due to
card redirtying", this change had to be updated too.

On Mon, 2014-04-14 at 11:59 +0200, Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews for the following short cleanup? While implementing
> 8019342 I found that there is some opportunity to clean up code in the
> various card closures in G1.
> 
> There is some code duplication, and the verification card closure code
> still assumes the presence of a perm gen. There are also some hardcoded
> card table values for clean/dirty cards.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8040002
> 
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8040002/webrev/

New webrev:
http://cr.openjdk.java.net/~tschatzl/8040002/webrev.1/

Testing:
jprt

Thomas



From bengt.rutisson at oracle.com  Tue Apr 15 11:55:12 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 15 Apr 2014 13:55:12 +0200
Subject: RFR (M): 8019342: G1: High "Other" time most likely due to card
	redirtying
In-Reply-To: <1397556382.2724.26.camel@cirrus>
References: <1397213631.2710.51.camel@cirrus>	
	<1397215986.2710.52.camel@cirrus> <534BE25E.9070408@oracle.com>
	<1397556382.2724.26.camel@cirrus>
Message-ID: <534D1E20.6090506@oracle.com>


Hi Thomas,

Thanks for doing these cleanups!

Looks good!
Bengt


On 2014-04-15 12:06, Thomas Schatzl wrote:
> Hi,
>
> On Mon, 2014-04-14 at 15:27 +0200, Bengt Rutisson wrote:
>> Hi Thomas,
>>
>> Looks good.
>>
>> A couple of minor things:
>>
>> You made apply_closure_to_all_completed_buffers() and
>> par_apply_closure_to_all_completed_buffers() take the closure they
>> should apply as a parameter instead of looking it up in the _closure
>> instance variable. I like this a lot better, but why did you keep the
>> _closure instance variable for other methods
>> (iterate_closure_all_threads() and mut_process_buffer()). It would have
>> been nice to have the same pattern for all methods. If it is difficult
>> to change the others to take a closure as parameter I think I would
>> prefer to revert the apply methods to also use the instance variable.
> I fixed that by making all methods use a closure parameter.
> Mut_process_buffer() still uses the "internal" closure (renamed
> _mut_process_closure) as it is called by the Java threads in a static
> context, so you cannot really avoid having this member around.
>
> _mut_process_closure is also passed in the DCQS constructor, and cannot
> be set any more.
>
>> Not strictly related to your change, but it would make it easier to
>> understand you change:
>> In G1CollectedHeap::check_ct_logs_at_safepoint() we start out by doing:
>>     DirtyCardQueueSet& dcqs = JavaThread::dirty_card_queue_set();
>> But in that method we still use JavaThread::dirty_card_queue_set()
>> explicitly twice. It would be nice to replace these calls with dcqs to
>> make it clear that it is the same instance.
> Done.
>
>> These two formatting changes are unrelated to your other changes:
>>
>> dirtyCardQueue.cpp:  165 BufferNode*
>> DirtyCardQueueSet::get_completed_buffer(int stop_at) {
>> g1CollectedHeap.cpp:  173  YoungList::YoungList(G1CollectedHeap* g1h) :
>>
>> I would prefer to leave those out.
> Done.
>
> New webrev at:
> http://cr.openjdk.java.net/~tschatzl/8019342/webrev.1
>
> Diff to previous (containing the changes due to the closure passing):
> http://cr.openjdk.java.net/~tschatzl/8019342/webrev.1.diff
>
> Testing:
> jprt
>
> Thanks,
>    THomas
>
>
>



From bengt.rutisson at oracle.com  Tue Apr 15 12:00:53 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 15 Apr 2014 14:00:53 +0200
Subject: RFR (S): 8038930: G1CodeRootSet::test fails with
	assert(_num_chunks_handed_out
	== 0) failed: No elements must have been handed out yet
In-Reply-To: <1397557430.2724.33.camel@cirrus>
References: <1396448631.3183.14.camel@cirrus>	
	<1397464432.2708.6.camel@cirrus> <534BF72D.3050408@oracle.com>
	<1397557430.2724.33.camel@cirrus>
Message-ID: <534D1F75.7090304@oracle.com>


Hi Thomas,

On 2014-04-15 12:23, Thomas Schatzl wrote:
> Hi,
>
> On Mon, 2014-04-14 at 16:56 +0200, Bengt Rutisson wrote:
>> Hi Thomas,
>> On 4/14/14 10:33 AM, Thomas Schatzl wrote:
>>> Hi all,
>>>
>>> On Wed, 2014-04-02 at 16:23 +0200, Thomas Schatzl wrote:
>>>> Hi all,
>>>>
>>>>    can I have reviews for the following fix for a test case?
>>>    Bengt found a race situation where the test fails when compilation is
>>> running while the test is run.
>>>
>>> Instead of trying to find a way to synchronize the test with the
>>> compiler, I changed the code to allow multiple code root chunk free
>>> lists - the test uses one separate from the global one, so there are no
>>> more synchronization problems, and the original change to remember the
>>> number of already allocated code root chunks is superfluous too.
>>>
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8038930
>>>
>>> Here is a new webrev:
>>> http://cr.openjdk.java.net/~tschatzl/8038930/webrev.1/
>> This looks good to me.
>>
>> I think I would have preferred passing exposing
>> G1CodeRootSet::_default_chunk_manager and explicitly passing that when
>> initializing HeapRegionRemSet::_code_roots rather than having the
>> special treatment of the default value NULL in the G1CodeRootSet
>> constructor. I'll leave it to you to decide.
> This would require me to make the default chunk manager public. I want
> to avoid that. Passing that reference would be the only valid use, no
> other uses of this reference are desired.

Yes, that's what I meant. It's trading one ugliness for another ;)

> If nobody else objects, I would like to keep the code as is.

Ok. I'm fine with leaving it as it is.

Bengt

>
>> Otherwise it looks good.
> Thanks,
>    Thomas
>
>



From bengt.rutisson at oracle.com  Tue Apr 15 12:19:28 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 15 Apr 2014 14:19:28 +0200
Subject: RFR(S): JDK-8040002: Clean up code and code duplication in
	re-diryting cards for verification
In-Reply-To: <1397558533.2724.42.camel@cirrus>
References: <1397469592.2708.28.camel@cirrus> <1397558533.2724.42.camel@cirrus>
Message-ID: <534D23D0.5060109@oracle.com>


Hi Thomas,

Looks good! Very nice cleanup!

Bengt


On 2014-04-15 12:42, Thomas Schatzl wrote:
> Hi all,
>
>    due to changes to 8019342: G1: High "Other" time most likely due to
> card redirtying", this change had to be updated too.
>
> On Mon, 2014-04-14 at 11:59 +0200, Thomas Schatzl wrote:
>> Hi all,
>>
>>    can I have reviews for the following short cleanup? While implementing
>> 8019342 I found that there is some opportunity to clean up code in the
>> various card closures in G1.
>>
>> There is some code duplication, and the verification card closure code
>> still assumes the presence of a perm gen. There are also some hardcoded
>> card table values for clean/dirty cards.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8040002
>>
>> Webrev:
>> http://cr.openjdk.java.net/~tschatzl/8040002/webrev/
> New webrev:
> http://cr.openjdk.java.net/~tschatzl/8040002/webrev.1/
>
> Testing:
> jprt
>
> Thomas
>



From yasuenag at gmail.com  Tue Apr 15 13:38:17 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 15 Apr 2014 22:38:17 +0900
Subject: -XX:MetaspaceSize is correct?
In-Reply-To: <CAGFVN2DOW3aSqwNL2hMvQ4yj5CsD9reRjAhN2MfC46Nvue-Dxw@mail.gmail.com>
References: <5345498F.20904@gmail.com>	<5345C0F0.7020606@oracle.com>	<CAGFVN2Bmt0=w5sQ-m5qrBFvPcO2UmkPh1AGY5uskbUFRGfQ98g@mail.gmail.com>	<53468C96.6080107@gmail.com>	<534C6814.4050202@oracle.com>
	<CAGFVN2DOW3aSqwNL2hMvQ4yj5CsD9reRjAhN2MfC46Nvue-Dxw@mail.gmail.com>
Message-ID: <534D3649.9090506@gmail.com>

I uploaded new webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8039867/webrev.01/

Please review and sponsoring.


Yasumasa

On 04/15/2014 12:48 PM, Yasumasa Suenaga wrote:
> Jon,
>
> I agree with you.
>
> MetaspaceSize is used as minimum value when JVM shrink capacity in
> MetaspaceGC::compute_new_size() .
> So I will change description to "minimum" and upload new webrev.
>
>
> Yasumasa
>
> 2014-04-15 7:58 GMT+09:00, Jon Masamitsu <jon.masamitsu at oracle.com>:
>> Yasumasa,
>>
>> It's hard to describe what this parameter is in a single
>> sentence.  "high-water-mark" doesn't mean much unless
>> you know about how it is used in the GC.   Although
>> "initial" is not right in the description, "minimum" might
>> be closer to a good description.  I'm really not sure.
>>
>> Jon
>>
>> On 04/10/2014 05:20 AM, Yasumasa Suenaga wrote:
>>> I uploaded webrev:
>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8039867/webrev.00/
>>>
>>> Please review and sponsoring!
>>>
>>>
>>> Yasumasa
>>>
>>>
>>> On 04/10/2014 12:37 PM, Yasumasa Suenaga wrote:
>>>> Hi Jon,
>>>> Thank you for replying.
>>>>
>>>> I filed this issue as JDK-8039867: Incorrect description:
>>>> -XX:MetaspaceSize .
>>>>
>>>> I attached a patch to this entry.
>>>> I will upload webrev later.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>>
>>>> 2014-04-10 6:51 GMT+09:00, Jon Masamitsu <jon.masamitsu at oracle.com>:
>>>>> On 04/09/2014 06:22 AM, Yasumasa Suenaga wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I checked initial metaspace size through jcmd PerfCounter.print .
>>>>>> However, it seems to be incorrect:
>>>>>>
>>>>>>    - Java command:
>>>>>>     java -XX:-UseCompressedClassPointers -XX:+PrintFlagsFinal LongSleep
>>>>>>
>>>>>>    - Output from -XX:+PrintFlagsFinal:
>>>>>>       uintx MetaspaceSize                             =
>>>>>> 21807104                            {pd product}
>>>>>>
>>>>>>    - Result of "PerfCounter.print"
>>>>>> sun.gc.metaspace.capacity=4194304
>>>>>> sun.gc.metaspace.maxCapacity=8388608
>>>>>> sun.gc.metaspace.minCapacity=0
>>>>>>
>>>>>>
>>>>>> I checked metaspace.cpp, initial size of metaspace is detected by
>>>>>> InitialBootClassLoaderMetaspaceSize.
>>>>>> However, description of MetaspaceSize in globals.hpp is
>>>>>> "Initial size of Metaspaces (in bytes)" .
>>>>>>
>>>>>> Is description of MetaspaceSize is correct?
>>>>> Description is not correct.
>>>>>
>>>>>> And this behavior is correct?
>>>>> Behavior is correct.
>>>>>
>>>>>> I have two plan for this mismatch:
>>>>>>
>>>>>>    A) Change description of MetaspaceSize
>>>>>>     MetaspaceSize is used to HWM in metaspace.cpp .
>>>>>>     So we should change description for this behavior.
>>>>>> ------------
>>>>>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>>>>>> --- a/src/share/vm/runtime/globals.hpp  Fri Apr 04 10:04:44 2014 -0700
>>>>>> +++ b/src/share/vm/runtime/globals.hpp  Wed Apr 09 22:05:18 2014 +0900
>>>>>> @@ -3160,7 +3156,7 @@
>>>>>>              "non-daemon thread (in
>>>>>> bytes)")                                   \
>>>>>> \
>>>>>>      product_pd(uintx,
>>>>>> MetaspaceSize,                                          \
>>>>>> -          "Initial size of Metaspaces (in
>>>>>> bytes)")                          \
>>>>>> +          "Initial HWM of Metaspaces (in
>>>>>> bytes)")                           \
>>>>> Explain what HWM is if you're going to use it.
>>>>>
>>>>>> \
>>>>>>      product(uintx, MaxMetaspaceSize,
>>>>>> max_uintx,                               \
>>>>>>              "Maximum size of Metaspaces (in
>>>>>> bytes)")                          \
>>>>>> ------------
>>>>>>
>>>>>>    B) Remove InitialBootClassLoaderMetaspaceSize and use MetaspaceSize
>>>>>>     In currently, InitialBootClassLoaderMetaspaceSize is used to
>>>>>> initialize
>>>>>>     metaspace.
>>>>>>     InitialBootClassLoaderMetaspaceSize is only to use for it.
>>>>>>     Thus we should remove this option and use MetaspaceSize to
>>>>>> initialize
>>>>>>     metaspace.
>>>>> InitialBootClassLoaderMetaspaceSize is an optimization.  It allows
>>>>> approximately
>>>>> enough space for the system classes without repeated allocations of
>>>>> Metaspaces.
>>>>> Not everyone agrees with this optimization but I would like it kept.
>>>>>
>>>>>> ------------
>>>>>> diff -r 48ce2e6e1add src/share/vm/memory/metaspace.cpp
>>>>>> --- a/src/share/vm/memory/metaspace.cpp Fri Apr 04 10:04:44 2014 -0700
>>>>>> +++ b/src/share/vm/memory/metaspace.cpp Wed Apr 09 22:05:18 2014 +0900
>>>>>> @@ -3172,7 +3172,7 @@
>>>>>>    #endif
>>>>>>
>>>>>>        // Initialize these before initializing the VirtualSpaceList
>>>>>> -    _first_chunk_word_size = InitialBootClassLoaderMetaspaceSize /
>>>>>> BytesPerWord;
>>>>>> +    _first_chunk_word_size = MetaspaceSize / BytesPerWord;
>>>>>>        _first_chunk_word_size =
>>>>>> align_word_size_up(_first_chunk_word_size);
>>>>>>        // Make the first class chunk bigger than a medium chunk so it's
>>>>>> not put
>>>>>>        // on the medium chunk list.   The next chunk will be small and
>>>>>> progress
>>>>>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>>>>>> --- a/src/share/vm/runtime/globals.hpp  Fri Apr 04 10:04:44 2014 -0700
>>>>>> +++ b/src/share/vm/runtime/globals.hpp  Wed Apr 09 22:05:18 2014 +0900
>>>>>> @@ -2333,10 +2333,6 @@
>>>>>>      develop(bool, TraceClassLoaderData,
>>>>>> false,                                \
>>>>>>              "Trace class loader loader_data
>>>>>> lifetime")                        \
>>>>>> \
>>>>>> -  product(uintx,
>>>>>> InitialBootClassLoaderMetaspaceSize,                       \
>>>>>> -          NOT_LP64(2200*K)
>>>>>> LP64_ONLY(4*M),                                  \
>>>>>> -          "Initial size of the boot class loader data
>>>>>> metaspace")           \
>>>>>> - \
>>>>>>      product(bool, TraceGen0Time,
>>>>>> false,                                       \
>>>>>>              "Trace accumulated time for Gen 0
>>>>>> collection")                    \
>>>>>> \
>>>>>> ------------
>>>>>>
>>>>>> I prefer "B" .
>>>>>> Because, I guess many users think MetaspaceSize decides initial
>>>>>> metaspace size.
>>>>>>
>>>>>> If my idea is correct, I will file this to JBS and upload patch to
>>>>>> webrev.
>>>>> Please only correct the description of MetaspaceSize.
>>>>>
>>>>> Jon
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Yasumasa
>>>>>>
>>>>>
>>>
>>
>>


From jon.masamitsu at oracle.com  Tue Apr 15 14:24:00 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 15 Apr 2014 07:24:00 -0700
Subject: RFR(S): JDK-8040002: Clean up code and code duplication in
	re-diryting cards for verification
In-Reply-To: <1397469592.2708.28.camel@cirrus>
References: <1397469592.2708.28.camel@cirrus>
Message-ID: <534D4100.3030902@oracle.com>

Thomas,

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

Changes look good.

Just a clarification.

So the is_in_reserved() test was an attempt to
make do_card_ptr() faster?

  163   bool do_card_ptr(jbyte* card_ptr, uint worker_i) {
  164     if (_g1h->is_in_reserved(_ctbs->addr_for(card_ptr))) {
  165       _calls++;
  166       *card_ptr = 0;
  167     }
  168     return true;
  169   }


And the assertion checking that addr_for() does on the
address card_ptr is not needed?

Jon

On 04/14/2014 02:59 AM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for the following short cleanup? While implementing
> 8019342 I found that there is some opportunity to clean up code in the
> various card closures in G1.
>
> There is some code duplication, and the verification card closure code
> still assumes the presence of a perm gen. There are also some hardcoded
> card table values for clean/dirty cards.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8040002
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8040002/webrev/
>
> Testing:
> jprt
>
> Thanks,
>    Thomas
>
>



From thomas.schatzl at oracle.com  Wed Apr 16 08:59:40 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 16 Apr 2014 10:59:40 +0200
Subject: RFR(S): JDK-8040002: Clean up code and code duplication in
	re-diryting cards for verification
In-Reply-To: <534D4100.3030902@oracle.com>
References: <1397469592.2708.28.camel@cirrus> <534D4100.3030902@oracle.com>
Message-ID: <1397638780.12194.10.camel@cirrus>

Hi Jon,

On Tue, 2014-04-15 at 07:24 -0700, Jon Masamitsu wrote:
> Thomas,
> 
> http://cr.openjdk.java.net/~tschatzl/8040002/webrev/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html
> 
> Changes look good.
> 
> Just a clarification.
> 
> So the is_in_reserved() test was an attempt to
> make do_card_ptr() faster?
> 
>   163   bool do_card_ptr(jbyte* card_ptr, uint worker_i) {
>   164     if (_g1h->is_in_reserved(_ctbs->addr_for(card_ptr))) {
>   165       _calls++;
>   166       *card_ptr = 0;
>   167     }
>   168     return true;
>   169   }
> 
> 
> And the assertion checking that addr_for() does on the
> address card_ptr is not needed?

Actually I think the whole check is superfluous, also in jdk7.
Is_in_reserved() checks whether the card is in the heap (including perm
gen), and addr_for() also checks the same before and after converting
the card address to a heap address.

However cards can only ever be in the heap anyway - if they are not,
this is an error.

This check is almost like an instance of of "if (something_true) {...}
else { guarantee(!false, "paranoia"); }" seen in other places in G1
code.

I can add an assert here if you think it is useful.

Thomas




From thomas.schatzl at oracle.com  Wed Apr 16 09:17:02 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 16 Apr 2014 11:17:02 +0200
Subject: RFR (M): 8025813: G1: Code root marking unbalanced
In-Reply-To: <1396255905.2712.17.camel@cirrus>
References: <1396255905.2712.17.camel@cirrus>
Message-ID: <1397639822.12194.17.camel@cirrus>

Hi all,

On Mon, 2014-03-31 at 10:51 +0200, Thomas Schatzl wrote:
> Hi all,
> 
>   could I have reviews for the following change that parallelizes code
> root scan on a per region's code root chunk basis instead of on the code
> root set of an entire region basis.
> 
> This fixes some imbalances when scanning the code roots with some
> regions containing 90% of code roots.
> 
> The idea is to keep around a current code root chunk pointer for every
> region, that is claimed by the threads using a CAS.

  this change will get obsolete with class unloading changes, so I will
close it as won't fix unless somebody objects (and I get reviews :). 

Target version for this change moved to 8u40, and class unloading is
planned for 8u40 too.

In more detail, with class unloading enabled, this phase will completely
go away. With class unloading disabled, the CLDG scan during ext root
scan will mark all references from nmethods.

Thanks,
  Thomas




From mikael.gerdin at oracle.com  Wed Apr 16 11:23:04 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 16 Apr 2014 13:23:04 +0200
Subject: RFR (S): 8038930: G1CodeRootSet::test fails with
	assert(_num_chunks_handed_out == 0) failed: No elements must
	have been handed out yet
In-Reply-To: <1397464432.2708.6.camel@cirrus>
References: <1396448631.3183.14.camel@cirrus> <1397464432.2708.6.camel@cirrus>
Message-ID: <3189593.tzdh4kcr3N@mgerdin03>

Thomas,

On Monday 14 April 2014 10.33.52 Thomas Schatzl wrote:
> Hi all,
> 
> On Wed, 2014-04-02 at 16:23 +0200, Thomas Schatzl wrote:
> > Hi all,
> > 
> >   can I have reviews for the following fix for a test case?
> 
>   Bengt found a race situation where the test fails when compilation is
> running while the test is run.
> 
> Instead of trying to find a way to synchronize the test with the
> compiler, I changed the code to allow multiple code root chunk free
> lists - the test uses one separate from the global one, so there are no
> more synchronization problems, and the original change to remember the
> number of already allocated code root chunks is superfluous too.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8038930
> 
> Here is a new webrev:
> http://cr.openjdk.java.net/~tschatzl/8038930/webrev.1/


  86 size_t G1CodeRootChunkManager::static_mem_size() {
  87   return sizeof(this);
  88 }

Should be sizeof(*this), the type of "this" is "G1CodeRootChunkManager *const"

I don't need to re-review that change.

/Mikael

> 
> Testing:
> Failing test with -Xcomp, jprt
> 
> > This test case does some basic code validation on recently introduced
> > code root memory management for G1 introduced recently (JDK-8035406).
> > 
> > It assumed that before running the test, no code root memory has been
> > handed out.
> > 
> > The problem is now, when running with -Xcomp, before the internal VM
> > tests (and this test) are run, it is likely that compiled code already
> > did some code root allocations.
> > 
> > So the test needs to be aware of that, and not assume that the number of
> > code root memory handed out is not zero.
> > 
> > This change fixes that assumption.
> > 
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8038930
> > 
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8038930/webrev/
> > 
> > Testing:
> > jprt, manual invocation of test case with -Xcomp
> 
> Thanks,
>  Thomas



From lev.priima at oracle.com  Wed Apr 16 11:58:46 2014
From: lev.priima at oracle.com (Lev Priima)
Date: Wed, 16 Apr 2014 15:58:46 +0400
Subject: [9] RFR (XS): 8039260:
	c.o.j.t.ProcessTools::createJavaProcessBuilder(boolean, 
	String... ) must also take test.java.opts
In-Reply-To: <5347D5F8.4060800@oracle.com>
References: <5347D5F8.4060800@oracle.com>
Message-ID: <534E7076.5050604@oracle.com>

adding other aliases explicitly

Lev

On 04/11/2014 03:46 PM, Lev Priima wrote:
> Hi all,
>
> Please review small patch:
>
> http://cr.openjdk.java.net/~iignatyev/lpriima/8039260/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8039260
> 6 lines changed: 0 ins; 3 del; 3 mod;
>
> Problem:
> method c.o.j.t.ProcessTools::createJavaProcessBuilder(boolean 
> addTestVmOptions, String... command) starts "java" launcher without 
> passing to it "test.java.opts" received from jtreg harness.
>
> Fix:
> Add both "test.vm.opts" and "test.java.opts" to newly created java 
> process by new parameter name "addTestVmAndJavaOptions"
>
> Testing: jprt default set + all hotspot regression tests
>



From bengt.rutisson at oracle.com  Wed Apr 16 13:46:40 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 16 Apr 2014 15:46:40 +0200
Subject: RFR (M):  JDK-8040722: G1: Clean up usages of heap_region_containing
Message-ID: <534E89C0.8020706@oracle.com>


Hi everyone,

Could I please have a few reviews of this cleanup?

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

Background:

Before the perm gen was removed 
G1CollectedHeap::heap_region_containing() could return NULL for 
addresses in the perm gen. This means that a lot of code had to check 
the result since it could potentially be NULL.

Now the only reason to return NULL is if the address passed in NULL. In 
many places it is possible to know that the address is not NULL and in 
the other places it is just as simple to check the address for NULL 
before calling G1CollectedHeap::heap_region_containing() rather than 
checking for NULL after having called it.

So, to simplify the code a bit we can assert that 
G1CollectedHeap::heap_region_containing() never returns NULL and then 
only check before we call it in the places where we would otherwise have 
passed NULL to it.

Thanks,
Bengt


From jon.masamitsu at oracle.com  Wed Apr 16 14:23:56 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 16 Apr 2014 07:23:56 -0700
Subject: RFR(S): JDK-8040002: Clean up code and code duplication in
	re-diryting cards for verification
In-Reply-To: <1397638780.12194.10.camel@cirrus>
References: <1397469592.2708.28.camel@cirrus> <534D4100.3030902@oracle.com>
	<1397638780.12194.10.camel@cirrus>
Message-ID: <534E927C.10306@oracle.com>


On 4/16/2014 1:59 AM, Thomas Schatzl wrote:
> Hi Jon,
>
> On Tue, 2014-04-15 at 07:24 -0700, Jon Masamitsu wrote:
>> Thomas,
>>
>> http://cr.openjdk.java.net/~tschatzl/8040002/webrev/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html
>>
>> Changes look good.
>>
>> Just a clarification.
>>
>> So the is_in_reserved() test was an attempt to
>> make do_card_ptr() faster?
>>
>>    163   bool do_card_ptr(jbyte* card_ptr, uint worker_i) {
>>    164     if (_g1h->is_in_reserved(_ctbs->addr_for(card_ptr))) {
>>    165       _calls++;
>>    166       *card_ptr = 0;
>>    167     }
>>    168     return true;
>>    169   }
>>
>>
>> And the assertion checking that addr_for() does on the
>> address card_ptr is not needed?
> Actually I think the whole check is superfluous, also in jdk7.
> Is_in_reserved() checks whether the card is in the heap (including perm
> gen), and addr_for() also checks the same before and after converting
> the card address to a heap address.
>
> However cards can only ever be in the heap anyway - if they are not,
> this is an error.
>
> This check is almost like an instance of of "if (something_true) {...}
> else { guarantee(!false, "paranoia"); }" seen in other places in G1
> code.

Yes, it has the feel of paranoia.

>
> I can add an assert here if you think it is useful.

No need for assertion checking.  If something is wrong, it should break
in an obvious way and we're getting too slow in fastdebug builds as
it is.

Jon

>
> Thomas
>
>



From michal at frajt.eu  Wed Apr 16 14:36:38 2014
From: michal at frajt.eu (Michal Frajt)
Date: Wed, 16 Apr 2014 16:36:38 +0200
Subject: =?utf-8?b?UmU6IFJlcXVlc3QgZm9yIHJldmlldzogODAzODI2NTogQ01TOiBlbmFi?=
	=?utf-8?b?bGUgdGltZSBiYXNlZCB0cmlnZ2VyaW5nIG9mIGNvbmN1cnJlbnQgY3lj?=
	=?utf-8?b?bGVz?=
In-Reply-To: <534BFDA0.9090803@oracle.com>
References: =?iso-8859-1?q?=3C1DDCA93502632C4DA22E9EE199CE907C015FAA93A0=40SE0025?=
	=?iso-8859-1?q?93=2Ecs=2Ecommerzbank=2Ecom=3E=09=3CN3AW5D=246641B5580?=
	=?iso-8859-1?q?48C64803233A598D2C464DA=40frajt=2Eeu=3E_=3C1666248=2Et?=
	=?iso-8859-1?q?j7xVnjxql=40mgerdin03=3E_=3C534BFDA0=2E9090803=40oracl?=
	=?iso-8859-1?q?e=2Ecom=3E?=
Message-ID: <N44OL3$33CE773F09B8356F3A783DFFAAD7C268@frajt.eu>

Hi Bengt,

We will provide you the new patch next week. All Mikael's comments will be addressed.

Best regards,
Michal


Od: "hotspot-gc-dev" hotspot-gc-dev-bounces at openjdk.java.net
Komu: "Mikael Gerdin" mikael.gerdin at oracle.com, hotspot-gc-dev at openjdk.java.net
Kopie: 
Datum: Mon, 14 Apr 2014 17:24:16 +0200
P?edmet: Re: Request for review: 8038265: CMS: enable time based triggering of concurrent cycles


> 
> Hi Michal,
> 
> I think the change looks good modulo the comments that Mikael has. If 
> you fix those I can help you with a new webrev and then push this change.
> 
> Thanks,
> Bengt
> 
> 
> On 2014-04-01 11:52, Mikael Gerdin wrote:
> > Hi Michal,
> >
> > On Monday 31 March 2014 14.32.01 Michal Frajt wrote:
> >> Hi all,could you please review the following change we prepared together
> >> with Bengt? The change adds new CMSTriggerInterval flag which allows to
> >> invoke CMS collections periodically. The periodically running CMS
> >> collections are helping us with replacing the deprecated incremental CMS
> >> collector. We believe it might be useful for other customers currently
> >> using the CMS in the incremental mode.Bugs:
> >> https://bugs.openjdk.java.net/browse/JDK-8038265
> >>
> >> Webrev:
> >> http://cr.openjdk.java.net/~brutisso/8038265/webrev.00/
> > If the addition of this functionality helps you replace iCMS then that's
> > great! I think this code change is simple and easy to understand.
> >
> > I just have some small (mostly stylistic) comments:
> >
> > 	The other time output in PrintCMSInitiationStatistics seems to use 	
> > 	%3.7f as the format specifier instead of %g.
> >
> > 1515     gclog_or_tty->print_cr("cms_time_since_begin=%g",
> > stats().cms_time_since_begin());
> > 1516     gclog_or_tty->print_cr("cms_time_since_end=%g",
> > stats().cms_time_since_end());
> >
> >
> > 	The HotSpot style is to have a space between if and the opening brace,
> > 	can you please change the if here:
> >
> > 1588     if(stats().cms_time_since_begin() >= (CMSTriggerInterval / ((double)
> > MILLIUNITS))) {
> > 1589       if (Verbose && PrintGCDetails) {
> >
> > 	And here:
> >
> > 1590         if(stats().valid()) {
> >
> > 	We usually align the parameters on the second line with the opening 	
> > 	brace on the function call, something like:
> >
> > gclog_or_tty->print_cr(foo, bar,
> >                         stats().baz());
> >
> > 1591           gclog_or_tty->print_cr("CMSCollector: collect because of
> > trigger interval (time since last begin %g secs)",
> > 1592             stats().cms_time_since_begin());
> > 1593         } else {
> >
> > 	You pass in cms_time_since_begin() but don't actually use that value 	
> > 	in the else branch.
> >
> > 1594           gclog_or_tty->print_cr("CMSCollector: collect because of
> > trigger interval (first collection)",
> > 1595             stats().cms_time_since_begin());
> > 1596         }
> > 1597       }
> >
> > /Mikael
> >
> >
> >> Thanks,
> >> Michal
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140416/b2b1e348/attachment.htm>

From jon.masamitsu at oracle.com  Wed Apr 16 16:06:12 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 16 Apr 2014 09:06:12 -0700
Subject: RFR (M): JDK-8040722: G1: Clean up usages of
	heap_region_containing
In-Reply-To: <534E89C0.8020706@oracle.com>
References: <534E89C0.8020706@oracle.com>
Message-ID: <534EAA74.40304@oracle.com>

Bengt,

http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp.frames.html
>    45 G1CollectedHeap::heap_region_containing_raw(const T addr) const {
>    46   assert(addr != NULL, "invariant");
heap_region_containing_raw() does an assertion check against
null and heap_region_containing() uses heap_region_containing_raw()
so is the null checking assertion at calls to heap_region_containing() 
useful?
For example here

http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html

2953 Space* G1CollectedHeap::space_containing(const void* addr) const {
2954   assert(addr != NULL, "invariant");
2955   return heap_region_containing(addr);

http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp.frames.html

>    32   assert(addr != NULL, "addr must be != NULL");
>    33   assert(addr < heap_end(),
>    34                 err_msg("addr: "PTR_FORMAT" end: "PTR_FORMAT, addr, heap_end()));
>    35   assert(addr >= heap_bottom(),
>    36         err_msg("addr: "PTR_FORMAT" bottom: "PTR_FORMAT, addr, heap_bottom()));
>    37

Don't need assertion at 32.  Assertion at 35 should caught the addr 
!=NULL case or
heap_bottom() is NULL in which case addr == NULL is a legal address.

heap_region_containing_raw() no longer does the check for 
continuousHumongous.
heap_region_containing_raw() is called from lots of places.   For example,

  130 inline void ConcurrentMark::count_region(MemRegion mr, uint worker_id) {
  131   HeapWord* addr = mr.start();
  132   HeapRegion* hr = _g1h->heap_region_containing_raw(addr);
  133   count_region(mr, hr, worker_id);
  134 }

Is that OK?  Should it now call heap_region_containing()?

Maybe we can improve on the name heap_region_containing_raw()
(the "raw" conveying little information).

Would

heap_region_containing_raw -> 
heap_region_containing_ignore_continuousHumongous

be an improvement.  A bit long, I'll admit.  I'm OK with
heap_region_containing_ICH if the declaration explained what
the ICH stood for.

Jon

On 4/16/2014 6:46 AM, Bengt Rutisson wrote:
>
> Hi everyone,
>
> Could I please have a few reviews of this cleanup?
>
> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/
>
> Background:
>
> Before the perm gen was removed 
> G1CollectedHeap::heap_region_containing() could return NULL for 
> addresses in the perm gen. This means that a lot of code had to check 
> the result since it could potentially be NULL.
>
> Now the only reason to return NULL is if the address passed in NULL. 
> In many places it is possible to know that the address is not NULL and 
> in the other places it is just as simple to check the address for NULL 
> before calling G1CollectedHeap::heap_region_containing() rather than 
> checking for NULL after having called it.
>
> So, to simplify the code a bit we can assert that 
> G1CollectedHeap::heap_region_containing() never returns NULL and then 
> only check before we call it in the places where we would otherwise 
> have passed NULL to it.
>
> Thanks,
> Bengt



From volker.simonis at gmail.com  Wed Apr 16 16:38:53 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 16 Apr 2014 18:38:53 +0200
Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
In-Reply-To: <1396357031.2707.13.camel@cirrus>
References: <4295855A5C1DE049A61835A1887419CC2CEAAA44@DEWDFEMB12A.global.corp.sap>
	<533A7A0E.5040100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEAC068@DEWDFEMB12A.global.corp.sap>
	<533A8FD8.3090400@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEAC0A6@DEWDFEMB12A.global.corp.sap>
	<1396357031.2707.13.camel@cirrus>
Message-ID: <CA+3eh13+AoGFHG2wDQDmCoQjzOhEfOXdzDB757vWFsDu_vgMqg@mail.gmail.com>

Hi Thomas,

thanks for sponsoring this change.

I just wonder why the downported change in jdk8u (
http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/rev/bfdf528be8e8) is
attributed to you and not to Goetz?
In the jdk9 repositories (
http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/4c16a27793eb) Goetz is
correctly mentioned as the author.

Regards,
Volker



On Tue, Apr 1, 2014 at 2:57 PM, Thomas Schatzl <thomas.schatzl at oracle.com>wrote:

> Hi Goetz,
>
> On Tue, 2014-04-01 at 10:24 +0000, Lindenmaier, Goetz wrote:
> > Sure!  I updated the webrev accordingly.
>
>   looks good to me.
>
> I will sponsor the change.
>
> Thanks,
>   Thomas
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140416/28d4913a/attachment.htm>

From vladimir.kozlov at oracle.com  Wed Apr 16 18:01:01 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 16 Apr 2014 11:01:01 -0700
Subject: [9] RFR (XS): 8039260:
	c.o.j.t.ProcessTools::createJavaProcessBuilder(boolean, 
	String... ) must also take test.java.opts
In-Reply-To: <534E7076.5050604@oracle.com>
References: <5347D5F8.4060800@oracle.com> <534E7076.5050604@oracle.com>
Message-ID: <534EC55D.6080604@oracle.com>

Looks good to me.

Thanks,
Vladimir

On 4/16/14 4:58 AM, Lev Priima wrote:
> adding other aliases explicitly
>
> Lev
>
> On 04/11/2014 03:46 PM, Lev Priima wrote:
>> Hi all,
>>
>> Please review small patch:
>>
>> http://cr.openjdk.java.net/~iignatyev/lpriima/8039260/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8039260
>> 6 lines changed: 0 ins; 3 del; 3 mod;
>>
>> Problem:
>> method c.o.j.t.ProcessTools::createJavaProcessBuilder(boolean
>> addTestVmOptions, String... command) starts "java" launcher without
>> passing to it "test.java.opts" received from jtreg harness.
>>
>> Fix:
>> Add both "test.vm.opts" and "test.java.opts" to newly created java
>> process by new parameter name "addTestVmAndJavaOptions"
>>
>> Testing: jprt default set + all hotspot regression tests
>>
>


From thomas.schatzl at oracle.com  Wed Apr 16 19:04:12 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 16 Apr 2014 21:04:12 +0200
Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
In-Reply-To: <CA+3eh13+AoGFHG2wDQDmCoQjzOhEfOXdzDB757vWFsDu_vgMqg@mail.gmail.com>
References: <4295855A5C1DE049A61835A1887419CC2CEAAA44@DEWDFEMB12A.global.corp.sap>
	<533A7A0E.5040100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEAC068@DEWDFEMB12A.global.corp.sap>
	<533A8FD8.3090400@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEAC0A6@DEWDFEMB12A.global.corp.sap>
	<1396357031.2707.13.camel@cirrus>
	<CA+3eh13+AoGFHG2wDQDmCoQjzOhEfOXdzDB757vWFsDu_vgMqg@mail.gmail.com>
Message-ID: <1397675052.6470.13.camel@cirrus>

Hi,

On Wed, 2014-04-16 at 18:38 +0200, Volker Simonis wrote:
> Hi Thomas,
>
> thanks for sponsoring this change.
>
> I just wonder why the downported change in jdk8u
> (http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/rev/bfdf528be8e8) is
> attributed to you and not to Goetz? 
> In the jdk9 repositories
> (http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/4c16a27793eb) Goetz
> is correctly mentioned as the author.

  that's my fault. When committing the backport a few days later, I
forgot to make Goetz the author (i.e. did not use "hg commit -u goetz",
or did not do a straight import of that patch - I do not remember). I
never intended to claim authorship for the change/commit.

There were no changes in the backport, just a straight re-commit. So
there was no review necessary. From the bugtracker (and this mail
thread) it should be clear (at least now) that this is "only" a
backport, and the reason for this difference human error.

Unfortunately the commit message cannot be changed any more.

Interestingly the push hook did not complain that the author is also
mentioned as reviewer :) (Then again, Stefan K is sufficient to pass).

I will try to be more wary of this next time. I hope this poses no
problem.

Sorry,
  Thomas




From bengt.rutisson at oracle.com  Wed Apr 16 19:08:06 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 16 Apr 2014 21:08:06 +0200
Subject: RFR (M): JDK-8040722: G1: Clean up usages of
	heap_region_containing
In-Reply-To: <534EAA74.40304@oracle.com>
References: <534E89C0.8020706@oracle.com> <534EAA74.40304@oracle.com>
Message-ID: <534ED516.1000804@oracle.com>


Hi Jon,

Thanks for looking at this!

On 4/16/14 6:06 PM, Jon Masamitsu wrote:
> Bengt,
>
> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp.frames.html 
>
>>    45 G1CollectedHeap::heap_region_containing_raw(const T addr) const {
>>    46   assert(addr != NULL, "invariant");
> heap_region_containing_raw() does an assertion check against
> null and heap_region_containing() uses heap_region_containing_raw()
> so is the null checking assertion at calls to heap_region_containing() 
> useful?
> For example here
>
> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html 
>
>
> 2953 Space* G1CollectedHeap::space_containing(const void* addr) const {
> 2954   assert(addr != NULL, "invariant");
> 2955   return heap_region_containing(addr);

I'm fine with removing these asserts, I just figured that it would be 
nice to catch any issues one frame earlier than in 
heap_region_containing(). But provided that we get good stack traces I 
guess it is fine to let the assert in heap_region_containing_raw() catch 
the issues.

Unless anybody else objects I'll remove those extra asserts.
>
> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp.frames.html 
>
>
>>    32   assert(addr != NULL, "addr must be != NULL");
>>    33   assert(addr < heap_end(),
>>    34                 err_msg("addr: "PTR_FORMAT" end: "PTR_FORMAT, 
>> addr, heap_end()));
>>    35   assert(addr >= heap_bottom(),
>>    36         err_msg("addr: "PTR_FORMAT" bottom: "PTR_FORMAT, addr, 
>> heap_bottom()));
>>    37
>
> Don't need assertion at 32.  Assertion at 35 should caught the addr 
> !=NULL case or
> heap_bottom() is NULL in which case addr == NULL is a legal address.

Right. I was actually going back and forth on this assert anyway. I'll 
remove it.

>
> heap_region_containing_raw() no longer does the check for 
> continuousHumongous.
> heap_region_containing_raw() is called from lots of places.   For 
> example,
>
>  130 inline void ConcurrentMark::count_region(MemRegion mr, uint 
> worker_id) {
>  131   HeapWord* addr = mr.start();
>  132   HeapRegion* hr = _g1h->heap_region_containing_raw(addr);
>  133   count_region(mr, hr, worker_id);
>  134 }
>
> Is that OK?  Should it now call heap_region_containing()?

I think you missed that heap_region_containing_raw() and 
heap_region_containing() have switched places in 
g1CollectedHeap.inline.hpp. I had to do that to get the inlining right 
now when heap_region_containing() calls heap_region_containing_raw().

So, heap_region_containing_raw() has not changed. Thus, all calls to it 
should still be correct.

>
> Maybe we can improve on the name heap_region_containing_raw()
> (the "raw" conveying little information).
>
> Would
>
> heap_region_containing_raw -> 
> heap_region_containing_ignore_continuousHumongous
>
> be an improvement.  A bit long, I'll admit.  I'm OK with
> heap_region_containing_ICH if the declaration explained what
> the ICH stood for.

I agree that heap_region_containing_raw() is not a great name. However, 
it does not ignore continues humongous regions. It is 
heap_region_containing() that does that. So, I guess your naming 
suggestion would be for heap_region_containing() to change to 
heap_region_containing_ignore_continues_humongous(), right?

With my patch for allocating objects into the last continues region of a 
humongous object heap_region_containing() will also be able to return 
continues regions occasionally. So, I'm not convinced about the name.

Would it be ok to leave the names as they are for now?

Thanks,
Bengt
>
> Jon
>
> On 4/16/2014 6:46 AM, Bengt Rutisson wrote:
>>
>> Hi everyone,
>>
>> Could I please have a few reviews of this cleanup?
>>
>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/
>>
>> Background:
>>
>> Before the perm gen was removed 
>> G1CollectedHeap::heap_region_containing() could return NULL for 
>> addresses in the perm gen. This means that a lot of code had to check 
>> the result since it could potentially be NULL.
>>
>> Now the only reason to return NULL is if the address passed in NULL. 
>> In many places it is possible to know that the address is not NULL 
>> and in the other places it is just as simple to check the address for 
>> NULL before calling G1CollectedHeap::heap_region_containing() rather 
>> than checking for NULL after having called it.
>>
>> So, to simplify the code a bit we can assert that 
>> G1CollectedHeap::heap_region_containing() never returns NULL and then 
>> only check before we call it in the places where we would otherwise 
>> have passed NULL to it.
>>
>> Thanks,
>> Bengt
>



From jon.masamitsu at oracle.com  Wed Apr 16 23:15:58 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 16 Apr 2014 16:15:58 -0700
Subject: RFR (M): JDK-8040722: G1: Clean up usages of
	heap_region_containing
In-Reply-To: <534ED516.1000804@oracle.com>
References: <534E89C0.8020706@oracle.com> <534EAA74.40304@oracle.com>
	<534ED516.1000804@oracle.com>
Message-ID: <534F0F2E.9060606@oracle.com>


On 4/16/2014 12:08 PM, Bengt Rutisson wrote:
>
> Hi Jon,
>
> Thanks for looking at this!
>
> On 4/16/14 6:06 PM, Jon Masamitsu wrote:
>> Bengt,
>>
>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp.frames.html 
>>
>>>    45 G1CollectedHeap::heap_region_containing_raw(const T addr) const {
>>>    46   assert(addr != NULL, "invariant");
>> heap_region_containing_raw() does an assertion check against
>> null and heap_region_containing() uses heap_region_containing_raw()
>> so is the null checking assertion at calls to 
>> heap_region_containing() useful?
>> For example here
>>
>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html 
>>
>>
>> 2953 Space* G1CollectedHeap::space_containing(const void* addr) const {
>> 2954   assert(addr != NULL, "invariant");
>> 2955   return heap_region_containing(addr);
>
> I'm fine with removing these asserts, I just figured that it would be 
> nice to catch any issues one frame earlier than in 
> heap_region_containing(). But provided that we get good stack traces I 
> guess it is fine to let the assert in heap_region_containing_raw() 
> catch the issues.
>
> Unless anybody else objects I'll remove those extra asserts.

Seems 1 less line of code in several places but I'm fine with either way.

>>
>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp.frames.html 
>>
>>
>>>    32   assert(addr != NULL, "addr must be != NULL");
>>>    33   assert(addr < heap_end(),
>>>    34                 err_msg("addr: "PTR_FORMAT" end: "PTR_FORMAT, 
>>> addr, heap_end()));
>>>    35   assert(addr >= heap_bottom(),
>>>    36         err_msg("addr: "PTR_FORMAT" bottom: "PTR_FORMAT, addr, 
>>> heap_bottom()));
>>>    37
>>
>> Don't need assertion at 32.  Assertion at 35 should caught the addr 
>> !=NULL case or
>> heap_bottom() is NULL in which case addr == NULL is a legal address.
>
> Right. I was actually going back and forth on this assert anyway. I'll 
> remove it.

Thanks.

>
>>
>> heap_region_containing_raw() no longer does the check for 
>> continuousHumongous.
>> heap_region_containing_raw() is called from lots of places. For example,
>>
>>  130 inline void ConcurrentMark::count_region(MemRegion mr, uint 
>> worker_id) {
>>  131   HeapWord* addr = mr.start();
>>  132   HeapRegion* hr = _g1h->heap_region_containing_raw(addr);
>>  133   count_region(mr, hr, worker_id);
>>  134 }
>>
>> Is that OK?  Should it now call heap_region_containing()?
>
> I think you missed that heap_region_containing_raw() and 
> heap_region_containing() have switched places in 
> g1CollectedHeap.inline.hpp. I had to do that to get the inlining right 
> now when heap_region_containing() calls heap_region_containing_raw().
>
> So, heap_region_containing_raw() has not changed. Thus, all calls to 
> it should still be correct.

Ok.

>
>>
>> Maybe we can improve on the name heap_region_containing_raw()
>> (the "raw" conveying little information).
>>
>> Would
>>
>> heap_region_containing_raw -> 
>> heap_region_containing_ignore_continuousHumongous
>>
>> be an improvement.  A bit long, I'll admit.  I'm OK with
>> heap_region_containing_ICH if the declaration explained what
>> the ICH stood for.
>
> I agree that heap_region_containing_raw() is not a great name. 
> However, it does not ignore continues humongous regions. It is 
> heap_region_containing() that does that. So, I guess your naming 
> suggestion would be for heap_region_containing() to change to 
> heap_region_containing_ignore_continues_humongous(), right?
>
> With my patch for allocating objects into the last continues region of 
> a humongous object heap_region_containing() will also be able to 
> return continues regions occasionally. So, I'm not convinced about the 
> name.
>
> Would it be ok to leave the names as they are for now?

That's fine.  That will give us a chance to come up with an
even better name.

Reviewed.

Jon

>
> Thanks,
> Bengt
>>
>> Jon
>>
>> On 4/16/2014 6:46 AM, Bengt Rutisson wrote:
>>>
>>> Hi everyone,
>>>
>>> Could I please have a few reviews of this cleanup?
>>>
>>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/
>>>
>>> Background:
>>>
>>> Before the perm gen was removed 
>>> G1CollectedHeap::heap_region_containing() could return NULL for 
>>> addresses in the perm gen. This means that a lot of code had to 
>>> check the result since it could potentially be NULL.
>>>
>>> Now the only reason to return NULL is if the address passed in NULL. 
>>> In many places it is possible to know that the address is not NULL 
>>> and in the other places it is just as simple to check the address 
>>> for NULL before calling G1CollectedHeap::heap_region_containing() 
>>> rather than checking for NULL after having called it.
>>>
>>> So, to simplify the code a bit we can assert that 
>>> G1CollectedHeap::heap_region_containing() never returns NULL and 
>>> then only check before we call it in the places where we would 
>>> otherwise have passed NULL to it.
>>>
>>> Thanks,
>>> Bengt
>>
>



From poonam.bajaj at oracle.com  Thu Apr 17 01:03:51 2014
From: poonam.bajaj at oracle.com (Poonam Bajaj)
Date: Thu, 17 Apr 2014 06:33:51 +0530
Subject: Review request(7u): JDK-8010738: G1: Output for full GCs with
	+PrintGCDetails should contain perm gen/meta data size change info
Message-ID: <534F2877.50303@oracle.com>

Hi,

Could I have reviews for the following fix:

JDK-8010738 <https://bugs.openjdk.java.net/browse/JDK-8010738>: G1: 
Output for full GCs with +PrintGCDetails should contain perm gen/meta 
data size change info
webrev: http://cr.openjdk.java.net/~poonam/8010738/webrev.00/

With JDK7 G1GC when we use -XX:+PrintGCDetails option, PermGen 
information does not get printed in the Full GC logs as shown below:
[Full GC 16M->16M(20M), 0.7055536 secs]
    [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 
16.7M(20.0M)->16.7M(20.0M)]

PermGen info should also get printed with Full GC info similar to what 
other garbage collectors report. These changes are backport of the fix 
in jdk8 where MetaSpace info gets printed in the Full GC logs.

With the fix the output looks like:
[Full GC 16M->16M(20M), 0.6763478 secs]
    [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 
16.7M(20.0M)->16.7M(20.0M)], [Perm: 1725K->1725K(16384K)]


Thanks,
Poonam

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

From bengt.rutisson at oracle.com  Thu Apr 17 08:26:22 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 17 Apr 2014 10:26:22 +0200
Subject: RFR (M): JDK-8040722: G1: Clean up usages of
	heap_region_containing
In-Reply-To: <534F0F2E.9060606@oracle.com>
References: <534E89C0.8020706@oracle.com> <534EAA74.40304@oracle.com>
	<534ED516.1000804@oracle.com> <534F0F2E.9060606@oracle.com>
Message-ID: <534F902E.4060200@oracle.com>


Hi again,

Here's an updated webrev:
http://cr.openjdk.java.net/~brutisso/8040722/webrev.01/

And here's the incremental change compared to the previous one:
http://cr.openjdk.java.net/~brutisso/8040722/webrev.00-01.diff/

Thanks,
Bengt


On 2014-04-17 01:15, Jon Masamitsu wrote:
>
> On 4/16/2014 12:08 PM, Bengt Rutisson wrote:
>>
>> Hi Jon,
>>
>> Thanks for looking at this!
>>
>> On 4/16/14 6:06 PM, Jon Masamitsu wrote:
>>> Bengt,
>>>
>>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp.frames.html 
>>>
>>>>    45 G1CollectedHeap::heap_region_containing_raw(const T addr) 
>>>> const {
>>>>    46   assert(addr != NULL, "invariant");
>>> heap_region_containing_raw() does an assertion check against
>>> null and heap_region_containing() uses heap_region_containing_raw()
>>> so is the null checking assertion at calls to 
>>> heap_region_containing() useful?
>>> For example here
>>>
>>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html 
>>>
>>>
>>> 2953 Space* G1CollectedHeap::space_containing(const void* addr) const {
>>> 2954   assert(addr != NULL, "invariant");
>>> 2955   return heap_region_containing(addr);
>>
>> I'm fine with removing these asserts, I just figured that it would be 
>> nice to catch any issues one frame earlier than in 
>> heap_region_containing(). But provided that we get good stack traces 
>> I guess it is fine to let the assert in heap_region_containing_raw() 
>> catch the issues.
>>
>> Unless anybody else objects I'll remove those extra asserts.
>
> Seems 1 less line of code in several places but I'm fine with either way.
>
>>>
>>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp.frames.html 
>>>
>>>
>>>>    32   assert(addr != NULL, "addr must be != NULL");
>>>>    33   assert(addr < heap_end(),
>>>>    34                 err_msg("addr: "PTR_FORMAT" end: "PTR_FORMAT, 
>>>> addr, heap_end()));
>>>>    35   assert(addr >= heap_bottom(),
>>>>    36         err_msg("addr: "PTR_FORMAT" bottom: "PTR_FORMAT, 
>>>> addr, heap_bottom()));
>>>>    37
>>>
>>> Don't need assertion at 32.  Assertion at 35 should caught the addr 
>>> !=NULL case or
>>> heap_bottom() is NULL in which case addr == NULL is a legal address.
>>
>> Right. I was actually going back and forth on this assert anyway. 
>> I'll remove it.
>
> Thanks.
>
>>
>>>
>>> heap_region_containing_raw() no longer does the check for 
>>> continuousHumongous.
>>> heap_region_containing_raw() is called from lots of places. For 
>>> example,
>>>
>>>  130 inline void ConcurrentMark::count_region(MemRegion mr, uint 
>>> worker_id) {
>>>  131   HeapWord* addr = mr.start();
>>>  132   HeapRegion* hr = _g1h->heap_region_containing_raw(addr);
>>>  133   count_region(mr, hr, worker_id);
>>>  134 }
>>>
>>> Is that OK?  Should it now call heap_region_containing()?
>>
>> I think you missed that heap_region_containing_raw() and 
>> heap_region_containing() have switched places in 
>> g1CollectedHeap.inline.hpp. I had to do that to get the inlining 
>> right now when heap_region_containing() calls 
>> heap_region_containing_raw().
>>
>> So, heap_region_containing_raw() has not changed. Thus, all calls to 
>> it should still be correct.
>
> Ok.
>
>>
>>>
>>> Maybe we can improve on the name heap_region_containing_raw()
>>> (the "raw" conveying little information).
>>>
>>> Would
>>>
>>> heap_region_containing_raw -> 
>>> heap_region_containing_ignore_continuousHumongous
>>>
>>> be an improvement.  A bit long, I'll admit.  I'm OK with
>>> heap_region_containing_ICH if the declaration explained what
>>> the ICH stood for.
>>
>> I agree that heap_region_containing_raw() is not a great name. 
>> However, it does not ignore continues humongous regions. It is 
>> heap_region_containing() that does that. So, I guess your naming 
>> suggestion would be for heap_region_containing() to change to 
>> heap_region_containing_ignore_continues_humongous(), right?
>>
>> With my patch for allocating objects into the last continues region 
>> of a humongous object heap_region_containing() will also be able to 
>> return continues regions occasionally. So, I'm not convinced about 
>> the name.
>>
>> Would it be ok to leave the names as they are for now?
>
> That's fine.  That will give us a chance to come up with an
> even better name.
>
> Reviewed.
>
> Jon
>
>>
>> Thanks,
>> Bengt
>>>
>>> Jon
>>>
>>> On 4/16/2014 6:46 AM, Bengt Rutisson wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> Could I please have a few reviews of this cleanup?
>>>>
>>>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/
>>>>
>>>> Background:
>>>>
>>>> Before the perm gen was removed 
>>>> G1CollectedHeap::heap_region_containing() could return NULL for 
>>>> addresses in the perm gen. This means that a lot of code had to 
>>>> check the result since it could potentially be NULL.
>>>>
>>>> Now the only reason to return NULL is if the address passed in 
>>>> NULL. In many places it is possible to know that the address is not 
>>>> NULL and in the other places it is just as simple to check the 
>>>> address for NULL before calling 
>>>> G1CollectedHeap::heap_region_containing() rather than checking for 
>>>> NULL after having called it.
>>>>
>>>> So, to simplify the code a bit we can assert that 
>>>> G1CollectedHeap::heap_region_containing() never returns NULL and 
>>>> then only check before we call it in the places where we would 
>>>> otherwise have passed NULL to it.
>>>>
>>>> Thanks,
>>>> Bengt
>>>
>>
>



From thomas.schatzl at oracle.com  Thu Apr 17 08:50:10 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 17 Apr 2014 10:50:10 +0200
Subject: RFR(S): JDK-8040002: Clean up code and code duplication in
	re-diryting cards for verification
In-Reply-To: <534E927C.10306@oracle.com>
References: <1397469592.2708.28.camel@cirrus> <534D4100.3030902@oracle.com>
	<1397638780.12194.10.camel@cirrus> <534E927C.10306@oracle.com>
Message-ID: <1397724610.2834.3.camel@cirrus>

Hi Jon,

On Wed, 2014-04-16 at 07:23 -0700, Jon Masamitsu wrote:
> On 4/16/2014 1:59 AM, Thomas Schatzl wrote:
> > Hi Jon,
> >
> > On Tue, 2014-04-15 at 07:24 -0700, Jon Masamitsu wrote:
> >> Thomas,
> >>
> >> http://cr.openjdk.java.net/~tschatzl/8040002/webrev/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html
> >>
> >> Changes look good.

Thanks for the review.

Thomas




From volker.simonis at gmail.com  Thu Apr 17 09:19:44 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 17 Apr 2014 11:19:44 +0200
Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
In-Reply-To: <1397675052.6470.13.camel@cirrus>
References: <4295855A5C1DE049A61835A1887419CC2CEAAA44@DEWDFEMB12A.global.corp.sap>
	<533A7A0E.5040100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEAC068@DEWDFEMB12A.global.corp.sap>
	<533A8FD8.3090400@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEAC0A6@DEWDFEMB12A.global.corp.sap>
	<1396357031.2707.13.camel@cirrus>
	<CA+3eh13+AoGFHG2wDQDmCoQjzOhEfOXdzDB757vWFsDu_vgMqg@mail.gmail.com>
	<1397675052.6470.13.camel@cirrus>
Message-ID: <CA+3eh1206vGqEsvv5nB0KOURXewJvrGJr0wt+yLgdhkXHb1hkg@mail.gmail.com>

Hi Thomas,

it's not really a problem. I'm only constantly trying to raise
awareness for this issue because it happens from time to time (you're
not the only one:)

The fundamental problem is that we as external committers can not push
to hotspot repositories - but that's another story...

So we're actually quite happy if people like you sponsor our changes -
and I hope you'll still help out in the future.

Thank you and best regards,
Volker


On Wed, Apr 16, 2014 at 9:04 PM, Thomas Schatzl
<thomas.schatzl at oracle.com> wrote:
> Hi,
>
> On Wed, 2014-04-16 at 18:38 +0200, Volker Simonis wrote:
>> Hi Thomas,
>>
>> thanks for sponsoring this change.
>>
>> I just wonder why the downported change in jdk8u
>> (http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/rev/bfdf528be8e8) is
>> attributed to you and not to Goetz?
>> In the jdk9 repositories
>> (http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/4c16a27793eb) Goetz
>> is correctly mentioned as the author.
>
>   that's my fault. When committing the backport a few days later, I
> forgot to make Goetz the author (i.e. did not use "hg commit -u goetz",
> or did not do a straight import of that patch - I do not remember). I
> never intended to claim authorship for the change/commit.
>
> There were no changes in the backport, just a straight re-commit. So
> there was no review necessary. From the bugtracker (and this mail
> thread) it should be clear (at least now) that this is "only" a
> backport, and the reason for this difference human error.
>
> Unfortunately the commit message cannot be changed any more.
>
> Interestingly the push hook did not complain that the author is also
> mentioned as reviewer :) (Then again, Stefan K is sufficient to pass).
>
> I will try to be more wary of this next time. I hope this poses no
> problem.
>
> Sorry,
>   Thomas
>
>


From thomas.schatzl at oracle.com  Thu Apr 17 10:42:54 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 17 Apr 2014 12:42:54 +0200
Subject: RFR (XXS): 8040792: G1CodeRootChunkManager::static_mem_size returns
	the wrong size
Message-ID: <1397731374.2834.8.camel@cirrus>

Hi all,

  can I have reviews for this tiny change that fixes one error that
Mikael Gerdin found in the review for "8038930: G1CodeRootSet::test()
fails with assert(...)" just a few minutes after I pushed the change?

It's about changing the following line in G1CodeRootSet.cpp:

  86 size_t G1CodeRootChunkManager::static_mem_size() {
  87   return sizeof(this);
  88 }

to

  87   return sizeof(*this);

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

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

Testing:
Internal test, jprt

Thanks,
Thomas



From thomas.schatzl at oracle.com  Thu Apr 17 10:51:09 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 17 Apr 2014 12:51:09 +0200
Subject: RFR (M): JDK-8040722: G1: Clean up usages of
	heap_region_containing
In-Reply-To: <534F902E.4060200@oracle.com>
References: <534E89C0.8020706@oracle.com> <534EAA74.40304@oracle.com>
	<534ED516.1000804@oracle.com> <534F0F2E.9060606@oracle.com>
	<534F902E.4060200@oracle.com>
Message-ID: <1397731869.2834.15.camel@cirrus>

Hi Bengt,

On Thu, 2014-04-17 at 10:26 +0200, Bengt Rutisson wrote:
> Hi again,
> 
> Here's an updated webrev:
> http://cr.openjdk.java.net/~brutisso/8040722/webrev.01/
> 
> And here's the incremental change compared to the previous one:
> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00-01.diff/
> 

  a few comments, none of them are critical:

 - g1CollectedHeap.inline.hpp, in
G1CollectedHeap::heap_region_containing_raw:

The != NULL check is subsumed by the other. Is it possible to merge them
with a useful error message?

E.g. assert(_g1_reserved.contains(...), err_msg("Address "PTR_FORMAT" is
outside of the heap ranging from ["PTR_FORMAT" to "PTR_FORMAT")", addr,
_g1_reserved.start(), _g1_reserved.end());

I would prefer to have one assert instead of separating them.

 - in CMTask::setup_for_region(): maybe the error message for the !=
NULL assert could be improved.

 - G1CollectedHeap::heap_region_containing_raw documentation: maybe
better:

// Returns the HeapRegion the given address addr contains. Addr must not
be NULL.

 - G1CollectedHeap::heap_region_containing() documentation: I would
prefer something like:

// Returns the HeapRegion the given address addr contains. Addr must not
be NULL. If addr is within a humongous continues region, it returns its
humongous start region.

Imo, to name a region, using "<type-name> region" (e.g. humongous
continues region) is better than trying to invent new descriptions like
continuing humonguous region.

Thanks,
Thomas




From jesper.wilhelmsson at oracle.com  Thu Apr 17 10:53:04 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 17 Apr 2014 12:53:04 +0200
Subject: RFR (XXS): 8040792: G1CodeRootChunkManager::static_mem_size
	returns the wrong size
In-Reply-To: <1397731374.2834.8.camel@cirrus>
References: <1397731374.2834.8.camel@cirrus>
Message-ID: <534FB290.3060802@oracle.com>

Ship it!
/Jesper

Thomas Schatzl skrev 17/4/14 12:42:
> Hi all,
>
>    can I have reviews for this tiny change that fixes one error that
> Mikael Gerdin found in the review for "8038930: G1CodeRootSet::test()
> fails with assert(...)" just a few minutes after I pushed the change?
>
> It's about changing the following line in G1CodeRootSet.cpp:
>
>    86 size_t G1CodeRootChunkManager::static_mem_size() {
>    87   return sizeof(this);
>    88 }
>
> to
>
>    87   return sizeof(*this);
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8040792
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8040792/webrev/
>
> Testing:
> Internal test, jprt
>
> Thanks,
> Thomas
>


From bengt.rutisson at oracle.com  Thu Apr 17 11:27:34 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 17 Apr 2014 13:27:34 +0200
Subject: RFR (M): JDK-8040722: G1: Clean up usages of
	heap_region_containing
In-Reply-To: <1397731869.2834.15.camel@cirrus>
References: <534E89C0.8020706@oracle.com> <534EAA74.40304@oracle.com>	
	<534ED516.1000804@oracle.com> <534F0F2E.9060606@oracle.com>	
	<534F902E.4060200@oracle.com> <1397731869.2834.15.camel@cirrus>
Message-ID: <534FBAA6.90304@oracle.com>


Hi Thomas,

Thanks for looking at this!

Details inlined below.

Updated webrev:
http://cr.openjdk.java.net/~brutisso/8040722/webrev02/

Diff against the 01 version:
http://cr.openjdk.java.net/~brutisso/8040722/webrev01-02.diff/

Thanks,
Bengt

On 2014-04-17 12:51, Thomas Schatzl wrote:
> Hi Bengt,
>
> On Thu, 2014-04-17 at 10:26 +0200, Bengt Rutisson wrote:
>> Hi again,
>>
>> Here's an updated webrev:
>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.01/
>>
>> And here's the incremental change compared to the previous one:
>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00-01.diff/
>>
>    a few comments, none of them are critical:
>
>   - g1CollectedHeap.inline.hpp, in
> G1CollectedHeap::heap_region_containing_raw:
>
> The != NULL check is subsumed by the other. Is it possible to merge them
> with a useful error message?
>
> E.g. assert(_g1_reserved.contains(...), err_msg("Address "PTR_FORMAT" is
> outside of the heap ranging from ["PTR_FORMAT" to "PTR_FORMAT")", addr,
> _g1_reserved.start(), _g1_reserved.end());
>
> I would prefer to have one assert instead of separating them.

I added an err_msg() to the second assert to log the value of the 
failing address. But I keep the explicit NULL check since I think this 
cleanup relies heavily on this invariant.

>
>   - in CMTask::setup_for_region(): maybe the error message for the !=
> NULL assert could be improved.

Changed to "claim_region() should have filtered out NULL regions".

>
>   - G1CollectedHeap::heap_region_containing_raw documentation: maybe
> better:
>
> // Returns the HeapRegion the given address addr contains. Addr must not
> be NULL.
>
>   - G1CollectedHeap::heap_region_containing() documentation: I would
> prefer something like:
>
> // Returns the HeapRegion the given address addr contains. Addr must not
> be NULL. If addr is within a humongous continues region, it returns its
> humongous start region.
>
> Imo, to name a region, using "<type-name> region" (e.g. humongous
> continues region) is better than trying to invent new descriptions like
> continuing humonguous region.

Sounds good. I updated the comments to be:


   // Returns the HeapRegion that contains addr. addr must not be NULL.
   template <class T>
   inline HeapRegion* heap_region_containing_raw(const T addr) const;

   // Returns the HeapRegion that contains addr. addr must not be NULL.
   // If addr is within a humongous continues region, it returns its 
humongous start region.
   template <class T>
   inline HeapRegion* heap_region_containing(const T addr) const;

Thanks again for looking at this!

Bengt


>
> Thanks,
> Thomas
>
>



From bengt.rutisson at oracle.com  Thu Apr 17 11:36:00 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 17 Apr 2014 13:36:00 +0200
Subject: RFR (XXS): 8040792: G1CodeRootChunkManager::static_mem_size
	returns the wrong size
In-Reply-To: <1397731374.2834.8.camel@cirrus>
References: <1397731374.2834.8.camel@cirrus>
Message-ID: <534FBCA0.5060108@oracle.com>


Hi Thomas,

On 2014-04-17 12:42, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for this tiny change that fixes one error that
> Mikael Gerdin found in the review for "8038930: G1CodeRootSet::test()
> fails with assert(...)" just a few minutes after I pushed the change?
>
> It's about changing the following line in G1CodeRootSet.cpp:
>
>    86 size_t G1CodeRootChunkManager::static_mem_size() {
>    87   return sizeof(this);
>    88 }
>
> to
>
>    87   return sizeof(*this);

I would kind of prefer

  return sizeof(G1CodeRootChunkManager);

since it would be faster for me to read.

Also, there are more places in the G1 code where we do sizeof(this). At 
a first glance it looks to me like all of them are wrong.

$ grep -r "sizeof(this)" src/share/vm/gc_implementation/g1/
src/share/vm/gc_implementation/g1/sparsePRT.cpp:  return sizeof(this) +
src/share/vm/gc_implementation/g1/sparsePRT.cpp:  return sizeof(this) + 
_next->mem_size();
src/share/vm/gc_implementation/g1/g1CodeCacheRemSet.cpp:  return 
sizeof(this);
src/share/vm/gc_implementation/g1/g1CodeCacheRemSet.cpp:  return 
sizeof(this) + _list.count() * _list.size();
src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp:      + 
(sizeof(this) - sizeof(OtherRegionsTable))
src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp:    return 
sizeof(this) + _bm.size_in_words() * HeapWordSize;

Can you verify these at the same time?

Thanks,
Bengt

>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8040792
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8040792/webrev/
>
> Testing:
> Internal test, jprt
>
> Thanks,
> Thomas
>



From per.liden at oracle.com  Thu Apr 17 12:27:15 2014
From: per.liden at oracle.com (Per Liden)
Date: Thu, 17 Apr 2014 14:27:15 +0200
Subject: RFR(xs): 8040245: G1: VM hangs during shutdown
Message-ID: <534FC8A3.6080806@oracle.com>

Hi,

Could I please have this fix reviewed.

Summary: JDK-8037112 added controlled shutdown of concurrent marking 
threads in G1 during VM exit, to prevent these threads from using 
resources that are destroyed later in the shutdown phase. However, it 
turns out there are at least two unrelated bugs (I've filed JDK-8040803 
and JDK-8040804) in the concurrent mark code which under some 
circumstances can provoke the concurrent mark threads to hang, and thus 
prevent the VM from exiting. This patch temporarily disables the 
controlled shutdown of the CM threads (because it causes timeouts in our 
testing) until those other bugs have been sorted out, at which point we 
should enabled this again (filed JDK-8040807 to track that).

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

Thanks!
/Per


From bengt.rutisson at oracle.com  Thu Apr 17 12:45:14 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 17 Apr 2014 14:45:14 +0200
Subject: RFR (M): JDK-8040722: G1: Clean up usages of
	heap_region_containing
In-Reply-To: <534FBAA6.90304@oracle.com>
References: <534E89C0.8020706@oracle.com>
	<534EAA74.40304@oracle.com>		<534ED516.1000804@oracle.com>
	<534F0F2E.9060606@oracle.com>		<534F902E.4060200@oracle.com>
	<1397731869.2834.15.camel@cirrus> <534FBAA6.90304@oracle.com>
Message-ID: <534FCCDA.9050806@oracle.com>


Hi again,

Thomas helped me track down a race that means that 
G1UpdateRSOrPushRefOopClosure::do_oop_nv() can not assert that the from 
and to regions are different. Reverted back to using an if-statement 
rather than an assert, just like the original code.

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

Incremental webrev:
http://cr.openjdk.java.net/~brutisso/8040722/webrev.02-03-diff/

Thanks,
Bengt

On 2014-04-17 13:27, Bengt Rutisson wrote:
>
> Hi Thomas,
>
> Thanks for looking at this!
>
> Details inlined below.
>
> Updated webrev:
> http://cr.openjdk.java.net/~brutisso/8040722/webrev02/
>
> Diff against the 01 version:
> http://cr.openjdk.java.net/~brutisso/8040722/webrev01-02.diff/
>
> Thanks,
> Bengt
>
> On 2014-04-17 12:51, Thomas Schatzl wrote:
>> Hi Bengt,
>>
>> On Thu, 2014-04-17 at 10:26 +0200, Bengt Rutisson wrote:
>>> Hi again,
>>>
>>> Here's an updated webrev:
>>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.01/
>>>
>>> And here's the incremental change compared to the previous one:
>>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00-01.diff/
>>>
>>    a few comments, none of them are critical:
>>
>>   - g1CollectedHeap.inline.hpp, in
>> G1CollectedHeap::heap_region_containing_raw:
>>
>> The != NULL check is subsumed by the other. Is it possible to merge them
>> with a useful error message?
>>
>> E.g. assert(_g1_reserved.contains(...), err_msg("Address "PTR_FORMAT" is
>> outside of the heap ranging from ["PTR_FORMAT" to "PTR_FORMAT")", addr,
>> _g1_reserved.start(), _g1_reserved.end());
>>
>> I would prefer to have one assert instead of separating them.
>
> I added an err_msg() to the second assert to log the value of the 
> failing address. But I keep the explicit NULL check since I think this 
> cleanup relies heavily on this invariant.
>
>>
>>   - in CMTask::setup_for_region(): maybe the error message for the !=
>> NULL assert could be improved.
>
> Changed to "claim_region() should have filtered out NULL regions".
>
>>
>>   - G1CollectedHeap::heap_region_containing_raw documentation: maybe
>> better:
>>
>> // Returns the HeapRegion the given address addr contains. Addr must not
>> be NULL.
>>
>>   - G1CollectedHeap::heap_region_containing() documentation: I would
>> prefer something like:
>>
>> // Returns the HeapRegion the given address addr contains. Addr must not
>> be NULL. If addr is within a humongous continues region, it returns its
>> humongous start region.
>>
>> Imo, to name a region, using "<type-name> region" (e.g. humongous
>> continues region) is better than trying to invent new descriptions like
>> continuing humonguous region.
>
> Sounds good. I updated the comments to be:
>
>
>   // Returns the HeapRegion that contains addr. addr must not be NULL.
>   template <class T>
>   inline HeapRegion* heap_region_containing_raw(const T addr) const;
>
>   // Returns the HeapRegion that contains addr. addr must not be NULL.
>   // If addr is within a humongous continues region, it returns its 
> humongous start region.
>   template <class T>
>   inline HeapRegion* heap_region_containing(const T addr) const;
>
> Thanks again for looking at this!
>
> Bengt
>
>
>>
>> Thanks,
>> Thomas
>>
>>
>



From bengt.rutisson at oracle.com  Thu Apr 17 13:26:47 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 17 Apr 2014 15:26:47 +0200
Subject: RFR(xs): 8040245: G1: VM hangs during shutdown
In-Reply-To: <534FC8A3.6080806@oracle.com>
References: <534FC8A3.6080806@oracle.com>
Message-ID: <534FD697.6010900@oracle.com>


Hi Per,

Looks good.

Bengt


On 2014-04-17 14:27, Per Liden wrote:
> Hi,
>
> Could I please have this fix reviewed.
>
> Summary: JDK-8037112 added controlled shutdown of concurrent marking 
> threads in G1 during VM exit, to prevent these threads from using 
> resources that are destroyed later in the shutdown phase. However, it 
> turns out there are at least two unrelated bugs (I've filed 
> JDK-8040803 and JDK-8040804) in the concurrent mark code which under 
> some circumstances can provoke the concurrent mark threads to hang, 
> and thus prevent the VM from exiting. This patch temporarily disables 
> the controlled shutdown of the CM threads (because it causes timeouts 
> in our testing) until those other bugs have been sorted out, at which 
> point we should enabled this again (filed JDK-8040807 to track that).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8040245
> Webrev: http://cr.openjdk.java.net/~pliden/8040245/webrev.0/
>
> Thanks!
> /Per



From thomas.schatzl at oracle.com  Thu Apr 17 14:35:23 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 17 Apr 2014 16:35:23 +0200
Subject: RFR(xs): 8040245: G1: VM hangs during shutdown
In-Reply-To: <534FC8A3.6080806@oracle.com>
References: <534FC8A3.6080806@oracle.com>
Message-ID: <1397745323.2834.21.camel@cirrus>

Hi,

On Thu, 2014-04-17 at 14:27 +0200, Per Liden wrote:
> Hi,
> 
> Could I please have this fix reviewed.
> 
> Summary: JDK-8037112 added controlled shutdown of concurrent marking 
> threads in G1 during VM exit, to prevent these threads from using 
> resources that are destroyed later in the shutdown phase. However, it 
> turns out there are at least two unrelated bugs (I've filed JDK-8040803 
> and JDK-8040804) in the concurrent mark code which under some 
> circumstances can provoke the concurrent mark threads to hang, and thus 
> prevent the VM from exiting. This patch temporarily disables the 
> controlled shutdown of the CM threads (because it causes timeouts in our 
> testing) until those other bugs have been sorted out, at which point we 
> should enabled this again (filed JDK-8040807 to track that).
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8040245
> Webrev: http://cr.openjdk.java.net/~pliden/8040245/webrev.0/
> 

  looks appropriate.

Thomas



From thomas.schatzl at oracle.com  Thu Apr 17 14:37:41 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 17 Apr 2014 16:37:41 +0200
Subject: RFR (M): JDK-8040722: G1: Clean up usages of
	heap_region_containing
In-Reply-To: <534FCCDA.9050806@oracle.com>
References: <534E89C0.8020706@oracle.com> <534EAA74.40304@oracle.com>
	<534ED516.1000804@oracle.com> <534F0F2E.9060606@oracle.com>
	<534F902E.4060200@oracle.com> <1397731869.2834.15.camel@cirrus>
	<534FBAA6.90304@oracle.com> <534FCCDA.9050806@oracle.com>
Message-ID: <1397745461.2834.23.camel@cirrus>

Hi,

On Thu, 2014-04-17 at 14:45 +0200, Bengt Rutisson wrote:
> Hi again,
> 
> Thomas helped me track down a race that means that 
> G1UpdateRSOrPushRefOopClosure::do_oop_nv() can not assert that the from 
> and to regions are different. Reverted back to using an if-statement 
> rather than an assert, just like the original code.
> 
> New webrev:
> http://cr.openjdk.java.net/~brutisso/8040722/webrev.03/
> 
> Incremental webrev:
> http://cr.openjdk.java.net/~brutisso/8040722/webrev.02-03-diff/

  looks okay, leave the check as it was.

Need to fix the remset at some point. :/

Thanks,
Thomas



From per.liden at oracle.com  Thu Apr 17 14:38:55 2014
From: per.liden at oracle.com (Per Liden)
Date: Thu, 17 Apr 2014 16:38:55 +0200
Subject: RFR(xs): 8040245: G1: VM hangs during shutdown
In-Reply-To: <1397745323.2834.21.camel@cirrus>
References: <534FC8A3.6080806@oracle.com> <1397745323.2834.21.camel@cirrus>
Message-ID: <534FE77F.9020808@oracle.com>

Thanks Bengt, thanks Thomas!

cheers,
/Per

On 04/17/2014 04:35 PM, Thomas Schatzl wrote:
> Hi,
>
> On Thu, 2014-04-17 at 14:27 +0200, Per Liden wrote:
>> Hi,
>>
>> Could I please have this fix reviewed.
>>
>> Summary: JDK-8037112 added controlled shutdown of concurrent marking
>> threads in G1 during VM exit, to prevent these threads from using
>> resources that are destroyed later in the shutdown phase. However, it
>> turns out there are at least two unrelated bugs (I've filed JDK-8040803
>> and JDK-8040804) in the concurrent mark code which under some
>> circumstances can provoke the concurrent mark threads to hang, and thus
>> prevent the VM from exiting. This patch temporarily disables the
>> controlled shutdown of the CM threads (because it causes timeouts in our
>> testing) until those other bugs have been sorted out, at which point we
>> should enabled this again (filed JDK-8040807 to track that).
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8040245
>> Webrev: http://cr.openjdk.java.net/~pliden/8040245/webrev.0/
>>
>
>    looks appropriate.
>
> Thomas
>



From jon.masamitsu at oracle.com  Thu Apr 17 15:13:37 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 17 Apr 2014 08:13:37 -0700
Subject: RFR (M): JDK-8040722: G1: Clean up usages of
	heap_region_containing
In-Reply-To: <534FCCDA.9050806@oracle.com>
References: <534E89C0.8020706@oracle.com>
	<534EAA74.40304@oracle.com>		<534ED516.1000804@oracle.com>
	<534F0F2E.9060606@oracle.com>		<534F902E.4060200@oracle.com>
	<1397731869.2834.15.camel@cirrus> <534FBAA6.90304@oracle.com>
	<534FCCDA.9050806@oracle.com>
Message-ID: <534FEFA1.7010904@oracle.com>

Bengt,

I looked at the

http://cr.openjdk.java.net/~brutisso/8040722/webrev.00-01.diff/
http://cr.openjdk.java.net/~brutisso/8040722/webrev01-02.diff/
http://cr.openjdk.java.net/~brutisso/8040722/webrev.02-03-diff/

All changes look good.  Thanks.

Reviewed.

Jon

On 4/17/2014 5:45 AM, Bengt Rutisson wrote:
>
> Hi again,
>
> Thomas helped me track down a race that means that 
> G1UpdateRSOrPushRefOopClosure::do_oop_nv() can not assert that the 
> from and to regions are different. Reverted back to using an 
> if-statement rather than an assert, just like the original code.
>
> New webrev:
> http://cr.openjdk.java.net/~brutisso/8040722/webrev.03/
>
> Incremental webrev:
> http://cr.openjdk.java.net/~brutisso/8040722/webrev.02-03-diff/
>
> Thanks,
> Bengt
>
> On 2014-04-17 13:27, Bengt Rutisson wrote:
>>
>> Hi Thomas,
>>
>> Thanks for looking at this!
>>
>> Details inlined below.
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~brutisso/8040722/webrev02/
>>
>> Diff against the 01 version:
>> http://cr.openjdk.java.net/~brutisso/8040722/webrev01-02.diff/
>>
>> Thanks,
>> Bengt
>>
>> On 2014-04-17 12:51, Thomas Schatzl wrote:
>>> Hi Bengt,
>>>
>>> On Thu, 2014-04-17 at 10:26 +0200, Bengt Rutisson wrote:
>>>> Hi again,
>>>>
>>>> Here's an updated webrev:
>>>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.01/
>>>>
>>>> And here's the incremental change compared to the previous one:
>>>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00-01.diff/
>>>>
>>>    a few comments, none of them are critical:
>>>
>>>   - g1CollectedHeap.inline.hpp, in
>>> G1CollectedHeap::heap_region_containing_raw:
>>>
>>> The != NULL check is subsumed by the other. Is it possible to merge 
>>> them
>>> with a useful error message?
>>>
>>> E.g. assert(_g1_reserved.contains(...), err_msg("Address 
>>> "PTR_FORMAT" is
>>> outside of the heap ranging from ["PTR_FORMAT" to "PTR_FORMAT")", addr,
>>> _g1_reserved.start(), _g1_reserved.end());
>>>
>>> I would prefer to have one assert instead of separating them.
>>
>> I added an err_msg() to the second assert to log the value of the 
>> failing address. But I keep the explicit NULL check since I think 
>> this cleanup relies heavily on this invariant.
>>
>>>
>>>   - in CMTask::setup_for_region(): maybe the error message for the !=
>>> NULL assert could be improved.
>>
>> Changed to "claim_region() should have filtered out NULL regions".
>>
>>>
>>>   - G1CollectedHeap::heap_region_containing_raw documentation: maybe
>>> better:
>>>
>>> // Returns the HeapRegion the given address addr contains. Addr must 
>>> not
>>> be NULL.
>>>
>>>   - G1CollectedHeap::heap_region_containing() documentation: I would
>>> prefer something like:
>>>
>>> // Returns the HeapRegion the given address addr contains. Addr must 
>>> not
>>> be NULL. If addr is within a humongous continues region, it returns its
>>> humongous start region.
>>>
>>> Imo, to name a region, using "<type-name> region" (e.g. humongous
>>> continues region) is better than trying to invent new descriptions like
>>> continuing humonguous region.
>>
>> Sounds good. I updated the comments to be:
>>
>>
>>   // Returns the HeapRegion that contains addr. addr must not be NULL.
>>   template <class T>
>>   inline HeapRegion* heap_region_containing_raw(const T addr) const;
>>
>>   // Returns the HeapRegion that contains addr. addr must not be NULL.
>>   // If addr is within a humongous continues region, it returns its 
>> humongous start region.
>>   template <class T>
>>   inline HeapRegion* heap_region_containing(const T addr) const;
>>
>> Thanks again for looking at this!
>>
>> Bengt
>>
>>
>>>
>>> Thanks,
>>> Thomas
>>>
>>>
>>
>



From jon.masamitsu at oracle.com  Thu Apr 17 15:26:07 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 17 Apr 2014 08:26:07 -0700
Subject: RFR(xs): 8040245: G1: VM hangs during shutdown
In-Reply-To: <534FC8A3.6080806@oracle.com>
References: <534FC8A3.6080806@oracle.com>
Message-ID: <534FF28F.2060909@oracle.com>

Per,

Change looks good.

Reviewed.

Jon

On 4/17/2014 5:27 AM, Per Liden wrote:
> Hi,
>
> Could I please have this fix reviewed.
>
> Summary: JDK-8037112 added controlled shutdown of concurrent marking 
> threads in G1 during VM exit, to prevent these threads from using 
> resources that are destroyed later in the shutdown phase. However, it 
> turns out there are at least two unrelated bugs (I've filed 
> JDK-8040803 and JDK-8040804) in the concurrent mark code which under 
> some circumstances can provoke the concurrent mark threads to hang, 
> and thus prevent the VM from exiting. This patch temporarily disables 
> the controlled shutdown of the CM threads (because it causes timeouts 
> in our testing) until those other bugs have been sorted out, at which 
> point we should enabled this again (filed JDK-8040807 to track that).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8040245
> Webrev: http://cr.openjdk.java.net/~pliden/8040245/webrev.0/
>
> Thanks!
> /Per



From per.liden at oracle.com  Thu Apr 17 15:30:01 2014
From: per.liden at oracle.com (Per Liden)
Date: Thu, 17 Apr 2014 17:30:01 +0200
Subject: RFR(xs): 8040245: G1: VM hangs during shutdown
In-Reply-To: <534FF28F.2060909@oracle.com>
References: <534FC8A3.6080806@oracle.com> <534FF28F.2060909@oracle.com>
Message-ID: <534FF379.4080402@oracle.com>

Thanks Jon!

/Per

On 04/17/2014 05:26 PM, Jon Masamitsu wrote:
> Per,
>
> Change looks good.
>
> Reviewed.
>
> Jon
>
> On 4/17/2014 5:27 AM, Per Liden wrote:
>> Hi,
>>
>> Could I please have this fix reviewed.
>>
>> Summary: JDK-8037112 added controlled shutdown of concurrent marking
>> threads in G1 during VM exit, to prevent these threads from using
>> resources that are destroyed later in the shutdown phase. However, it
>> turns out there are at least two unrelated bugs (I've filed
>> JDK-8040803 and JDK-8040804) in the concurrent mark code which under
>> some circumstances can provoke the concurrent mark threads to hang,
>> and thus prevent the VM from exiting. This patch temporarily disables
>> the controlled shutdown of the CM threads (because it causes timeouts
>> in our testing) until those other bugs have been sorted out, at which
>> point we should enabled this again (filed JDK-8040807 to track that).
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8040245
>> Webrev: http://cr.openjdk.java.net/~pliden/8040245/webrev.0/
>>
>> Thanks!
>> /Per
>



From jon.masamitsu at oracle.com  Thu Apr 17 16:37:20 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 17 Apr 2014 09:37:20 -0700
Subject: Review request(7u): JDK-8010738: G1: Output for full GCs with
	+PrintGCDetails should contain perm gen/meta data size change info
In-Reply-To: <534F2877.50303@oracle.com>
References: <534F2877.50303@oracle.com>
Message-ID: <53500340.4050702@oracle.com>

Poonam,

In jdk7 I think there is a

  GenCollectedHeap::print_perm_heap_change()

Your changes have added in G1CollectorPolicy

1168 void G1CollectorPolicy::print_perm_heap_change(size_t perm_prev_used) const {


Is there still a  GenCollectedHeap::print_perm_heap_change() in the jdk7
you're fixing and could you have used that instead of adding the
print_perm_heap_change() to G1CollectorPolicy.


Jon



On 4/16/2014 6:03 PM, Poonam Bajaj wrote:
> Hi,
>
> Could I have reviews for the following fix:
>
> JDK-8010738 <https://bugs.openjdk.java.net/browse/JDK-8010738>: G1: 
> Output for full GCs with +PrintGCDetails should contain perm gen/meta 
> data size change info
> webrev: http://cr.openjdk.java.net/~poonam/8010738/webrev.00/
>
> With JDK7 G1GC when we use -XX:+PrintGCDetails option, PermGen 
> information does not get printed in the Full GC logs as shown below:
> [Full GC 16M->16M(20M), 0.7055536 secs]
>    [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 
> 16.7M(20.0M)->16.7M(20.0M)]
>
> PermGen info should also get printed with Full GC info similar to what 
> other garbage collectors report. These changes are backport of the fix 
> in jdk8 where MetaSpace info gets printed in the Full GC logs.
>
> With the fix the output looks like:
> [Full GC 16M->16M(20M), 0.6763478 secs]
>    [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 
> 16.7M(20.0M)->16.7M(20.0M)], [Perm: 1725K->1725K(16384K)]
>
>
> Thanks,
> Poonam
>

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

From bengt.rutisson at oracle.com  Thu Apr 17 16:48:38 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 17 Apr 2014 18:48:38 +0200
Subject: RFR (M): JDK-8040722: G1: Clean up usages of
	heap_region_containing
In-Reply-To: <534FEFA1.7010904@oracle.com>
References: <534E89C0.8020706@oracle.com>	<534EAA74.40304@oracle.com>		<534ED516.1000804@oracle.com>	<534F0F2E.9060606@oracle.com>		<534F902E.4060200@oracle.com>	<1397731869.2834.15.camel@cirrus>
	<534FBAA6.90304@oracle.com>	<534FCCDA.9050806@oracle.com>
	<534FEFA1.7010904@oracle.com>
Message-ID: <535005E6.9010606@oracle.com>


Thanks for the reviews Jon and Thomas!

Bengt

On 4/17/14 5:13 PM, Jon Masamitsu wrote:
> Bengt,
>
> I looked at the
>
> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00-01.diff/
> http://cr.openjdk.java.net/~brutisso/8040722/webrev01-02.diff/
> http://cr.openjdk.java.net/~brutisso/8040722/webrev.02-03-diff/
>
> All changes look good.  Thanks.
>
> Reviewed.
>
> Jon
>
> On 4/17/2014 5:45 AM, Bengt Rutisson wrote:
>>
>> Hi again,
>>
>> Thomas helped me track down a race that means that 
>> G1UpdateRSOrPushRefOopClosure::do_oop_nv() can not assert that the 
>> from and to regions are different. Reverted back to using an 
>> if-statement rather than an assert, just like the original code.
>>
>> New webrev:
>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.03/
>>
>> Incremental webrev:
>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.02-03-diff/
>>
>> Thanks,
>> Bengt
>>
>> On 2014-04-17 13:27, Bengt Rutisson wrote:
>>>
>>> Hi Thomas,
>>>
>>> Thanks for looking at this!
>>>
>>> Details inlined below.
>>>
>>> Updated webrev:
>>> http://cr.openjdk.java.net/~brutisso/8040722/webrev02/
>>>
>>> Diff against the 01 version:
>>> http://cr.openjdk.java.net/~brutisso/8040722/webrev01-02.diff/
>>>
>>> Thanks,
>>> Bengt
>>>
>>> On 2014-04-17 12:51, Thomas Schatzl wrote:
>>>> Hi Bengt,
>>>>
>>>> On Thu, 2014-04-17 at 10:26 +0200, Bengt Rutisson wrote:
>>>>> Hi again,
>>>>>
>>>>> Here's an updated webrev:
>>>>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.01/
>>>>>
>>>>> And here's the incremental change compared to the previous one:
>>>>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00-01.diff/
>>>>>
>>>>    a few comments, none of them are critical:
>>>>
>>>>   - g1CollectedHeap.inline.hpp, in
>>>> G1CollectedHeap::heap_region_containing_raw:
>>>>
>>>> The != NULL check is subsumed by the other. Is it possible to merge 
>>>> them
>>>> with a useful error message?
>>>>
>>>> E.g. assert(_g1_reserved.contains(...), err_msg("Address 
>>>> "PTR_FORMAT" is
>>>> outside of the heap ranging from ["PTR_FORMAT" to "PTR_FORMAT")", 
>>>> addr,
>>>> _g1_reserved.start(), _g1_reserved.end());
>>>>
>>>> I would prefer to have one assert instead of separating them.
>>>
>>> I added an err_msg() to the second assert to log the value of the 
>>> failing address. But I keep the explicit NULL check since I think 
>>> this cleanup relies heavily on this invariant.
>>>
>>>>
>>>>   - in CMTask::setup_for_region(): maybe the error message for the !=
>>>> NULL assert could be improved.
>>>
>>> Changed to "claim_region() should have filtered out NULL regions".
>>>
>>>>
>>>>   - G1CollectedHeap::heap_region_containing_raw documentation: maybe
>>>> better:
>>>>
>>>> // Returns the HeapRegion the given address addr contains. Addr 
>>>> must not
>>>> be NULL.
>>>>
>>>>   - G1CollectedHeap::heap_region_containing() documentation: I would
>>>> prefer something like:
>>>>
>>>> // Returns the HeapRegion the given address addr contains. Addr 
>>>> must not
>>>> be NULL. If addr is within a humongous continues region, it returns 
>>>> its
>>>> humongous start region.
>>>>
>>>> Imo, to name a region, using "<type-name> region" (e.g. humongous
>>>> continues region) is better than trying to invent new descriptions 
>>>> like
>>>> continuing humonguous region.
>>>
>>> Sounds good. I updated the comments to be:
>>>
>>>
>>>   // Returns the HeapRegion that contains addr. addr must not be NULL.
>>>   template <class T>
>>>   inline HeapRegion* heap_region_containing_raw(const T addr) const;
>>>
>>>   // Returns the HeapRegion that contains addr. addr must not be NULL.
>>>   // If addr is within a humongous continues region, it returns its 
>>> humongous start region.
>>>   template <class T>
>>>   inline HeapRegion* heap_region_containing(const T addr) const;
>>>
>>> Thanks again for looking at this!
>>>
>>> Bengt
>>>
>>>
>>>>
>>>> Thanks,
>>>> Thomas
>>>>
>>>>
>>>
>>
>



From poonam.bajaj at oracle.com  Fri Apr 18 01:53:20 2014
From: poonam.bajaj at oracle.com (Poonam Bajaj)
Date: Fri, 18 Apr 2014 07:23:20 +0530
Subject: Review request(7u): JDK-8010738: G1: Output for full GCs with
	+PrintGCDetails should contain perm gen/meta data size change info
In-Reply-To: <53500340.4050702@oracle.com>
References: <534F2877.50303@oracle.com> <53500340.4050702@oracle.com>
Message-ID: <53508590.6060201@oracle.com>

Hi Jon,

On 4/17/2014 10:07 PM, Jon Masamitsu wrote:
> Poonam,
>
> In jdk7 I think there is a
>
>  GenCollectedHeap::print_perm_heap_change()
>
> Your changes have added in G1CollectorPolicy
> 1168 void G1CollectorPolicy::print_perm_heap_change(size_t perm_prev_used) const {
>
>
> Is there still a  GenCollectedHeap::print_perm_heap_change() in the jdk7
> you're fixing and could you have used that instead of adding the
> print_perm_heap_change() to G1CollectorPolicy.

Yes, there is print_perm_heap_change() in GenCollectedHeap class. But 
according to the following hierarchy of classes, I could not use it in 
G1CollectedHeap

//
// CollectedHeap
//   SharedHeap
//       GenCollectedHeap
//       G1CollectedHeap
//   ParallelScavengeHeap
//

So I added the similar function in G1CollectorPolicy. I can move it to 
G1CollectedHeap too. And if we don't want duplication, I can explore the 
possibility of moving it to SharedHeap and then use it in both the 
derived classes.

Thanks,
Poonam

>
>
> Jon
>
>
>
> On 4/16/2014 6:03 PM, Poonam Bajaj wrote:
>> Hi,
>>
>> Could I have reviews for the following fix:
>>
>> JDK-8010738 <https://bugs.openjdk.java.net/browse/JDK-8010738>: G1: 
>> Output for full GCs with +PrintGCDetails should contain perm gen/meta 
>> data size change info
>> webrev: http://cr.openjdk.java.net/~poonam/8010738/webrev.00/
>>
>> With JDK7 G1GC when we use -XX:+PrintGCDetails option, PermGen 
>> information does not get printed in the Full GC logs as shown below:
>> [Full GC 16M->16M(20M), 0.7055536 secs]
>>    [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 
>> 16.7M(20.0M)->16.7M(20.0M)]
>>
>> PermGen info should also get printed with Full GC info similar to 
>> what other garbage collectors report. These changes are backport of 
>> the fix in jdk8 where MetaSpace info gets printed in the Full GC logs.
>>
>> With the fix the output looks like:
>> [Full GC 16M->16M(20M), 0.6763478 secs]
>>    [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 
>> 16.7M(20.0M)->16.7M(20.0M)], [Perm: 1725K->1725K(16384K)]
>>
>>
>> Thanks,
>> Poonam
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140418/ab918fe8/attachment.htm>

From jon.masamitsu at oracle.com  Fri Apr 18 02:06:29 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 17 Apr 2014 19:06:29 -0700
Subject: Review request(7u): JDK-8010738: G1: Output for full GCs with
	+PrintGCDetails should contain perm gen/meta data size change info
In-Reply-To: <53508590.6060201@oracle.com>
References: <534F2877.50303@oracle.com> <53500340.4050702@oracle.com>
	<53508590.6060201@oracle.com>
Message-ID: <535088A5.2040501@oracle.com>


On 4/17/2014 6:53 PM, Poonam Bajaj wrote:
> Hi Jon,
>
> On 4/17/2014 10:07 PM, Jon Masamitsu wrote:
>> Poonam,
>>
>> In jdk7 I think there is a
>>
>>  GenCollectedHeap::print_perm_heap_change()
>>
>> Your changes have added in G1CollectorPolicy
>> 1168 void G1CollectorPolicy::print_perm_heap_change(size_t perm_prev_used) const {
>>
>>
>> Is there still a  GenCollectedHeap::print_perm_heap_change() in the jdk7
>> you're fixing and could you have used that instead of adding the
>> print_perm_heap_change() to G1CollectorPolicy.
>
> Yes, there is print_perm_heap_change() in GenCollectedHeap class. But 
> according to the following hierarchy of classes, I could not use it in 
> G1CollectedHeap
>
> //
> // CollectedHeap
> //   SharedHeap
> //       GenCollectedHeap
> //       G1CollectedHeap
> //   ParallelScavengeHeap
> //
>
> So I added the similar function in G1CollectorPolicy. I can move it to 
> G1CollectedHeap too. And if we don't want duplication, I can explore 
> the possibility of moving it to SharedHeap and then use it in both the 
> derived classes.

I would recommend against moving things to SharedHeap.  That might 
complicate other backports
and since perm gen is gone in jdk9, I think your solution is fine.

Reviewed.

Jon

>
> Thanks,
> Poonam
>
>>
>>
>> Jon
>>
>>
>>
>> On 4/16/2014 6:03 PM, Poonam Bajaj wrote:
>>> Hi,
>>>
>>> Could I have reviews for the following fix:
>>>
>>> JDK-8010738 <https://bugs.openjdk.java.net/browse/JDK-8010738>: G1: 
>>> Output for full GCs with +PrintGCDetails should contain perm 
>>> gen/meta data size change info
>>> webrev: http://cr.openjdk.java.net/~poonam/8010738/webrev.00/
>>>
>>> With JDK7 G1GC when we use -XX:+PrintGCDetails option, PermGen 
>>> information does not get printed in the Full GC logs as shown below:
>>> [Full GC 16M->16M(20M), 0.7055536 secs]
>>>    [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 
>>> 16.7M(20.0M)->16.7M(20.0M)]
>>>
>>> PermGen info should also get printed with Full GC info similar to 
>>> what other garbage collectors report. These changes are backport of 
>>> the fix in jdk8 where MetaSpace info gets printed in the Full GC logs.
>>>
>>> With the fix the output looks like:
>>> [Full GC 16M->16M(20M), 0.6763478 secs]
>>>    [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 
>>> 16.7M(20.0M)->16.7M(20.0M)], [Perm: 1725K->1725K(16384K)]
>>>
>>>
>>> Thanks,
>>> Poonam
>>>
>>

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

From poonam.bajaj at oracle.com  Fri Apr 18 03:29:02 2014
From: poonam.bajaj at oracle.com (Poonam Bajaj)
Date: Fri, 18 Apr 2014 08:59:02 +0530
Subject: Review request(7u): JDK-8010738: G1: Output for full GCs with
	+PrintGCDetails should contain perm gen/meta data size change info
In-Reply-To: <535088A5.2040501@oracle.com>
References: <534F2877.50303@oracle.com> <53500340.4050702@oracle.com>
	<53508590.6060201@oracle.com> <535088A5.2040501@oracle.com>
Message-ID: <53509BFE.8090909@oracle.com>

Ok. Thanks Jon!

regards,
Poonam

On 4/18/2014 7:36 AM, Jon Masamitsu wrote:
>
> On 4/17/2014 6:53 PM, Poonam Bajaj wrote:
>> Hi Jon,
>>
>> On 4/17/2014 10:07 PM, Jon Masamitsu wrote:
>>> Poonam,
>>>
>>> In jdk7 I think there is a
>>>
>>>  GenCollectedHeap::print_perm_heap_change()
>>>
>>> Your changes have added in G1CollectorPolicy
>>> 1168 void G1CollectorPolicy::print_perm_heap_change(size_t perm_prev_used) const {
>>>
>>>
>>> Is there still a  GenCollectedHeap::print_perm_heap_change() in the jdk7
>>> you're fixing and could you have used that instead of adding the
>>> print_perm_heap_change() to G1CollectorPolicy.
>>
>> Yes, there is print_perm_heap_change() in GenCollectedHeap class. But 
>> according to the following hierarchy of classes, I could not use it 
>> in G1CollectedHeap
>>
>> //
>> // CollectedHeap
>> //   SharedHeap
>> //       GenCollectedHeap
>> //       G1CollectedHeap
>> //   ParallelScavengeHeap
>> //
>>
>> So I added the similar function in G1CollectorPolicy. I can move it 
>> to G1CollectedHeap too. And if we don't want duplication, I can 
>> explore the possibility of moving it to SharedHeap and then use it in 
>> both the derived classes.
>
> I would recommend against moving things to SharedHeap.  That might 
> complicate other backports
> and since perm gen is gone in jdk9, I think your solution is fine.
>
> Reviewed.
>
> Jon
>
>>
>> Thanks,
>> Poonam
>>
>>>
>>>
>>> Jon
>>>
>>>
>>>
>>> On 4/16/2014 6:03 PM, Poonam Bajaj wrote:
>>>> Hi,
>>>>
>>>> Could I have reviews for the following fix:
>>>>
>>>> JDK-8010738 <https://bugs.openjdk.java.net/browse/JDK-8010738>: G1: 
>>>> Output for full GCs with +PrintGCDetails should contain perm 
>>>> gen/meta data size change info
>>>> webrev: http://cr.openjdk.java.net/~poonam/8010738/webrev.00/
>>>>
>>>> With JDK7 G1GC when we use -XX:+PrintGCDetails option, PermGen 
>>>> information does not get printed in the Full GC logs as shown below:
>>>> [Full GC 16M->16M(20M), 0.7055536 secs]
>>>>    [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 
>>>> 16.7M(20.0M)->16.7M(20.0M)]
>>>>
>>>> PermGen info should also get printed with Full GC info similar to 
>>>> what other garbage collectors report. These changes are backport of 
>>>> the fix in jdk8 where MetaSpace info gets printed in the Full GC logs.
>>>>
>>>> With the fix the output looks like:
>>>> [Full GC 16M->16M(20M), 0.6763478 secs]
>>>>    [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 
>>>> 16.7M(20.0M)->16.7M(20.0M)], [Perm: 1725K->1725K(16384K)]
>>>>
>>>>
>>>> Thanks,
>>>> Poonam
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140418/6b913230/attachment.htm>

From kirk at kodewerk.com  Fri Apr 18 05:44:09 2014
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Fri, 18 Apr 2014 07:44:09 +0200
Subject: Review request(7u): JDK-8010738: G1: Output for full GCs with
	+PrintGCDetails should contain perm gen/meta data size change info
In-Reply-To: <53508590.6060201@oracle.com>
References: <534F2877.50303@oracle.com> <53500340.4050702@oracle.com>
	<53508590.6060201@oracle.com>
Message-ID: <6F9E52B8-9FBC-40A5-902F-669894DD7870@kodewerk.com>

Hi Poonam,

Not a reviewer but looks good. Does this little amount of dup?ed code matter since perm is gone so this code won?t show up in 8 and beyond? In fact wouldn?t keeping if unshared be best in this case?

Regards,
Kirk

On Apr 18, 2014, at 3:53 AM, Poonam Bajaj <poonam.bajaj at oracle.com> wrote:

> Hi Jon,
> 
> On 4/17/2014 10:07 PM, Jon Masamitsu wrote:
>> 
>> Poonam,
>> 
>> In jdk7 I think there is a 
>> 
>>  GenCollectedHeap::print_perm_heap_change()
>> 
>> Your changes have added in G1CollectorPolicy
>> 1168 void G1CollectorPolicy::print_perm_heap_change(size_t perm_prev_used) const {
>> 
>> 
>> Is there still a  GenCollectedHeap::print_perm_heap_change() in the jdk7
>> you're fixing and could you have used that instead of adding the
>> print_perm_heap_change() to G1CollectorPolicy.
> 
> Yes, there is print_perm_heap_change() in GenCollectedHeap class. But according to the following hierarchy of classes, I could not use it in G1CollectedHeap
> 
> //
> // CollectedHeap
> //   SharedHeap
> //       GenCollectedHeap
> //       G1CollectedHeap
> //   ParallelScavengeHeap
> //
> 
> So I added the similar function in G1CollectorPolicy. I can move it to G1CollectedHeap too. And if we don't want duplication, I can explore the possibility of moving it to SharedHeap and then use it in both the derived classes.
> 
> Thanks,
> Poonam
> 
>> 
>> 
>> Jon
>> 
>> 
>> 
>> On 4/16/2014 6:03 PM, Poonam Bajaj wrote:
>>> Hi,
>>> 
>>> Could I have reviews for the following fix:
>>> 
>>> JDK-8010738: G1: Output for full GCs with +PrintGCDetails should contain perm gen/meta data size change info
>>> webrev: http://cr.openjdk.java.net/~poonam/8010738/webrev.00/
>>> 
>>> With JDK7 G1GC when we use -XX:+PrintGCDetails option, PermGen information does not get printed in the Full GC logs as shown below:
>>> [Full GC 16M->16M(20M), 0.7055536 secs]
>>>    [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 16.7M(20.0M)->16.7M(20.0M)]
>>> 
>>> PermGen info should also get printed with Full GC info similar to what other garbage collectors report. These changes are backport of the fix in jdk8 where MetaSpace info gets printed in the Full GC logs.
>>> 
>>> With the fix the output looks like:
>>> [Full GC 16M->16M(20M), 0.6763478 secs]
>>>    [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 16.7M(20.0M)->16.7M(20.0M)], [Perm: 1725K->1725K(16384K)]
>>> 
>>> 
>>> Thanks,
>>> Poonam
>>> 
>> 

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

From poonam.bajaj at oracle.com  Fri Apr 18 09:53:52 2014
From: poonam.bajaj at oracle.com (Poonam Bajaj)
Date: Fri, 18 Apr 2014 15:23:52 +0530
Subject: Review request(7u): JDK-8010738: G1: Output for full GCs with
	+PrintGCDetails should contain perm gen/meta data size change info
In-Reply-To: <6F9E52B8-9FBC-40A5-902F-669894DD7870@kodewerk.com>
References: <534F2877.50303@oracle.com> <53500340.4050702@oracle.com>
	<53508590.6060201@oracle.com>
	<6F9E52B8-9FBC-40A5-902F-669894DD7870@kodewerk.com>
Message-ID: <5350F630.3020609@oracle.com>

Thanks Kirk. Yes, even I think keeping these separate is good.

Thanks,
Poonam

On 4/18/2014 11:14 AM, Kirk Pepperdine wrote:
> Hi Poonam,
>
> Not a reviewer but looks good. Does this little amount of dup?ed code 
> matter since perm is gone so this code won?t show up in 8 and beyond? 
> In fact wouldn?t keeping if unshared be best in this case?
>
> Regards,
> Kirk
>
> On Apr 18, 2014, at 3:53 AM, Poonam Bajaj <poonam.bajaj at oracle.com 
> <mailto:poonam.bajaj at oracle.com>> wrote:
>
>> Hi Jon,
>>
>> On 4/17/2014 10:07 PM, Jon Masamitsu wrote:
>>> Poonam,
>>>
>>> In jdk7 I think there is a
>>>
>>>  GenCollectedHeap::print_perm_heap_change()
>>>
>>> Your changes have added in G1CollectorPolicy
>>> 1168 void G1CollectorPolicy::print_perm_heap_change(size_t perm_prev_used) const {
>>>
>>>
>>> Is there still a  GenCollectedHeap::print_perm_heap_change() in the jdk7
>>> you're fixing and could you have used that instead of adding the
>>> print_perm_heap_change() to G1CollectorPolicy.
>>
>> Yes, there is print_perm_heap_change() in GenCollectedHeap class. But 
>> according to the following hierarchy of classes, I could not use it 
>> in G1CollectedHeap
>>
>> //
>> // CollectedHeap
>> //   SharedHeap
>> //       GenCollectedHeap
>> //       G1CollectedHeap
>> //   ParallelScavengeHeap
>> //
>>
>> So I added the similar function in G1CollectorPolicy. I can move it 
>> to G1CollectedHeap too. And if we don't want duplication, I can 
>> explore the possibility of moving it to SharedHeap and then use it in 
>> both the derived classes.
>>
>> Thanks,
>> Poonam
>>
>>>
>>>
>>> Jon
>>>
>>>
>>>
>>> On 4/16/2014 6:03 PM, Poonam Bajaj wrote:
>>>> Hi,
>>>>
>>>> Could I have reviews for the following fix:
>>>>
>>>> JDK-8010738 <https://bugs.openjdk.java.net/browse/JDK-8010738>: G1: 
>>>> Output for full GCs with +PrintGCDetails should contain perm 
>>>> gen/meta data size change info
>>>> webrev: http://cr.openjdk.java.net/~poonam/8010738/webrev.00/
>>>>
>>>> With JDK7 G1GC when we use -XX:+PrintGCDetails option, PermGen 
>>>> information does not get printed in the Full GC logs as shown below:
>>>> [Full GC 16M->16M(20M), 0.7055536 secs]
>>>>    [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 
>>>> 16.7M(20.0M)->16.7M(20.0M)]
>>>>
>>>> PermGen info should also get printed with Full GC info similar to 
>>>> what other garbage collectors report. These changes are backport of 
>>>> the fix in jdk8 where MetaSpace info gets printed in the Full GC logs.
>>>>
>>>> With the fix the output looks like:
>>>> [Full GC 16M->16M(20M), 0.6763478 secs]
>>>>    [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 
>>>> 16.7M(20.0M)->16.7M(20.0M)], [Perm: 1725K->1725K(16384K)]
>>>>
>>>>
>>>> Thanks,
>>>> Poonam
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140418/a69cbe42/attachment.htm>

From vladimir.kempik at oracle.com  Fri Apr 18 12:25:35 2014
From: vladimir.kempik at oracle.com (Vladimir Kempik)
Date: Fri, 18 Apr 2014 16:25:35 +0400
Subject: Request for review: 8016302: Change type of the number of GC workers
	to unsigned int (2)
Message-ID: <535119BF.2000401@oracle.com>

Hi all,

Could I have a couple of reviews for this change?

http://cr.openjdk.java.net/~vkempik/8016302/jdk7/8016302/webrev.00/

It's backport of https://bugs.openjdk.java.net/browse/JDK-8016302 to jdk7.

I made few additional changes: change return value of num_par_rem_sets() 
from int to uint (heapRegionRemSet.cpp), just like it is in jdk8. And 
changed few ints to uints where num_par_rem_sets were used.

Rest of changes just to adopt patch to jdk7.

Thanks,
Vladimir



From thomas.schatzl at oracle.com  Fri Apr 18 13:15:52 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 18 Apr 2014 15:15:52 +0200
Subject: Review request(7u): JDK-8010738: G1: Output for full GCs with
	+PrintGCDetails should contain perm gen/meta data size change info
In-Reply-To: <534F2877.50303@oracle.com>
References: <534F2877.50303@oracle.com>
Message-ID: <1397826952.2717.19.camel@cirrus>

HI,

On Thu, 2014-04-17 at 06:33 +0530, Poonam Bajaj wrote:
> Hi,
> 
> Could I have reviews for the following fix:
> 
> JDK-8010738: G1: Output for full GCs with +PrintGCDetails should
> contain perm gen/meta data size change info
> webrev: http://cr.openjdk.java.net/~poonam/8010738/webrev.00/
> 
> With JDK7 G1GC when we use -XX:+PrintGCDetails option, PermGen
> information does not get printed in the Full GC logs as shown below:
> [Full GC 16M->16M(20M), 0.7055536 secs]
>    [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap:
> 16.7M(20.0M)->16.7M(20.0M)]
> 
> PermGen info should also get printed with Full GC info similar to what
> other garbage collectors report. These changes are backport of the fix
> in jdk8 where MetaSpace info gets printed in the Full GC logs.
> 
> With the fix the output looks like:
> [Full GC 16M->16M(20M), 0.6763478 secs]
>    [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap:
> 16.7M(20.0M)->16.7M(20.0M)], [Perm: 1725K->1725K(16384K)]
> 
  just out of curiosity, do the other collectors also add a comma
between the output for the heap proper and the perm gen statistics?

Thanks,
  Thomas




From thomas.schatzl at oracle.com  Fri Apr 18 13:29:42 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 18 Apr 2014 15:29:42 +0200
Subject: RFR (XXS): 8040792: G1CodeRootChunkManager::static_mem_size
	returns the wrong size
In-Reply-To: <534FBCA0.5060108@oracle.com>
References: <1397731374.2834.8.camel@cirrus> <534FBCA0.5060108@oracle.com>
Message-ID: <1397827782.2717.21.camel@cirrus>

Hi Bengt,

  thanks for the review.

On Thu, 2014-04-17 at 13:36 +0200, Bengt Rutisson wrote:
> Hi Thomas,
> 
> On 2014-04-17 12:42, Thomas Schatzl wrote:
> > Hi all,
> >
> > to
> >
> >    87   return sizeof(*this);
> 
> I would kind of prefer
> 
>   return sizeof(G1CodeRootChunkManager);
>
> since it would be faster for me to read.

Done. I also changed a few "sizeof(*this)" at the same time.

> Also, there are more places in the G1 code where we do sizeof(this). At 
> a first glance it looks to me like all of them are wrong.
> 
> $ grep -r "sizeof(this)" src/share/vm/gc_implementation/g1/
> src/share/vm/gc_implementation/g1/sparsePRT.cpp:  return sizeof(this) +
> src/share/vm/gc_implementation/g1/sparsePRT.cpp:  return sizeof(this) + 
> _next->mem_size();
> src/share/vm/gc_implementation/g1/g1CodeCacheRemSet.cpp:  return 
> sizeof(this);
> src/share/vm/gc_implementation/g1/g1CodeCacheRemSet.cpp:  return 
> sizeof(this) + _list.count() * _list.size();
> src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp:      + 
> (sizeof(this) - sizeof(OtherRegionsTable))
> src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp:    return 
> sizeof(this) + _bm.size_in_words() * HeapWordSize;
> 
> Can you verify these at the same time?

Fixed all of them.

I only added test cases where there is already infrastructure to do so
for this trivial "> sizeof(void*)" checks, and where there was no need
to do too much calculation.

I hope this is okay. If not, I prefer splitting these out into an extra
CR.

New webrev:
http://cr.openjdk.java.net/~tschatzl/8040792/webrev.1/

Testing:
new test cases, jprt

Thanks,
  Thomas




From thomas.schatzl at oracle.com  Fri Apr 18 13:29:51 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 18 Apr 2014 15:29:51 +0200
Subject: RFR (M): JDK-8035401: Fix visibility of G1ParScanThreadState members
Message-ID: <1397827791.2717.23.camel@cirrus>

Hi all,

  can I have reviews for this change? After moving G1ParScanThreadState,
this change cleans up visibility, making a whole lot of stuff private.

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

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

Testing:
perf testing indicated no changes, jprt

Thanks,
  Thomas




From thomas.schatzl at oracle.com  Fri Apr 18 13:52:36 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 18 Apr 2014 15:52:36 +0200
Subject: RFR (M/L): JDK-8035400: Move G1ParScanThreadState into its own files
Message-ID: <1397829156.2717.24.camel@cirrus>


Hi all,

  can I have reviews for the above change? It moves G1ParScanThreadState
into G1ParScanThreadState*pp files.

The only changes are limited to:
 - adding a "#pragma warning( disable:4355 ) // 'this' : used in base
member initializer list" to shut visual C up about the problem (which
should be cleaned up at some point - I found an issue that slipped
through because of that, JDK-8040977)
 - added necessary include file references; I hope the AIX guys can
compile that change to avoid troubles. It compiles fine with all Oracle
supported archs.

There will be another CR for fixing up visibility and cleaning up stuff
a little.

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

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

Testing:
perf testing indicated no changes, jprt

Thanks,
  Thomas





From thomas.schatzl at oracle.com  Fri Apr 18 13:53:14 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 18 Apr 2014 15:53:14 +0200
Subject: RFR (M): JDK-8035401: Fix visibility of G1ParScanThreadState
	members
In-Reply-To: <1397827791.2717.23.camel@cirrus>
References: <1397827791.2717.23.camel@cirrus>
Message-ID: <1397829194.2717.25.camel@cirrus>

On Fri, 2014-04-18 at 15:29 +0200, Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews for this change? After moving G1ParScanThreadState,
> this change cleans up visibility, making a whole lot of stuff private.

 This CR is based on the review for 8035400.

Thomas


> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8035401
> 
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8035401/webrev/
> 
> Testing:
> perf testing indicated no changes, jprt
> 
> Thanks,
>   Thomas
> 
> 




From poonam.bajaj at oracle.com  Sat Apr 19 00:31:15 2014
From: poonam.bajaj at oracle.com (Poonam Bajaj)
Date: Sat, 19 Apr 2014 06:01:15 +0530
Subject: Review request(7u): JDK-8010738: G1: Output for full GCs with
	+PrintGCDetails should contain perm gen/meta data size change info
In-Reply-To: <1397826952.2717.19.camel@cirrus>
References: <534F2877.50303@oracle.com> <1397826952.2717.19.camel@cirrus>
Message-ID: <5351C3D3.7000400@oracle.com>

Hi Thomas,

On 4/18/2014 6:45 PM, Thomas Schatzl wrote:
> HI,
>
> On Thu, 2014-04-17 at 06:33 +0530, Poonam Bajaj wrote:
>> Hi,
>>
>> Could I have reviews for the following fix:
>>
>> JDK-8010738: G1: Output for full GCs with +PrintGCDetails should
>> contain perm gen/meta data size change info
>> webrev: http://cr.openjdk.java.net/~poonam/8010738/webrev.00/
>>
>> With JDK7 G1GC when we use -XX:+PrintGCDetails option, PermGen
>> information does not get printed in the Full GC logs as shown below:
>> [Full GC 16M->16M(20M), 0.7055536 secs]
>>     [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap:
>> 16.7M(20.0M)->16.7M(20.0M)]
>>
>> PermGen info should also get printed with Full GC info similar to what
>> other garbage collectors report. These changes are backport of the fix
>> in jdk8 where MetaSpace info gets printed in the Full GC logs.
>>
>> With the fix the output looks like:
>> [Full GC 16M->16M(20M), 0.6763478 secs]
>>     [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap:
>> 16.7M(20.0M)->16.7M(20.0M)], [Perm: 1725K->1725K(16384K)]
>>
>    just out of curiosity, do the other collectors also add a comma
> between the output for the heap proper and the perm gen statistics?
Yes, e.g.

[Full GC (System) [Tenured: 0K->290K(4480K), 0.0053810 secs] 
694K->290K(6464K), [Perm : 2625K->2625K(21248K)], 0.0058610 secs] 
[Times: user=0.01 sys=0.00, real=0.01 secs]

Thanks,
Poonam

> Thanks,
>    Thomas
>
>


From mikael.gerdin at oracle.com  Tue Apr 22 07:54:37 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 22 Apr 2014 09:54:37 +0200
Subject: RFR (XXS): 8040792: G1CodeRootChunkManager::static_mem_size
	returns the wrong size
In-Reply-To: <1397827782.2717.21.camel@cirrus>
References: <1397731374.2834.8.camel@cirrus> <534FBCA0.5060108@oracle.com>
	<1397827782.2717.21.camel@cirrus>
Message-ID: <3132480.fs5eekChzL@mgerdin03>

Hi Thomas,

On Friday 18 April 2014 15.29.42 Thomas Schatzl wrote:
> Hi Bengt,
> 
>   thanks for the review.
> 
> On Thu, 2014-04-17 at 13:36 +0200, Bengt Rutisson wrote:
> > Hi Thomas,
> > 
> > On 2014-04-17 12:42, Thomas Schatzl wrote:
> > > Hi all,
> > > 
> > > to
> > > 
> > >    87   return sizeof(*this);
> > 
> > I would kind of prefer
> > 
> >   return sizeof(G1CodeRootChunkManager);
> > 
> > since it would be faster for me to read.
> 
> Done. I also changed a few "sizeof(*this)" at the same time.
> 
> > Also, there are more places in the G1 code where we do sizeof(this). At
> > a first glance it looks to me like all of them are wrong.
> > 
> > $ grep -r "sizeof(this)" src/share/vm/gc_implementation/g1/
> > src/share/vm/gc_implementation/g1/sparsePRT.cpp:  return sizeof(this) +
> > src/share/vm/gc_implementation/g1/sparsePRT.cpp:  return sizeof(this) +
> > _next->mem_size();
> > src/share/vm/gc_implementation/g1/g1CodeCacheRemSet.cpp:  return
> > sizeof(this);
> > src/share/vm/gc_implementation/g1/g1CodeCacheRemSet.cpp:  return
> > sizeof(this) + _list.count() * _list.size();
> > src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp:      +
> > (sizeof(this) - sizeof(OtherRegionsTable))
> > src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp:    return
> > sizeof(this) + _bm.size_in_words() * HeapWordSize;
> > 
> > Can you verify these at the same time?
> 
> Fixed all of them.
> 
> I only added test cases where there is already infrastructure to do so
> for this trivial "> sizeof(void*)" checks, and where there was no need
> to do too much calculation.
> 
> I hope this is okay. If not, I prefer splitting these out into an extra
> CR.

I think it's fine to fix all these at the same time but please update the bug 
synopsis and description to reflect that all these should be fixed.

> 
> New webrev:
> http://cr.openjdk.java.net/~tschatzl/8040792/webrev.1/

Looks good.

/Mikael

> 
> Testing:
> new test cases, jprt
> 
> Thanks,
>   Thomas



From bengt.rutisson at oracle.com  Tue Apr 22 08:39:31 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 22 Apr 2014 10:39:31 +0200
Subject: RFR (XXS): 8040792: G1CodeRootChunkManager::static_mem_size
	returns the wrong size
In-Reply-To: <3132480.fs5eekChzL@mgerdin03>
References: <1397731374.2834.8.camel@cirrus> <534FBCA0.5060108@oracle.com>
	<1397827782.2717.21.camel@cirrus> <3132480.fs5eekChzL@mgerdin03>
Message-ID: <53562AC3.9030106@oracle.com>

On 4/22/14 9:54 AM, Mikael Gerdin wrote:
> Hi Thomas,
>
> On Friday 18 April 2014 15.29.42 Thomas Schatzl wrote:
>> Hi Bengt,
>>
>>    thanks for the review.
>>
>> On Thu, 2014-04-17 at 13:36 +0200, Bengt Rutisson wrote:
>>> Hi Thomas,
>>>
>>> On 2014-04-17 12:42, Thomas Schatzl wrote:
>>>> Hi all,
>>>>
>>>> to
>>>>
>>>>     87   return sizeof(*this);
>>> I would kind of prefer
>>>
>>>    return sizeof(G1CodeRootChunkManager);
>>>
>>> since it would be faster for me to read.
>> Done. I also changed a few "sizeof(*this)" at the same time.
>>
>>> Also, there are more places in the G1 code where we do sizeof(this). At
>>> a first glance it looks to me like all of them are wrong.
>>>
>>> $ grep -r "sizeof(this)" src/share/vm/gc_implementation/g1/
>>> src/share/vm/gc_implementation/g1/sparsePRT.cpp:  return sizeof(this) +
>>> src/share/vm/gc_implementation/g1/sparsePRT.cpp:  return sizeof(this) +
>>> _next->mem_size();
>>> src/share/vm/gc_implementation/g1/g1CodeCacheRemSet.cpp:  return
>>> sizeof(this);
>>> src/share/vm/gc_implementation/g1/g1CodeCacheRemSet.cpp:  return
>>> sizeof(this) + _list.count() * _list.size();
>>> src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp:      +
>>> (sizeof(this) - sizeof(OtherRegionsTable))
>>> src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp:    return
>>> sizeof(this) + _bm.size_in_words() * HeapWordSize;
>>>
>>> Can you verify these at the same time?
>> Fixed all of them.
>>
>> I only added test cases where there is already infrastructure to do so
>> for this trivial "> sizeof(void*)" checks, and where there was no need
>> to do too much calculation.
>>
>> I hope this is okay. If not, I prefer splitting these out into an extra
>> CR.
> I think it's fine to fix all these at the same time but please update the bug
> synopsis and description to reflect that all these should be fixed.
>
>> New webrev:
>> http://cr.openjdk.java.net/~tschatzl/8040792/webrev.1/
> Looks good.

Looks good to me too. I agree with Mikael about updating the bug 
synopsis and description.

Thanks,
Bengt


>
> /Mikael
>
>> Testing:
>> new test cases, jprt
>>
>> Thanks,
>>    Thomas



From thomas.schatzl at oracle.com  Tue Apr 22 08:45:20 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 22 Apr 2014 10:45:20 +0200
Subject: RFR (XXS): 8040792: G1CodeRootChunkManager::static_mem_size
	returns the wrong size
In-Reply-To: <53562AC3.9030106@oracle.com>
References: <1397731374.2834.8.camel@cirrus> <534FBCA0.5060108@oracle.com>
	<1397827782.2717.21.camel@cirrus> <3132480.fs5eekChzL@mgerdin03>
	<53562AC3.9030106@oracle.com>
Message-ID: <1398156320.3002.2.camel@cirrus>

Hi Bengt, Mikael,

 thanks for the reviews.

I will change the synopsis/title of the bug properly.

Thom



From thomas.schatzl at oracle.com  Tue Apr 22 12:56:31 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 22 Apr 2014 14:56:31 +0200
Subject: RFR (XS): JDK-8040977: G1 crashes when run with
	-XX:-G1DeferredRSUpdate
Message-ID: <1398171391.3002.24.camel@cirrus>


Hi all,

  can I have reviews for this change? It fixes wrong order of
declaration of members of G1ParScanThreadState that causes crashes when
G1DeferredRSUpdate is disabled.

The change is based on the changes for 8035400 and8035401 posted recently.

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

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

Testing:
jprt, new jtreg test case

Thanks,
  Thomas





From jon.masamitsu at oracle.com  Tue Apr 22 16:08:03 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 22 Apr 2014 09:08:03 -0700
Subject: Request for review (s) - 8031323: Optionally align objects copied
	to survivor spaces
In-Reply-To: <53284A7E.9060106@oracle.com>
References: <53267CBB.9020804@oracle.com> <53284A7E.9060106@oracle.com>
Message-ID: <535693E3.3070500@oracle.com>


On 3/18/14 6: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?
>
> 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.
>
>
> The code in PSYoungPromotionLAB::allcoate(), 
> ParGCAllocBuffer::allocate_aligned() and 
> ContiguousSpace::allocate_aligned() is very similar. Is there a way to 
> consolidate these methods?

To consolidate this code I've added CollectedHeap::allocate_inc_top()

http://javaweb.us.oracle.com/net/arches-sunw.us.oracle.com/export/home1/java/jdk9-gc-8031323/webrev_inc_top/webrev/src/share/vm/gc_interface/collectedHeap.inline.hpp.frames.html

Note "top" passed by reference.

  278 inline HeapWord* CollectedHeap::allocate_inc_top(HeapWord* &top,
  279                                                 HeapWord* end,
  280                                                 size_t word_size) {
  281   HeapWord* res = top;
  282   if (pointer_delta(end, top) >= word_size) {
  283     top = top + word_size;
  284     assert(is_ptr_aligned(res, HeapWordSize) &&
  285       is_ptr_aligned(top, HeapWordSize), "checking alignment");
  286     return res;
  287   } else {
  288     return NULL;
  289   }

and use it in places such as

http://javaweb.us.oracle.com/net/arches-sunw.us.oracle.com/export/home1/java/jdk9-gc-8031323/webrev_inc_top/webrev/src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp.udiff.html

-    HeapWord* new_top = obj + size;
-    // The 'new_top>obj' check is needed to detect overflow of obj+size.
-    if (new_top > obj && new_top <= end()) {
-      set_top(new_top);
-      assert(is_object_aligned((intptr_t)obj) && is_object_aligned((intptr_t)new_top),
-             "checking alignment");
-      return obj;
-    }
      set_top(obj);
-    return NULL;
+    return CollectedHeap::allocate_inc_top(_top, end(), size);


Does this do what you want in an OK way?

Jon

>
>
> 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);
>
>   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;
>   }
> }
>
> Thanks,
> Bengt
>
>>
>> Jon
>

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

From jon.masamitsu at oracle.com  Tue Apr 22 20:07:49 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 22 Apr 2014 13:07:49 -0700
Subject: RFR (M): JDK-8035401: Fix visibility of G1ParScanThreadState
	members
In-Reply-To: <1397827791.2717.23.camel@cirrus>
References: <1397827791.2717.23.camel@cirrus>
Message-ID: <5356CC15.7070507@oracle.com>

Thomas,

What I see in these changes are

1) no semantic changes
2) some methods in .hpp files moved to .cpp files
3) creation of steal_and_trim_queue() with definition in
a .cpp file (I may have missed additional such new
methods)
4) change in visibility as the CR says
5) no performance regressions as stated in your RFR

If that's what constitutes the change,
looks good.

Reviewed.

If there is something more significant that I have
overlooked, please point me at it and I'll look again.

Jon


On 4/18/14 6:29 AM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for this change? After moving G1ParScanThreadState,
> this change cleans up visibility, making a whole lot of stuff private.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8035401
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8035401/webrev/
>
> Testing:
> perf testing indicated no changes, jprt
>
> Thanks,
>    Thomas
>
>



From thomas.schatzl at oracle.com  Tue Apr 22 20:36:14 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 22 Apr 2014 22:36:14 +0200
Subject: RFR (M): JDK-8035401: Fix visibility of G1ParScanThreadState
	members
In-Reply-To: <5356CC15.7070507@oracle.com>
References: <1397827791.2717.23.camel@cirrus> <5356CC15.7070507@oracle.com>
Message-ID: <1398198974.2532.32.camel@cirrus>

Hi Jon,

On Tue, 2014-04-22 at 13:07 -0700, Jon Masamitsu wrote:
> Thomas,
> 
> What I see in these changes are
> 
> 1) no semantic changes

No.

> 2) some methods in .hpp files moved to .cpp files

Yes, because they were only referenced by the cpp file, so I thought it
would be good to move them there. They will be inlined as needed anyway
(and I think for some of them they were never inlined due to their
size).

I will do some more runs with the inline's added again.

> 3) creation of steal_and_trim_queue() with definition in
> a .cpp file (I may have missed additional such new
> methods)

There are none except queue_is_empty(), see below.

> 4) change in visibility as the CR says

That's the main change.

> 5) no performance regressions as stated in your RFR

No. Checked the results for the usual benchmarks (specjvm2008,
specjbb05/2013) again right now, and there are no significant
differences in the scores (on x64 and sparc), and for specjbb05/2013 the
average gc pause time, and the object copy time (assuming that this is
the part that will be affected most) stay the same as in the baseline.

> If that's what constitutes the change, looks good.

Thanks.

> Reviewed.
> 
> If there is something more significant that I have
> overlooked, please point me at it and I'll look again.

There is not. Sorry, I should have pointed out the changes in more
detail instead of you making guesses.

Additional minor changes:

- G1ParScanThreadState accesses members directly instead of using
getters (e.g. _refs instead of refs()).

- fixed some newlines in method declarations, removing newlines

- removed refs() to avoid direct access from outside, and adding a new
method queue_is_empty() (only used in asserts as refs()->is_empty(), and
I did not want to expose refs() just for the asserts).

Thanks,
  Thomas

> 
> On 4/18/14 6:29 AM, Thomas Schatzl wrote:
> > Hi all,
> >
> >    can I have reviews for this change? After moving G1ParScanThreadState,
> > this change cleans up visibility, making a whole lot of stuff private.
> >
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8035401
> >
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8035401/webrev/
> >
> > Testing:
> > perf testing indicated no changes, jprt
> >
> > Thanks,
> >    Thomas
> >
> >
> 




From jon.masamitsu at oracle.com  Tue Apr 22 21:31:31 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 22 Apr 2014 14:31:31 -0700
Subject: RFR (M): JDK-8035401: Fix visibility of G1ParScanThreadState
	members
In-Reply-To: <1398198974.2532.32.camel@cirrus>
References: <1397827791.2717.23.camel@cirrus> <5356CC15.7070507@oracle.com>
	<1398198974.2532.32.camel@cirrus>
Message-ID: <5356DFB3.7050400@oracle.com>


On 4/22/14 1:36 PM, Thomas Schatzl wrote:
> Hi Jon,
>
> On Tue, 2014-04-22 at 13:07 -0700, Jon Masamitsu wrote:
>> Thomas,
>>
>> What I see in these changes are
>>
>> 1) no semantic changes
> No.
>
>> 2) some methods in .hpp files moved to .cpp files
> Yes, because they were only referenced by the cpp file, so I thought it
> would be good to move them there. They will be inlined as needed anyway
> (and I think for some of them they were never inlined due to their
> size).
>
> I will do some more runs with the inline's added again.
>
>> 3) creation of steal_and_trim_queue() with definition in
>> a .cpp file (I may have missed additional such new
>> methods)
> There are none except queue_is_empty(), see below.
>
>> 4) change in visibility as the CR says
> That's the main change.
>
>> 5) no performance regressions as stated in your RFR
> No. Checked the results for the usual benchmarks (specjvm2008,
> specjbb05/2013) again right now, and there are no significant
> differences in the scores (on x64 and sparc), and for specjbb05/2013 the
> average gc pause time, and the object copy time (assuming that this is
> the part that will be affected most) stay the same as in the baseline.
>
>> If that's what constitutes the change, looks good.
> Thanks.
>
>> Reviewed.
>>
>> If there is something more significant that I have
>> overlooked, please point me at it and I'll look again.
> There is not. Sorry, I should have pointed out the changes in more
> detail instead of you making guesses.
>
> Additional minor changes:
>
> - G1ParScanThreadState accesses members directly instead of using
> getters (e.g. _refs instead of refs()).
>
> - fixed some newlines in method declarations, removing newlines
>
> - removed refs() to avoid direct access from outside, and adding a new
> method queue_is_empty() (only used in asserts as refs()->is_empty(), and
> I did not want to expose refs() just for the asserts).

All looks good.

Reviewed.

Jon

>
> Thanks,
>    Thomas
>
>> On 4/18/14 6:29 AM, Thomas Schatzl wrote:
>>> Hi all,
>>>
>>>     can I have reviews for this change? After moving G1ParScanThreadState,
>>> this change cleans up visibility, making a whole lot of stuff private.
>>>
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8035401
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~tschatzl/8035401/webrev/
>>>
>>> Testing:
>>> perf testing indicated no changes, jprt
>>>
>>> Thanks,
>>>     Thomas
>>>
>>>
>



From bengt.rutisson at oracle.com  Wed Apr 23 08:20:45 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 23 Apr 2014 10:20:45 +0200
Subject: RFR(S/M): 7132678: G1: verify that the marking bitmaps have no
	marks for objects over TAMS
In-Reply-To: <50F5B7BF.5060800@oracle.com>
References: <50F5B7BF.5060800@oracle.com>
Message-ID: <535777DD.9050601@oracle.com>


Hi all,

Picking up an over 1 year old task...

Tony created this patch at some point and passed it on to John 
Cuthbertson. John sent out a review request and there were some comments 
(http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/thread.html#7202 
and 
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/007279.html), 
but the patch never got finalized or pushed. I thought I'd try to get 
this pushed now.

Just like John suggested I would like to do the push as contributed-by 
Tony unless there are major changes due to comments.

Here is a new webrev:
http://cr.openjdk.java.net/~brutisso/7132678/webrev.1/

Here is the diff compared to the one John sent out 15 months ago:
http://cr.openjdk.java.net/~brutisso/7132678/webrev.0-1.diff/

In the original patch there is a bug in the full GC case. We verify the 
"prev" bitmap after doing a full GC. But the full GC has compacted 
objects and reset tams without updating the prev bitmap. I think this is 
normally safe since the prev bitmap will be cleared once it becomes the 
next bitmap later on. However, the new verification code looks at stale 
data in the prev bitmap. There was already code added to clear the prev 
bitmap if verification was enabled. I moved that code to just before the 
verification. It might seem unnecessary to verify a bitmap that we just 
cleared, but that seemed easier than to propagate the state down to the 
verification code that it should not verify the prev bitmap for this 
particular call.

There is one more change that I made. I removed one guarantee that I 
think was unnecessary.

Thanks,
Bengt

On 2013-01-15 21:10, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of volunteers review the changes for this CR? The 
> webrev can be found at: 
> http://cr.openjdk.java.net/~johnc/7132678/webrev.0/
>
> Most of the changes come from a patch that Tony gave me before he left 
> and I had to tweak them slightly to remove a spurious failure. The 
> changes verify that the heap regions don't have any marks between 
> [TAMS, top) at strategic places: start and end of each GC, start and 
> end of remark and cleanup, and when allocating a region. Tony deserves 
> the bulk of the credit so, if possible and there are no objections, I 
> intend to list him as author of the change and include myself as a 
> reviewer.
>
> Testing:
> GC test suite with the both the new flags (separately and together) 
> and a low IHOP value.
> jprt with the new flags (+IgnoreUnrecognizedVMOptions so that product 
> test runs did not fail).
>
> Thanks,
>
> JohnC



From michal at frajt.eu  Wed Apr 23 09:40:59 2014
From: michal at frajt.eu (Michal Frajt)
Date: Wed, 23 Apr 2014 11:40:59 +0200
Subject: =?utf-8?b?UmU6IFJlcXVlc3QgZm9yIHJldmlldzogODAzODI2NTogQ01TOiBlbmFi?=
	=?utf-8?b?bGUgdGltZSBiYXNlZCB0cmlnZ2VyaW5nIG9mIGNvbmN1cnJlbnQgY3lj?=
	=?utf-8?b?bGVz?=
In-Reply-To: <N44OL3$33CE773F09B8356F3A783DFFAAD7C268@frajt.eu>
References: =?iso-8859-1?q?=3C1DDCA93502632C4DA22E9EE199CE907C015FAA93A0=40SE0025?=
	=?iso-8859-1?q?93=2Ecs=2Ecommerzbank=2Ecom=3E=09=3CN3AW5D=246641B5580?=
	=?iso-8859-1?q?48C64803233A598D2C464DA=40frajt=2Eeu=3E_=3C1666248=2Et?=
	=?iso-8859-1?q?j7xVnjxql=40mgerdin03=3E_=3C534BFDA0=2E9090803=40oracl?=
	=?iso-8859-1?q?e=2Ecom=3E_=3CN44OL3=2433CE773F09B8356F3A783DFFAAD7C26?=
	=?iso-8859-1?q?8=40frajt=2Eeu=3E?=
Message-ID: <N4H9KB$C329D4FE433F13909E50401B5DDCDE87@frajt.eu>

Hi Mikael,

Find a new webrev which is addressing your small (mostly stylistic) comments. If you still find something missing we can quickly create new webrev. 

Here is a new webrev:

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

    

    Here is a diff between the old and the new webrev:

    http://cr.openjdk.java.net/~brutisso/8038265/webrev.00-01.diff/

Best regards,
Michal


Od: "Michal Frajt" michal at frajt.eu
Komu: bengt.rutisson at oracle.com
Kopie: mikael.gerdin at oracle.com, hotspot-gc-dev at openjdk.java.net
Datum: Wed, 16 Apr 2014 16:36:38 +0200
P?edmet: Re: Request for review: 8038265: CMS: enable time based triggering of concurrent cycles






> Hi Bengt,

> We will provide you the new patch next week. All Mikael's comments will be addressed.

> Best regards,
> Michal


> Od: "hotspot-gc-dev" hotspot-gc-dev-bounces at openjdk.java.net
> Komu: "Mikael Gerdin" mikael.gerdin at oracle.com, hotspot-gc-dev at openjdk.java.net
> Kopie: 
> Datum: Mon, 14 Apr 2014 17:24:16 +0200
> P?edmet: Re: Request for review: 8038265: CMS: enable time based triggering of concurrent cycles


> > 
> > Hi Michal,
> > 
> > I think the change looks good modulo the comments that Mikael has. If 
> > you fix those I can help you with a new webrev and then push this change.
> > 
> > Thanks,
> > Bengt
> > 
> > 
> > On 2014-04-01 11:52, Mikael Gerdin wrote:
> > > Hi Michal,
> > >
> > > On Monday 31 March 2014 14.32.01 Michal Frajt wrote:
> > >> Hi all,could you please review the following change we prepared together
> > >> with Bengt? The change adds new CMSTriggerInterval flag which allows to
> > >> invoke CMS collections periodically. The periodically running CMS
> > >> collections are helping us with replacing the deprecated incremental CMS
> > >> collector. We believe it might be useful for other customers currently
> > >> using the CMS in the incremental mode.Bugs:
> > >> https://bugs.openjdk.java.net/browse/JDK-8038265
> > >>
> > >> Webrev:
> > >> http://cr.openjdk.java.net/~brutisso/8038265/webrev.00/
> > > If the addition of this functionality helps you replace iCMS then that's
> > > great! I think this code change is simple and easy to understand.
> > >
> > > I just have some small (mostly stylistic) comments:
> > >
> > > 	The other time output in PrintCMSInitiationStatistics seems to use 	
> > > 	%3.7f as the format specifier instead of %g.
> > >
> > > 1515     gclog_or_tty->print_cr("cms_time_since_begin=%g",
> > > stats().cms_time_since_begin());
> > > 1516     gclog_or_tty->print_cr("cms_time_since_end=%g",
> > > stats().cms_time_since_end());
> > >
> > >
> > > 	The HotSpot style is to have a space between if and the opening brace,
> > > 	can you please change the if here:
> > >
> > > 1588     if(stats().cms_time_since_begin() >= (CMSTriggerInterval / ((double)
> > > MILLIUNITS))) {
> > > 1589       if (Verbose && PrintGCDetails) {
> > >
> > > 	And here:
> > >
> > > 1590         if(stats().valid()) {
> > >
> > > 	We usually align the parameters on the second line with the opening 	
> > > 	brace on the function call, something like:
> > >
> > > gclog_or_tty->print_cr(foo, bar,
> > >                         stats().baz());
> > >
> > > 1591           gclog_or_tty->print_cr("CMSCollector: collect because of
> > > trigger interval (time since last begin %g secs)",
> > > 1592             stats().cms_time_since_begin());
> > > 1593         } else {
> > >
> > > 	You pass in cms_time_since_begin() but don't actually use that value 	
> > > 	in the else branch.
> > >
> > > 1594           gclog_or_tty->print_cr("CMSCollector: collect because of
> > > trigger interval (first collection)",
> > > 1595             stats().cms_time_since_begin());
> > > 1596         }
> > > 1597       }
> > >
> > > /Mikael
> > >
> > >
> > >> Thanks,
> > >> Michal
> > 



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

From mikael.gerdin at oracle.com  Wed Apr 23 10:25:26 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 23 Apr 2014 12:25:26 +0200
Subject: Request for review: 8038265: CMS: enable time based triggering of
	concurrent cycles
In-Reply-To: <N4H9KB$C329D4FE433F13909E50401B5DDCDE87@frajt.eu>
References: <N4H9KB$C329D4FE433F13909E50401B5DDCDE87@frajt.eu>
Message-ID: <7582402.WyW2iQDyui@mgerdin03>

Hi Michal,

On Wednesday 23 April 2014 11.40.59 Michal Frajt wrote:
> Hi Mikael,
> 
> Find a new webrev which is addressing your small (mostly stylistic)
> comments. If you still find something missing we can quickly create new
> webrev.
> 
> Here is a new webrev:
> 
>     http://cr.openjdk.java.net/~brutisso/8038265/webrev.01/
> 
> 
> 
>     Here is a diff between the old and the new webrev:
> 
>     http://cr.openjdk.java.net/~brutisso/8038265/webrev.00-01.diff/

The change looks good to me.
/Mikael

> 
> Best regards,
> Michal
> 
> 
> Od: "Michal Frajt" michal at frajt.eu
> Komu: bengt.rutisson at oracle.com
> Kopie: mikael.gerdin at oracle.com, hotspot-gc-dev at openjdk.java.net
> Datum: Wed, 16 Apr 2014 16:36:38 +0200
> P?edmet: Re: Request for review: 8038265: CMS: enable time based triggering
> of concurrent cycles
> > Hi Bengt,
> > 
> > We will provide you the new patch next week. All Mikael's comments will be
> > addressed.
> > 
> > Best regards,
> > Michal
> > 
> > 
> > Od: "hotspot-gc-dev" hotspot-gc-dev-bounces at openjdk.java.net
> > Komu: "Mikael Gerdin" mikael.gerdin at oracle.com,
> > hotspot-gc-dev at openjdk.java.net Kopie:
> > Datum: Mon, 14 Apr 2014 17:24:16 +0200
> > P?edmet: Re: Request for review: 8038265: CMS: enable time based
> > triggering of concurrent cycles> 
> > > Hi Michal,
> > > 
> > > I think the change looks good modulo the comments that Mikael has. If
> > > you fix those I can help you with a new webrev and then push this
> > > change.
> > > 
> > > Thanks,
> > > Bengt
> > > 
> > > On 2014-04-01 11:52, Mikael Gerdin wrote:
> > > > Hi Michal,
> > > > 
> > > > On Monday 31 March 2014 14.32.01 Michal Frajt wrote:
> > > >> Hi all,could you please review the following change we prepared
> > > >> together
> > > >> with Bengt? The change adds new CMSTriggerInterval flag which allows
> > > >> to
> > > >> invoke CMS collections periodically. The periodically running CMS
> > > >> collections are helping us with replacing the deprecated incremental
> > > >> CMS
> > > >> collector. We believe it might be useful for other customers
> > > >> currently
> > > >> using the CMS in the incremental mode.Bugs:
> > > >> https://bugs.openjdk.java.net/browse/JDK-8038265
> > > >> 
> > > >> Webrev:
> > > >> http://cr.openjdk.java.net/~brutisso/8038265/webrev.00/
> > > > 
> > > > If the addition of this functionality helps you replace iCMS then
> > > > that's
> > > > great! I think this code change is simple and easy to understand.
> > > > 
> > > > I just have some small (mostly stylistic) comments:
> > > > 	The other time output in PrintCMSInitiationStatistics seems to 
use
> > > > 	%3.7f as the format specifier instead of %g.
> > > > 
> > > > 1515     gclog_or_tty->print_cr("cms_time_since_begin=%g",
> > > > stats().cms_time_since_begin());
> > > > 1516     gclog_or_tty->print_cr("cms_time_since_end=%g",
> > > > stats().cms_time_since_end());
> > > > 
> > > > 	The HotSpot style is to have a space between if and the 
opening
> > > > 	brace,
> > > > 
> > > > 	can you please change the if here:
> > > > 1588     if(stats().cms_time_since_begin() >= (CMSTriggerInterval /
> > > > ((double) MILLIUNITS))) {
> > > > 1589       if (Verbose && PrintGCDetails) {
> > > > 
> > > > 	And here:
> > > > 1590         if(stats().valid()) {
> > > > 
> > > > 	We usually align the parameters on the second line with the 
opening
> > > > 
> > > > 	brace on the function call, something like:
> > > > gclog_or_tty->print_cr(foo, bar,
> > > > 
> > > >                         stats().baz());
> > > > 
> > > > 1591           gclog_or_tty->print_cr("CMSCollector: collect because
> > > > of
> > > > trigger interval (time since last begin %g secs)",
> > > > 1592             stats().cms_time_since_begin());
> > > > 1593         } else {
> > > > 
> > > > 	You pass in cms_time_since_begin() but don't actually use that 
value
> > > > 	in the else branch.
> > > > 
> > > > 1594           gclog_or_tty->print_cr("CMSCollector: collect because
> > > > of
> > > > trigger interval (first collection)",
> > > > 1595             stats().cms_time_since_begin());
> > > > 1596         }
> > > > 1597       }
> > > > 
> > > > /Mikael
> > > > 
> > > >> Thanks,
> > > >> Michal



From bengt.rutisson at oracle.com  Wed Apr 23 10:42:13 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 23 Apr 2014 12:42:13 +0200
Subject: Request for review: 8038265: CMS: enable time based triggering
	of concurrent cycles
In-Reply-To: <7582402.WyW2iQDyui@mgerdin03>
References: <N4H9KB$C329D4FE433F13909E50401B5DDCDE87@frajt.eu>
	<7582402.WyW2iQDyui@mgerdin03>
Message-ID: <53579905.2010702@oracle.com>


On 2014-04-23 12:25, Mikael Gerdin wrote:
> Hi Michal,
>
> On Wednesday 23 April 2014 11.40.59 Michal Frajt wrote:
>> Hi Mikael,
>>
>> Find a new webrev which is addressing your small (mostly stylistic)
>> comments. If you still find something missing we can quickly create new
>> webrev.
>>
>> Here is a new webrev:
>>
>>      http://cr.openjdk.java.net/~brutisso/8038265/webrev.01/
>>
>>
>>
>>      Here is a diff between the old and the new webrev:
>>
>>      http://cr.openjdk.java.net/~brutisso/8038265/webrev.00-01.diff/
> The change looks good to me.

Looks good to me too.

I'll push this with:

Contributed-by: michal at frajt.eu

Thanks,
Bengt

> /Mikael
>
>> Best regards,
>> Michal
>>
>>
>> Od: "Michal Frajt" michal at frajt.eu
>> Komu: bengt.rutisson at oracle.com
>> Kopie: mikael.gerdin at oracle.com, hotspot-gc-dev at openjdk.java.net
>> Datum: Wed, 16 Apr 2014 16:36:38 +0200
>> P?edmet: Re: Request for review: 8038265: CMS: enable time based triggering
>> of concurrent cycles
>>> Hi Bengt,
>>>
>>> We will provide you the new patch next week. All Mikael's comments will be
>>> addressed.
>>>
>>> Best regards,
>>> Michal
>>>
>>>
>>> Od: "hotspot-gc-dev" hotspot-gc-dev-bounces at openjdk.java.net
>>> Komu: "Mikael Gerdin" mikael.gerdin at oracle.com,
>>> hotspot-gc-dev at openjdk.java.net Kopie:
>>> Datum: Mon, 14 Apr 2014 17:24:16 +0200
>>> P?edmet: Re: Request for review: 8038265: CMS: enable time based
>>> triggering of concurrent cycles>
>>>> Hi Michal,
>>>>
>>>> I think the change looks good modulo the comments that Mikael has. If
>>>> you fix those I can help you with a new webrev and then push this
>>>> change.
>>>>
>>>> Thanks,
>>>> Bengt
>>>>
>>>> On 2014-04-01 11:52, Mikael Gerdin wrote:
>>>>> Hi Michal,
>>>>>
>>>>> On Monday 31 March 2014 14.32.01 Michal Frajt wrote:
>>>>>> Hi all,could you please review the following change we prepared
>>>>>> together
>>>>>> with Bengt? The change adds new CMSTriggerInterval flag which allows
>>>>>> to
>>>>>> invoke CMS collections periodically. The periodically running CMS
>>>>>> collections are helping us with replacing the deprecated incremental
>>>>>> CMS
>>>>>> collector. We believe it might be useful for other customers
>>>>>> currently
>>>>>> using the CMS in the incremental mode.Bugs:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8038265
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~brutisso/8038265/webrev.00/
>>>>> If the addition of this functionality helps you replace iCMS then
>>>>> that's
>>>>> great! I think this code change is simple and easy to understand.
>>>>>
>>>>> I just have some small (mostly stylistic) comments:
>>>>> 	The other time output in PrintCMSInitiationStatistics seems to
> use
>>>>> 	%3.7f as the format specifier instead of %g.
>>>>>
>>>>> 1515     gclog_or_tty->print_cr("cms_time_since_begin=%g",
>>>>> stats().cms_time_since_begin());
>>>>> 1516     gclog_or_tty->print_cr("cms_time_since_end=%g",
>>>>> stats().cms_time_since_end());
>>>>>
>>>>> 	The HotSpot style is to have a space between if and the
> opening
>>>>> 	brace,
>>>>>
>>>>> 	can you please change the if here:
>>>>> 1588     if(stats().cms_time_since_begin() >= (CMSTriggerInterval /
>>>>> ((double) MILLIUNITS))) {
>>>>> 1589       if (Verbose && PrintGCDetails) {
>>>>>
>>>>> 	And here:
>>>>> 1590         if(stats().valid()) {
>>>>>
>>>>> 	We usually align the parameters on the second line with the
> opening
>>>>> 	brace on the function call, something like:
>>>>> gclog_or_tty->print_cr(foo, bar,
>>>>>
>>>>>                          stats().baz());
>>>>>
>>>>> 1591           gclog_or_tty->print_cr("CMSCollector: collect because
>>>>> of
>>>>> trigger interval (time since last begin %g secs)",
>>>>> 1592             stats().cms_time_since_begin());
>>>>> 1593         } else {
>>>>>
>>>>> 	You pass in cms_time_since_begin() but don't actually use that
> value
>>>>> 	in the else branch.
>>>>>
>>>>> 1594           gclog_or_tty->print_cr("CMSCollector: collect because
>>>>> of
>>>>> trigger interval (first collection)",
>>>>> 1595             stats().cms_time_since_begin());
>>>>> 1596         }
>>>>> 1597       }
>>>>>
>>>>> /Mikael
>>>>>
>>>>>> Thanks,
>>>>>> Michal



From vladimir.kempik at oracle.com  Wed Apr 23 16:18:35 2014
From: vladimir.kempik at oracle.com (Vladimir Kempik)
Date: Wed, 23 Apr 2014 20:18:35 +0400
Subject: Request for review: 8016302: Change type of the number of GC
	workers to unsigned int (2)
In-Reply-To: <535119BF.2000401@oracle.com>
References: <535119BF.2000401@oracle.com>
Message-ID: <5357E7DB.6080402@oracle.com>

Can I have a couple of reviews for this please?
On 18.04.2014 16:25, Vladimir Kempik wrote:
> Hi all,
>
> Could I have a couple of reviews for this change?
>
> http://cr.openjdk.java.net/~vkempik/8016302/jdk7/8016302/webrev.00/
>
> It's backport of https://bugs.openjdk.java.net/browse/JDK-8016302 to 
> jdk7.
>
> I made few additional changes: change return value of 
> num_par_rem_sets() from int to uint (heapRegionRemSet.cpp), just like 
> it is in jdk8. And changed few ints to uints where num_par_rem_sets 
> were used.
>
> Rest of changes just to adopt patch to jdk7.
>
> Thanks,
> Vladimir
>



From jon.masamitsu at oracle.com  Wed Apr 23 18:00:13 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 23 Apr 2014 11:00:13 -0700
Subject: Request for review: 8016302: Change type of the number of GC
	workers to unsigned int (2)
In-Reply-To: <5357E7DB.6080402@oracle.com>
References: <535119BF.2000401@oracle.com> <5357E7DB.6080402@oracle.com>
Message-ID: <5357FFAD.9030905@oracle.com>

Vladimir,

What's the motivation for this backport?

Jon

On 4/23/2014 9:18 AM, Vladimir Kempik wrote:
> Can I have a couple of reviews for this please?
> On 18.04.2014 16:25, Vladimir Kempik wrote:
>> Hi all,
>>
>> Could I have a couple of reviews for this change?
>>
>> http://cr.openjdk.java.net/~vkempik/8016302/jdk7/8016302/webrev.00/
>>
>> It's backport of https://bugs.openjdk.java.net/browse/JDK-8016302 to 
>> jdk7.
>>
>> I made few additional changes: change return value of 
>> num_par_rem_sets() from int to uint (heapRegionRemSet.cpp), just like 
>> it is in jdk8. And changed few ints to uints where num_par_rem_sets 
>> were used.
>>
>> Rest of changes just to adopt patch to jdk7.
>>
>> Thanks,
>> Vladimir
>>
>



From stefan.johansson at oracle.com  Thu Apr 24 11:07:30 2014
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 24 Apr 2014 13:07:30 +0200
Subject: [8u20] Backport RFR: JDK-8033426: Scale initial NewSize using NewRatio
	if not set on command line
Message-ID: <5358F072.9080202@oracle.com>

Hi,

I want to backport JDK-8033426 to solve the regression in jdk-8 where 
the default young generation size is always the same as the minimum 
generation size for the generational collectors.

The backport applied clean except for the testing parts in jni.cpp, 
where another test-call had moved. The backport webrev is available at:
http://cr.openjdk.java.net/~sjohanss/8033426/backport.00
The original jdk9 change:
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f7f0c6a77d6d

As a follow up on this backport I also plan to backport JDK-8035057, 
which fixes a problem with unaligned sizes introduced by this fix. That 
change applies clean, here is the jdk9 change:
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/bac9ef65b71d

Jon and Jesper, you reviewed this the last time. Would you please have a 
quick look and see if you think everything is ok.

Thanks,
Stefan


From jesper.wilhelmsson at oracle.com  Thu Apr 24 16:05:42 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 24 Apr 2014 18:05:42 +0200
Subject: [8u20] Backport RFR: JDK-8033426: Scale initial NewSize using
	NewRatio if not set on command line
In-Reply-To: <5358F072.9080202@oracle.com>
References: <5358F072.9080202@oracle.com>
Message-ID: <53593656.7070908@oracle.com>

Looks good.
/Jesper

Stefan Johansson skrev 24/4/14 13:07:
> Hi,
>
> I want to backport JDK-8033426 to solve the regression in jdk-8 where the
> default young generation size is always the same as the minimum generation size
> for the generational collectors.
>
> The backport applied clean except for the testing parts in jni.cpp, where
> another test-call had moved. The backport webrev is available at:
> http://cr.openjdk.java.net/~sjohanss/8033426/backport.00
> The original jdk9 change:
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f7f0c6a77d6d
>
> As a follow up on this backport I also plan to backport JDK-8035057, which fixes
> a problem with unaligned sizes introduced by this fix. That change applies
> clean, here is the jdk9 change:
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/bac9ef65b71d
>
> Jon and Jesper, you reviewed this the last time. Would you please have a quick
> look and see if you think everything is ok.
>
> Thanks,
> Stefan


From jon.masamitsu at oracle.com  Thu Apr 24 21:17:05 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 24 Apr 2014 14:17:05 -0700
Subject: [8u20] Backport RFR: JDK-8033426: Scale initial NewSize using
	NewRatio if not set on command line
In-Reply-To: <5358F072.9080202@oracle.com>
References: <5358F072.9080202@oracle.com>
Message-ID: <53597F51.60204@oracle.com>

Changes look good.

Reviewed.

Jon

On 4/24/14 4:07 AM, Stefan Johansson wrote:
> Hi,
>
> I want to backport JDK-8033426 to solve the regression in jdk-8 where 
> the default young generation size is always the same as the minimum 
> generation size for the generational collectors.
>
> The backport applied clean except for the testing parts in jni.cpp, 
> where another test-call had moved. The backport webrev is available at:
> http://cr.openjdk.java.net/~sjohanss/8033426/backport.00
> The original jdk9 change:
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f7f0c6a77d6d
>
> As a follow up on this backport I also plan to backport JDK-8035057, 
> which fixes a problem with unaligned sizes introduced by this fix. 
> That change applies clean, here is the jdk9 change:
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/bac9ef65b71d
>
> Jon and Jesper, you reviewed this the last time. Would you please have 
> a quick look and see if you think everything is ok.
>
> Thanks,
> Stefan



From staffan.larsen at oracle.com  Fri Apr 25 06:20:31 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 25 Apr 2014 08:20:31 +0200
Subject: RFR: 8038947 HotSpotDiagnosticMXBean/CheckOrigin.java 'NewSize'
	should have origin 'ERGONOMIC' but had 'DEFAULT'
In-Reply-To: <6B180B1F-9799-48B3-8B18-CCBE7F32FF6B@oracle.com>
References: <6B180B1F-9799-48B3-8B18-CCBE7F32FF6B@oracle.com>
Message-ID: <67324BA3-62E9-45E7-8AB4-829C9B56942E@oracle.com>

Can I get a Review for this, please?

Thanks,
/Staffan

On 8 apr 2014, at 14:07, Staffan Larsen <staffan.larsen at oracle.com> wrote:

> This test verifies the origins of a couple of flags. One origin type is ERGONOMIC. The test used NewSize as an example flag that was set ergonomically by the JVM. It turns out that flag is not always set ergonomically. 
> 
> This change switches to use UseParNewGC as the ergonomic flag. This flag is set whenever UseConcMarkSweepGC is used.
> 
> webrev: http://cr.openjdk.java.net/~sla/8038947/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8038947
> 
> Thanks,
> /Staffan



From mandy.chung at oracle.com  Fri Apr 25 06:35:22 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 24 Apr 2014 23:35:22 -0700
Subject: RFR: 8038947 HotSpotDiagnosticMXBean/CheckOrigin.java 'NewSize'
	should have origin 'ERGONOMIC' but had 'DEFAULT'
In-Reply-To: <67324BA3-62E9-45E7-8AB4-829C9B56942E@oracle.com>
References: <6B180B1F-9799-48B3-8B18-CCBE7F32FF6B@oracle.com>
	<67324BA3-62E9-45E7-8AB4-829C9B56942E@oracle.com>
Message-ID: <535A022A.3050006@oracle.com>

The patch looks okay to me.

Mandy

On 4/24/2014 11:20 PM, Staffan Larsen wrote:
> Can I get a Review for this, please?
>
> Thanks,
> /Staffan
>
> On 8 apr 2014, at 14:07, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>
>> This test verifies the origins of a couple of flags. One origin type is ERGONOMIC. The test used NewSize as an example flag that was set ergonomically by the JVM. It turns out that flag is not always set ergonomically.
>>
>> This change switches to use UseParNewGC as the ergonomic flag. This flag is set whenever UseConcMarkSweepGC is used.
>>
>> webrev: http://cr.openjdk.java.net/~sla/8038947/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8038947
>>
>> Thanks,
>> /Staffan



From staffan.larsen at oracle.com  Fri Apr 25 06:52:17 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 25 Apr 2014 08:52:17 +0200
Subject: RFR: 8038947 HotSpotDiagnosticMXBean/CheckOrigin.java 'NewSize'
	should have origin 'ERGONOMIC' but had 'DEFAULT'
In-Reply-To: <535A022A.3050006@oracle.com>
References: <6B180B1F-9799-48B3-8B18-CCBE7F32FF6B@oracle.com>
	<67324BA3-62E9-45E7-8AB4-829C9B56942E@oracle.com>
	<535A022A.3050006@oracle.com>
Message-ID: <8D1FFEF5-3C71-4E45-AB5C-CFEF91276A23@oracle.com>

Thanks, Mandy!

On 25 apr 2014, at 08:35, Mandy Chung <mandy.chung at oracle.com> wrote:

> The patch looks okay to me.
> 
> Mandy
> 
> On 4/24/2014 11:20 PM, Staffan Larsen wrote:
>> Can I get a Review for this, please?
>> 
>> Thanks,
>> /Staffan
>> 
>> On 8 apr 2014, at 14:07, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>> 
>>> This test verifies the origins of a couple of flags. One origin type is ERGONOMIC. The test used NewSize as an example flag that was set ergonomically by the JVM. It turns out that flag is not always set ergonomically.
>>> 
>>> This change switches to use UseParNewGC as the ergonomic flag. This flag is set whenever UseConcMarkSweepGC is used.
>>> 
>>> webrev: http://cr.openjdk.java.net/~sla/8038947/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8038947
>>> 
>>> Thanks,
>>> /Staffan
> 



From stefan.johansson at oracle.com  Fri Apr 25 08:54:49 2014
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Fri, 25 Apr 2014 10:54:49 +0200
Subject: [8u20] Backport RFR: JDK-8033426: Scale initial NewSize using
	NewRatio if not set on command line
In-Reply-To: <53597F51.60204@oracle.com>
References: <5358F072.9080202@oracle.com> <53597F51.60204@oracle.com>
Message-ID: <535A22D9.40806@oracle.com>

Thanks Jon and Jesper!

On 2014-04-24 23:17, Jon Masamitsu wrote:
> Changes look good.
>
> Reviewed.
>
> Jon
>
> On 4/24/14 4:07 AM, Stefan Johansson wrote:
>> Hi,
>>
>> I want to backport JDK-8033426 to solve the regression in jdk-8 where 
>> the default young generation size is always the same as the minimum 
>> generation size for the generational collectors.
>>
>> The backport applied clean except for the testing parts in jni.cpp, 
>> where another test-call had moved. The backport webrev is available at:
>> http://cr.openjdk.java.net/~sjohanss/8033426/backport.00
>> The original jdk9 change:
>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f7f0c6a77d6d
>>
>> As a follow up on this backport I also plan to backport JDK-8035057, 
>> which fixes a problem with unaligned sizes introduced by this fix. 
>> That change applies clean, here is the jdk9 change:
>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/bac9ef65b71d
>>
>> Jon and Jesper, you reviewed this the last time. Would you please 
>> have a quick look and see if you think everything is ok.
>>
>> Thanks,
>> Stefan
>



From andreas.eriksson at oracle.com  Fri Apr 25 12:17:17 2014
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Fri, 25 Apr 2014 14:17:17 +0200
Subject: RFR: 8038925: Java 7 with G1 crashes in dump_instance_fields using
	jmap or jcmd without fullgc
Message-ID: <535A524D.1000701@oracle.com>

Hi,

Could I have a review for this G1 jdk7 only fix please?

Description:
When using G1 and doing a heap dump while no fullgc has been done, 
hotspot crashes.
This is because G1CollectedHeap::safe_object_iterate uses 
ContiguousSpace::object_iterate_from, which does not avoid dead objects 
that can still be on the heap when using G1.

The fix adds a G1 specific safe_object_iterate code path that avoids 
dead objects.

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

Thanks to Mikael Gerdin for his help with this.

Regards,
Andreas



From thomas.schatzl at oracle.com  Fri Apr 25 12:53:29 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 25 Apr 2014 14:53:29 +0200
Subject: RFR: 8038925: Java 7 with G1 crashes in dump_instance_fields
	using jmap or jcmd without fullgc
In-Reply-To: <535A524D.1000701@oracle.com>
References: <535A524D.1000701@oracle.com>
Message-ID: <1398430409.14355.72.camel@cirrus>

Hi,

On Fri, 2014-04-25 at 14:17 +0200, Andreas Eriksson wrote:
> Hi,
> 
> Could I have a review for this G1 jdk7 only fix please?

  why is this change only necessary for jdk7?

> Description:
> When using G1 and doing a heap dump while no fullgc has been done, 
> hotspot crashes.
> This is because G1CollectedHeap::safe_object_iterate uses 
> ContiguousSpace::object_iterate_from, which does not avoid dead objects 
> that can still be on the heap when using G1.
> 
> The fix adds a G1 specific safe_object_iterate code path that avoids 
> dead objects.
> 
> http://cr.openjdk.java.net/~aeriksso/8038925/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8038925
> 
> Thanks to Mikael Gerdin for his help with this.
> 

Thanks,
Thomas




From mikael.gerdin at oracle.com  Fri Apr 25 13:14:28 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 25 Apr 2014 15:14:28 +0200
Subject: RFR: 8038925: Java 7 with G1 crashes in dump_instance_fields
	using jmap or jcmd without fullgc
In-Reply-To: <1398430409.14355.72.camel@cirrus>
References: <535A524D.1000701@oracle.com> <1398430409.14355.72.camel@cirrus>
Message-ID: <2609553.USauZpmh17@mgerdin03>

On Friday 25 April 2014 14.53.29 Thomas Schatzl wrote:
> Hi,
> 
> On Fri, 2014-04-25 at 14:17 +0200, Andreas Eriksson wrote:
> > Hi,
> > 
> > Could I have a review for this G1 jdk7 only fix please?
> 
>   why is this change only necessary for jdk7?

The idea was that for 9 and 8u40+ we will need a separate way to handle this 
anyway due to class unloading (as previously discussed).

We may or may not want to get this fix into 8u20, I'd like to hear your input 
on that Thomas.

/Mikael

> 
> > Description:
> > When using G1 and doing a heap dump while no fullgc has been done,
> > hotspot crashes.
> > This is because G1CollectedHeap::safe_object_iterate uses
> > ContiguousSpace::object_iterate_from, which does not avoid dead objects
> > that can still be on the heap when using G1.
> > 
> > The fix adds a G1 specific safe_object_iterate code path that avoids
> > dead objects.
> > 
> > http://cr.openjdk.java.net/~aeriksso/8038925/webrev.00/
> > https://bugs.openjdk.java.net/browse/JDK-8038925
> > 
> > Thanks to Mikael Gerdin for his help with this.
> 
> Thanks,
> Thomas



From andreas.eriksson at oracle.com  Fri Apr 25 13:21:45 2014
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Fri, 25 Apr 2014 15:21:45 +0200
Subject: RFR: 8038925: Java 7 with G1 crashes in dump_instance_fields
	using jmap or jcmd without fullgc
In-Reply-To: <2609553.USauZpmh17@mgerdin03>
References: <535A524D.1000701@oracle.com> <1398430409.14355.72.camel@cirrus>
	<2609553.USauZpmh17@mgerdin03>
Message-ID: <535A6169.6030609@oracle.com>

In addition, this particular test doesn't reproduce on jdk8 or jdk9 for 
some reason.
I will take a quick look and see if I can spot why.

/Andreas

On 2014-04-25 15:14, Mikael Gerdin wrote:
> On Friday 25 April 2014 14.53.29 Thomas Schatzl wrote:
>> Hi,
>>
>> On Fri, 2014-04-25 at 14:17 +0200, Andreas Eriksson wrote:
>>> Hi,
>>>
>>> Could I have a review for this G1 jdk7 only fix please?
>>    why is this change only necessary for jdk7?
> The idea was that for 9 and 8u40+ we will need a separate way to handle this
> anyway due to class unloading (as previously discussed).
>
> We may or may not want to get this fix into 8u20, I'd like to hear your input
> on that Thomas.
>
> /Mikael
>
>>> Description:
>>> When using G1 and doing a heap dump while no fullgc has been done,
>>> hotspot crashes.
>>> This is because G1CollectedHeap::safe_object_iterate uses
>>> ContiguousSpace::object_iterate_from, which does not avoid dead objects
>>> that can still be on the heap when using G1.
>>>
>>> The fix adds a G1 specific safe_object_iterate code path that avoids
>>> dead objects.
>>>
>>> http://cr.openjdk.java.net/~aeriksso/8038925/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8038925
>>>
>>> Thanks to Mikael Gerdin for his help with this.
>> Thanks,
>> Thomas



From andreas.eriksson at oracle.com  Fri Apr 25 13:57:00 2014
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Fri, 25 Apr 2014 15:57:00 +0200
Subject: RFR: 8038925: Java 7 with G1 crashes in dump_instance_fields
	using jmap or jcmd without fullgc
In-Reply-To: <535A6169.6030609@oracle.com>
References: <535A524D.1000701@oracle.com> <1398430409.14355.72.camel@cirrus>
	<2609553.USauZpmh17@mgerdin03> <535A6169.6030609@oracle.com>
Message-ID: <535A69AC.6070702@oracle.com>

I saw no obvious reason why it doesn't reproduce on jdk8 or jdk9.
Maybe someone with better knowledge of G1 can say.
Could it have something to do with the metaspace rewrites?

/Andreas

On 2014-04-25 15:21, Andreas Eriksson wrote:
> In addition, this particular test doesn't reproduce on jdk8 or jdk9 
> for some reason.
> I will take a quick look and see if I can spot why.
>
> /Andreas
>
> On 2014-04-25 15:14, Mikael Gerdin wrote:
>> On Friday 25 April 2014 14.53.29 Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Fri, 2014-04-25 at 14:17 +0200, Andreas Eriksson wrote:
>>>> Hi,
>>>>
>>>> Could I have a review for this G1 jdk7 only fix please?
>>>    why is this change only necessary for jdk7?
>> The idea was that for 9 and 8u40+ we will need a separate way to 
>> handle this
>> anyway due to class unloading (as previously discussed).
>>
>> We may or may not want to get this fix into 8u20, I'd like to hear 
>> your input
>> on that Thomas.
>>
>> /Mikael
>>
>>>> Description:
>>>> When using G1 and doing a heap dump while no fullgc has been done,
>>>> hotspot crashes.
>>>> This is because G1CollectedHeap::safe_object_iterate uses
>>>> ContiguousSpace::object_iterate_from, which does not avoid dead 
>>>> objects
>>>> that can still be on the heap when using G1.
>>>>
>>>> The fix adds a G1 specific safe_object_iterate code path that avoids
>>>> dead objects.
>>>>
>>>> http://cr.openjdk.java.net/~aeriksso/8038925/webrev.00/
>>>> https://bugs.openjdk.java.net/browse/JDK-8038925
>>>>
>>>> Thanks to Mikael Gerdin for his help with this.
>>> Thanks,
>>> Thomas
>



From erik.helin at oracle.com  Fri Apr 25 13:55:37 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Fri, 25 Apr 2014 15:55:37 +0200
Subject: RFR(S/M): 7132678: G1: verify that the marking bitmaps have no
	marks for objects over TAMS
In-Reply-To: <535777DD.9050601@oracle.com>
References: <50F5B7BF.5060800@oracle.com> <535777DD.9050601@oracle.com>
Message-ID: <535A6959.6050005@oracle.com>

Hi Bengt,

On 2014-04-23 10:20, Bengt Rutisson wrote:
>
> Hi all,
>
> Picking up an over 1 year old task...
>
> Tony created this patch at some point and passed it on to John
> Cuthbertson. John sent out a review request and there were some comments
> (http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/thread.html#7202
> and
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/007279.html),
> but the patch never got finalized or pushed. I thought I'd try to get
> this pushed now.
>
> Just like John suggested I would like to do the push as contributed-by
> Tony unless there are major changes due to comments.
>
> Here is a new webrev:
> http://cr.openjdk.java.net/~brutisso/7132678/webrev.1/

I had a look at the patch and noticed:

   bool G1CollectedHeap::verify_bitmaps:
     ...
     if (mark_in_progress() || !_cmThread->in_progress()) {
       res_n = verify_bitmap("next", next_bitmap, ntams, end);
     }
     ...

what does the condition mark_in_process() || !_cmThread->in_progress() 
mean here?

What do you think about adding a comment (or extracting this check into 
a method) to make it more obvious why we are doing this check?

Thanks,
Erik

> Here is the diff compared to the one John sent out 15 months ago:
> http://cr.openjdk.java.net/~brutisso/7132678/webrev.0-1.diff/
>
> In the original patch there is a bug in the full GC case. We verify the
> "prev" bitmap after doing a full GC. But the full GC has compacted
> objects and reset tams without updating the prev bitmap. I think this is
> normally safe since the prev bitmap will be cleared once it becomes the
> next bitmap later on. However, the new verification code looks at stale
> data in the prev bitmap. There was already code added to clear the prev
> bitmap if verification was enabled. I moved that code to just before the
> verification. It might seem unnecessary to verify a bitmap that we just
> cleared, but that seemed easier than to propagate the state down to the
> verification code that it should not verify the prev bitmap for this
> particular call.
>
> There is one more change that I made. I removed one guarantee that I
> think was unnecessary.
>
> Thanks,
> Bengt
>
> On 2013-01-15 21:10, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> Can I have a couple of volunteers review the changes for this CR? The
>> webrev can be found at:
>> http://cr.openjdk.java.net/~johnc/7132678/webrev.0/
>>
>> Most of the changes come from a patch that Tony gave me before he left
>> and I had to tweak them slightly to remove a spurious failure. The
>> changes verify that the heap regions don't have any marks between
>> [TAMS, top) at strategic places: start and end of each GC, start and
>> end of remark and cleanup, and when allocating a region. Tony deserves
>> the bulk of the credit so, if possible and there are no objections, I
>> intend to list him as author of the change and include myself as a
>> reviewer.
>>
>> Testing:
>> GC test suite with the both the new flags (separately and together)
>> and a low IHOP value.
>> jprt with the new flags (+IgnoreUnrecognizedVMOptions so that product
>> test runs did not fail).
>>
>> Thanks,
>>
>> JohnC
>


From bengt.rutisson at oracle.com  Fri Apr 25 14:30:22 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 25 Apr 2014 16:30:22 +0200
Subject: RFR(S/M): 7132678: G1: verify that the marking bitmaps have no
	marks for objects over TAMS
In-Reply-To: <535A6959.6050005@oracle.com>
References: <50F5B7BF.5060800@oracle.com> <535777DD.9050601@oracle.com>
	<535A6959.6050005@oracle.com>
Message-ID: <535A717E.8060204@oracle.com>


Hi Erik,

Thanks for looking at this!

On 2014-04-25 15:55, Erik Helin wrote:
> Hi Bengt,
>
> On 2014-04-23 10:20, Bengt Rutisson wrote:
>>
>> Hi all,
>>
>> Picking up an over 1 year old task...
>>
>> Tony created this patch at some point and passed it on to John
>> Cuthbertson. John sent out a review request and there were some comments
>> (http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/thread.html#7202 
>>
>> and
>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/007279.html), 
>>
>> but the patch never got finalized or pushed. I thought I'd try to get
>> this pushed now.
>>
>> Just like John suggested I would like to do the push as contributed-by
>> Tony unless there are major changes due to comments.
>>
>> Here is a new webrev:
>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.1/
>
> I had a look at the patch and noticed:
>
>   bool G1CollectedHeap::verify_bitmaps:
>     ...
>     if (mark_in_progress() || !_cmThread->in_progress()) {
>       res_n = verify_bitmap("next", next_bitmap, ntams, end);
>     }
>     ...
>
> what does the condition mark_in_process() || !_cmThread->in_progress() 
> mean here?
>
> What do you think about adding a comment (or extracting this check 
> into a method) to make it more obvious why we are doing this check?

Good point!

Updated webrev:
http://cr.openjdk.java.net/~brutisso/7132678/webrev.2/

And the diff with only the comment added:
http://cr.openjdk.java.net/~brutisso/7132678/webrev.1-2.diff/

Thanks,
Bengt

>
> Thanks,
> Erik
>
>> Here is the diff compared to the one John sent out 15 months ago:
>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.0-1.diff/
>>
>> In the original patch there is a bug in the full GC case. We verify the
>> "prev" bitmap after doing a full GC. But the full GC has compacted
>> objects and reset tams without updating the prev bitmap. I think this is
>> normally safe since the prev bitmap will be cleared once it becomes the
>> next bitmap later on. However, the new verification code looks at stale
>> data in the prev bitmap. There was already code added to clear the prev
>> bitmap if verification was enabled. I moved that code to just before the
>> verification. It might seem unnecessary to verify a bitmap that we just
>> cleared, but that seemed easier than to propagate the state down to the
>> verification code that it should not verify the prev bitmap for this
>> particular call.
>>
>> There is one more change that I made. I removed one guarantee that I
>> think was unnecessary.
>>
>> Thanks,
>> Bengt
>>
>> On 2013-01-15 21:10, John Cuthbertson wrote:
>>> Hi Everyone,
>>>
>>> Can I have a couple of volunteers review the changes for this CR? The
>>> webrev can be found at:
>>> http://cr.openjdk.java.net/~johnc/7132678/webrev.0/
>>>
>>> Most of the changes come from a patch that Tony gave me before he left
>>> and I had to tweak them slightly to remove a spurious failure. The
>>> changes verify that the heap regions don't have any marks between
>>> [TAMS, top) at strategic places: start and end of each GC, start and
>>> end of remark and cleanup, and when allocating a region. Tony deserves
>>> the bulk of the credit so, if possible and there are no objections, I
>>> intend to list him as author of the change and include myself as a
>>> reviewer.
>>>
>>> Testing:
>>> GC test suite with the both the new flags (separately and together)
>>> and a low IHOP value.
>>> jprt with the new flags (+IgnoreUnrecognizedVMOptions so that product
>>> test runs did not fail).
>>>
>>> Thanks,
>>>
>>> JohnC
>>



From vladimir.kempik at oracle.com  Fri Apr 25 15:15:47 2014
From: vladimir.kempik at oracle.com (Vladimir Kempik)
Date: Fri, 25 Apr 2014 19:15:47 +0400
Subject: Request for review: 8016302: Change type of the number of GC
	workers to unsigned int (2)
In-Reply-To: <5357FFAD.9030905@oracle.com>
References: <535119BF.2000401@oracle.com> <5357E7DB.6080402@oracle.com>
	<5357FFAD.9030905@oracle.com>
Message-ID: <535A7C23.50008@oracle.com>

Hi

Why not?
Ints as array indexes isn't a good thing and the backport didn't took 
much time, so I've decided to try to get it to jdk7 as well. Maybe it 
will prevent some errors in future, when jdk7 goes to sustaining mode.

Thanks
On 23.04.2014 22:00, Jon Masamitsu wrote:
> Vladimir,
>
> What's the motivation for this backport?
>
> Jon
>
> On 4/23/2014 9:18 AM, Vladimir Kempik wrote:
>> Can I have a couple of reviews for this please?
>> On 18.04.2014 16:25, Vladimir Kempik wrote:
>>> Hi all,
>>>
>>> Could I have a couple of reviews for this change?
>>>
>>> http://cr.openjdk.java.net/~vkempik/8016302/jdk7/8016302/webrev.00/
>>>
>>> It's backport of https://bugs.openjdk.java.net/browse/JDK-8016302 to 
>>> jdk7.
>>>
>>> I made few additional changes: change return value of 
>>> num_par_rem_sets() from int to uint (heapRegionRemSet.cpp), just 
>>> like it is in jdk8. And changed few ints to uints where 
>>> num_par_rem_sets were used.
>>>
>>> Rest of changes just to adopt patch to jdk7.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>
>



From jon.masamitsu at oracle.com  Fri Apr 25 17:28:38 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 25 Apr 2014 10:28:38 -0700
Subject: RFR(S/M): 7132678: G1: verify that the marking bitmaps have no
	marks for objects over TAMS
In-Reply-To: <535A717E.8060204@oracle.com>
References: <50F5B7BF.5060800@oracle.com> <535777DD.9050601@oracle.com>
	<535A6959.6050005@oracle.com> <535A717E.8060204@oracle.com>
Message-ID: <535A9B46.4070000@oracle.com>

There are two new flags introduced.

>   334   develop(bool, G1VerifyBitmaps, false,                                     \
>   335           "Verifies the consistency of the marking bitmaps")                \
>   336                                                                             \
>   337   develop(bool, G1VerifyPrevBitmap, false,                                  \
>   338           "Verifies the consistency of the prev marking bitmap")

When would we want to verify the next bitmap but not the prev bitmap?

I see that G1VerifyPrevBitmap guards

> 1515       // Clear the previous marking bitmap, if needed for bitmap verification.
> 1516       // Note we cannot do this when we clear the next marking bitmap in
> 1517       // ConcurrentMark::abort() above since VerifyDuringGC verifies the
> 1518       // objects marked during a full GC against the previous bitmap.
> 1519       // But we need to clear it before calling check_bitmaps below since
> 1520       // the full GC has compacted objects and updated TAMS but not updated
> 1521       // the prev bitmap.
> 1522       if (G1VerifyPrevBitmap) {
> 1523         ((CMBitMap*) concurrent_mark()->prevMarkBitMap())->clearAll();
> 1524       }

Is it worth the extra flag for that?

How about changing verify_bitmaps() to verify_both_bitmaps()? To make it
easier on the eyes to distinguish from verify_bitmap().

Rest looks good.

Jon


On 4/25/2014 7:30 AM, Bengt Rutisson wrote:
>
> Hi Erik,
>
> Thanks for looking at this!
>
> On 2014-04-25 15:55, Erik Helin wrote:
>> Hi Bengt,
>>
>> On 2014-04-23 10:20, Bengt Rutisson wrote:
>>>
>>> Hi all,
>>>
>>> Picking up an over 1 year old task...
>>>
>>> Tony created this patch at some point and passed it on to John
>>> Cuthbertson. John sent out a review request and there were some 
>>> comments
>>> (http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/thread.html#7202 
>>>
>>> and
>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/007279.html), 
>>>
>>> but the patch never got finalized or pushed. I thought I'd try to get
>>> this pushed now.
>>>
>>> Just like John suggested I would like to do the push as contributed-by
>>> Tony unless there are major changes due to comments.
>>>
>>> Here is a new webrev:
>>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.1/
>>
>> I had a look at the patch and noticed:
>>
>>   bool G1CollectedHeap::verify_bitmaps:
>>     ...
>>     if (mark_in_progress() || !_cmThread->in_progress()) {
>>       res_n = verify_bitmap("next", next_bitmap, ntams, end);
>>     }
>>     ...
>>
>> what does the condition mark_in_process() || 
>> !_cmThread->in_progress() mean here?
>>
>> What do you think about adding a comment (or extracting this check 
>> into a method) to make it more obvious why we are doing this check?
>
> Good point!
>
> Updated webrev:
> http://cr.openjdk.java.net/~brutisso/7132678/webrev.2/
>
> And the diff with only the comment added:
> http://cr.openjdk.java.net/~brutisso/7132678/webrev.1-2.diff/
>
> Thanks,
> Bengt
>
>>
>> Thanks,
>> Erik
>>
>>> Here is the diff compared to the one John sent out 15 months ago:
>>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.0-1.diff/
>>>
>>> In the original patch there is a bug in the full GC case. We verify the
>>> "prev" bitmap after doing a full GC. But the full GC has compacted
>>> objects and reset tams without updating the prev bitmap. I think 
>>> this is
>>> normally safe since the prev bitmap will be cleared once it becomes the
>>> next bitmap later on. However, the new verification code looks at stale
>>> data in the prev bitmap. There was already code added to clear the prev
>>> bitmap if verification was enabled. I moved that code to just before 
>>> the
>>> verification. It might seem unnecessary to verify a bitmap that we just
>>> cleared, but that seemed easier than to propagate the state down to the
>>> verification code that it should not verify the prev bitmap for this
>>> particular call.
>>>
>>> There is one more change that I made. I removed one guarantee that I
>>> think was unnecessary.
>>>
>>> Thanks,
>>> Bengt
>>>
>>> On 2013-01-15 21:10, John Cuthbertson wrote:
>>>> Hi Everyone,
>>>>
>>>> Can I have a couple of volunteers review the changes for this CR? The
>>>> webrev can be found at:
>>>> http://cr.openjdk.java.net/~johnc/7132678/webrev.0/
>>>>
>>>> Most of the changes come from a patch that Tony gave me before he left
>>>> and I had to tweak them slightly to remove a spurious failure. The
>>>> changes verify that the heap regions don't have any marks between
>>>> [TAMS, top) at strategic places: start and end of each GC, start and
>>>> end of remark and cleanup, and when allocating a region. Tony deserves
>>>> the bulk of the credit so, if possible and there are no objections, I
>>>> intend to list him as author of the change and include myself as a
>>>> reviewer.
>>>>
>>>> Testing:
>>>> GC test suite with the both the new flags (separately and together)
>>>> and a low IHOP value.
>>>> jprt with the new flags (+IgnoreUnrecognizedVMOptions so that product
>>>> test runs did not fail).
>>>>
>>>> Thanks,
>>>>
>>>> JohnC
>>>
>



From ysr1729 at gmail.com  Sun Apr 27 20:07:06 2014
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Sun, 27 Apr 2014 13:07:06 -0700
Subject: RFR: 8038947 HotSpotDiagnosticMXBean/CheckOrigin.java 'NewSize'
	should have origin 'ERGONOMIC' but had 'DEFAULT'
In-Reply-To: <67324BA3-62E9-45E7-8AB4-829C9B56942E@oracle.com>
References: <6B180B1F-9799-48B3-8B18-CCBE7F32FF6B@oracle.com>
	<67324BA3-62E9-45E7-8AB4-829C9B56942E@oracle.com>
Message-ID: <792BCAE0-796B-4C77-A1C2-33C959A21D4C@gmail.com>

Looks good.

ysr1729

> On Apr 24, 2014, at 23:20, Staffan Larsen <staffan.larsen at oracle.com> wrote:
> 
> Can I get a Review for this, please?
> 
> Thanks,
> /Staffan
> 
>> On 8 apr 2014, at 14:07, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>> 
>> This test verifies the origins of a couple of flags. One origin type is ERGONOMIC. The test used NewSize as an example flag that was set ergonomically by the JVM. It turns out that flag is not always set ergonomically. 
>> 
>> This change switches to use UseParNewGC as the ergonomic flag. This flag is set whenever UseConcMarkSweepGC is used.
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8038947/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8038947
>> 
>> Thanks,
>> /Staffan
> 


From thomas.schatzl at oracle.com  Mon Apr 28 07:52:14 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 28 Apr 2014 09:52:14 +0200
Subject: RFR(S/M): 7132678: G1: verify that the marking bitmaps have no
	marks for objects over TAMS
In-Reply-To: <535A717E.8060204@oracle.com>
References: <50F5B7BF.5060800@oracle.com> <535777DD.9050601@oracle.com>
	<535A6959.6050005@oracle.com> <535A717E.8060204@oracle.com>
Message-ID: <1398671534.2642.2.camel@cirrus>

Hi,

On Fri, 2014-04-25 at 16:30 +0200, Bengt Rutisson wrote:
> Hi Erik,
> 
> Thanks for looking at this!
> 
> On 2014-04-25 15:55, Erik Helin wrote:
> > Hi Bengt,
> >
> > On 2014-04-23 10:20, Bengt Rutisson wrote:
> >>
> >> Hi all,
> >>
> >> Picking up an over 1 year old task...
> >>
> >> Tony created this patch at some point and passed it on to John
> >> Cuthbertson. John sent out a review request and there were some comments
> >> (http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/thread.html#7202 
>[...]
> Good point!
> 
> Updated webrev:
> http://cr.openjdk.java.net/~brutisso/7132678/webrev.2/
> 
> And the diff with only the comment added:
> http://cr.openjdk.java.net/~brutisso/7132678/webrev.1-2.diff/

Looks good.

Thanks,
  Thomas




From bengt.rutisson at oracle.com  Mon Apr 28 11:09:36 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 28 Apr 2014 13:09:36 +0200
Subject: RFR(S/M): 7132678: G1: verify that the marking bitmaps have no
	marks for objects over TAMS
In-Reply-To: <535A9B46.4070000@oracle.com>
References: <50F5B7BF.5060800@oracle.com>
	<535777DD.9050601@oracle.com>	<535A6959.6050005@oracle.com>
	<535A717E.8060204@oracle.com> <535A9B46.4070000@oracle.com>
Message-ID: <535E36F0.9070001@oracle.com>


Hi Jon,

Thanks for looking at this!


On 2014-04-25 19:28, Jon Masamitsu wrote:
> There are two new flags introduced.
>
>>   334   develop(bool, G1VerifyBitmaps, 
>> false,                                     \
>>   335           "Verifies the consistency of the marking 
>> bitmaps")                \
>> 336 \
>>   337   develop(bool, G1VerifyPrevBitmap, 
>> false,                                  \
>>   338           "Verifies the consistency of the prev marking bitmap")
>
> When would we want to verify the next bitmap but not the prev bitmap?
>
> I see that G1VerifyPrevBitmap guards
>
>> 1515       // Clear the previous marking bitmap, if needed for bitmap 
>> verification.
>> 1516       // Note we cannot do this when we clear the next marking 
>> bitmap in
>> 1517       // ConcurrentMark::abort() above since VerifyDuringGC 
>> verifies the
>> 1518       // objects marked during a full GC against the previous 
>> bitmap.
>> 1519       // But we need to clear it before calling check_bitmaps 
>> below since
>> 1520       // the full GC has compacted objects and updated TAMS but 
>> not updated
>> 1521       // the prev bitmap.
>> 1522       if (G1VerifyPrevBitmap) {
>> 1523         ((CMBitMap*) 
>> concurrent_mark()->prevMarkBitMap())->clearAll();
>> 1524       }
>
> Is it worth the extra flag for that?

I think that is the reason, but I doubt that it is worth it. I do agree 
that it is questionable if we need two flags and if we do we should name 
them differently and make sure that they behave consistently.

Rather than making things more complicated I removed G1VerifyPrevBitmap 
and only use G1VerifyBitmaps now.

>
> How about changing verify_bitmaps() to verify_both_bitmaps()? To make it
> easier on the eyes to distinguish from verify_bitmap().

I renamed verify_bitmap() to verify_no_bits_over_tams() since it 
actually does not verify the whole bitmap, just that there are not bits 
set over TAMS.

New webrev:
http://cr.openjdk.java.net/~brutisso/7132678/webrev.3/

Diff compared to last one:
http://cr.openjdk.java.net/~brutisso/7132678/webrev.2-3.diff/

Thanks,
Bengt


>
> Rest looks good.
>
> Jon
>
>
> On 4/25/2014 7:30 AM, Bengt Rutisson wrote:
>>
>> Hi Erik,
>>
>> Thanks for looking at this!
>>
>> On 2014-04-25 15:55, Erik Helin wrote:
>>> Hi Bengt,
>>>
>>> On 2014-04-23 10:20, Bengt Rutisson wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Picking up an over 1 year old task...
>>>>
>>>> Tony created this patch at some point and passed it on to John
>>>> Cuthbertson. John sent out a review request and there were some 
>>>> comments
>>>> (http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/thread.html#7202 
>>>>
>>>> and
>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/007279.html), 
>>>>
>>>> but the patch never got finalized or pushed. I thought I'd try to get
>>>> this pushed now.
>>>>
>>>> Just like John suggested I would like to do the push as contributed-by
>>>> Tony unless there are major changes due to comments.
>>>>
>>>> Here is a new webrev:
>>>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.1/
>>>
>>> I had a look at the patch and noticed:
>>>
>>>   bool G1CollectedHeap::verify_bitmaps:
>>>     ...
>>>     if (mark_in_progress() || !_cmThread->in_progress()) {
>>>       res_n = verify_bitmap("next", next_bitmap, ntams, end);
>>>     }
>>>     ...
>>>
>>> what does the condition mark_in_process() || 
>>> !_cmThread->in_progress() mean here?
>>>
>>> What do you think about adding a comment (or extracting this check 
>>> into a method) to make it more obvious why we are doing this check?
>>
>> Good point!
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.2/
>>
>> And the diff with only the comment added:
>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.1-2.diff/
>>
>> Thanks,
>> Bengt
>>
>>>
>>> Thanks,
>>> Erik
>>>
>>>> Here is the diff compared to the one John sent out 15 months ago:
>>>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.0-1.diff/
>>>>
>>>> In the original patch there is a bug in the full GC case. We verify 
>>>> the
>>>> "prev" bitmap after doing a full GC. But the full GC has compacted
>>>> objects and reset tams without updating the prev bitmap. I think 
>>>> this is
>>>> normally safe since the prev bitmap will be cleared once it becomes 
>>>> the
>>>> next bitmap later on. However, the new verification code looks at 
>>>> stale
>>>> data in the prev bitmap. There was already code added to clear the 
>>>> prev
>>>> bitmap if verification was enabled. I moved that code to just 
>>>> before the
>>>> verification. It might seem unnecessary to verify a bitmap that we 
>>>> just
>>>> cleared, but that seemed easier than to propagate the state down to 
>>>> the
>>>> verification code that it should not verify the prev bitmap for this
>>>> particular call.
>>>>
>>>> There is one more change that I made. I removed one guarantee that I
>>>> think was unnecessary.
>>>>
>>>> Thanks,
>>>> Bengt
>>>>
>>>> On 2013-01-15 21:10, John Cuthbertson wrote:
>>>>> Hi Everyone,
>>>>>
>>>>> Can I have a couple of volunteers review the changes for this CR? The
>>>>> webrev can be found at:
>>>>> http://cr.openjdk.java.net/~johnc/7132678/webrev.0/
>>>>>
>>>>> Most of the changes come from a patch that Tony gave me before he 
>>>>> left
>>>>> and I had to tweak them slightly to remove a spurious failure. The
>>>>> changes verify that the heap regions don't have any marks between
>>>>> [TAMS, top) at strategic places: start and end of each GC, start and
>>>>> end of remark and cleanup, and when allocating a region. Tony 
>>>>> deserves
>>>>> the bulk of the credit so, if possible and there are no objections, I
>>>>> intend to list him as author of the change and include myself as a
>>>>> reviewer.
>>>>>
>>>>> Testing:
>>>>> GC test suite with the both the new flags (separately and together)
>>>>> and a low IHOP value.
>>>>> jprt with the new flags (+IgnoreUnrecognizedVMOptions so that product
>>>>> test runs did not fail).
>>>>>
>>>>> Thanks,
>>>>>
>>>>> JohnC
>>>>
>>
>



From goetz.lindenmaier at sap.com  Mon Apr 28 12:19:58 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 28 Apr 2014 12:19:58 +0000
Subject: RFR(M): 8038498: Fix includes and C inlining after 8035330
In-Reply-To: <1397675052.6470.13.camel@cirrus>
References: <4295855A5C1DE049A61835A1887419CC2CEAAA44@DEWDFEMB12A.global.corp.sap>
	<533A7A0E.5040100@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEAC068@DEWDFEMB12A.global.corp.sap>
	<533A8FD8.3090400@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEAC0A6@DEWDFEMB12A.global.corp.sap>
	<1396357031.2707.13.camel@cirrus>
	<CA+3eh13+AoGFHG2wDQDmCoQjzOhEfOXdzDB757vWFsDu_vgMqg@mail.gmail.com>
	<1397675052.6470.13.camel@cirrus>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CEB3842@DEWDFEMB12A.global.corp.sap>

Hi Thomas, 

no, no problem with this!  But correct attribution is a nice-to-have ;)

Best regards,
  Goetz.

-----Original Message-----
From: Thomas Schatzl [mailto:thomas.schatzl at oracle.com] 
Sent: Mittwoch, 16. April 2014 21:04
To: Volker Simonis
Cc: Lindenmaier, Goetz; hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR(M): 8038498: Fix includes and C inlining after 8035330

Hi,

On Wed, 2014-04-16 at 18:38 +0200, Volker Simonis wrote:
> Hi Thomas,
>
> thanks for sponsoring this change.
>
> I just wonder why the downported change in jdk8u
> (http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/rev/bfdf528be8e8) is
> attributed to you and not to Goetz? 
> In the jdk9 repositories
> (http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/4c16a27793eb) Goetz
> is correctly mentioned as the author.

  that's my fault. When committing the backport a few days later, I
forgot to make Goetz the author (i.e. did not use "hg commit -u goetz",
or did not do a straight import of that patch - I do not remember). I
never intended to claim authorship for the change/commit.

There were no changes in the backport, just a straight re-commit. So
there was no review necessary. From the bugtracker (and this mail
thread) it should be clear (at least now) that this is "only" a
backport, and the reason for this difference human error.

Unfortunately the commit message cannot be changed any more.

Interestingly the push hook did not complain that the author is also
mentioned as reviewer :) (Then again, Stefan K is sufficient to pass).

I will try to be more wary of this next time. I hope this poses no
problem.

Sorry,
  Thomas



From erik.helin at oracle.com  Mon Apr 28 12:48:21 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Mon, 28 Apr 2014 14:48:21 +0200
Subject: RFR(S/M): 7132678: G1: verify that the marking bitmaps have no
	marks for objects over TAMS
In-Reply-To: <535E36F0.9070001@oracle.com>
References: <50F5B7BF.5060800@oracle.com>	<535777DD.9050601@oracle.com>	<535A6959.6050005@oracle.com>	<535A717E.8060204@oracle.com>
	<535A9B46.4070000@oracle.com> <535E36F0.9070001@oracle.com>
Message-ID: <535E4E15.4010408@oracle.com>

On 2014-04-28 13:09, Bengt Rutisson wrote:
>
> Hi Jon,
>
> Thanks for looking at this!
>
>
> On 2014-04-25 19:28, Jon Masamitsu wrote:
>> There are two new flags introduced.
>>
>>>   334   develop(bool, G1VerifyBitmaps,
>>> false,                                     \
>>>   335           "Verifies the consistency of the marking
>>> bitmaps")                \
>>> 336 \
>>>   337   develop(bool, G1VerifyPrevBitmap,
>>> false,                                  \
>>>   338           "Verifies the consistency of the prev marking bitmap")
>>
>> When would we want to verify the next bitmap but not the prev bitmap?
>>
>> I see that G1VerifyPrevBitmap guards
>>
>>> 1515       // Clear the previous marking bitmap, if needed for bitmap
>>> verification.
>>> 1516       // Note we cannot do this when we clear the next marking
>>> bitmap in
>>> 1517       // ConcurrentMark::abort() above since VerifyDuringGC
>>> verifies the
>>> 1518       // objects marked during a full GC against the previous
>>> bitmap.
>>> 1519       // But we need to clear it before calling check_bitmaps
>>> below since
>>> 1520       // the full GC has compacted objects and updated TAMS but
>>> not updated
>>> 1521       // the prev bitmap.
>>> 1522       if (G1VerifyPrevBitmap) {
>>> 1523         ((CMBitMap*)
>>> concurrent_mark()->prevMarkBitMap())->clearAll();
>>> 1524       }
>>
>> Is it worth the extra flag for that?
>
> I think that is the reason, but I doubt that it is worth it. I do agree
> that it is questionable if we need two flags and if we do we should name
> them differently and make sure that they behave consistently.
>
> Rather than making things more complicated I removed G1VerifyPrevBitmap
> and only use G1VerifyBitmaps now.
>
>>
>> How about changing verify_bitmaps() to verify_both_bitmaps()? To make it
>> easier on the eyes to distinguish from verify_bitmap().
>
> I renamed verify_bitmap() to verify_no_bits_over_tams() since it
> actually does not verify the whole bitmap, just that there are not bits
> set over TAMS.
>
> New webrev:
> http://cr.openjdk.java.net/~brutisso/7132678/webrev.3/

Looks good!

Thanks,
Erik

> Diff compared to last one:
> http://cr.openjdk.java.net/~brutisso/7132678/webrev.2-3.diff/
>
> Thanks,
> Bengt
>
>
>>
>> Rest looks good.
>>
>> Jon
>>
>>
>> On 4/25/2014 7:30 AM, Bengt Rutisson wrote:
>>>
>>> Hi Erik,
>>>
>>> Thanks for looking at this!
>>>
>>> On 2014-04-25 15:55, Erik Helin wrote:
>>>> Hi Bengt,
>>>>
>>>> On 2014-04-23 10:20, Bengt Rutisson wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Picking up an over 1 year old task...
>>>>>
>>>>> Tony created this patch at some point and passed it on to John
>>>>> Cuthbertson. John sent out a review request and there were some
>>>>> comments
>>>>> (http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/thread.html#7202
>>>>>
>>>>> and
>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/007279.html),
>>>>>
>>>>> but the patch never got finalized or pushed. I thought I'd try to get
>>>>> this pushed now.
>>>>>
>>>>> Just like John suggested I would like to do the push as contributed-by
>>>>> Tony unless there are major changes due to comments.
>>>>>
>>>>> Here is a new webrev:
>>>>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.1/
>>>>
>>>> I had a look at the patch and noticed:
>>>>
>>>>   bool G1CollectedHeap::verify_bitmaps:
>>>>     ...
>>>>     if (mark_in_progress() || !_cmThread->in_progress()) {
>>>>       res_n = verify_bitmap("next", next_bitmap, ntams, end);
>>>>     }
>>>>     ...
>>>>
>>>> what does the condition mark_in_process() ||
>>>> !_cmThread->in_progress() mean here?
>>>>
>>>> What do you think about adding a comment (or extracting this check
>>>> into a method) to make it more obvious why we are doing this check?
>>>
>>> Good point!
>>>
>>> Updated webrev:
>>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.2/
>>>
>>> And the diff with only the comment added:
>>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.1-2.diff/
>>>
>>> Thanks,
>>> Bengt
>>>
>>>>
>>>> Thanks,
>>>> Erik
>>>>
>>>>> Here is the diff compared to the one John sent out 15 months ago:
>>>>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.0-1.diff/
>>>>>
>>>>> In the original patch there is a bug in the full GC case. We verify
>>>>> the
>>>>> "prev" bitmap after doing a full GC. But the full GC has compacted
>>>>> objects and reset tams without updating the prev bitmap. I think
>>>>> this is
>>>>> normally safe since the prev bitmap will be cleared once it becomes
>>>>> the
>>>>> next bitmap later on. However, the new verification code looks at
>>>>> stale
>>>>> data in the prev bitmap. There was already code added to clear the
>>>>> prev
>>>>> bitmap if verification was enabled. I moved that code to just
>>>>> before the
>>>>> verification. It might seem unnecessary to verify a bitmap that we
>>>>> just
>>>>> cleared, but that seemed easier than to propagate the state down to
>>>>> the
>>>>> verification code that it should not verify the prev bitmap for this
>>>>> particular call.
>>>>>
>>>>> There is one more change that I made. I removed one guarantee that I
>>>>> think was unnecessary.
>>>>>
>>>>> Thanks,
>>>>> Bengt
>>>>>
>>>>> On 2013-01-15 21:10, John Cuthbertson wrote:
>>>>>> Hi Everyone,
>>>>>>
>>>>>> Can I have a couple of volunteers review the changes for this CR? The
>>>>>> webrev can be found at:
>>>>>> http://cr.openjdk.java.net/~johnc/7132678/webrev.0/
>>>>>>
>>>>>> Most of the changes come from a patch that Tony gave me before he
>>>>>> left
>>>>>> and I had to tweak them slightly to remove a spurious failure. The
>>>>>> changes verify that the heap regions don't have any marks between
>>>>>> [TAMS, top) at strategic places: start and end of each GC, start and
>>>>>> end of remark and cleanup, and when allocating a region. Tony
>>>>>> deserves
>>>>>> the bulk of the credit so, if possible and there are no objections, I
>>>>>> intend to list him as author of the change and include myself as a
>>>>>> reviewer.
>>>>>>
>>>>>> Testing:
>>>>>> GC test suite with the both the new flags (separately and together)
>>>>>> and a low IHOP value.
>>>>>> jprt with the new flags (+IgnoreUnrecognizedVMOptions so that product
>>>>>> test runs did not fail).
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> JohnC
>>>>>
>>>
>>
>


From vladimir.kempik at oracle.com  Mon Apr 28 14:04:00 2014
From: vladimir.kempik at oracle.com (Vladimir Kempik)
Date: Mon, 28 Apr 2014 18:04:00 +0400
Subject: RFR: 8038925: Java 7 with G1 crashes in dump_instance_fields
	using jmap or jcmd without fullgc
In-Reply-To: <535A69AC.6070702@oracle.com>
References: <535A524D.1000701@oracle.com>
	<1398430409.14355.72.camel@cirrus>	<2609553.USauZpmh17@mgerdin03>
	<535A6169.6030609@oracle.com> <535A69AC.6070702@oracle.com>
Message-ID: <535E5FD0.9060402@oracle.com>

Hello

I've had a similar bug with G1 a while ago (Crash in build 1.7.0_40-b43 
when using g1 and heapdumpbeforefullgc. ).
I did lots of hotspot builds to find out when it started and stopped to 
appear.
The changeset to introduce my bug was 
http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/aaf61e68b25
  and the changeset to stop the crash were - 
http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/da91efe96a93

That's permgen removal.

Also the workaround was - -XX:-ResizePLAB.

I have a reproducer for my bug and this fix for 8038925 does fix it.

Thanks.
On 25.04.2014 17:57, Andreas Eriksson wrote:
> I saw no obvious reason why it doesn't reproduce on jdk8 or jdk9.
> Maybe someone with better knowledge of G1 can say.
> Could it have something to do with the metaspace rewrites?
>
> /Andreas
>
> On 2014-04-25 15:21, Andreas Eriksson wrote:
>> In addition, this particular test doesn't reproduce on jdk8 or jdk9 
>> for some reason.
>> I will take a quick look and see if I can spot why.
>>
>> /Andreas
>>
>> On 2014-04-25 15:14, Mikael Gerdin wrote:
>>> On Friday 25 April 2014 14.53.29 Thomas Schatzl wrote:
>>>> Hi,
>>>>
>>>> On Fri, 2014-04-25 at 14:17 +0200, Andreas Eriksson wrote:
>>>>> Hi,
>>>>>
>>>>> Could I have a review for this G1 jdk7 only fix please?
>>>>    why is this change only necessary for jdk7?
>>> The idea was that for 9 and 8u40+ we will need a separate way to 
>>> handle this
>>> anyway due to class unloading (as previously discussed).
>>>
>>> We may or may not want to get this fix into 8u20, I'd like to hear 
>>> your input
>>> on that Thomas.
>>>
>>> /Mikael
>>>
>>>>> Description:
>>>>> When using G1 and doing a heap dump while no fullgc has been done,
>>>>> hotspot crashes.
>>>>> This is because G1CollectedHeap::safe_object_iterate uses
>>>>> ContiguousSpace::object_iterate_from, which does not avoid dead 
>>>>> objects
>>>>> that can still be on the heap when using G1.
>>>>>
>>>>> The fix adds a G1 specific safe_object_iterate code path that avoids
>>>>> dead objects.
>>>>>
>>>>> http://cr.openjdk.java.net/~aeriksso/8038925/webrev.00/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8038925
>>>>>
>>>>> Thanks to Mikael Gerdin for his help with this.
>>>> Thanks,
>>>> Thomas
>>
>



From jon.masamitsu at oracle.com  Mon Apr 28 16:07:37 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 28 Apr 2014 09:07:37 -0700
Subject: RFR(S/M): 7132678: G1: verify that the marking bitmaps have no
	marks for objects over TAMS
In-Reply-To: <535E36F0.9070001@oracle.com>
References: <50F5B7BF.5060800@oracle.com>
	<535777DD.9050601@oracle.com>	<535A6959.6050005@oracle.com>
	<535A717E.8060204@oracle.com> <535A9B46.4070000@oracle.com>
	<535E36F0.9070001@oracle.com>
Message-ID: <535E7CC9.7090404@oracle.com>


On 04/28/2014 04:09 AM, Bengt Rutisson wrote:
>
> Hi Jon,
>
> Thanks for looking at this!
>
>
> On 2014-04-25 19:28, Jon Masamitsu wrote:
>> There are two new flags introduced.
>>
>>>   334   develop(bool, G1VerifyBitmaps, 
>>> false,                                     \
>>>   335           "Verifies the consistency of the marking 
>>> bitmaps")                \
>>> 336 \
>>>   337   develop(bool, G1VerifyPrevBitmap, 
>>> false,                                  \
>>>   338           "Verifies the consistency of the prev marking bitmap")
>>
>> When would we want to verify the next bitmap but not the prev bitmap?
>>
>> I see that G1VerifyPrevBitmap guards
>>
>>> 1515       // Clear the previous marking bitmap, if needed for 
>>> bitmap verification.
>>> 1516       // Note we cannot do this when we clear the next marking 
>>> bitmap in
>>> 1517       // ConcurrentMark::abort() above since VerifyDuringGC 
>>> verifies the
>>> 1518       // objects marked during a full GC against the previous 
>>> bitmap.
>>> 1519       // But we need to clear it before calling check_bitmaps 
>>> below since
>>> 1520       // the full GC has compacted objects and updated TAMS but 
>>> not updated
>>> 1521       // the prev bitmap.
>>> 1522       if (G1VerifyPrevBitmap) {
>>> 1523         ((CMBitMap*) 
>>> concurrent_mark()->prevMarkBitMap())->clearAll();
>>> 1524       }
>>
>> Is it worth the extra flag for that?
>
> I think that is the reason, but I doubt that it is worth it. I do 
> agree that it is questionable if we need two flags and if we do we 
> should name them differently and make sure that they behave consistently.
>
> Rather than making things more complicated I removed 
> G1VerifyPrevBitmap and only use G1VerifyBitmaps now.

Sounds good.

>
>>
>> How about changing verify_bitmaps() to verify_both_bitmaps()? To make it
>> easier on the eyes to distinguish from verify_bitmap().
>
> I renamed verify_bitmap() to verify_no_bits_over_tams() since it 
> actually does not verify the whole bitmap, just that there are not 
> bits set over TAMS.

Even better.

>
> New webrev:
> http://cr.openjdk.java.net/~brutisso/7132678/webrev.3/
>
> Diff compared to last one:
> http://cr.openjdk.java.net/~brutisso/7132678/webrev.2-3.diff/

Changes look good.

Reviewed.

Jon
> Thanks,
> Bengt
>
>
>>
>> Rest looks good.
>>
>> Jon
>>
>>
>> On 4/25/2014 7:30 AM, Bengt Rutisson wrote:
>>>
>>> Hi Erik,
>>>
>>> Thanks for looking at this!
>>>
>>> On 2014-04-25 15:55, Erik Helin wrote:
>>>> Hi Bengt,
>>>>
>>>> On 2014-04-23 10:20, Bengt Rutisson wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Picking up an over 1 year old task...
>>>>>
>>>>> Tony created this patch at some point and passed it on to John
>>>>> Cuthbertson. John sent out a review request and there were some 
>>>>> comments
>>>>> (http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/thread.html#7202 
>>>>>
>>>>> and
>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/007279.html), 
>>>>>
>>>>> but the patch never got finalized or pushed. I thought I'd try to get
>>>>> this pushed now.
>>>>>
>>>>> Just like John suggested I would like to do the push as 
>>>>> contributed-by
>>>>> Tony unless there are major changes due to comments.
>>>>>
>>>>> Here is a new webrev:
>>>>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.1/
>>>>
>>>> I had a look at the patch and noticed:
>>>>
>>>>   bool G1CollectedHeap::verify_bitmaps:
>>>>     ...
>>>>     if (mark_in_progress() || !_cmThread->in_progress()) {
>>>>       res_n = verify_bitmap("next", next_bitmap, ntams, end);
>>>>     }
>>>>     ...
>>>>
>>>> what does the condition mark_in_process() || 
>>>> !_cmThread->in_progress() mean here?
>>>>
>>>> What do you think about adding a comment (or extracting this check 
>>>> into a method) to make it more obvious why we are doing this check?
>>>
>>> Good point!
>>>
>>> Updated webrev:
>>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.2/
>>>
>>> And the diff with only the comment added:
>>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.1-2.diff/
>>>
>>> Thanks,
>>> Bengt
>>>
>>>>
>>>> Thanks,
>>>> Erik
>>>>
>>>>> Here is the diff compared to the one John sent out 15 months ago:
>>>>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.0-1.diff/
>>>>>
>>>>> In the original patch there is a bug in the full GC case. We 
>>>>> verify the
>>>>> "prev" bitmap after doing a full GC. But the full GC has compacted
>>>>> objects and reset tams without updating the prev bitmap. I think 
>>>>> this is
>>>>> normally safe since the prev bitmap will be cleared once it 
>>>>> becomes the
>>>>> next bitmap later on. However, the new verification code looks at 
>>>>> stale
>>>>> data in the prev bitmap. There was already code added to clear the 
>>>>> prev
>>>>> bitmap if verification was enabled. I moved that code to just 
>>>>> before the
>>>>> verification. It might seem unnecessary to verify a bitmap that we 
>>>>> just
>>>>> cleared, but that seemed easier than to propagate the state down 
>>>>> to the
>>>>> verification code that it should not verify the prev bitmap for this
>>>>> particular call.
>>>>>
>>>>> There is one more change that I made. I removed one guarantee that I
>>>>> think was unnecessary.
>>>>>
>>>>> Thanks,
>>>>> Bengt
>>>>>
>>>>> On 2013-01-15 21:10, John Cuthbertson wrote:
>>>>>> Hi Everyone,
>>>>>>
>>>>>> Can I have a couple of volunteers review the changes for this CR? 
>>>>>> The
>>>>>> webrev can be found at:
>>>>>> http://cr.openjdk.java.net/~johnc/7132678/webrev.0/
>>>>>>
>>>>>> Most of the changes come from a patch that Tony gave me before he 
>>>>>> left
>>>>>> and I had to tweak them slightly to remove a spurious failure. The
>>>>>> changes verify that the heap regions don't have any marks between
>>>>>> [TAMS, top) at strategic places: start and end of each GC, start and
>>>>>> end of remark and cleanup, and when allocating a region. Tony 
>>>>>> deserves
>>>>>> the bulk of the credit so, if possible and there are no 
>>>>>> objections, I
>>>>>> intend to list him as author of the change and include myself as a
>>>>>> reviewer.
>>>>>>
>>>>>> Testing:
>>>>>> GC test suite with the both the new flags (separately and together)
>>>>>> and a low IHOP value.
>>>>>> jprt with the new flags (+IgnoreUnrecognizedVMOptions so that 
>>>>>> product
>>>>>> test runs did not fail).
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> JohnC
>>>>>
>>>
>>
>



From jon.masamitsu at oracle.com  Mon Apr 28 21:17:28 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 28 Apr 2014 14:17:28 -0700
Subject: Request for Review (xs) : 8038928 - gc/g1/TestGCLogMessages.java
	fail with "[Evacuation Failure' found"
Message-ID: <535EC568.7060207@oracle.com>

The requirement that an evacuation failure not happen during this
test is based on the expected behavior of the GC and is not a
required behavior.  In some instance the evacuation failure will
happen, but it is a not a  GC failure if it does and is only an
unexpected path being followed.

The test is not reliable but before removing it, I've made
some changes to try and save it.  I've modified the
test to slow down the allocations and changed the allocation to
allocate smaller objects (which also has a side effect of slowing
allocations).   The goal is to detect gross breakages of
evacuation failure while risking only very, very rare spurious
failures.

I had reproduced the failure with the unmodified test and it
would fail within 30 minutes.  With the modifications, I haven't
seen the failure in a day of testing.

If the modifications don't work, I'll remove the test.

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

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

Thanks.

Jon


From serguei.spitsyn at oracle.com  Mon Apr 28 21:27:10 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 28 Apr 2014 14:27:10 -0700
Subject: RFR: 8038947 HotSpotDiagnosticMXBean/CheckOrigin.java 'NewSize'
	should have origin 'ERGONOMIC' but had 'DEFAULT'
In-Reply-To: <67324BA3-62E9-45E7-8AB4-829C9B56942E@oracle.com>
References: <6B180B1F-9799-48B3-8B18-CCBE7F32FF6B@oracle.com>
	<67324BA3-62E9-45E7-8AB4-829C9B56942E@oracle.com>
Message-ID: <535EC7AE.4010300@oracle.com>

Looks good.

Thanks,
Serguei

On 4/24/14 11:20 PM, Staffan Larsen wrote:
> Can I get a Review for this, please?
>
> Thanks,
> /Staffan
>
> On 8 apr 2014, at 14:07, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>
>> This test verifies the origins of a couple of flags. One origin type is ERGONOMIC. The test used NewSize as an example flag that was set ergonomically by the JVM. It turns out that flag is not always set ergonomically.
>>
>> This change switches to use UseParNewGC as the ergonomic flag. This flag is set whenever UseConcMarkSweepGC is used.
>>
>> webrev: http://cr.openjdk.java.net/~sla/8038947/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8038947
>>
>> Thanks,
>> /Staffan



From bengt.rutisson at oracle.com  Tue Apr 29 06:43:03 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 29 Apr 2014 08:43:03 +0200
Subject: Request for Review (xs) : 8038928 - gc/g1/TestGCLogMessages.java
	fail with "[Evacuation Failure' found"
In-Reply-To: <535EC568.7060207@oracle.com>
References: <535EC568.7060207@oracle.com>
Message-ID: <535F49F7.6060204@oracle.com>


Hi Jon,

On 4/28/14 11:17 PM, Jon Masamitsu wrote:
> The requirement that an evacuation failure not happen during this
> test is based on the expected behavior of the GC and is not a
> required behavior.  In some instance the evacuation failure will
> happen, but it is a not a  GC failure if it does and is only an
> unexpected path being followed.
>
> The test is not reliable but before removing it, I've made
> some changes to try and save it.  I've modified the
> test to slow down the allocations and changed the allocation to
> allocate smaller objects (which also has a side effect of slowing
> allocations).   The goal is to detect gross breakages of
> evacuation failure while risking only very, very rare spurious
> failures.
>
> I had reproduced the failure with the unmodified test and it
> would fail within 30 minutes.  With the modifications, I haven't
> seen the failure in a day of testing.
>
> If the modifications don't work, I'll remove the test.
>
> http://cr.openjdk.java.net/~jmasa/8038928/webrev.00/
>
> https://bugs.openjdk.java.net/browse/JDK-8038928

Slowing down the test does not seem like a stable solution. Just like 
you point out.

What do you think about this instead?

The original code does:

// create 128MB of garbage. This should result in at least one GC
for (int i = 0; i < 1024; i++) {
   garbage = new byte[128 * 1024];
}

We run with -Xmx10M but no -Xmn set. We should only ever promote one 
object each GC, so I assume that what happens when we get an evacuation 
failure is that we get too many GCs that it fills up the old space.

How about specifying -Xmn and only allocate enough to fill the young gen 
a few times. Instead of allocating 128MB we could maybe run with -Xmn2M 
and allocate 8MB worth of objects. That should be enough to get a few 
GCs but not enough to fill the old gen up. If you want to be really safe 
you could also increase -Xmx to something like 128M.

Thanks,
Bengt

>
> Thanks.
>
> Jon

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

From bengt.rutisson at oracle.com  Tue Apr 29 07:39:00 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 29 Apr 2014 09:39:00 +0200
Subject: RFR(S/M): 7132678: G1: verify that the marking bitmaps have no
	marks for objects over TAMS
In-Reply-To: <535E7CC9.7090404@oracle.com>
References: <50F5B7BF.5060800@oracle.com>
	<535777DD.9050601@oracle.com>	<535A6959.6050005@oracle.com>
	<535A717E.8060204@oracle.com> <535A9B46.4070000@oracle.com>
	<535E36F0.9070001@oracle.com> <535E7CC9.7090404@oracle.com>
Message-ID: <535F5714.3040609@oracle.com>


Thanks for the reviews, Jon, Thomas and Erik!

Bengt


On 2014-04-28 18:07, Jon Masamitsu wrote:
>
> On 04/28/2014 04:09 AM, Bengt Rutisson wrote:
>>
>> Hi Jon,
>>
>> Thanks for looking at this!
>>
>>
>> On 2014-04-25 19:28, Jon Masamitsu wrote:
>>> There are two new flags introduced.
>>>
>>>>   334   develop(bool, G1VerifyBitmaps, 
>>>> false,                                     \
>>>>   335           "Verifies the consistency of the marking 
>>>> bitmaps")                \
>>>> 336 \
>>>>   337   develop(bool, G1VerifyPrevBitmap, 
>>>> false,                                  \
>>>>   338           "Verifies the consistency of the prev marking bitmap")
>>>
>>> When would we want to verify the next bitmap but not the prev bitmap?
>>>
>>> I see that G1VerifyPrevBitmap guards
>>>
>>>> 1515       // Clear the previous marking bitmap, if needed for 
>>>> bitmap verification.
>>>> 1516       // Note we cannot do this when we clear the next marking 
>>>> bitmap in
>>>> 1517       // ConcurrentMark::abort() above since VerifyDuringGC 
>>>> verifies the
>>>> 1518       // objects marked during a full GC against the previous 
>>>> bitmap.
>>>> 1519       // But we need to clear it before calling check_bitmaps 
>>>> below since
>>>> 1520       // the full GC has compacted objects and updated TAMS 
>>>> but not updated
>>>> 1521       // the prev bitmap.
>>>> 1522       if (G1VerifyPrevBitmap) {
>>>> 1523         ((CMBitMap*) 
>>>> concurrent_mark()->prevMarkBitMap())->clearAll();
>>>> 1524       }
>>>
>>> Is it worth the extra flag for that?
>>
>> I think that is the reason, but I doubt that it is worth it. I do 
>> agree that it is questionable if we need two flags and if we do we 
>> should name them differently and make sure that they behave 
>> consistently.
>>
>> Rather than making things more complicated I removed 
>> G1VerifyPrevBitmap and only use G1VerifyBitmaps now.
>
> Sounds good.
>
>>
>>>
>>> How about changing verify_bitmaps() to verify_both_bitmaps()? To 
>>> make it
>>> easier on the eyes to distinguish from verify_bitmap().
>>
>> I renamed verify_bitmap() to verify_no_bits_over_tams() since it 
>> actually does not verify the whole bitmap, just that there are not 
>> bits set over TAMS.
>
> Even better.
>
>>
>> New webrev:
>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.3/
>>
>> Diff compared to last one:
>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.2-3.diff/
>
> Changes look good.
>
> Reviewed.
>
> Jon
>> Thanks,
>> Bengt
>>
>>
>>>
>>> Rest looks good.
>>>
>>> Jon
>>>
>>>
>>> On 4/25/2014 7:30 AM, Bengt Rutisson wrote:
>>>>
>>>> Hi Erik,
>>>>
>>>> Thanks for looking at this!
>>>>
>>>> On 2014-04-25 15:55, Erik Helin wrote:
>>>>> Hi Bengt,
>>>>>
>>>>> On 2014-04-23 10:20, Bengt Rutisson wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Picking up an over 1 year old task...
>>>>>>
>>>>>> Tony created this patch at some point and passed it on to John
>>>>>> Cuthbertson. John sent out a review request and there were some 
>>>>>> comments
>>>>>> (http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/thread.html#7202 
>>>>>>
>>>>>> and
>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/007279.html), 
>>>>>>
>>>>>> but the patch never got finalized or pushed. I thought I'd try to 
>>>>>> get
>>>>>> this pushed now.
>>>>>>
>>>>>> Just like John suggested I would like to do the push as 
>>>>>> contributed-by
>>>>>> Tony unless there are major changes due to comments.
>>>>>>
>>>>>> Here is a new webrev:
>>>>>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.1/
>>>>>
>>>>> I had a look at the patch and noticed:
>>>>>
>>>>>   bool G1CollectedHeap::verify_bitmaps:
>>>>>     ...
>>>>>     if (mark_in_progress() || !_cmThread->in_progress()) {
>>>>>       res_n = verify_bitmap("next", next_bitmap, ntams, end);
>>>>>     }
>>>>>     ...
>>>>>
>>>>> what does the condition mark_in_process() || 
>>>>> !_cmThread->in_progress() mean here?
>>>>>
>>>>> What do you think about adding a comment (or extracting this check 
>>>>> into a method) to make it more obvious why we are doing this check?
>>>>
>>>> Good point!
>>>>
>>>> Updated webrev:
>>>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.2/
>>>>
>>>> And the diff with only the comment added:
>>>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.1-2.diff/
>>>>
>>>> Thanks,
>>>> Bengt
>>>>
>>>>>
>>>>> Thanks,
>>>>> Erik
>>>>>
>>>>>> Here is the diff compared to the one John sent out 15 months ago:
>>>>>> http://cr.openjdk.java.net/~brutisso/7132678/webrev.0-1.diff/
>>>>>>
>>>>>> In the original patch there is a bug in the full GC case. We 
>>>>>> verify the
>>>>>> "prev" bitmap after doing a full GC. But the full GC has compacted
>>>>>> objects and reset tams without updating the prev bitmap. I think 
>>>>>> this is
>>>>>> normally safe since the prev bitmap will be cleared once it 
>>>>>> becomes the
>>>>>> next bitmap later on. However, the new verification code looks at 
>>>>>> stale
>>>>>> data in the prev bitmap. There was already code added to clear 
>>>>>> the prev
>>>>>> bitmap if verification was enabled. I moved that code to just 
>>>>>> before the
>>>>>> verification. It might seem unnecessary to verify a bitmap that 
>>>>>> we just
>>>>>> cleared, but that seemed easier than to propagate the state down 
>>>>>> to the
>>>>>> verification code that it should not verify the prev bitmap for this
>>>>>> particular call.
>>>>>>
>>>>>> There is one more change that I made. I removed one guarantee that I
>>>>>> think was unnecessary.
>>>>>>
>>>>>> Thanks,
>>>>>> Bengt
>>>>>>
>>>>>> On 2013-01-15 21:10, John Cuthbertson wrote:
>>>>>>> Hi Everyone,
>>>>>>>
>>>>>>> Can I have a couple of volunteers review the changes for this 
>>>>>>> CR? The
>>>>>>> webrev can be found at:
>>>>>>> http://cr.openjdk.java.net/~johnc/7132678/webrev.0/
>>>>>>>
>>>>>>> Most of the changes come from a patch that Tony gave me before 
>>>>>>> he left
>>>>>>> and I had to tweak them slightly to remove a spurious failure. The
>>>>>>> changes verify that the heap regions don't have any marks between
>>>>>>> [TAMS, top) at strategic places: start and end of each GC, start 
>>>>>>> and
>>>>>>> end of remark and cleanup, and when allocating a region. Tony 
>>>>>>> deserves
>>>>>>> the bulk of the credit so, if possible and there are no 
>>>>>>> objections, I
>>>>>>> intend to list him as author of the change and include myself as a
>>>>>>> reviewer.
>>>>>>>
>>>>>>> Testing:
>>>>>>> GC test suite with the both the new flags (separately and together)
>>>>>>> and a low IHOP value.
>>>>>>> jprt with the new flags (+IgnoreUnrecognizedVMOptions so that 
>>>>>>> product
>>>>>>> test runs did not fail).
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> JohnC
>>>>>>
>>>>
>>>
>>
>



From jon.masamitsu at oracle.com  Tue Apr 29 21:25:25 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 29 Apr 2014 14:25:25 -0700
Subject: Request for Review (xs) : 8038928 - gc/g1/TestGCLogMessages.java
	fail with "[Evacuation Failure' found"
In-Reply-To: <535F49F7.6060204@oracle.com>
References: <535EC568.7060207@oracle.com> <535F49F7.6060204@oracle.com>
Message-ID: <536018C5.6080203@oracle.com>


On 04/28/2014 11:43 PM, Bengt Rutisson wrote:
>
> Hi Jon,
>
> On 4/28/14 11:17 PM, Jon Masamitsu wrote:
>> The requirement that an evacuation failure not happen during this
>> test is based on the expected behavior of the GC and is not a
>> required behavior.  In some instance the evacuation failure will
>> happen, but it is a not a  GC failure if it does and is only an
>> unexpected path being followed.
>>
>> The test is not reliable but before removing it, I've made
>> some changes to try and save it.  I've modified the
>> test to slow down the allocations and changed the allocation to
>> allocate smaller objects (which also has a side effect of slowing
>> allocations).   The goal is to detect gross breakages of
>> evacuation failure while risking only very, very rare spurious
>> failures.
>>
>> I had reproduced the failure with the unmodified test and it
>> would fail within 30 minutes.  With the modifications, I haven't
>> seen the failure in a day of testing.
>>
>> If the modifications don't work, I'll remove the test.
>>
>> http://cr.openjdk.java.net/~jmasa/8038928/webrev.00/
>>
>> https://bugs.openjdk.java.net/browse/JDK-8038928
>
> Slowing down the test does not seem like a stable solution. Just like 
> you point out.
>
> What do you think about this instead?
>
> The original code does:
>
> // create 128MB of garbage. This should result in at least one GC
> for (int i = 0; i < 1024; i++) {
>   garbage = new byte[128 * 1024];
> }
>
> We run with -Xmx10M but no -Xmn set. We should only ever promote one 
> object each GC, so I assume that what happens when we get an 
> evacuation failure is that we get too many GCs that it fills up the 
> old space.
>
> How about specifying -Xmn and only allocate enough to fill the young 
> gen a few times. Instead of allocating 128MB we could maybe run with 
> -Xmn2M and allocate 8MB worth of objects. That should be enough to get 
> a few GCs but not enough to fill the old gen up. If you want to be 
> really safe you could also increase -Xmx to something like 128M.

The new code for GCTest is

     public static void main(String [] args) {
       System.out.println("Creating garbage");
       // create 128MB of garbage. This should result in at least one GC
       for (int i = 0; i < 1024; i++) {
         work(i);
         for (int k = 0; k < 1024; k++) {
           garbage = new byte[128];
         }
       }
       System.out.println("Done");
     }
   }

This still does as many young GC's but promotes less since object size
is only about 128 bytes.  I think that puts less pressure on the old gen
the way doing fewer GC's as you suggest.  I ran this test (without the
work method) for about half day without any failures and  then I
got an evacuation failure.  I looked at the heap and the old gen was
full.  I thought then that the allocation rate was just too high.  I
tried lowering the initiating occupancy but ran into another bug.
I then added the work() method and it's been running (product and
fastdebug) for a couple of days.

I could reshape the heap as you say and avoid the evacuation
failure but I don't know how much value that is.  Might be the
same as removing the requirement for no evacuation failure.
I settled on this because I thought I was close to an evacuation
failure (if something in the G1 changed like slower mixed collections
or concurrent marking cycle starting way too late, this might
caught it) but not too close (so that it happened very rarely
if it was just happenstance).

My first thought was just to remove the requirement that no
evacuation failure happened, but I vaguely felt it might be worth trying
to save.

Jon

>
> Thanks,
> Bengt
>
>>
>> Thanks.
>>
>> Jon
>

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

From jesper.wilhelmsson at oracle.com  Tue Apr 29 22:28:05 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 30 Apr 2014 00:28:05 +0200
Subject: RFR: 8027643 - Merge GenCollectorPolicy and
	TwoGenerationCollectorPolicy
Message-ID: <53602775.4090400@oracle.com>

Hi,

This is another step in cleaning up the collector policy code. It is the first 
of a few related patches. This change merges the GenCollectorPolicy class with 
TwoGenerationalCollectorPolicy.

I have deliberately refrained from doing any other cleanups that is made 
possible by this change. That will come in later changes. That makes this change 
really easy to review :-)

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

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

Thanks!
/Jesper


From bengt.rutisson at oracle.com  Wed Apr 30 10:50:11 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 30 Apr 2014 12:50:11 +0200
Subject: RFR (XS): JDK-8040977: G1 crashes when run with
	-XX:-G1DeferredRSUpdate
In-Reply-To: <1398171391.3002.24.camel@cirrus>
References: <1398171391.3002.24.camel@cirrus>
Message-ID: <5360D563.1070303@oracle.com>


Hi Thomas,

On 2014-04-22 14:56, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for this change? It fixes wrong order of
> declaration of members of G1ParScanThreadState that causes crashes when
> G1DeferredRSUpdate is disabled.
>
> The change is based on the changes for 8035400 and8035401 posted recently.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8040977
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8040977/webrev/

I realize that this fixes the code but I would really appreciate a more 
stable way of handling the dependencies.

As it it now we end up calling methods on a G1ParScanThreadState 
instance while we are setting it up. This seems broken to me and will 
probably lead to similar initialization order issues again. Best would 
be to not pass "this" to the constructor of G1ParScanClosure and instead 
manage the circular dependency between G1ParScanClosure and 
G1ParScanThreadState more explicitly after they have both been properly 
set up.

Second best would be to at least pass the worker id/queue num as a 
separate parameter to avoid having to call methods on an uninitialized 
object.

Thanks,
Bengt

>
> Testing:
> jprt, new jtreg test case
>
> Thanks,
>    Thomas
>
>
>



From stefan.johansson at oracle.com  Wed Apr 30 11:29:44 2014
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Wed, 30 Apr 2014 13:29:44 +0200
Subject: RFR: 8027643 - Merge GenCollectorPolicy and
	TwoGenerationCollectorPolicy
In-Reply-To: <53602775.4090400@oracle.com>
References: <53602775.4090400@oracle.com>
Message-ID: <5360DEA8.1070608@oracle.com>

Hi Jesper,

The change looks good.

Do the further cleanups you mention include getting rid of the 
_generations array in GenCollectorPolicy and instead having a 
GenerationSpec for young and one for old? If not, I think that is 
something that should be added in upcoming one, since the policy no 
longer supports anything but 2 generations.

Cheers,
Stefan

On 2014-04-30 00:28, Jesper Wilhelmsson wrote:
> Hi,
>
> This is another step in cleaning up the collector policy code. It is 
> the first of a few related patches. This change merges the 
> GenCollectorPolicy class with TwoGenerationalCollectorPolicy.
>
> I have deliberately refrained from doing any other cleanups that is 
> made possible by this change. That will come in later changes. That 
> makes this change really easy to review :-)
>
> Webrev: http://cr.openjdk.java.net/~jwilhelm/8027643/webrev/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8027643
>
> Thanks!
> /Jesper



From bengt.rutisson at oracle.com  Wed Apr 30 11:35:58 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 30 Apr 2014 13:35:58 +0200
Subject: RFR (M): JDK-8035401: Fix visibility of G1ParScanThreadState
	members
In-Reply-To: <5356DFB3.7050400@oracle.com>
References: <1397827791.2717.23.camel@cirrus>
	<5356CC15.7070507@oracle.com>	<1398198974.2532.32.camel@cirrus>
	<5356DFB3.7050400@oracle.com>
Message-ID: <5360E01E.7020906@oracle.com>


Hi Thomas,

Over all this looks good to me too.

One question for g1ParScanThreadState.cpp. You have marked the 
deal_with_refrence() methods as "inline" even though they are in the 
same cpp file. Does that have any effect?

  394
  395 template <class T> inline void 
G1ParScanThreadState::deal_with_reference(T* ref_to_scan) {
  396   if (!has_partial_array_mask(ref_to_scan)) {
  397     // Note: we can use "raw" versions of "region_containing" because
  398     // "obj_to_scan" is definitely in the heap, and is not in a
  399     // humongous region.
  400     HeapRegion* r = _g1h->heap_region_containing_raw(ref_to_scan);
  401     do_oop_evac(ref_to_scan, r);
  402   } else {
  403     do_oop_partial_array((oop*)ref_to_scan);
  404   }
  405 }
  406
  407 inline void G1ParScanThreadState::deal_with_reference(StarTask ref) {
  408   assert(verify_task(ref), "sanity");
  409   if (ref.is_narrow()) {
  410     deal_with_reference((narrowOop*)ref);
  411   } else {
  412     deal_with_reference((oop*)ref);
  413   }
  414 }

Also, I think that you have to declare methods that should be inlined 
before the place where they are being used on some platforms (Solaris). 
In this case I think it means that they should be declared before 
steal_and_trim_queue().

Personally I also find the new deal_with_reference(StarTask ref) a 
little confusing. With that method and the two methods generated by 
deal_with_reference(T* ref_to_scan) I get kind of unsure which method 
that will be executed by a call like:

  156   StarTask stolen_task;
  157   while (task_queues->steal(queue_num(), hash_seed(), stolen_task)) {
  158     assert(verify_task(stolen_task), "sanity");
  159     deal_with_reference(stolen_task);

All three deal_with_reference() methods are potential matches. I assume 
the compiler prefers the deal_with_reference(StarTask ref) but it makes 
me unsure when I read the code.

One minor nit:

g1ParScanThreadState.hpp
You have changed the indentation of private/protected/public keywords to 
have one space indentation. That's fine as I think that is the standard, 
but since the whole file used no space indentation I would also have 
been fine with leaving that. However now the last "public" keyword is 
still having no space before it. Can you indent that too?

218 public:

Thanks,
Bengt


On 2014-04-22 23:31, Jon Masamitsu wrote:
>
> On 4/22/14 1:36 PM, Thomas Schatzl wrote:
>> Hi Jon,
>>
>> On Tue, 2014-04-22 at 13:07 -0700, Jon Masamitsu wrote:
>>> Thomas,
>>>
>>> What I see in these changes are
>>>
>>> 1) no semantic changes
>> No.
>>
>>> 2) some methods in .hpp files moved to .cpp files
>> Yes, because they were only referenced by the cpp file, so I thought it
>> would be good to move them there. They will be inlined as needed anyway
>> (and I think for some of them they were never inlined due to their
>> size).
>>
>> I will do some more runs with the inline's added again.
>>
>>> 3) creation of steal_and_trim_queue() with definition in
>>> a .cpp file (I may have missed additional such new
>>> methods)
>> There are none except queue_is_empty(), see below.
>>
>>> 4) change in visibility as the CR says
>> That's the main change.
>>
>>> 5) no performance regressions as stated in your RFR
>> No. Checked the results for the usual benchmarks (specjvm2008,
>> specjbb05/2013) again right now, and there are no significant
>> differences in the scores (on x64 and sparc), and for specjbb05/2013 the
>> average gc pause time, and the object copy time (assuming that this is
>> the part that will be affected most) stay the same as in the baseline.
>>
>>> If that's what constitutes the change, looks good.
>> Thanks.
>>
>>> Reviewed.
>>>
>>> If there is something more significant that I have
>>> overlooked, please point me at it and I'll look again.
>> There is not. Sorry, I should have pointed out the changes in more
>> detail instead of you making guesses.
>>
>> Additional minor changes:
>>
>> - G1ParScanThreadState accesses members directly instead of using
>> getters (e.g. _refs instead of refs()).
>>
>> - fixed some newlines in method declarations, removing newlines
>>
>> - removed refs() to avoid direct access from outside, and adding a new
>> method queue_is_empty() (only used in asserts as refs()->is_empty(), and
>> I did not want to expose refs() just for the asserts).
>
> All looks good.
>
> Reviewed.
>
> Jon
>
>>
>> Thanks,
>>    Thomas
>>
>>> On 4/18/14 6:29 AM, Thomas Schatzl wrote:
>>>> Hi all,
>>>>
>>>>     can I have reviews for this change? After moving 
>>>> G1ParScanThreadState,
>>>> this change cleans up visibility, making a whole lot of stuff private.
>>>>
>>>> CR:
>>>> https://bugs.openjdk.java.net/browse/JDK-8035401
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~tschatzl/8035401/webrev/
>>>>
>>>> Testing:
>>>> perf testing indicated no changes, jprt
>>>>
>>>> Thanks,
>>>>     Thomas
>>>>
>>>>
>>
>



From andreas.eriksson at oracle.com  Wed Apr 30 12:14:25 2014
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Wed, 30 Apr 2014 14:14:25 +0200
Subject: RFR: 8038925: Java 7 with G1 crashes in dump_instance_fields
	using jmap or jcmd without fullgc
In-Reply-To: <535A69AC.6070702@oracle.com>
References: <535A524D.1000701@oracle.com> <1398430409.14355.72.camel@cirrus>
	<2609553.USauZpmh17@mgerdin03> <535A6169.6030609@oracle.com>
	<535A69AC.6070702@oracle.com>
Message-ID: <5360E921.5040507@oracle.com>

Thomas showed that this reproduces on jdk9 as well, so I'm re-targeting 
(and maybe reworking) the fix.
Right now it looks like changes related to permgen removal makes it only 
reproduce on debug builds for jdk9 though.
More info can be found in the jira bug.

Regards,
Andreas

On 2014-04-25 15:57, Andreas Eriksson wrote:
> I saw no obvious reason why it doesn't reproduce on jdk8 or jdk9.
> Maybe someone with better knowledge of G1 can say.
> Could it have something to do with the metaspace rewrites?
>
> /Andreas
>
> On 2014-04-25 15:21, Andreas Eriksson wrote:
>> In addition, this particular test doesn't reproduce on jdk8 or jdk9 
>> for some reason.
>> I will take a quick look and see if I can spot why.
>>
>> /Andreas
>>
>> On 2014-04-25 15:14, Mikael Gerdin wrote:
>>> On Friday 25 April 2014 14.53.29 Thomas Schatzl wrote:
>>>> Hi,
>>>>
>>>> On Fri, 2014-04-25 at 14:17 +0200, Andreas Eriksson wrote:
>>>>> Hi,
>>>>>
>>>>> Could I have a review for this G1 jdk7 only fix please?
>>>>    why is this change only necessary for jdk7?
>>> The idea was that for 9 and 8u40+ we will need a separate way to 
>>> handle this
>>> anyway due to class unloading (as previously discussed).
>>>
>>> We may or may not want to get this fix into 8u20, I'd like to hear 
>>> your input
>>> on that Thomas.
>>>
>>> /Mikael
>>>
>>>>> Description:
>>>>> When using G1 and doing a heap dump while no fullgc has been done,
>>>>> hotspot crashes.
>>>>> This is because G1CollectedHeap::safe_object_iterate uses
>>>>> ContiguousSpace::object_iterate_from, which does not avoid dead 
>>>>> objects
>>>>> that can still be on the heap when using G1.
>>>>>
>>>>> The fix adds a G1 specific safe_object_iterate code path that avoids
>>>>> dead objects.
>>>>>
>>>>> http://cr.openjdk.java.net/~aeriksso/8038925/webrev.00/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8038925
>>>>>
>>>>> Thanks to Mikael Gerdin for his help with this.
>>>> Thanks,
>>>> Thomas
>>
>



From per.liden at oracle.com  Wed Apr 30 13:04:11 2014
From: per.liden at oracle.com (Per Liden)
Date: Wed, 30 Apr 2014 15:04:11 +0200
Subject: RFR(S): 8040803: G1: Concurrent mark hangs when mark stack overflows
Message-ID: <5360F4CB.9040106@oracle.com>

Hi,

Could I please have a couple of reviews in this bug fix:

Summary: G1's concurrent marking can potentially hang forever if the 
global mark stack overflows and immediately after that a Full GC 
happens, which tries to abort the marking. The reason is that there's a 
race between detecting the overflow situation and detecting the abort 
signal. Threads detecting the overflow situation first will go into the 
overflow protocol and wait on a barrier for all threads to reach this 
state. However, threads detecting the abort signal first will terminate 
and never participate in the barrier.

This patch introduces an abort state and function on the 
WorkGangBarrierSync class, to unblock any threads waiting for the 
barrier to complete when the concurrent mark is aborted.

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

/Per


From per.liden at oracle.com  Wed Apr 30 13:13:08 2014
From: per.liden at oracle.com (Per Liden)
Date: Wed, 30 Apr 2014 15:13:08 +0200
Subject: RFR(XS): G1: Concurrent mark stuck in loop calling os::elapsedVTime()
Message-ID: <5360F6E4.6040801@oracle.com>

Hi,

Here's another G1 concurrent mark fix I'd like to have reviewed.

Summary: If the heap is expended when a concurrent mark is in progress 
there's a window where the global marking finger (_cm->_finger) points 
past the heap end (_cm->_heap_end). When this happens the marking 
threads will get stuck in a loop spinning, because _cm->out_of_regions() 
will still return false. out_of_regions() is currently implemented as 
"return _finger == _heap_end;".

This patch fixes this problem by adjusting out_of_region() to instead be 
"return _finger >= _heap_end;". This is safe because objects in those 
new regions will be considered live anyway, because their TAMS will be 
equal to bottom.

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

/Per


From bengt.rutisson at oracle.com  Wed Apr 30 14:12:58 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 30 Apr 2014 16:12:58 +0200
Subject: RFR(XS): G1: Concurrent mark stuck in loop calling
	os::elapsedVTime()
In-Reply-To: <5360F6E4.6040801@oracle.com>
References: <5360F6E4.6040801@oracle.com>
Message-ID: <536104EA.2090103@oracle.com>


Hi Per,

On 2014-04-30 15:13, Per Liden wrote:
> Hi,
>
> Here's another G1 concurrent mark fix I'd like to have reviewed.
>
> Summary: If the heap is expended when a concurrent mark is in progress 
> there's a window where the global marking finger (_cm->_finger) points 
> past the heap end (_cm->_heap_end). When this happens the marking 
> threads will get stuck in a loop spinning, because 
> _cm->out_of_regions() will still return false. out_of_regions() is 
> currently implemented as "return _finger == _heap_end;".
>
> This patch fixes this problem by adjusting out_of_region() to instead 
> be "return _finger >= _heap_end;". This is safe because objects in 
> those new regions will be considered live anyway, because their TAMS 
> will be equal to bottom.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8040804
> Webrev: http://cr.openjdk.java.net/~pliden/8040804/webrev.0/

Looks good!

Bengt

>
> /Per



From thomas.schatzl at oracle.com  Wed Apr 30 16:09:51 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 30 Apr 2014 18:09:51 +0200
Subject: RFR(XS): G1: Concurrent mark stuck in loop calling
	os::elapsedVTime()
In-Reply-To: <5360F6E4.6040801@oracle.com>
References: <5360F6E4.6040801@oracle.com>
Message-ID: <1398874191.2766.0.camel@cirrus>

Hi,

On Wed, 2014-04-30 at 15:13 +0200, Per Liden wrote:
> Hi,
> 
> Here's another G1 concurrent mark fix I'd like to have reviewed.
> 
> Summary: If the heap is expended when a concurrent mark is in progress 
> there's a window where the global marking finger (_cm->_finger) points 
> past the heap end (_cm->_heap_end). When this happens the marking 
> threads will get stuck in a loop spinning, because _cm->out_of_regions() 
> will still return false. out_of_regions() is currently implemented as 
> "return _finger == _heap_end;".
> 
> This patch fixes this problem by adjusting out_of_region() to instead be 
> "return _finger >= _heap_end;". This is safe because objects in those 
> new regions will be considered live anyway, because their TAMS will be 
> equal to bottom.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8040804
> Webrev: http://cr.openjdk.java.net/~pliden/8040804/webrev.0/
> 

  Looks good.

Thomas




From jon.masamitsu at oracle.com  Wed Apr 30 17:52:08 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 30 Apr 2014 10:52:08 -0700
Subject: RFR(S): 8040803: G1: Concurrent mark hangs when mark stack
	overflows
In-Reply-To: <5360F4CB.9040106@oracle.com>
References: <5360F4CB.9040106@oracle.com>
Message-ID: <53613848.2000409@oracle.com>

Per,

Adding a new flag sometimes is like adding a new degree
of freedom and sometimes can make a complicated situation
more complicated.

Before I review this can you help  me understand the
problem.   Is the window for the race condition this
code in do_marking_step()?

   4108    if (_cm->has_overflown()) {
   4109      // This can happen if the mark stack overflows during a GC 
pause
   4110      // and this task, after a yield point, restarts. We have to 
abort
   4111      // as we need to get into the overflow protocol which happens
   4112      // right at the end of this task.
   4113      set_has_aborted();
   4114    }

The window being between the time _has_overflown is set and when
_has_aborted is set?

Jon

On 4/30/2014 6:04 AM, Per Liden wrote:
> Hi,
>
> Could I please have a couple of reviews in this bug fix:
>
> Summary: G1's concurrent marking can potentially hang forever if the 
> global mark stack overflows and immediately after that a Full GC 
> happens, which tries to abort the marking. The reason is that there's 
> a race between detecting the overflow situation and detecting the 
> abort signal. Threads detecting the overflow situation first will go 
> into the overflow protocol and wait on a barrier for all threads to 
> reach this state. However, threads detecting the abort signal first 
> will terminate and never participate in the barrier.
>
> This patch introduces an abort state and function on the 
> WorkGangBarrierSync class, to unblock any threads waiting for the 
> barrier to complete when the concurrent mark is aborted.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8040803
> Webrev: http://cr.openjdk.java.net/~pliden/8040803/webrev.0/
>
> /Per



From jon.masamitsu at oracle.com  Wed Apr 30 23:29:18 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 30 Apr 2014 16:29:18 -0700
Subject: RFR(XS): G1: Concurrent mark stuck in loop calling
	os::elapsedVTime()
In-Reply-To: <5360F6E4.6040801@oracle.com>
References: <5360F6E4.6040801@oracle.com>
Message-ID: <5361874E.1080504@oracle.com>

Per,

Are you saying that when the heap expands, "_heap_end" might not be 
updated but
"_finger" will be updated for an allocation in the newly expanded part 
of the heap?

Jon

On 4/30/2014 6:13 AM, Per Liden wrote:
> Hi,
>
> Here's another G1 concurrent mark fix I'd like to have reviewed.
>
> Summary: If the heap is expended when a concurrent mark is in progress 
> there's a window where the global marking finger (_cm->_finger) points 
> past the heap end (_cm->_heap_end). When this happens the marking 
> threads will get stuck in a loop spinning, because 
> _cm->out_of_regions() will still return false. out_of_regions() is 
> currently implemented as "return _finger == _heap_end;".
>
> This patch fixes this problem by adjusting out_of_region() to instead 
> be "return _finger >= _heap_end;". This is safe because objects in 
> those new regions will be considered live anyway, because their TAMS 
> will be equal to bottom.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8040804
> Webrev: http://cr.openjdk.java.net/~pliden/8040804/webrev.0/
>
> /Per