From david.holmes at oracle.com Mon Mar 2 01:28:29 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 02 Mar 2015 11:28:29 +1000 Subject: nmethodBucket in instanceKlass.hpp atomic counters In-Reply-To: <54F122F3.60700@oracle.com> References: <54F122F3.60700@oracle.com> Message-ID: <54F3BCBD.1030006@oracle.com> Hi Staffan, cc'ing gc group as ... On 28/02/2015 12:07 PM, Staffan Friberg wrote: > Hi, > > Was reading through the code for the nmethodBucket in instanceKlass.hpp > and noticed that when we increase the number we simply do a +1, while > when we remove the dependency we do a using an atomic. > > Do we have synchronization else where for the increment and decrement, > and we simply use the atomic in the decrement to ensure visibility to > non-compiler threads (GC)? ... the atomic decrement was added as part of the G1 class unloading code: https://bugs.openjdk.java.net/browse/JDK-804942 The increment is only performed at a safepoint or under the CodeCache_lock. However unless there is something else that guarantees increments and decrements can not be occurring around the same time, then the use of the atomic decrement is not sufficient for thread-safety. David > //Staffan From david.holmes at oracle.com Mon Mar 2 01:46:51 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 02 Mar 2015 11:46:51 +1000 Subject: nmethodBucket in instanceKlass.hpp atomic counters In-Reply-To: <54F3BCBD.1030006@oracle.com> References: <54F122F3.60700@oracle.com> <54F3BCBD.1030006@oracle.com> Message-ID: <54F3C10B.30707@oracle.com> Please ignore - #$#@ autocomplete jumped to the wrong GC address. David On 2/03/2015 11:28 AM, David Holmes wrote: > Hi Staffan, > > cc'ing gc group as ... > > On 28/02/2015 12:07 PM, Staffan Friberg wrote: >> Hi, >> >> Was reading through the code for the nmethodBucket in instanceKlass.hpp >> and noticed that when we increase the number we simply do a +1, while >> when we remove the dependency we do a using an atomic. >> >> Do we have synchronization else where for the increment and decrement, >> and we simply use the atomic in the decrement to ensure visibility to >> non-compiler threads (GC)? > > ... the atomic decrement was added as part of the G1 class unloading > code: > > https://bugs.openjdk.java.net/browse/JDK-804942 > > The increment is only performed at a safepoint or under the > CodeCache_lock. However unless there is something else that guarantees > increments and decrements can not be occurring around the same time, > then the use of the atomic decrement is not sufficient for thread-safety. > > David > >> //Staffan From bengt.rutisson at oracle.com Mon Mar 2 08:23:33 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 02 Mar 2015 09:23:33 +0100 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> References: <54F08F8A.7070901@oracle.com> <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> Message-ID: <54F41E05.2090905@oracle.com> Hi Kim, Thanks for looking at this! On 2015-02-28 00:43, Kim Barrett wrote: > On Feb 27, 2015, at 10:38 AM, Bengt Rutisson wrote: >> Can I have a couple of reviews for this cleanup change? >> >> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8074037 >> >> [?] >> The patch also introduces a new class called G1GCPhaseTimesTracker, which is a scoped object to simplify time measurements. I've also tried to move conversion of times down to when we print the log messages instead of when we store them. This removes several "* 1000.0" in the code. Eventually I would like to replace os::elapsedTime() with os::elapsed_counter(). But that should be done as a separate patch. > Before I proceed any further with this review, I feel like I'm getting > lost in unit changes. In some places values of msecs used to be used > but now we're using secs, right? But it seems like there might be some > confusion about that, and I'm not sure whether it's me or the code > that's confused. > > For example: > > src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp > 1079 cost_per_card_ms = phase_times()->average_time(G1GCPhaseTimes::UpdateRS) / (double) _pending_cards; > 1080 _cost_per_card_ms_seq->add(cost_per_card_ms); > > I think the values that have been recorded in the phase_times are > secs, and average_time appears to just use the values as is. So > shouldn't that now be cost_per_card_secs? And the value added to > _cost_per_card_ms_seq needs to be cost_per_card_secs * 1000.0? Right! Good catch! I was so happy to get rid of some of the "* 1000.0" statements sprinkled all over the G1 code that I forgot to add some of them back ;) I'll send out an updated webrev soon. Bengt > > Oh how I wish for a units package! > From thomas.schatzl at oracle.com Mon Mar 2 12:11:04 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 02 Mar 2015 13:11:04 +0100 Subject: RFR (S): 8073466: Remove buffer retaining functionality and clean up in ParGCAllocBuffer In-Reply-To: <54F10B2D.90701@oracle.com> References: <1424443224.3267.6.camel@oracle.com> <1425038318.3288.53.camel@oracle.com> <54F10B2D.90701@oracle.com> Message-ID: <1425298264.3357.42.camel@oracle.com> Hi Jon, thanks for the review :) On Fri, 2015-02-27 at 16:26 -0800, Jon Masamitsu wrote: > Thomas, > > http://cr.openjdk.java.net/~tschatzl/8073466/webrev.1/src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp.frames.html > > Could you add a comment here that the stats are being "flushed". > Something like > > // Flush the statistics. > > 67 stats->add_allocated(_allocated); > > 68 // Retire() counts the unused space as wasted. So we need to remove it again > > 69 // before updating the statistics. > > 70 stats->add_wasted(_wasted - unused); Done. > In a context where the unused space at the end of a buffer might be used > later (as when there was the "retaining functionality"), I can see that > you might want to differentiate between _wasted and unused. Since there > is no longer a "retain", it seems all to be just waste. So > I don't see the use of passing "_wasted - unused" as opposed to just > "_wasted". There is still use of "_unused" in the calculation of the desired PLAB size. I tried to avoid changing the current PLAB sizing in this change, and later for G1 I plan to override the desired_plab_size() method. [This is needed in any case because of improved statistics for G1, where we want to distinguish between waste within the PLABs and waste caused by refill due to the current PLAB not fitting into the current region.] The existing PLAB sizing calculates the amount of "target_refills" using the _unused member. I admit I do not really understand that calculation, and the results seem bogus in particular in presence of multiple threads each having its own PLAB and considering the integer truncation in the formula. I can create a CR to remove _unused and fix the CMS PLAB sizing. > If you would like to keep the differentiation between "_wasted - used" > and "_wasted", consider adding back the "end_of_gc" flag to > retire() and moving > > > 127 _wasted += pointer_delta(_end, _top); // unused space > > out of invalidate() and into retire() in this fashion > > if (!end_of_gc) { > _wasted += pointer_delta(_end, _top); // unused space > } Done. I did not use an additional parameter to retire, as we already have two retiring methods (retire and flush_stats_and_retire) to be called at different times during GC anyway. Also, please ignore that G1 at the moment calls flush_stats_and_retire() every time it allocates a G1ParScanThreadState. This is basically JDK-8040162. I will ask for a review of that soon. > Throwaway suggestion (your call, since not in your change) > > Fix the indentation on the fields > > > 39 char head[32]; > > 40 size_t _word_sz; // In HeapWord units > > > 48 char tail[32]; Fixed. http://cr.openjdk.java.net/~tschatzl/8073466/webrev.1_to_2/ (incremental) http://cr.openjdk.java.net/~tschatzl/8073466/webrev.2/ (full) (The change also moves invalidate() to the protected section of ParGCAllocBuffer). Thanks, Thomas From thomas.schatzl at oracle.com Mon Mar 2 14:05:13 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 02 Mar 2015 15:05:13 +0100 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> References: <54F08F8A.7070901@oracle.com> <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> Message-ID: <1425305113.3357.69.camel@oracle.com> Hi, On Fri, 2015-02-27 at 18:43 -0500, Kim Barrett wrote: > On Feb 27, 2015, at 10:38 AM, Bengt Rutisson wrote: > > > > Can I have a couple of reviews for this cleanup change? > > > > http://cr.openjdk.java.net/~brutisso/8074037/webrev.00/ > > https://bugs.openjdk.java.net/browse/JDK-8074037 > > > > [?] > > The patch also introduces a new class called G1GCPhaseTimesTracker, which is > >a scoped object to simplify time measurements. I've also tried to move >>conversion of times down to when we print the log messages instead of >>when we store them. This removes several "* 1000.0" in the code. >>Eventually I would like to replace os::elapsedTime() with >>os::elapsed_counter(). But that should be done as a separate patch. > > Before I proceed any further with this review, I feel like I'm getting > lost in unit changes. In some places values of msecs used to be used > but now we're using secs, right? But it seems like there might be some > confusion about that, and I'm not sure whether it's me or the code > that's confused. Given the confusion one option is to do the change above before that, or in this change. At least the change of type from double to jlong in the passed parameters should cause compiler warnings which are automatically translated to errors. Some more comments about the change: - g1CollectedHeap.cpp:4659: if (mark_in_progress() && ! _process_strong_tasks->is_task_claimed(G1H_PS_filter....) { G1GCPhaseTimesTracker x(timer, G1GCPhaseTimes::SATB_Filtering, worker_i); } else { set_satb_filtering_time_to_zero() } I think g1_process_roots() must always claim all tasks, even if the task itself does nothing. I suggest something like this instead: { G1GCPhaseTimesTracker x(timer, G1GCPhaseTimes::SATB_Filtering, worker_i); if (!_process_strong_tasks->is_task_claimed() && mark_in_progress()) { // optionally keep the extra if-clause } } - the mentioned unit issues with ms and s in g1CollectorPolicy.cpp:1079, 1087, 1129, 1138, 1139, 1180, 1181, 2123-2128, 2130-2135 - in G1GCPhaseTimes::note_gc_start() there is some difference in how the optional gc phases are enabled. I.e. for marking, the change passes a new parameter, for the string deduplication the code uses some global variables. Mark_in_progress could as well be determined by getting the global g1collectorpolicy instance and querying it. That's just a note, it seems somewhat ugly to me. - g1GCphasetimes.cpp, line 269, instead of using the Sentinel directly the change could use the ARRAY_SIZE macro on _gc_phases. - The template methods WorkerDataArray::uninitialized() are declared NOT_PRODUCT, but there is no guard for them in the cpp file. - ms/s mismatch in g1StringDedup.cpp:162 Thanks, Thomas From mikael.gerdin at oracle.com Mon Mar 2 14:17:37 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 02 Mar 2015 15:17:37 +0100 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: <1425305113.3357.69.camel@oracle.com> References: <54F08F8A.7070901@oracle.com> <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> <1425305113.3357.69.camel@oracle.com> Message-ID: <54F47101.8010906@oracle.com> On 2015-03-02 15:05, Thomas Schatzl wrote: > Hi, > > On Fri, 2015-02-27 at 18:43 -0500, Kim Barrett wrote: >> On Feb 27, 2015, at 10:38 AM, Bengt Rutisson wrote: >>> >>> Can I have a couple of reviews for this cleanup change? >>> >>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8074037 >>> >>> [?] >>> The patch also introduces a new class called G1GCPhaseTimesTracker, which is >>> a scoped object to simplify time measurements. I've also tried to move >>> conversion of times down to when we print the log messages instead of >>> when we store them. This removes several "* 1000.0" in the code. >>> Eventually I would like to replace os::elapsedTime() with >>> os::elapsed_counter(). But that should be done as a separate patch. >> >> Before I proceed any further with this review, I feel like I'm getting >> lost in unit changes. In some places values of msecs used to be used >> but now we're using secs, right? But it seems like there might be some >> confusion about that, and I'm not sure whether it's me or the code >> that's confused. > > Given the confusion one option is to do the change above before that, or > in this change. At least the change of type from double to jlong in the > passed parameters should cause compiler warnings which are automatically > translated to errors. > > Some more comments about the change: > > - g1CollectedHeap.cpp:4659: > > if (mark_in_progress() && ! > _process_strong_tasks->is_task_claimed(G1H_PS_filter....) { > G1GCPhaseTimesTracker x(timer, G1GCPhaseTimes::SATB_Filtering, > worker_i); > } else { > set_satb_filtering_time_to_zero() > } > > I think g1_process_roots() must always claim all tasks, even if the task > itself does nothing. I'm pretty sure that is incorrect. There is a comment before all_tasks_completed which hints at some verification that all tasks have been claimed but I have never found any code which performs this verification. /Mikael > > I suggest something like this instead: > > { > G1GCPhaseTimesTracker x(timer, G1GCPhaseTimes::SATB_Filtering, > worker_i); > if (!_process_strong_tasks->is_task_claimed() && > mark_in_progress()) { // optionally keep the extra if-clause > } > } > > - the mentioned unit issues with ms and s in g1CollectorPolicy.cpp:1079, > 1087, 1129, 1138, 1139, 1180, 1181, 2123-2128, 2130-2135 > > - in G1GCPhaseTimes::note_gc_start() there is some difference in how the > optional gc phases are enabled. I.e. for marking, the change passes a > new parameter, for the string deduplication the code uses some global > variables. Mark_in_progress could as well be determined by getting the > global g1collectorpolicy instance and querying it. > That's just a note, it seems somewhat ugly to me. > > - g1GCphasetimes.cpp, line 269, instead of using the Sentinel directly > the change could use the ARRAY_SIZE macro on _gc_phases. > > - The template methods WorkerDataArray::uninitialized() are > declared NOT_PRODUCT, but there is no guard for them in the cpp file. > > - ms/s mismatch in g1StringDedup.cpp:162 > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Mon Mar 2 14:52:09 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 02 Mar 2015 15:52:09 +0100 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: <54F47101.8010906@oracle.com> References: <54F08F8A.7070901@oracle.com> <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> <1425305113.3357.69.camel@oracle.com> <54F47101.8010906@oracle.com> Message-ID: <1425307929.3357.84.camel@oracle.com> Hi Mikael, On Mon, 2015-03-02 at 15:17 +0100, Mikael Gerdin wrote: > > On 2015-03-02 15:05, Thomas Schatzl wrote: > > Hi, > > > > On Fri, 2015-02-27 at 18:43 -0500, Kim Barrett wrote: > >> On Feb 27, 2015, at 10:38 AM, Bengt Rutisson wrote: > >>> > >>> Can I have a couple of reviews for this cleanup change? > >>> > >>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00/ > >>> https://bugs.openjdk.java.net/browse/JDK-8074037 > >>> [...] > > > > I think g1_process_roots() must always claim all tasks, even if the task > > itself does nothing. > > I'm pretty sure that is incorrect. There is a comment before > all_tasks_completed which hints at some verification that all tasks have > been claimed but I have never found any code which performs this > verification. Okay, I just went by the comment. Imo it would be nice to actually have such a verification. I added an RFE. Thanks, Thomas From thomas.schatzl at oracle.com Mon Mar 2 14:57:33 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 02 Mar 2015 15:57:33 +0100 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <54EF5E2D.5020503@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> <54E4848A.2010203@oracle.com> <54EDFD38.6010002@oracle.com> <54EF5E2D.5020503@oracle.com> Message-ID: <1425308253.3357.90.camel@oracle.com> Hi Andrey, On Thu, 2015-02-26 at 20:55 +0300, Andrey Zakharov wrote: > Updated test with > - updated 2 spaces for c++ code and code style > - updated copyrights > - renamed variable hotCardTableSize > - added output for current page size > > webrev: > http://cr.openjdk.java.net/~azakharov/8061715/webrev.05/ - in HeapRegionManager::get_auxiliary_data_memory_usage(), please avoid declaring and initializing using multiple variables in a single statement, particularly if these statements span multiple lines. While coding guidelines do not explicitly prohibit this, it is easier to read if you repeat the type of the variable. Also, it would be easier to read, if there were an additional line between the return statement and the declaration of committed_sz. The existing code also spells out "sz". - the method bodies in the G1 code use an indentation of four spaces. Hotspot code uses two space. - not sure about this, but the changed tests do not add 8061715 to their @bug tag. It will be impossible to test particularly 8061715 then without finding the original bug number. - the webrev is missing the changes to the WhiteBox.java file at /test/lib/sun/hotspot/WhiteBox.java. Please generate an extra webrev for that repo. > testing: yes (sthjprt 2015-02-26-172927.gtee.auxdata - I will restart > solaris on complete) > > Thanks. > > >>> > >>> - in TestShrinkAuxiliaryData.java, line 107 seems to be debugging code. > >>> Afaik jtreg already automatically puts all output into the log files. > This is why this code here: OutputAnalyzer with ProcessBuilder doesn't > implicitly output anything. Many other tests do not either (can be easily added for debugging), but if so, I recommend putting the System.out.println() statement before the output.shouldHaveExitValue(0); line. Otherwise the test will exit before printing the messages if there is some VM error. > >>> - line 174, I do not understand the comment. What does "if auxdata size > >>> will be more than page size it would not decommit auxiliary data > >>> size is > >>> about ~3.6% of heap size" seem to be at least two sentences. > Fixed > >>> > >>> - what do the two reasons given in the comment of > >>> checkEnvApplicability() actually mean? I.e. why do you not run the test > >>> if large pages are enabled? > I dont want to run this test on box where page size is larger than > auxiliary data size for region, where decommitment wouldn't occurs for sure. Okay. But then the comment is wrong: it states "if auxdata size will be more than page size it would not decommit" which is the reverse of what you said above. I also think the comparison below should be a ">=" and not only ">" then. The skip message could be improved to mention "Skipping test because the auxiliary data is smaller than page size %d" to make the reason more clear. Thanks, Thomas From thomas.schatzl at oracle.com Mon Mar 2 16:07:20 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 02 Mar 2015 17:07:20 +0100 Subject: [8u-hs-dev] Backport RFR: 7176220: 'Full GC' events miss date stamp information occasionally In-Reply-To: <54EF0F56.3040202@oracle.com> References: <547C5ED8.5010908@oracle.com> <5485A5D6.1080209@oracle.com> <5485A692.2080908@oracle.com> <5485E418.2030808@oracle.com> <5485E753.6090900@oracle.com> <5485E89F.9080306@oracle.com> <54EF0F56.3040202@oracle.com> Message-ID: <1425312440.3357.99.camel@oracle.com> Hi Andreas, On Thu, 2015-02-26 at 13:19 +0100, Andreas Eriksson wrote: > Hi, trying this RFR again, since 8u40 rampdown is done now. > > The bug is JDK-7176220. > The jdk9 changeset still applies cleanly. Looks good. Thomas From bengt.rutisson at oracle.com Mon Mar 2 16:15:00 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 02 Mar 2015 17:15:00 +0100 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: <54F41E05.2090905@oracle.com> References: <54F08F8A.7070901@oracle.com> <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> <54F41E05.2090905@oracle.com> Message-ID: <54F48C84.3060602@oracle.com> Hi again, Here is an updated webrev: http://cr.openjdk.java.net/~brutisso/8074037/webrev.01/ And here's the diff compared to the last webrev: http://cr.openjdk.java.net/~brutisso/8074037/webrev.00-01.diff/ I tried to clean up the seconds vs. milliseconds confusion by making it G1GCPhaseTimes' responsibility to handle the conversion in all cases. So, the interface is now that times are reported in seconds (for example G1GCPhaseTimes::record_time_secs()) but returned in milliseconds (for example G1GCPhaseTimes::average_time_ms()). I suffixed the method names "_secs" and "_ms" to make it easier to follow the code. I'm not very happy about this inconsistency, but I want it to be an intermediate step on the way to getting rid of os::elapsedTime() completely. StefanK also suggested to move the logging code out to its own class. This simplified the logging quite a bit I think. The class, G1GCPhasePrinter, has to know a lot about both G1GCPhaseTimes and WorkerDataArray, but I still think it is nice to have the logging separated out. I didn't read Thomas' email with comments until after I had prepared this updated webrev. But I think I have addressed the issues brought up there. Thanks for looking at this, Thomas! Bengt On 2015-03-02 09:23, Bengt Rutisson wrote: > > Hi Kim, > > Thanks for looking at this! > > On 2015-02-28 00:43, Kim Barrett wrote: >> On Feb 27, 2015, at 10:38 AM, Bengt Rutisson >> wrote: >>> Can I have a couple of reviews for this cleanup change? >>> >>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8074037 >>> >>> [?] >>> The patch also introduces a new class called G1GCPhaseTimesTracker, >>> which is a scoped object to simplify time measurements. I've also >>> tried to move conversion of times down to when we print the log >>> messages instead of when we store them. This removes several "* >>> 1000.0" in the code. Eventually I would like to replace >>> os::elapsedTime() with os::elapsed_counter(). But that should be >>> done as a separate patch. >> Before I proceed any further with this review, I feel like I'm getting >> lost in unit changes. In some places values of msecs used to be used >> but now we're using secs, right? But it seems like there might be some >> confusion about that, and I'm not sure whether it's me or the code >> that's confused. >> >> For example: >> >> src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp >> 1079 cost_per_card_ms = >> phase_times()->average_time(G1GCPhaseTimes::UpdateRS) / (double) >> _pending_cards; >> 1080 _cost_per_card_ms_seq->add(cost_per_card_ms); >> >> I think the values that have been recorded in the phase_times are >> secs, and average_time appears to just use the values as is. So >> shouldn't that now be cost_per_card_secs? And the value added to >> _cost_per_card_ms_seq needs to be cost_per_card_secs * 1000.0? > > Right! Good catch! I was so happy to get rid of some of the "* 1000.0" > statements sprinkled all over the G1 code that I forgot to add some of > them back ;) > > I'll send out an updated webrev soon. > > Bengt > >> >> Oh how I wish for a units package! >> > From andreas.eriksson at oracle.com Mon Mar 2 16:33:02 2015 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Mon, 02 Mar 2015 17:33:02 +0100 Subject: [8u-hs-dev] Backport RFR: 7176220: 'Full GC' events miss date stamp information occasionally In-Reply-To: <1425312440.3357.99.camel@oracle.com> References: <547C5ED8.5010908@oracle.com> <5485A5D6.1080209@oracle.com> <5485A692.2080908@oracle.com> <5485E418.2030808@oracle.com> <5485E753.6090900@oracle.com> <5485E89F.9080306@oracle.com> <54EF0F56.3040202@oracle.com> <1425312440.3357.99.camel@oracle.com> Message-ID: <54F490BE.5030008@oracle.com> Thanks Thomas. - Andreas On 2015-03-02 17:07, Thomas Schatzl wrote: > Hi Andreas, > > On Thu, 2015-02-26 at 13:19 +0100, Andreas Eriksson wrote: >> Hi, trying this RFR again, since 8u40 rampdown is done now. >> >> The bug is JDK-7176220. >> The jdk9 changeset still applies cleanly. > Looks good. > > Thomas > > From jon.masamitsu at oracle.com Mon Mar 2 17:47:11 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 02 Mar 2015 09:47:11 -0800 Subject: RFR (S): 8073466: Remove buffer retaining functionality and clean up in ParGCAllocBuffer In-Reply-To: <1425298264.3357.42.camel@oracle.com> References: <1424443224.3267.6.camel@oracle.com> <1425038318.3288.53.camel@oracle.com> <54F10B2D.90701@oracle.com> <1425298264.3357.42.camel@oracle.com> Message-ID: <54F4A21F.9080805@oracle.com> Thomas, Looks good. Reviewed. Some comments below but nothing important. Jon On 03/02/2015 04:11 AM, Thomas Schatzl wrote: > Hi Jon, > > thanks for the review :) > > On Fri, 2015-02-27 at 16:26 -0800, Jon Masamitsu wrote: >> Thomas, >> >> http://cr.openjdk.java.net/~tschatzl/8073466/webrev.1/src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp.frames.html >> >> Could you add a comment here that the stats are being "flushed". >> Something like >> >> // Flush the statistics. >>> 67 stats->add_allocated(_allocated); >>> 68 // Retire() counts the unused space as wasted. So we need to remove it again >>> 69 // before updating the statistics. >>> 70 stats->add_wasted(_wasted - unused); > Done. Thanks. > >> In a context where the unused space at the end of a buffer might be used >> later (as when there was the "retaining functionality"), I can see that >> you might want to differentiate between _wasted and unused. Since there >> is no longer a "retain", it seems all to be just waste. So >> I don't see the use of passing "_wasted - unused" as opposed to just >> "_wasted". > There is still use of "_unused" in the calculation of the desired PLAB > size. I tried to avoid changing the current PLAB sizing in this change, > and later for G1 I plan to override the desired_plab_size() method. > > [This is needed in any case because of improved statistics for G1, where > we want to distinguish between waste within the PLABs and waste caused > by refill due to the current PLAB not fitting into the current region.] Ok. That's reasonable. > > The existing PLAB sizing calculates the amount of "target_refills" using > the _unused member. I admit I do not really understand that calculation, > and the results seem bogus in particular in presence of multiple threads > each having its own PLAB and considering the integer truncation in the > formula. > > I can create a CR to remove _unused and fix the CMS PLAB sizing. I don't know what "fix the CMS PLAB sizing" means but if you put it into a CR, I'll know. > >> If you would like to keep the differentiation between "_wasted - used" >> and "_wasted", consider adding back the "end_of_gc" flag to >> retire() and moving >> >>> 127 _wasted += pointer_delta(_end, _top); // unused space >> out of invalidate() and into retire() in this fashion >> >> if (!end_of_gc) { >> _wasted += pointer_delta(_end, _top); // unused space >> } > Done. I did not use an additional parameter to retire, as we already > have two retiring methods (retire and flush_stats_and_retire) to be > called at different times during GC anyway. Thanks. > > Also, please ignore that G1 at the moment calls flush_stats_and_retire() > every time it allocates a G1ParScanThreadState. This is basically > JDK-8040162. I will ask for a review of that soon. OK. > >> Throwaway suggestion (your call, since not in your change) >> >> Fix the indentation on the fields >> >>> 39 char head[32]; >>> 40 size_t _word_sz; // In HeapWord units >>> 48 char tail[32]; > Fixed. > > http://cr.openjdk.java.net/~tschatzl/8073466/webrev.1_to_2/ Looks good. Reviewed. Jon > (incremental) > http://cr.openjdk.java.net/~tschatzl/8073466/webrev.2/ (full) > > (The change also moves invalidate() to the protected section of > ParGCAllocBuffer). > > Thanks, > Thomas > > From jesper.wilhelmsson at oracle.com Mon Mar 2 18:22:40 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 02 Mar 2015 19:22:40 +0100 Subject: RFR: JDK-8057632 - Remove auxiliary code used to handle the generations array Message-ID: <54F4AA70.5070003@oracle.com> Hi, The generation array removal enabled several other cleanups. I have several changes in queue to perform these cleanups one at a time. In this change the methods next_gen(), prev_gen() and get_gen() are removed and calls are replaced with explicit calls to young_gen() and old_gen(). Please have a look. Bug: https://bugs.openjdk.java.net/browse/JDK-8057632 Webrev: http://cr.openjdk.java.net/~jwilhelm/8057632/webrev.02/ Thanks! /Jesper From jesper.wilhelmsson at oracle.com Mon Mar 2 20:12:31 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 02 Mar 2015 21:12:31 +0100 Subject: RFR(XS): JDK-8071335 - gc/TestSmallHeap.java throw OOM Message-ID: <54F4C42F.60302@oracle.com> Hi, Please review this small change. The test TestSmallHeap.java is designed to make sure we can run a tiny application in 2MB of heap (according to the documentation this should work). Unfortunately when adding a specific set of flags we get an OOME. (For details see the bug.) The conclusion in the bug is to not run the test with -Xcomp. This change fixes that. Bug: https://bugs.openjdk.java.net/browse/JDK-8071335 Webrev: http://cr.openjdk.java.net/~jwilhelm/8071335/webrev.00/ Thanks, /Jesper From staffan.friberg at oracle.com Mon Mar 2 23:42:26 2015 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Mon, 02 Mar 2015 15:42:26 -0800 Subject: Request for sponsor - JDK-8031538 In-Reply-To: <1390477895.2607.39.camel@cirrus> References: <52E068AB.6070901@oracle.com> <1390469331.2607.16.camel@cirrus> <1390477895.2607.39.camel@cirrus> Message-ID: <54F4F562.7060001@oracle.com> Found this old thread lying around. How about the following patch? Checking the calculate_young_list_desired_min_length which simply just adds the base_min_length I think changing the base_min_length to contain more than survivors might increase the nursery size unexpectedly. This will keep the calculation the same, while still making sure we can't set the young size below what the it currently is. @@ -538,13 +538,13 @@ // This is how many young regions we already have (currently: the survivors). uint base_min_length = recorded_survivor_regions(); // This is the absolute minimum young length, which ensures that we - // can allocate one eden region in the worst-case. - uint absolute_min_length = base_min_length + 1; + // will at least have one eden region available in the young list. + // If we shrink the young list target it won't shrink below the current size. + uint eden_length = _g1->young_list()->length() - recorded_survivor_regions(); + uint absolute_min_length = base_min_length + (eden_length == 0) ? 1 : eden_length; uint desired_min_length = calculate_young_list_desired_min_length(base_min_length); - if (desired_min_length < absolute_min_length) { - desired_min_length = absolute_min_length; - } + desired_min_length = MAX2(desired_min_length, absolute_min_length); // Calculate the absolute and desired max bounds. //Staffan > Hi again, > > On Thu, 2014-01-23 at 10:28 +0100, Thomas Schatzl wrote: >> Hi, >> >> On Wed, 2014-01-22 at 16:56 -0800, Staffan Friberg wrote: > [..] >>> [1] - https://bugs.openjdk.java.net/browse/JDK-8031538 >> I think there is a small problem after the change: when revising the >> young target list length concurrently, the code in lines 550/551 more or >> less make sure that the young gen will only ever increase because >> absolute_min_length is always young_list_length() + 1. >> >> So this could mean that if this length is updated really frequently, we >> may exhaust the entire heap. E.g. recalculation of this length increases >> the amount of eden -> allocation can continue -> before OOM there is >> another recalculation -> goto start. >> >> 542 // This is how many young regions we already have (survivors + >> // eventual eden) >> 543 // The young list contain all survivors regions and any eden regions >> >> Maybe add an explanation that during a GC pause the young list contains >> only survivor regions at this point. >> >> 544 uint base_min_length = _g1->young_list()->length(); >> 545 // This is the absolute minimum young length, which ensures that we >> 546 // can allocate one eden region in the worst-case. >> 547 uint absolute_min_length = base_min_length + 1; >> >> I think the unconditional +1 is wrong. It should probably only add this single region if there are not yet eden regions added. I think you could get this information (whether the young list already contains an eden region) from YoungList, by subtracting length() with survivor_length(). If the result is > 0, there are eden regions in the list already. It's possibly best to add a method that returns that boolean value. > Another possible fix is > > uint absolute_min_length = _g1->recorded_survivor_regions() + 1; (or > _g1->young_list()->survivor_regions(). > > Did not think about what is better yet though (or whether they have > issues of their own). Both solutions would not require additional code. > > Thomas > > From kim.barrett at oracle.com Tue Mar 3 01:16:00 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 2 Mar 2015 20:16:00 -0500 Subject: RFR (S): 8073466: Remove buffer retaining functionality and clean up in ParGCAllocBuffer In-Reply-To: <1425298264.3357.42.camel@oracle.com> References: <1424443224.3267.6.camel@oracle.com> <1425038318.3288.53.camel@oracle.com> <54F10B2D.90701@oracle.com> <1425298264.3357.42.camel@oracle.com> Message-ID: On Mar 2, 2015, at 7:11 AM, Thomas Schatzl wrote: > > http://cr.openjdk.java.net/~tschatzl/8073466/webrev.1_to_2/ > (incremental) > http://cr.openjdk.java.net/~tschatzl/8073466/webrev.2/ (full) Update looks good. From bengt.rutisson at oracle.com Tue Mar 3 06:49:14 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 03 Mar 2015 07:49:14 +0100 Subject: RFR(XS): JDK-8071335 - gc/TestSmallHeap.java throw OOM In-Reply-To: <54F4C42F.60302@oracle.com> References: <54F4C42F.60302@oracle.com> Message-ID: <54F5596A.9040508@oracle.com> Hi Jesper, On 2015-03-02 21:12, Jesper Wilhelmsson wrote: > Hi, > > Please review this small change. > > The test TestSmallHeap.java is designed to make sure we can run a tiny > application in 2MB of heap (according to the documentation this should > work). Unfortunately when adding a specific set of flags we get an > OOME. (For details see the bug.) > > The conclusion in the bug is to not run the test with -Xcomp. This > change fixes that. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8071335 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8071335/webrev.00/ This seems to be the first use of vm.compMode in any test. Have you verified that it works in the expected way? I found an odd comment in the JTreg documentation about @requires. It says: "The @requires tag may be used at most once in a given test." http://openjdk.java.net/jtreg/tag-spec.html#DECLARATIVE_TAGS I doubt that this is correct since we already have tests with multiple @requires tags (even this test already has it). But it might be worth verifying the new @requires statement actually has an effect. If it works as expected I think this change looks reasonable. Thanks, Bengt > Thanks, > /Jesper From jesper.wilhelmsson at oracle.com Tue Mar 3 07:20:33 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 3 Mar 2015 08:20:33 +0100 Subject: RFR(XS): JDK-8071335 - gc/TestSmallHeap.java throw OOM In-Reply-To: <54F5596A.9040508@oracle.com> References: <54F4C42F.60302@oracle.com> <54F5596A.9040508@oracle.com> Message-ID: Hi Bengt, Thanks for looking at this! I have verified locally that the test is excluded when running jtreg with -vmoptions="-Xcomp". Thanks, /Jesper > 3 mar 2015 kl. 07:49 skrev Bengt Rutisson : > > > Hi Jesper, > >> On 2015-03-02 21:12, Jesper Wilhelmsson wrote: >> Hi, >> >> Please review this small change. >> >> The test TestSmallHeap.java is designed to make sure we can run a tiny application in 2MB of heap (according to the documentation this should work). Unfortunately when adding a specific set of flags we get an OOME. (For details see the bug.) >> >> The conclusion in the bug is to not run the test with -Xcomp. This change fixes that. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8071335 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8071335/webrev.00/ > > This seems to be the first use of vm.compMode in any test. Have you verified that it works in the expected way? > > I found an odd comment in the JTreg documentation about @requires. It says: > > "The @requires tag may be used at most once in a given test." > > http://openjdk.java.net/jtreg/tag-spec.html#DECLARATIVE_TAGS > > > I doubt that this is correct since we already have tests with multiple @requires tags (even this test already has it). But it might be worth verifying the new @requires statement actually has an effect. > > If it works as expected I think this change looks reasonable. > > Thanks, > Bengt > >> Thanks, >> /Jesper > From bengt.rutisson at oracle.com Tue Mar 3 08:02:30 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 03 Mar 2015 09:02:30 +0100 Subject: RFR: 8026047: [TESTBUG] add regression test for DisableExplicitGC flag In-Reply-To: <54EDC32B.7020605@oracle.com> References: <54C7B051.8050808@oracle.com> <54C90036.8030506@oracle.com> <54CBA45D.8090503@oracle.com> <54D10193.3060407@oracle.com> <54D3B107.9050901@oracle.com> <54DB512A.7070003@oracle.com> <54DB55E9.2080302@oracle.com> <54DB7667.3020107@oracle.com> <54DCB396.2080807@oracle.com> <54EDC32B.7020605@oracle.com> Message-ID: <54F56A96.20702@oracle.com> Hi Michail, I like the idea of using the GarbageCollectionMXBean! However, I am not too happy about the test waiting for 20 seconds. Especially since you have the failing test which will actually wait for 20 seconds. Instead I would suggest to just use the collection count. Attaching a version of the test that use that instead. What do you think about this approach? Thanks, Bengt On 2015-02-25 13:42, Michail Chernov wrote: > Hi Bengt, > > I've rewritten test using JMX. I don't see here any reason to use gc > log for testing this flag. > > http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.02/ > > It seems better solution because it doesn't depend on used GC or log > message format. > > Tested locally with JDK 9 b51 using several GC. Tested using Aurora on > all platforms. > > Thanks, > Michail > > On 12.02.2015 17:07, Bengt Rutisson wrote: >> >> Hi Michail, >> >> On 11/02/15 16:33, Michail Chernov wrote: >>> Hi Bengt, >>> >>> Test works with all options passed to jtreg during testing ( see >>> line 97 vmOpts.addAll(0, Utils.getVmOptions());). Doesn't >>> need to check all GC's, it will be done during nightly. >> >> Ah. I see that now. >> >>> >>> 44 public final static String[] PARALLEL_GC_OPTIONS = >>> {"UseParallelGC", "UseParallelOldGC"}; >>> Here is defined special options. If define one of these options - >>> will be used other pattern to match output. >> >> Right. >> >>> >>> But it seems to me a little bit wrong. I've checked output of GC log >>> with different GCs and ExplicitGCInvokesConcurrent. Message "Full GC >>> (System.gc())" does not appear only in case of using G1 or CMS with >>> ExplicitGCInvokesConcurrent=true. Will fix it. >> >> OK. >> >> My main point was that I think the whole structure of the test is >> different than how we usually write tests that verify the log output. >> I would prefer if the tests look similar. Would you mind re-writing >> the test to look like the other tests. >> >> I much prefer that you explicitly start with the GCs you want to test >> than that you use the WhiteBox API to find out which GC you are running. >> >> I'm having a similar discussion with Dima who recently invented yet >> another way to parse the GC log output from tests. I think it gets >> very hard to read the tests when they do the same thing in different >> ways. >> >> Thanks, >> Bengt >>> >>> Thanks, >>> Michail >>> On 11.02.2015 16:15, Bengt Rutisson wrote: >>>> >>>> Hi Michail, >>>> >>>> On 11/02/15 13:55, Michail Chernov wrote: >>>>> Hi, >>>>> >>>>> Still hoping for review! >>>> >>>> Sorry for being so late in looking at this. >>>> >>>> A couple of questions: >>>> >>>> Why does the test only test the parallel GC? DisableExplicitGC is >>>> valid for all GCs. >>>> >>>> What do you think about writing this test similar to other tests >>>> that validate the output from the GC logging? Here's an example: >>>> >>>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/file/566574421b40/test/gc/g1/TestGCLogMessages.java >>>> >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> >>>>> Thanks, >>>>> Michail >>>>> >>>>> On 05.02.2015 21:05, Michail Chernov wrote: >>>>>> Hi, >>>>>> >>>>>> Still waiting for reviews! >>>>>> >>>>>> Thanks, >>>>>> Michail >>>>>> >>>>>> On 03.02.2015 20:12, Michail Chernov wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Can someone take a look on these changes, please? >>>>>>> >>>>>>> Thanks, >>>>>>> Michail >>>>>>> >>>>>>> On 30.01.2015 18:33, Michail Chernov wrote: >>>>>>>> Hi Leonid, >>>>>>>> >>>>>>>> Issues were fixed: >>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.01/ >>>>>>>> >>>>>>>> Now all testcases are executed from the same VM. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Michail >>>>>>>> >>>>>>>> On 28.01.2015 18:28, Leonid Mesnik wrote: >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> Why is it needed to start VM twice for each test. It is very >>>>>>>>> expensive especially for low-end devices. >>>>>>>>> >>>>>>>>> Is it possible to have driver which starts VM several times >>>>>>>>> with different combinations of options and check it >>>>>>>>> output/exit code etc? Also it would be much easier to read >>>>>>>>> such test. >>>>>>>>> >>>>>>>>> >>>>>>>>> Leonid >>>>>>>>> >>>>>>>>> On 27.01.2015 18:35, Michail Chernov wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Please review the fix with new test for DisableExplicitGC VM >>>>>>>>>> flag. >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.00/ >>>>>>>>>> >>>>>>>>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8026047 >>>>>>>>>> >>>>>>>>>> There is one scenario with 6 parameters combinations. >>>>>>>>>> >>>>>>>>>> 1,2,3 scenarios test default value for DisableExplicitGC, >>>>>>>>>> DisableExplicitGC=true and DisableExplicitGC=false >>>>>>>>>> 4,5,6 scenarios check how VM works when VM changes >>>>>>>>>> DisableExplicitGC flag using WhiteBox. >>>>>>>>>> >>>>>>>>>> Test tries to call System.gc() and check that VM puts message >>>>>>>>>> to stdout. After (in case of 4,5,6 scenarios) test tries to >>>>>>>>>> change DisableExplicitGC value and calls System.gc() twice. >>>>>>>>>> >>>>>>>>>> Test was executed locally on linux-i586 with all available GC >>>>>>>>>> and several GC-related flags. Also it was executed using >>>>>>>>>> Aurora on other platforms. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Michail >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestDisableExplicitGC.java Type: text/x-java Size: 2239 bytes Desc: not available URL: From kim.barrett at oracle.com Tue Mar 3 08:30:50 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 Mar 2015 03:30:50 -0500 Subject: RFR: JDK-8057632 - Remove auxiliary code used to handle the generations array In-Reply-To: <54F4AA70.5070003@oracle.com> References: <54F4AA70.5070003@oracle.com> Message-ID: <2290FDCB-B09D-42E9-9480-89C6EC3F0BD1@oracle.com> On Mar 2, 2015, at 1:22 PM, Jesper Wilhelmsson wrote: > > Hi, > > The generation array removal enabled several other cleanups. I have several changes in queue to perform these cleanups one at a time. > > In this change the methods next_gen(), prev_gen() and get_gen() are removed and calls are replaced with explicit calls to young_gen() and old_gen(). > > Please have a look. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8057632 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8057632/webrev.02/ > > Thanks! > /Jesper Looks good. A couple of questions: ------------------------------------------------------------------------------ src/share/vm/memory/defNewGeneration.cpp Maybe this will be part of the planned future cleanups, but I'll mention it now, just in case. There are various places where _old_gen is assigned or tested for NULL. This all seems rather odd; shouldn't there just be an associated old generation that is recorded in _old_gen at construction time or thereabouts, and be done with it? ------------------------------------------------------------------------------ src/share/vm/runtime/vmStructs.cpp Removed: 533 nonstatic_field(DefNewGeneration, _next_gen, Generation*) \ Was it intentional to remove rather than rename to _old_gen here? From david.lindholm at oracle.com Tue Mar 3 09:02:38 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Tue, 03 Mar 2015 10:02:38 +0100 Subject: RFR: 8073464 - GC workers do not have thread names In-Reply-To: <1424444490.3267.12.camel@oracle.com> References: <54E73922.4040001@oracle.com> <1424444490.3267.12.camel@oracle.com> Message-ID: <54F578AE.909@oracle.com> Hi, On 2015-02-20 16:01, Thomas Schatzl wrote: > Hi, > > On Fri, 2015-02-20 at 14:39 +0100, David Lindholm wrote: >> Hi, >> >> Please review this small fix in GangWorker:initialize(). This addition >> sets the native thread names of GangWorker threads, which the GC uses >> for worker threads. Now these names will be visible when debugging in GDB. >> >> Webrev: http://cr.openjdk.java.net/~stefank/0thers/david/8073464/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8073464 >> > please use Thread::set_native_thread_name() instead of the os function > directly. Ok. > Also, wouldn't it be much more useful to set the native thread name for > all NamedThreads to the name that is passed via set_name() by default? > This would prevent us from doing this work multiple times. Ok, this new patch does this for all NamedThreads. > You might also fix the names themselves for gc owned threads in this CR. > I do not see the need to split this up in CRs per thread type with each > CR being a one-line change. The changes of all the thread names will be handled in a separate change. There is a separate bug for this. I have also changed the copyright year in the changed files, even though I think it is a weird process to do this separately for every change. New webrev: http://cr.openjdk.java.net/~brutisso/8073464/webrev.01/ I have run and passed JPRT on this change. Thanks, David > Thanks, > Thomas > > From bengt.rutisson at oracle.com Tue Mar 3 09:36:34 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 03 Mar 2015 10:36:34 +0100 Subject: RFR: 8073464 - GC workers do not have thread names In-Reply-To: <54F578AE.909@oracle.com> References: <54E73922.4040001@oracle.com> <1424444490.3267.12.camel@oracle.com> <54F578AE.909@oracle.com> Message-ID: <54F580A2.2080902@oracle.com> Hi David, On 2015-03-03 10:02, David Lindholm wrote: > Hi, > > On 2015-02-20 16:01, Thomas Schatzl wrote: >> Hi, >> >> On Fri, 2015-02-20 at 14:39 +0100, David Lindholm wrote: >>> Hi, >>> >>> Please review this small fix in GangWorker:initialize(). This addition >>> sets the native thread names of GangWorker threads, which the GC uses >>> for worker threads. Now these names will be visible when debugging >>> in GDB. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~stefank/0thers/david/8073464/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073464 >>> >> please use Thread::set_native_thread_name() instead of the os >> function >> directly. > > Ok. > >> Also, wouldn't it be much more useful to set the native thread name for >> all NamedThreads to the name that is passed via set_name() by default? >> This would prevent us from doing this work multiple times. > > Ok, this new patch does this for all NamedThreads. > >> You might also fix the names themselves for gc owned threads in this CR. >> I do not see the need to split this up in CRs per thread type with each >> CR being a one-line change. > > The changes of all the thread names will be handled in a separate > change. There is a separate bug for this. > > I have also changed the copyright year in the changed files, even > though I think it is a weird process to do this separately for every > change. It is a strange process :) > > New webrev: http://cr.openjdk.java.net/~brutisso/8073464/webrev.01/ Looks good to me. Bengt > > I have run and passed JPRT on this change. > > Thanks, > David >> Thanks, >> Thomas >> > From thomas.schatzl at oracle.com Tue Mar 3 10:06:14 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 03 Mar 2015 11:06:14 +0100 Subject: Request for sponsor - JDK-8031538 In-Reply-To: <54F4F562.7060001@oracle.com> References: <52E068AB.6070901@oracle.com> <1390469331.2607.16.camel@cirrus> <1390477895.2607.39.camel@cirrus> <54F4F562.7060001@oracle.com> Message-ID: <1425377174.3315.42.camel@oracle.com> Hi Staffan, On Mon, 2015-03-02 at 15:42 -0800, Staffan Friberg wrote: > Found this old thread lying around. > > How about the following patch? > > Checking the calculate_young_list_desired_min_length which simply just > adds the base_min_length I think changing the base_min_length to contain > more than survivors might increase the nursery size unexpectedly. This > will keep the calculation the same, while still making sure we can't set > the young size below what the it currently is. > > @@ -538,13 +538,13 @@ > // This is how many young regions we already have (currently: the > survivors). > uint base_min_length = recorded_survivor_regions(); > // This is the absolute minimum young length, which ensures that we > - // can allocate one eden region in the worst-case. > - uint absolute_min_length = base_min_length + 1; > + // will at least have one eden region available in the young list. > + // If we shrink the young list target it won't shrink below the > current size. > + uint eden_length = _g1->young_list()->length() - > recorded_survivor_regions(); > + uint absolute_min_length = base_min_length + (eden_length == 0) ? 1 : > eden_length; > uint desired_min_length = > calculate_young_list_desired_min_length(base_min_length); > - if (desired_min_length < absolute_min_length) { > - desired_min_length = absolute_min_length; > - } > + desired_min_length = MAX2(desired_min_length, absolute_min_length); > > // Calculate the absolute and desired max bounds. looks good; I applied some minor refactoring (the eden length calculation moved to the YoungList class). If you are good with these changes, I can sponsor it. Webrev: http://cr.openjdk.java.net/~tschatzl/8031538/webrev/ Thanks, Thomas From bengt.rutisson at oracle.com Tue Mar 3 10:53:47 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 03 Mar 2015 11:53:47 +0100 Subject: RFR(XS): JDK-8071335 - gc/TestSmallHeap.java throw OOM In-Reply-To: References: <54F4C42F.60302@oracle.com> <54F5596A.9040508@oracle.com> Message-ID: <54F592BB.8080007@oracle.com> Hi Jesper, On 2015-03-03 08:20, Jesper Wilhelmsson wrote: > Hi Bengt, > > Thanks for looking at this! > I have verified locally that the test is excluded when running jtreg with -vmoptions="-Xcomp". Thanks for verifying it. So, I guess the JTreg documentation is wrong then. Reviewed. Thanks, Bengt > > Thanks, > /Jesper > > >> 3 mar 2015 kl. 07:49 skrev Bengt Rutisson : >> >> >> Hi Jesper, >> >>> On 2015-03-02 21:12, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> Please review this small change. >>> >>> The test TestSmallHeap.java is designed to make sure we can run a tiny application in 2MB of heap (according to the documentation this should work). Unfortunately when adding a specific set of flags we get an OOME. (For details see the bug.) >>> >>> The conclusion in the bug is to not run the test with -Xcomp. This change fixes that. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071335 >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8071335/webrev.00/ >> This seems to be the first use of vm.compMode in any test. Have you verified that it works in the expected way? >> >> I found an odd comment in the JTreg documentation about @requires. It says: >> >> "The @requires tag may be used at most once in a given test." >> >> http://openjdk.java.net/jtreg/tag-spec.html#DECLARATIVE_TAGS >> >> >> I doubt that this is correct since we already have tests with multiple @requires tags (even this test already has it). But it might be worth verifying the new @requires statement actually has an effect. >> >> If it works as expected I think this change looks reasonable. >> >> Thanks, >> Bengt >> >>> Thanks, >>> /Jesper From thomas.schatzl at oracle.com Tue Mar 3 11:05:47 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 03 Mar 2015 12:05:47 +0100 Subject: RFR: 8073464 - GC workers do not have thread names In-Reply-To: <54F578AE.909@oracle.com> References: <54E73922.4040001@oracle.com> <1424444490.3267.12.camel@oracle.com> <54F578AE.909@oracle.com> Message-ID: <1425380747.3315.53.camel@oracle.com> Hi David, On Tue, 2015-03-03 at 10:02 +0100, David Lindholm wrote: > Hi, > > On 2015-02-20 16:01, Thomas Schatzl wrote: > > Hi, > > > > On Fri, 2015-02-20 at 14:39 +0100, David Lindholm wrote: > >> Hi, > >> > >> Please review this small fix in GangWorker:initialize(). This addition > >> sets the native thread names of GangWorker threads, which the GC uses > >> for worker threads. Now these names will be visible when debugging in GDB. > >> [...] > > Also, wouldn't it be much more useful to set the native thread name for > > all NamedThreads to the name that is passed via set_name() by default? > > This would prevent us from doing this work multiple times. > > Ok, this new patch does this for all NamedThreads. Thanks. > > You might also fix the names themselves for gc owned threads in this CR. > > I do not see the need to split this up in CRs per thread type with each > > CR being a one-line change. > > The changes of all the thread names will be handled in a separate > change. There is a separate bug for this. > > I have also changed the copyright year in the changed files, even though > I think it is a weird process to do this separately for every change. > > New webrev: http://cr.openjdk.java.net/~brutisso/8073464/webrev.01/ > > I have run and passed JPRT on this change. Looks good. It would be nice to have an initialize_in_thread() method in NamedThread that all descendants call. If you look at the current code, all NamedThread children duplicate the calls to record_stack_base_and_size(), initialize_thread_local_storage(), and initialize_named_thread(). However I am not insisting on doing this cleanup in this CR if you do not want to. In that case, please create a new cleanup CR for that. Thanks, Thomas From thomas.schatzl at oracle.com Tue Mar 3 11:08:58 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 03 Mar 2015 12:08:58 +0100 Subject: RFR(XS): JDK-8071335 - gc/TestSmallHeap.java throw OOM In-Reply-To: <54F4C42F.60302@oracle.com> References: <54F4C42F.60302@oracle.com> Message-ID: <1425380938.3315.54.camel@oracle.com> Hi Jesper, On Mon, 2015-03-02 at 21:12 +0100, Jesper Wilhelmsson wrote: > Hi, > > Please review this small change. > > The test TestSmallHeap.java is designed to make sure we can run a tiny > application in 2MB of heap (according to the documentation this should work). > Unfortunately when adding a specific set of flags we get an OOME. (For details > see the bug.) > > The conclusion in the bug is to not run the test with -Xcomp. This change fixes > that. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8071335 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8071335/webrev.00/ looks good. Thomas From jesper.wilhelmsson at oracle.com Tue Mar 3 11:24:23 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 3 Mar 2015 12:24:23 +0100 Subject: RFR(XS): JDK-8071335 - gc/TestSmallHeap.java throw OOM In-Reply-To: <1425380938.3315.54.camel@oracle.com> References: <54F4C42F.60302@oracle.com> <1425380938.3315.54.camel@oracle.com> Message-ID: <17977066-7BFF-41FF-AEC5-2BA0CB5A04BB@oracle.com> Thank you Thomas! /Jesper > 3 mar 2015 kl. 12:08 skrev Thomas Schatzl : > > Hi Jesper, > >> On Mon, 2015-03-02 at 21:12 +0100, Jesper Wilhelmsson wrote: >> Hi, >> >> Please review this small change. >> >> The test TestSmallHeap.java is designed to make sure we can run a tiny >> application in 2MB of heap (according to the documentation this should work). >> Unfortunately when adding a specific set of flags we get an OOME. (For details >> see the bug.) >> >> The conclusion in the bug is to not run the test with -Xcomp. This change fixes >> that. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8071335 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8071335/webrev.00/ > > looks good. > > Thomas > > From jesper.wilhelmsson at oracle.com Tue Mar 3 11:24:53 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 3 Mar 2015 12:24:53 +0100 Subject: RFR(XS): JDK-8071335 - gc/TestSmallHeap.java throw OOM In-Reply-To: <54F592BB.8080007@oracle.com> References: <54F4C42F.60302@oracle.com> <54F5596A.9040508@oracle.com> <54F592BB.8080007@oracle.com> Message-ID: Thanks! /Jesper > 3 mar 2015 kl. 11:53 skrev Bengt Rutisson : > > > Hi Jesper, > >> On 2015-03-03 08:20, Jesper Wilhelmsson wrote: >> Hi Bengt, >> >> Thanks for looking at this! >> I have verified locally that the test is excluded when running jtreg with -vmoptions="-Xcomp". > > Thanks for verifying it. > > So, I guess the JTreg documentation is wrong then. > > Reviewed. > > Thanks, > Bengt > >> >> Thanks, >> /Jesper >> >> >>> 3 mar 2015 kl. 07:49 skrev Bengt Rutisson : >>> >>> >>> Hi Jesper, >>> >>>> On 2015-03-02 21:12, Jesper Wilhelmsson wrote: >>>> Hi, >>>> >>>> Please review this small change. >>>> >>>> The test TestSmallHeap.java is designed to make sure we can run a tiny application in 2MB of heap (according to the documentation this should work). Unfortunately when adding a specific set of flags we get an OOME. (For details see the bug.) >>>> >>>> The conclusion in the bug is to not run the test with -Xcomp. This change fixes that. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071335 >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8071335/webrev.00/ >>> This seems to be the first use of vm.compMode in any test. Have you verified that it works in the expected way? >>> >>> I found an odd comment in the JTreg documentation about @requires. It says: >>> >>> "The @requires tag may be used at most once in a given test." >>> >>> http://openjdk.java.net/jtreg/tag-spec.html#DECLARATIVE_TAGS >>> >>> >>> I doubt that this is correct since we already have tests with multiple @requires tags (even this test already has it). But it might be worth verifying the new @requires statement actually has an effect. >>> >>> If it works as expected I think this change looks reasonable. >>> >>> Thanks, >>> Bengt >>> >>>> Thanks, >>>> /Jesper > From thomas.schatzl at oracle.com Tue Mar 3 11:32:18 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 03 Mar 2015 12:32:18 +0100 Subject: RFR (S): 8073466: Remove buffer retaining functionality and clean up in ParGCAllocBuffer In-Reply-To: References: <1424443224.3267.6.camel@oracle.com> <1425038318.3288.53.camel@oracle.com> <54F10B2D.90701@oracle.com> <1425298264.3357.42.camel@oracle.com> Message-ID: <1425382338.3315.67.camel@oracle.com> Hi Kom, On Mon, 2015-03-02 at 20:16 -0500, Kim Barrett wrote: > On Mar 2, 2015, at 7:11 AM, Thomas Schatzl wrote: > > > > http://cr.openjdk.java.net/~tschatzl/8073466/webrev.1_to_2/ > > (incremental) > > http://cr.openjdk.java.net/~tschatzl/8073466/webrev.2/ (full) > > Update looks good. thanks for the review. Thomas From david.lindholm at oracle.com Tue Mar 3 12:52:34 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Tue, 03 Mar 2015 13:52:34 +0100 Subject: RFR: 8073464 - GC workers do not have thread names In-Reply-To: <1425380747.3315.53.camel@oracle.com> References: <54E73922.4040001@oracle.com> <1424444490.3267.12.camel@oracle.com> <54F578AE.909@oracle.com> <1425380747.3315.53.camel@oracle.com> Message-ID: <54F5AE92.2020605@oracle.com> Hi, Thanks for the review. On 2015-03-03 12:05, Thomas Schatzl wrote: > It would be nice to have an initialize_in_thread() method in NamedThread > that all descendants call. If you look at the current code, all > NamedThread children duplicate the calls to > record_stack_base_and_size(), initialize_thread_local_storage(), and > initialize_named_thread(). However I am not insisting on doing this > cleanup in this CR if you do not want to. In that case, please create a > new cleanup CR for that. > > Thanks, > Thomas > Yes, I saw this and had the same idea, and I also implemented this idea. However, after discussing with Bengt we came to the conclusion that this was not the right thing to do, since initialize_named_thread() is located in NamedThread and the two other in Thread. If we were to unify these in an initialization function it should be a part of a larger rewrite of the initialization of Thread and its subclasses. Thanks, David From david.lindholm at oracle.com Tue Mar 3 12:53:53 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Tue, 03 Mar 2015 13:53:53 +0100 Subject: RFR: 8073464 - GC workers do not have thread names In-Reply-To: <54F580A2.2080902@oracle.com> References: <54E73922.4040001@oracle.com> <1424444490.3267.12.camel@oracle.com> <54F578AE.909@oracle.com> <54F580A2.2080902@oracle.com> Message-ID: <54F5AEE1.1020505@oracle.com> Hi, On 2015-03-03 10:36, Bengt Rutisson wrote: > > Hi David, > > On 2015-03-03 10:02, David Lindholm wrote: >> Hi, >> >> On 2015-02-20 16:01, Thomas Schatzl wrote: >>> Hi, >>> >>> On Fri, 2015-02-20 at 14:39 +0100, David Lindholm wrote: >>>> Hi, >>>> >>>> Please review this small fix in GangWorker:initialize(). This addition >>>> sets the native thread names of GangWorker threads, which the GC uses >>>> for worker threads. Now these names will be visible when debugging >>>> in GDB. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~stefank/0thers/david/8073464/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073464 >>>> >>> please use Thread::set_native_thread_name() instead of the os >>> function >>> directly. >> >> Ok. >> >>> Also, wouldn't it be much more useful to set the native thread name for >>> all NamedThreads to the name that is passed via set_name() by default? >>> This would prevent us from doing this work multiple times. >> >> Ok, this new patch does this for all NamedThreads. >> >>> You might also fix the names themselves for gc owned threads in this >>> CR. >>> I do not see the need to split this up in CRs per thread type with each >>> CR being a one-line change. >> >> The changes of all the thread names will be handled in a separate >> change. There is a separate bug for this. >> >> I have also changed the copyright year in the changed files, even >> though I think it is a weird process to do this separately for every >> change. > > It is a strange process :) > >> >> New webrev: http://cr.openjdk.java.net/~brutisso/8073464/webrev.01/ > > Looks good to me. Thanks for the review! /David > Bengt > >> >> I have run and passed JPRT on this change. >> >> Thanks, >> David >>> Thanks, >>> Thomas >>> >> > From michail.chernov at oracle.com Tue Mar 3 15:32:44 2015 From: michail.chernov at oracle.com (Michail Chernov) Date: Tue, 03 Mar 2015 18:32:44 +0300 Subject: RFR: 8026047: [TESTBUG] add regression test for DisableExplicitGC flag In-Reply-To: <54F56A96.20702@oracle.com> References: <54C7B051.8050808@oracle.com> <54C90036.8030506@oracle.com> <54CBA45D.8090503@oracle.com> <54D10193.3060407@oracle.com> <54D3B107.9050901@oracle.com> <54DB512A.7070003@oracle.com> <54DB55E9.2080302@oracle.com> <54DB7667.3020107@oracle.com> <54DCB396.2080807@oracle.com> <54EDC32B.7020605@oracle.com> <54F56A96.20702@oracle.com> Message-ID: <54F5D41C.3080009@oracle.com> Hi Bengt, I checked run time of test on raspberry-pi and on some solaris host with -Xcomp option. On r-pi it works 2.8 seconds, on solaris host it works 3.5 seconds. I can set NOTIFICATION_DELAY=5 (for example) to speed up the test. Your approach has some cons - it does not check that System.gc() was real GC source. In case if we don't check source of GC events, we can simplify test more and avoid usage of JMX: import java.lang.ref.WeakReference; public class Test{ public static volatile WeakReference ref; public static Object refObject; public static void main(String[] args) { ref=new WeakReference<>(new Object()); refObject=ref.get(); if ( refObject==null) throw new RuntimeException("ERROR! Object was collected before GC"); refObject=null; System.gc(); refObject=ref.get(); if ( refObject!=null) throw new RuntimeException("ERROR! Object was not collected during GC"); } } However, this solution does not check the real cause of GC. If this way is applicable here, I could use this code for testing DisableExplicitGC flag. Thanks, Michail On 03.03.2015 11:02, Bengt Rutisson wrote: > > Hi Michail, > > I like the idea of using the GarbageCollectionMXBean! > > However, I am not too happy about the test waiting for 20 seconds. > Especially since you have the failing test which will actually wait > for 20 seconds. > > Instead I would suggest to just use the collection count. Attaching a > version of the test that use that instead. What do you think about > this approach? > > Thanks, > Bengt > > > > On 2015-02-25 13:42, Michail Chernov wrote: >> Hi Bengt, >> >> I've rewritten test using JMX. I don't see here any reason to use gc >> log for testing this flag. >> >> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.02/ >> >> It seems better solution because it doesn't depend on used GC or log >> message format. >> >> Tested locally with JDK 9 b51 using several GC. Tested using Aurora >> on all platforms. >> >> Thanks, >> Michail >> >> On 12.02.2015 17:07, Bengt Rutisson wrote: >>> >>> Hi Michail, >>> >>> On 11/02/15 16:33, Michail Chernov wrote: >>>> Hi Bengt, >>>> >>>> Test works with all options passed to jtreg during testing ( see >>>> line 97 vmOpts.addAll(0, Utils.getVmOptions());). Doesn't >>>> need to check all GC's, it will be done during nightly. >>> >>> Ah. I see that now. >>> >>>> >>>> 44 public final static String[] PARALLEL_GC_OPTIONS = >>>> {"UseParallelGC", "UseParallelOldGC"}; >>>> Here is defined special options. If define one of these options - >>>> will be used other pattern to match output. >>> >>> Right. >>> >>>> >>>> But it seems to me a little bit wrong. I've checked output of GC >>>> log with different GCs and ExplicitGCInvokesConcurrent. Message >>>> "Full GC (System.gc())" does not appear only in case of using G1 or >>>> CMS with ExplicitGCInvokesConcurrent=true. Will fix it. >>> >>> OK. >>> >>> My main point was that I think the whole structure of the test is >>> different than how we usually write tests that verify the log >>> output. I would prefer if the tests look similar. Would you mind >>> re-writing the test to look like the other tests. >>> >>> I much prefer that you explicitly start with the GCs you want to >>> test than that you use the WhiteBox API to find out which GC you are >>> running. >>> >>> I'm having a similar discussion with Dima who recently invented yet >>> another way to parse the GC log output from tests. I think it gets >>> very hard to read the tests when they do the same thing in different >>> ways. >>> >>> Thanks, >>> Bengt >>>> >>>> Thanks, >>>> Michail >>>> On 11.02.2015 16:15, Bengt Rutisson wrote: >>>>> >>>>> Hi Michail, >>>>> >>>>> On 11/02/15 13:55, Michail Chernov wrote: >>>>>> Hi, >>>>>> >>>>>> Still hoping for review! >>>>> >>>>> Sorry for being so late in looking at this. >>>>> >>>>> A couple of questions: >>>>> >>>>> Why does the test only test the parallel GC? DisableExplicitGC is >>>>> valid for all GCs. >>>>> >>>>> What do you think about writing this test similar to other tests >>>>> that validate the output from the GC logging? Here's an example: >>>>> >>>>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/file/566574421b40/test/gc/g1/TestGCLogMessages.java >>>>> >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>>> >>>>>> Thanks, >>>>>> Michail >>>>>> >>>>>> On 05.02.2015 21:05, Michail Chernov wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Still waiting for reviews! >>>>>>> >>>>>>> Thanks, >>>>>>> Michail >>>>>>> >>>>>>> On 03.02.2015 20:12, Michail Chernov wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Can someone take a look on these changes, please? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Michail >>>>>>>> >>>>>>>> On 30.01.2015 18:33, Michail Chernov wrote: >>>>>>>>> Hi Leonid, >>>>>>>>> >>>>>>>>> Issues were fixed: >>>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.01/ >>>>>>>>> >>>>>>>>> Now all testcases are executed from the same VM. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Michail >>>>>>>>> >>>>>>>>> On 28.01.2015 18:28, Leonid Mesnik wrote: >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> Why is it needed to start VM twice for each test. It is very >>>>>>>>>> expensive especially for low-end devices. >>>>>>>>>> >>>>>>>>>> Is it possible to have driver which starts VM several times >>>>>>>>>> with different combinations of options and check it >>>>>>>>>> output/exit code etc? Also it would be much easier to read >>>>>>>>>> such test. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Leonid >>>>>>>>>> >>>>>>>>>> On 27.01.2015 18:35, Michail Chernov wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Please review the fix with new test for DisableExplicitGC VM >>>>>>>>>>> flag. >>>>>>>>>>> >>>>>>>>>>> Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8026047 >>>>>>>>>>> >>>>>>>>>>> There is one scenario with 6 parameters combinations. >>>>>>>>>>> >>>>>>>>>>> 1,2,3 scenarios test default value for DisableExplicitGC, >>>>>>>>>>> DisableExplicitGC=true and DisableExplicitGC=false >>>>>>>>>>> 4,5,6 scenarios check how VM works when VM changes >>>>>>>>>>> DisableExplicitGC flag using WhiteBox. >>>>>>>>>>> >>>>>>>>>>> Test tries to call System.gc() and check that VM puts >>>>>>>>>>> message to stdout. After (in case of 4,5,6 scenarios) test >>>>>>>>>>> tries to change DisableExplicitGC value and calls >>>>>>>>>>> System.gc() twice. >>>>>>>>>>> >>>>>>>>>>> Test was executed locally on linux-i586 with all available >>>>>>>>>>> GC and several GC-related flags. Also it was executed using >>>>>>>>>>> Aurora on other platforms. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Michail >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > From andrey.x.zakharov at oracle.com Tue Mar 3 15:40:24 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Tue, 03 Mar 2015 18:40:24 +0300 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <1425308253.3357.90.camel@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> <54E4848A.2010203@oracle.com> <54EDFD38.6010002@oracle.com> <54EF5E2D.5020503@oracle.com> <1425308253.3357.90.camel@oracle.com> Message-ID: <54F5D5E8.3060400@oracle.com> Fixed according comments. hotspot webrev: http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/ hs-gc webrev: http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/hs-gc/ testing: in progress Thanks. 02.03.2015 17:57, Thomas Schatzl ?????: > Hi Andrey, > > On Thu, 2015-02-26 at 20:55 +0300, Andrey Zakharov wrote: >> Updated test with >> - updated 2 spaces for c++ code and code style >> - updated copyrights >> - renamed variable hotCardTableSize >> - added output for current page size >> >> webrev: >> http://cr.openjdk.java.net/~azakharov/8061715/webrev.05/ > - in HeapRegionManager::get_auxiliary_data_memory_usage(), please avoid > declaring and initializing using multiple variables in a single > statement, particularly if these statements span multiple lines. > > While coding guidelines do not explicitly prohibit this, it is easier to > read if you repeat the type of the variable. > > Also, it would be easier to read, if there were an additional line > between the return statement and the declaration of committed_sz. The > existing code also spells out "sz". > > - the method bodies in the G1 code use an indentation of four spaces. > Hotspot code uses two space. > > - not sure about this, but the changed tests do not add 8061715 to their > @bug tag. It will be impossible to test particularly 8061715 then > without finding the original bug number. > > - the webrev is missing the changes to the WhiteBox.java file at > /test/lib/sun/hotspot/WhiteBox.java. Please generate an extra > webrev for that repo. > >> testing: yes (sthjprt 2015-02-26-172927.gtee.auxdata - I will restart >> solaris on complete) >> >> Thanks. >> >>>>> - in TestShrinkAuxiliaryData.java, line 107 seems to be debugging code. >>>>> Afaik jtreg already automatically puts all output into the log files. >> This is why this code here: OutputAnalyzer with ProcessBuilder doesn't >> implicitly output anything. > Many other tests do not either (can be easily added for debugging), but > if so, I recommend putting the System.out.println() statement before the > output.shouldHaveExitValue(0); line. Otherwise the test will exit before > printing the messages if there is some VM error. > >>>>> - line 174, I do not understand the comment. What does "if auxdata size >>>>> will be more than page size it would not decommit auxiliary data >>>>> size is >>>>> about ~3.6% of heap size" seem to be at least two sentences. >> Fixed >>>>> - what do the two reasons given in the comment of >>>>> checkEnvApplicability() actually mean? I.e. why do you not run the test >>>>> if large pages are enabled? >> I dont want to run this test on box where page size is larger than >> auxiliary data size for region, where decommitment wouldn't occurs for sure. > Okay. But then the comment is wrong: it states "if auxdata size will be > more than page size it would not decommit" which is the reverse of what > you said above. > > I also think the comparison below should be a ">=" and not only ">" > then. > > The skip message could be improved to mention "Skipping test because the > auxiliary data is smaller than page size %d" to make the reason more > clear. > > Thanks, > Thomas > > > From bengt.rutisson at oracle.com Tue Mar 3 16:10:34 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 03 Mar 2015 17:10:34 +0100 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: <54F48C84.3060602@oracle.com> References: <54F08F8A.7070901@oracle.com> <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> <54F41E05.2090905@oracle.com> <54F48C84.3060602@oracle.com> Message-ID: <54F5DCFA.8010900@oracle.com> Hi all, After some testing I noticed that I had done all my testing with StringDedup enabled. The code did not work properly with it disabled since StringDedup reported times for full GCs and concurrent marking even though it was not logged anywhere. I changed the code to only report times when the times will be reported as part of a GC. Here's an updated webrev: http://cr.openjdk.java.net/~brutisso/8074037/webrev.02/ And a diff compared to the last review: http://cr.openjdk.java.net/~brutisso/8074037/webrev.01-02.diff/ Thanks, Bengt On 2015-03-02 17:15, Bengt Rutisson wrote: > > Hi again, > > Here is an updated webrev: > http://cr.openjdk.java.net/~brutisso/8074037/webrev.01/ > > And here's the diff compared to the last webrev: > http://cr.openjdk.java.net/~brutisso/8074037/webrev.00-01.diff/ > > I tried to clean up the seconds vs. milliseconds confusion by making > it G1GCPhaseTimes' responsibility to handle the conversion in all > cases. So, the interface is now that times are reported in seconds > (for example G1GCPhaseTimes::record_time_secs()) but returned in > milliseconds (for example G1GCPhaseTimes::average_time_ms()). I > suffixed the method names "_secs" and "_ms" to make it easier to > follow the code. > > I'm not very happy about this inconsistency, but I want it to be an > intermediate step on the way to getting rid of os::elapsedTime() > completely. > > StefanK also suggested to move the logging code out to its own class. > This simplified the logging quite a bit I think. The class, > G1GCPhasePrinter, has to know a lot about both G1GCPhaseTimes and > WorkerDataArray, but I still think it is nice to have the logging > separated out. > > I didn't read Thomas' email with comments until after I had prepared > this updated webrev. But I think I have addressed the issues brought > up there. Thanks for looking at this, Thomas! > > Bengt > > On 2015-03-02 09:23, Bengt Rutisson wrote: >> >> Hi Kim, >> >> Thanks for looking at this! >> >> On 2015-02-28 00:43, Kim Barrett wrote: >>> On Feb 27, 2015, at 10:38 AM, Bengt Rutisson >>> wrote: >>>> Can I have a couple of reviews for this cleanup change? >>>> >>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8074037 >>>> >>>> [?] >>>> The patch also introduces a new class called G1GCPhaseTimesTracker, >>>> which is a scoped object to simplify time measurements. I've also >>>> tried to move conversion of times down to when we print the log >>>> messages instead of when we store them. This removes several "* >>>> 1000.0" in the code. Eventually I would like to replace >>>> os::elapsedTime() with os::elapsed_counter(). But that should be >>>> done as a separate patch. >>> Before I proceed any further with this review, I feel like I'm getting >>> lost in unit changes. In some places values of msecs used to be used >>> but now we're using secs, right? But it seems like there might be some >>> confusion about that, and I'm not sure whether it's me or the code >>> that's confused. >>> >>> For example: >>> >>> src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp >>> 1079 cost_per_card_ms = >>> phase_times()->average_time(G1GCPhaseTimes::UpdateRS) / (double) >>> _pending_cards; >>> 1080 _cost_per_card_ms_seq->add(cost_per_card_ms); >>> >>> I think the values that have been recorded in the phase_times are >>> secs, and average_time appears to just use the values as is. So >>> shouldn't that now be cost_per_card_secs? And the value added to >>> _cost_per_card_ms_seq needs to be cost_per_card_secs * 1000.0? >> >> Right! Good catch! I was so happy to get rid of some of the "* >> 1000.0" statements sprinkled all over the G1 code that I forgot to >> add some of them back ;) >> >> I'll send out an updated webrev soon. >> >> Bengt >> >>> >>> Oh how I wish for a units package! >>> >> > From kim.barrett at oracle.com Tue Mar 3 16:26:33 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 Mar 2015 11:26:33 -0500 Subject: RFR: 8074319: barrier_set_cast defined via friend injection Message-ID: <28177A82-C2AC-4674-9831-D63CEEFCA5E2@oracle.com> Please review this small change to the recently added barrier_set_cast (see https://bugs.openjdk.java.net/browse/JDK-8069016). The way that new function is being defined is unintentionally not standards conforming and should not compile, but all of our present official test platforms accept it anyway. The code is presently only known to fail with the more recent Xcode6. I will need a sponsor for this change. CR: https://bugs.openjdk.java.net/browse/JDK-8074319 Webrev: http://cr.openjdk.java.net/~kbarrett/8074319/webrev.00/ From kim.barrett at oracle.com Tue Mar 3 16:28:59 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 Mar 2015 11:28:59 -0500 Subject: RFR: 8074319: barrier_set_cast defined via friend injection In-Reply-To: <28177A82-C2AC-4674-9831-D63CEEFCA5E2@oracle.com> References: <28177A82-C2AC-4674-9831-D63CEEFCA5E2@oracle.com> Message-ID: <56FA376C-9C39-4ADF-BC06-FCA2356AB2A5@oracle.com> On Mar 3, 2015, at 11:26 AM, Kim Barrett wrote: > > Please review this small change to the recently added barrier_set_cast > (see https://bugs.openjdk.java.net/browse/JDK-8069016). The way that > new function is being defined is unintentionally not standards > conforming and should not compile, but all of our present official > test platforms accept it anyway. The code is presently only known to > fail with the more recent Xcode6. That should be Xcode5. Xcode4 is the present test platform. From jesper.wilhelmsson at oracle.com Tue Mar 3 16:37:43 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 03 Mar 2015 17:37:43 +0100 Subject: RFR: 8074319: barrier_set_cast defined via friend injection In-Reply-To: <28177A82-C2AC-4674-9831-D63CEEFCA5E2@oracle.com> References: <28177A82-C2AC-4674-9831-D63CEEFCA5E2@oracle.com> Message-ID: <54F5E357.4000504@oracle.com> Kim, Thanks for fixing this! I'm not fluid in C++ templates, but it looks good to me. I have verified that it builds fine with Xcode 5 using your patch. Thanks, /Jesper Kim Barrett skrev den 3/3/15 17:26: > Please review this small change to the recently added barrier_set_cast > (see https://bugs.openjdk.java.net/browse/JDK-8069016). The way that > new function is being defined is unintentionally not standards > conforming and should not compile, but all of our present official > test platforms accept it anyway. The code is presently only known to > fail with the more recent Xcode6. > > I will need a sponsor for this change. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8074319 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8074319/webrev.00/ > From andrey.x.zakharov at oracle.com Tue Mar 3 16:59:49 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Tue, 03 Mar 2015 19:59:49 +0300 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <54F5D5E8.3060400@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> <54E4848A.2010203@oracle.com> <54EDFD38.6010002@oracle.com> <54EF5E2D.5020503@oracle.com> <1425308253.3357.90.camel@oracle.com> <54F5D5E8.3060400@oracle.com> Message-ID: <54F5E885.6070704@oracle.com> Testing as 2015-03-03-151040.gtee.auxdata looks good in Sth queue. Thanks. 03.03.2015 18:40, Andrey Zakharov ?????: > Fixed according comments. > > hotspot webrev: > http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/ > > hs-gc webrev: > http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/hs-gc/ > > testing: in progress > > Thanks. > > 02.03.2015 17:57, Thomas Schatzl ?????: >> Hi Andrey, >> >> On Thu, 2015-02-26 at 20:55 +0300, Andrey Zakharov wrote: >>> Updated test with >>> - updated 2 spaces for c++ code and code style >>> - updated copyrights >>> - renamed variable hotCardTableSize >>> - added output for current page size >>> >>> webrev: >>> http://cr.openjdk.java.net/~azakharov/8061715/webrev.05/ >> - in HeapRegionManager::get_auxiliary_data_memory_usage(), please avoid >> declaring and initializing using multiple variables in a single >> statement, particularly if these statements span multiple lines. >> >> While coding guidelines do not explicitly prohibit this, it is easier to >> read if you repeat the type of the variable. >> >> Also, it would be easier to read, if there were an additional line >> between the return statement and the declaration of committed_sz. The >> existing code also spells out "sz". >> >> - the method bodies in the G1 code use an indentation of four spaces. >> Hotspot code uses two space. >> >> - not sure about this, but the changed tests do not add 8061715 to their >> @bug tag. It will be impossible to test particularly 8061715 then >> without finding the original bug number. >> >> - the webrev is missing the changes to the WhiteBox.java file at >> /test/lib/sun/hotspot/WhiteBox.java. Please generate an extra >> webrev for that repo. >> >>> testing: yes (sthjprt 2015-02-26-172927.gtee.auxdata - I will restart >>> solaris on complete) >>> >>> Thanks. >>> >>>>>> - in TestShrinkAuxiliaryData.java, line 107 seems to be debugging >>>>>> code. >>>>>> Afaik jtreg already automatically puts all output into the log >>>>>> files. >>> This is why this code here: OutputAnalyzer with ProcessBuilder doesn't >>> implicitly output anything. >> Many other tests do not either (can be easily added for debugging), but >> if so, I recommend putting the System.out.println() statement before the >> output.shouldHaveExitValue(0); line. Otherwise the test will exit before >> printing the messages if there is some VM error. >> >>>>>> - line 174, I do not understand the comment. What does "if >>>>>> auxdata size >>>>>> will be more than page size it would not decommit auxiliary data >>>>>> size is >>>>>> about ~3.6% of heap size" seem to be at least two sentences. >>> Fixed >>>>>> - what do the two reasons given in the comment of >>>>>> checkEnvApplicability() actually mean? I.e. why do you not run >>>>>> the test >>>>>> if large pages are enabled? >>> I dont want to run this test on box where page size is larger than >>> auxiliary data size for region, where decommitment wouldn't occurs >>> for sure. >> Okay. But then the comment is wrong: it states "if auxdata size will be >> more than page size it would not decommit" which is the reverse of what >> you said above. >> >> I also think the comparison below should be a ">=" and not only ">" >> then. >> >> The skip message could be improved to mention "Skipping test because the >> auxiliary data is smaller than page size %d" to make the reason more >> clear. >> >> Thanks, >> Thomas >> >> >> > From staffan.friberg at oracle.com Tue Mar 3 17:12:51 2015 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Tue, 03 Mar 2015 09:12:51 -0800 Subject: Request for sponsor - JDK-8031538 In-Reply-To: <1425377174.3315.42.camel@oracle.com> References: <52E068AB.6070901@oracle.com> <1390469331.2607.16.camel@cirrus> <1390477895.2607.39.camel@cirrus> <54F4F562.7060001@oracle.com> <1425377174.3315.42.camel@oracle.com> Message-ID: <54F5EB93.5050005@oracle.com> Looks good, nice solution with the MAX2 instead of 0 check. //Staffan On 03/03/2015 02:06 AM, Thomas Schatzl wrote: > Hi Staffan, > > On Mon, 2015-03-02 at 15:42 -0800, Staffan Friberg wrote: >> Found this old thread lying around. >> >> How about the following patch? >> >> Checking the calculate_young_list_desired_min_length which simply just >> adds the base_min_length I think changing the base_min_length to contain >> more than survivors might increase the nursery size unexpectedly. This >> will keep the calculation the same, while still making sure we can't set >> the young size below what the it currently is. >> >> @@ -538,13 +538,13 @@ >> // This is how many young regions we already have (currently: the >> survivors). >> uint base_min_length = recorded_survivor_regions(); >> // This is the absolute minimum young length, which ensures that we >> - // can allocate one eden region in the worst-case. >> - uint absolute_min_length = base_min_length + 1; >> + // will at least have one eden region available in the young list. >> + // If we shrink the young list target it won't shrink below the >> current size. >> + uint eden_length = _g1->young_list()->length() - >> recorded_survivor_regions(); >> + uint absolute_min_length = base_min_length + (eden_length == 0) ? 1 : >> eden_length; >> uint desired_min_length = >> calculate_young_list_desired_min_length(base_min_length); >> - if (desired_min_length < absolute_min_length) { >> - desired_min_length = absolute_min_length; >> - } >> + desired_min_length = MAX2(desired_min_length, absolute_min_length); >> >> // Calculate the absolute and desired max bounds. > looks good; I applied some minor refactoring (the eden length > calculation moved to the YoungList class). If you are good with these > changes, I can sponsor it. > > Webrev: http://cr.openjdk.java.net/~tschatzl/8031538/webrev/ > > Thanks, > Thomas > > From volker.simonis at gmail.com Tue Mar 3 17:55:06 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 3 Mar 2015 18:55:06 +0100 Subject: RFR: 8074319: barrier_set_cast defined via friend injection In-Reply-To: <56FA376C-9C39-4ADF-BC06-FCA2356AB2A5@oracle.com> References: <28177A82-C2AC-4674-9831-D63CEEFCA5E2@oracle.com> <56FA376C-9C39-4ADF-BC06-FCA2356AB2A5@oracle.com> Message-ID: Hi Kim, I was looking at the same problem today because it also fails on AIX with xlC 12.1. I'm not one hundred percent sure but I currently more tend to say it is a compiler bug although I'll have to dive deeper into the C++ standard before I can give a qualified answer here. But your change looks good and it also works on AIX. So if you like, you can consider it reviewed. However, with your change "barrier_set_cast()" won't be an inline function any more which may have performance impacts (this is something you'll have to judge). I'd like to propose a similar change which keeps "barrier_set_cast()" as inline function and still works with Xcode5 and xlC 12 on AIX: diff -r 71f4ed3c627f src/share/vm/memory/barrierSet.hpp --- a/src/share/vm/memory/barrierSet.hpp Tue Mar 03 13:25:23 2015 +0000 +++ b/src/share/vm/memory/barrierSet.hpp Tue Mar 03 18:51:47 2015 +0100 @@ -32,6 +32,10 @@ // This class provides the interface between a barrier implementation and // the rest of the system. +class BarrierSet; +template +T* barrier_set_cast(BarrierSet* bs); + class BarrierSet: public CHeapObj { friend class VMStructs; public: Regards, Volker PS: I'm a little bit confused that this error hasn't been catched by JPRT because the OpenJDK Wiki (https://wiki.openjdk.java.net/display/Build/Supported+build+platforms) lists clang 5.1 as official build platform for MacOS X? On Tue, Mar 3, 2015 at 5:28 PM, Kim Barrett wrote: > On Mar 3, 2015, at 11:26 AM, Kim Barrett wrote: >> >> Please review this small change to the recently added barrier_set_cast >> (see https://bugs.openjdk.java.net/browse/JDK-8069016). The way that >> new function is being defined is unintentionally not standards >> conforming and should not compile, but all of our present official >> test platforms accept it anyway. The code is presently only known to >> fail with the more recent Xcode6. > > That should be Xcode5. Xcode4 is the present test platform. > From kim.barrett at oracle.com Tue Mar 3 19:52:29 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 Mar 2015 14:52:29 -0500 Subject: RFR: 8074319: barrier_set_cast defined via friend injection In-Reply-To: References: <28177A82-C2AC-4674-9831-D63CEEFCA5E2@oracle.com> <56FA376C-9C39-4ADF-BC06-FCA2356AB2A5@oracle.com> Message-ID: <8103520A-364D-4F63-A99F-C1389C1F5215@oracle.com> On Mar 3, 2015, at 12:55 PM, Volker Simonis wrote: > > I was looking at the same problem today because it also fails on AIX > with xlC 12.1. > > I'm not one hundred percent sure but I currently more tend to say it > is a compiler bug although I'll have to dive deeper into the C++ > standard before I can give a qualified answer here. The relevant standardese, from C++03 7.3.1.2, is If a friend declaration in a non-local class first declares a class or function (footnote 83: this implies that the name of the class or function is unqualified) the friend class or function is a member of the innermost enclosing namespace. The name of the friend is not found by simple name lookup until a matching declaration is provided in that namespace scope (either before or after the class declaration granting friendship). > But your change looks good and it also works on AIX. So if you like, > you can consider it reviewed. Thanks. > However, with your change "barrier_set_cast()" won't be an inline > function any more which may have performance impacts (this is > something you'll have to judge). The definition moved to namespace scope in the webrev I posted is declared inline. > I'd like to propose a similar change which keeps "barrier_set_cast()" > as inline function and still works with Xcode5 and xlC 12 on AIX: > > diff -r 71f4ed3c627f src/share/vm/memory/barrierSet.hpp > --- a/src/share/vm/memory/barrierSet.hpp Tue Mar 03 13:25:23 2015 +0000 > +++ b/src/share/vm/memory/barrierSet.hpp Tue Mar 03 18:51:47 2015 +0100 > @@ -32,6 +32,10 @@ > // This class provides the interface between a barrier implementation and > // the rest of the system. > > +class BarrierSet; > +template > +T* barrier_set_cast(BarrierSet* bs); > + > class BarrierSet: public CHeapObj { > friend class VMStructs; > public: This doesn?t have an inline storage class specifier. > PS: I'm a little bit confused that this error hasn't been catched by > JPRT because the OpenJDK Wiki > (https://wiki.openjdk.java.net/display/Build/Supported+build+platforms) > lists clang 5.1 as official build platform for MacOS X? Maybe the JPRT farm is still lagging? From jesper.wilhelmsson at oracle.com Tue Mar 3 22:47:48 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 03 Mar 2015 23:47:48 +0100 Subject: RFR: JDK-8057632 - Remove auxiliary code used to handle the generations array In-Reply-To: <2290FDCB-B09D-42E9-9480-89C6EC3F0BD1@oracle.com> References: <54F4AA70.5070003@oracle.com> <2290FDCB-B09D-42E9-9480-89C6EC3F0BD1@oracle.com> Message-ID: <54F63A14.8060404@oracle.com> Kim Barrett skrev den 3/3/15 09:30: > On Mar 2, 2015, at 1:22 PM, Jesper Wilhelmsson wrote: >> >> Hi, >> >> The generation array removal enabled several other cleanups. I have several changes in queue to perform these cleanups one at a time. >> >> In this change the methods next_gen(), prev_gen() and get_gen() are removed and calls are replaced with explicit calls to young_gen() and old_gen(). >> >> Please have a look. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8057632 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8057632/webrev.02/ >> >> Thanks! >> /Jesper > > Looks good. > > A couple of questions: > > ------------------------------------------------------------------------------ > src/share/vm/memory/defNewGeneration.cpp > > Maybe this will be part of the planned future cleanups, but I'll > mention it now, just in case. > > There are various places where _old_gen is assigned or tested for > NULL. This all seems rather odd; shouldn't there just be an > associated old generation that is recorded in _old_gen at construction > time or thereabouts, and be done with it? Yes, there is room for more improvements here :) I have added this to my list of future cleanups which is now up to nine separate cleanup changes after the generation array removal. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/vmStructs.cpp > Removed: > 533 nonstatic_field(DefNewGeneration, _next_gen, Generation*) \ > > Was it intentional to remove rather than rename to _old_gen here? > It was intentional. The field is not used in the SA code so it really doesn't matter if it is present in VM_STRUCTS or not. After consulting the SA expertise I was advised to rename the field instead to keep the VM_STRUCTS in sync with the code as much as possible. A new webrev is available. The _old_gen field in vmStructs.cpp is the only change from the last webrev: http://cr.openjdk.java.net/~jwilhelm/8057632/webrev.03/ For some reason though the webrev script thought that the files parNewGeneration.cpp/hpp are new in this webrev, so they don't have any old version here. I see nothing wrong in the hg diff or status of the repository... Anyway, there are no new changes in those files. Thanks, /Jesper From kim.barrett at oracle.com Tue Mar 3 23:01:18 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 Mar 2015 18:01:18 -0500 Subject: RFR: JDK-8057632 - Remove auxiliary code used to handle the generations array In-Reply-To: <54F63A14.8060404@oracle.com> References: <54F4AA70.5070003@oracle.com> <2290FDCB-B09D-42E9-9480-89C6EC3F0BD1@oracle.com> <54F63A14.8060404@oracle.com> Message-ID: On Mar 3, 2015, at 5:47 PM, Jesper Wilhelmsson wrote: > >> ------------------------------------------------------------------------------ >> src/share/vm/memory/defNewGeneration.cpp >> >> Maybe this will be part of the planned future cleanups, but I'll >> mention it now, just in case. >> >> There are various places where _old_gen is assigned or tested for >> NULL. This all seems rather odd; shouldn't there just be an >> associated old generation that is recorded in _old_gen at construction >> time or thereabouts, and be done with it? > > Yes, there is room for more improvements here :) > I have added this to my list of future cleanups which is now up to nine separate cleanup changes after the generation array removal. OK. >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/vmStructs.cpp >> Removed: >> 533 nonstatic_field(DefNewGeneration, _next_gen, Generation*) \ >> >> Was it intentional to remove rather than rename to _old_gen here? >> > > It was intentional. The field is not used in the SA code so it really doesn't matter if it is present in VM_STRUCTS or not. After consulting the SA expertise I was advised to rename the field instead to keep the VM_STRUCTS in sync with the code as much as possible. OK. > A new webrev is available. The _old_gen field in vmStructs.cpp is the only change from the last webrev: > > http://cr.openjdk.java.net/~jwilhelm/8057632/webrev.03/ > > For some reason though the webrev script thought that the files parNewGeneration.cpp/hpp are new in this webrev, so they don't have any old version here. I see nothing wrong in the hg diff or status of the repository... > Anyway, there are no new changes in those files. Your?s is the second review I?ve seen in the last couple of days that had this sort of problem. New webrev script with a bug? Looks good. From kim.barrett at oracle.com Tue Mar 3 23:03:38 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 Mar 2015 18:03:38 -0500 Subject: RFR: 8074319: barrier_set_cast defined via friend injection In-Reply-To: <54F5E357.4000504@oracle.com> References: <28177A82-C2AC-4674-9831-D63CEEFCA5E2@oracle.com> <54F5E357.4000504@oracle.com> Message-ID: <179F9AB1-CE1F-42BD-9F70-35095AE7C45A@oracle.com> On Mar 3, 2015, at 11:37 AM, Jesper Wilhelmsson wrote: > > Thanks for fixing this! I'm not fluid in C++ templates, but it looks good to me. I have verified that it builds fine with Xcode 5 using your patch. Thanks for your review, and for testing it on a platform I don?t know how to drive. And thanks for your offer of sponsorship. From kim.barrett at oracle.com Tue Mar 3 23:05:06 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 Mar 2015 18:05:06 -0500 Subject: RFR: 8074319: barrier_set_cast defined via friend injection In-Reply-To: References: <28177A82-C2AC-4674-9831-D63CEEFCA5E2@oracle.com> <56FA376C-9C39-4ADF-BC06-FCA2356AB2A5@oracle.com> Message-ID: <1643B642-DAE1-4565-A0BE-2524E798C776@oracle.com> On Mar 3, 2015, at 12:55 PM, Volker Simonis wrote: > > I was looking at the same problem today because it also fails on AIX > with xlC 12.1. > > I'm not one hundred percent sure but I currently more tend to say it > is a compiler bug although I'll have to dive deeper into the C++ > standard before I can give a qualified answer here. > > But your change looks good and it also works on AIX. So if you like, > you can consider it reviewed. Thanks for your review, and for test results for a platform I don?t know how to access. From jesper.wilhelmsson at oracle.com Tue Mar 3 23:19:01 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 4 Mar 2015 00:19:01 +0100 Subject: RFR: JDK-8057632 - Remove auxiliary code used to handle the generations array In-Reply-To: References: <54F4AA70.5070003@oracle.com> <2290FDCB-B09D-42E9-9480-89C6EC3F0BD1@oracle.com> <54F63A14.8060404@oracle.com> Message-ID: Thanks Kim, There have not been any changes to the webrev script lately. Maybe some more OSX tool that has weird limitations like the awk "feature" I ran into in the previous change.... /Jesper > 4 mar 2015 kl. 00:01 skrev Kim Barrett : > >> On Mar 3, 2015, at 5:47 PM, Jesper Wilhelmsson wrote: >> >>> ------------------------------------------------------------------------------ >>> src/share/vm/memory/defNewGeneration.cpp >>> >>> Maybe this will be part of the planned future cleanups, but I'll >>> mention it now, just in case. >>> >>> There are various places where _old_gen is assigned or tested for >>> NULL. This all seems rather odd; shouldn't there just be an >>> associated old generation that is recorded in _old_gen at construction >>> time or thereabouts, and be done with it? >> >> Yes, there is room for more improvements here :) >> I have added this to my list of future cleanups which is now up to nine separate cleanup changes after the generation array removal. > > OK. > >>> ------------------------------------------------------------------------------ >>> src/share/vm/runtime/vmStructs.cpp >>> Removed: >>> 533 nonstatic_field(DefNewGeneration, _next_gen, Generation*) \ >>> >>> Was it intentional to remove rather than rename to _old_gen here? >>> >> >> It was intentional. The field is not used in the SA code so it really doesn't matter if it is present in VM_STRUCTS or not. After consulting the SA expertise I was advised to rename the field instead to keep the VM_STRUCTS in sync with the code as much as possible. > > OK. > >> A new webrev is available. The _old_gen field in vmStructs.cpp is the only change from the last webrev: >> >> http://cr.openjdk.java.net/~jwilhelm/8057632/webrev.03/ >> >> For some reason though the webrev script thought that the files parNewGeneration.cpp/hpp are new in this webrev, so they don't have any old version here. I see nothing wrong in the hg diff or status of the repository... >> Anyway, there are no new changes in those files. > > Your?s is the second review I?ve seen in the last couple of days that had this sort of problem. New webrev script with a bug? > > Looks good. > From dmitry.fazunenko at oracle.com Wed Mar 4 08:00:12 2015 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 04 Mar 2015 11:00:12 +0300 Subject: RFR(XS): JDK-8071335 - gc/TestSmallHeap.java throw OOM In-Reply-To: <54F5596A.9040508@oracle.com> References: <54F4C42F.60302@oracle.com> <54F5596A.9040508@oracle.com> Message-ID: <54F6BB8C.5090502@oracle.com> Hi Bengt, On 03.03.2015 09:49, Bengt Rutisson wrote: > > Hi Jesper, > > On 2015-03-02 21:12, Jesper Wilhelmsson wrote: >> Hi, >> >> Please review this small change. >> >> The test TestSmallHeap.java is designed to make sure we can run a >> tiny application in 2MB of heap (according to the documentation this >> should work). Unfortunately when adding a specific set of flags we >> get an OOME. (For details see the bug.) >> >> The conclusion in the bug is to not run the test with -Xcomp. This >> change fixes that. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8071335 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8071335/webrev.00/ > > This seems to be the first use of vm.compMode in any test. Have you > verified that it works in the expected way? > > I found an odd comment in the JTreg documentation about @requires. It > says: > > "The @requires tag may be used at most once in a given test." > > http://openjdk.java.net/jtreg/tag-spec.html#DECLARATIVE_TAGS I've checked with Jon Gibbons that today, he said this is a documentation bug, he will fix it. So multiple @requires are ok. Thanks, Dima > > > I doubt that this is correct since we already have tests with multiple > @requires tags (even this test already has it). But it might be worth > verifying the new @requires statement actually has an effect. > > If it works as expected I think this change looks reasonable. > > Thanks, > Bengt > >> Thanks, >> /Jesper > From thomas.schatzl at oracle.com Wed Mar 4 08:26:13 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 04 Mar 2015 09:26:13 +0100 Subject: RFR: 8074319: barrier_set_cast defined via friend injection In-Reply-To: <28177A82-C2AC-4674-9831-D63CEEFCA5E2@oracle.com> References: <28177A82-C2AC-4674-9831-D63CEEFCA5E2@oracle.com> Message-ID: <1425457573.3305.0.camel@oracle.com> Hi, On Tue, 2015-03-03 at 11:26 -0500, Kim Barrett wrote: > Please review this small change to the recently added barrier_set_cast > (see https://bugs.openjdk.java.net/browse/JDK-8069016). The way that > new function is being defined is unintentionally not standards > conforming and should not compile, but all of our present official > test platforms accept it anyway. The code is presently only known to > fail with the more recent Xcode6. > > I will need a sponsor for this change. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8074319 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8074319/webrev.00/ the change looks good to me. Thanks, Thomas From bengt.rutisson at oracle.com Wed Mar 4 08:26:40 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 04 Mar 2015 09:26:40 +0100 Subject: RFR(XS): JDK-8071335 - gc/TestSmallHeap.java throw OOM In-Reply-To: <54F6BB8C.5090502@oracle.com> References: <54F4C42F.60302@oracle.com> <54F5596A.9040508@oracle.com> <54F6BB8C.5090502@oracle.com> Message-ID: <54F6C1C0.8090303@oracle.com> Hi Dima, On 2015-03-04 09:00, Dmitry Fazunenko wrote: > Hi Bengt, > > > On 03.03.2015 09:49, Bengt Rutisson wrote: >> >> Hi Jesper, >> >> On 2015-03-02 21:12, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> Please review this small change. >>> >>> The test TestSmallHeap.java is designed to make sure we can run a >>> tiny application in 2MB of heap (according to the documentation this >>> should work). Unfortunately when adding a specific set of flags we >>> get an OOME. (For details see the bug.) >>> >>> The conclusion in the bug is to not run the test with -Xcomp. This >>> change fixes that. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071335 >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8071335/webrev.00/ >> >> This seems to be the first use of vm.compMode in any test. Have you >> verified that it works in the expected way? >> >> I found an odd comment in the JTreg documentation about @requires. It >> says: >> >> "The @requires tag may be used at most once in a given test." >> >> http://openjdk.java.net/jtreg/tag-spec.html#DECLARATIVE_TAGS > > I've checked with Jon Gibbons that today, he said this is a > documentation bug, he will fix it. > > So multiple @requires are ok. Thanks for following this up, Dima! Bengt > > Thanks, > Dima > >> >> >> I doubt that this is correct since we already have tests with >> multiple @requires tags (even this test already has it). But it might >> be worth verifying the new @requires statement actually has an effect. >> >> If it works as expected I think this change looks reasonable. >> >> Thanks, >> Bengt >> >>> Thanks, >>> /Jesper >> > From volker.simonis at gmail.com Wed Mar 4 08:34:39 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 4 Mar 2015 09:34:39 +0100 Subject: RFR: 8074319: barrier_set_cast defined via friend injection In-Reply-To: <8103520A-364D-4F63-A99F-C1389C1F5215@oracle.com> References: <28177A82-C2AC-4674-9831-D63CEEFCA5E2@oracle.com> <56FA376C-9C39-4ADF-BC06-FCA2356AB2A5@oracle.com> <8103520A-364D-4F63-A99F-C1389C1F5215@oracle.com> Message-ID: On Tue, Mar 3, 2015 at 8:52 PM, Kim Barrett wrote: > On Mar 3, 2015, at 12:55 PM, Volker Simonis wrote: >> >> I was looking at the same problem today because it also fails on AIX >> with xlC 12.1. >> >> I'm not one hundred percent sure but I currently more tend to say it >> is a compiler bug although I'll have to dive deeper into the C++ >> standard before I can give a qualified answer here. > > The relevant standardese, from C++03 7.3.1.2, is > > If a friend declaration in a non-local class first declares > a class or function (footnote 83: this implies that the name of the > class or function is unqualified) the friend class or function is a > member of the innermost enclosing namespace. The name of the friend > is not found by simple name lookup until a matching declaration is > provided in that namespace scope (either before or after the class > declaration granting friendship). > Thanks for providing the reference. That makes it pretty clear. >> But your change looks good and it also works on AIX. So if you like, >> you can consider it reviewed. > > Thanks. > >> However, with your change "barrier_set_cast()" won't be an inline >> function any more which may have performance impacts (this is >> something you'll have to judge). > > The definition moved to namespace scope in the webrev I posted is > declared inline. > Sorry, I've overlooked that. That makes your change even better :) Thanks again for fixing, Volker >> I'd like to propose a similar change which keeps "barrier_set_cast()" >> as inline function and still works with Xcode5 and xlC 12 on AIX: >> >> diff -r 71f4ed3c627f src/share/vm/memory/barrierSet.hpp >> --- a/src/share/vm/memory/barrierSet.hpp Tue Mar 03 13:25:23 2015 +0000 >> +++ b/src/share/vm/memory/barrierSet.hpp Tue Mar 03 18:51:47 2015 +0100 >> @@ -32,6 +32,10 @@ >> // This class provides the interface between a barrier implementation and >> // the rest of the system. >> >> +class BarrierSet; >> +template >> +T* barrier_set_cast(BarrierSet* bs); >> + >> class BarrierSet: public CHeapObj { >> friend class VMStructs; >> public: > > This doesn?t have an inline storage class specifier. > >> PS: I'm a little bit confused that this error hasn't been catched by >> JPRT because the OpenJDK Wiki >> (https://wiki.openjdk.java.net/display/Build/Supported+build+platforms) >> lists clang 5.1 as official build platform for MacOS X? > > Maybe the JPRT farm is still lagging? > From bengt.rutisson at oracle.com Wed Mar 4 08:42:33 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 04 Mar 2015 09:42:33 +0100 Subject: RFR: 8026047: [TESTBUG] add regression test for DisableExplicitGC flag In-Reply-To: <54F5D41C.3080009@oracle.com> References: <54C7B051.8050808@oracle.com> <54C90036.8030506@oracle.com> <54CBA45D.8090503@oracle.com> <54D10193.3060407@oracle.com> <54D3B107.9050901@oracle.com> <54DB512A.7070003@oracle.com> <54DB55E9.2080302@oracle.com> <54DB7667.3020107@oracle.com> <54DCB396.2080807@oracle.com> <54EDC32B.7020605@oracle.com> <54F56A96.20702@oracle.com> <54F5D41C.3080009@oracle.com> Message-ID: <54F6C579.9020500@oracle.com> Hi Michail, On 2015-03-03 16:32, Michail Chernov wrote: > Hi Bengt, > > I checked run time of test on raspberry-pi and on some solaris host > with -Xcomp option. On r-pi it works 2.8 seconds, on solaris host it > works 3.5 seconds. I can set NOTIFICATION_DELAY=5 (for example) to > speed up the test. This sounds like a pretty fragile approach. My opinion is that we should always avoid tests that wait a certain amount of time for things to happen. They almost always turn out to be unstable or take unnecessarily long time. > Your approach has some cons - it does not check that System.gc() was > real GC source. Agreed. But since we actually don't have any problems with the DisbableExplicitGC flag I don't think it is worth adding a test that is potentially unstable and complex to test it. If we feel that we really need to test this flag I think the test must be simple and fast. > In case if we don't check source of GC events, we can simplify test > more and avoid usage of JMX: > > import java.lang.ref.WeakReference; > > public class Test{ > public static volatile WeakReference ref; > public static Object refObject; > public static void main(String[] args) { > ref=new WeakReference<>(new Object()); > refObject=ref.get(); > if ( refObject==null) > throw new RuntimeException("ERROR! Object was collected > before GC"); > refObject=null; > System.gc(); > refObject=ref.get(); > if ( refObject!=null) > throw new RuntimeException("ERROR! Object was not > collected during GC"); > } > } > > However, this solution does not check the real cause of GC. If this > way is applicable here, I could use this code for testing > DisableExplicitGC flag. Sure, this will probably work, but I think it is kind of a strange way to check this. I prefer a more explicit way of testing. Thanks, Bengt > > Thanks, > Michail > > On 03.03.2015 11:02, Bengt Rutisson wrote: >> >> Hi Michail, >> >> I like the idea of using the GarbageCollectionMXBean! >> >> However, I am not too happy about the test waiting for 20 seconds. >> Especially since you have the failing test which will actually wait >> for 20 seconds. >> >> Instead I would suggest to just use the collection count. Attaching a >> version of the test that use that instead. What do you think about >> this approach? >> >> Thanks, >> Bengt >> >> >> >> On 2015-02-25 13:42, Michail Chernov wrote: >>> Hi Bengt, >>> >>> I've rewritten test using JMX. I don't see here any reason to use gc >>> log for testing this flag. >>> >>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.02/ >>> >>> It seems better solution because it doesn't depend on used GC or log >>> message format. >>> >>> Tested locally with JDK 9 b51 using several GC. Tested using Aurora >>> on all platforms. >>> >>> Thanks, >>> Michail >>> >>> On 12.02.2015 17:07, Bengt Rutisson wrote: >>>> >>>> Hi Michail, >>>> >>>> On 11/02/15 16:33, Michail Chernov wrote: >>>>> Hi Bengt, >>>>> >>>>> Test works with all options passed to jtreg during testing ( see >>>>> line 97 vmOpts.addAll(0, Utils.getVmOptions());). Doesn't >>>>> need to check all GC's, it will be done during nightly. >>>> >>>> Ah. I see that now. >>>> >>>>> >>>>> 44 public final static String[] PARALLEL_GC_OPTIONS = >>>>> {"UseParallelGC", "UseParallelOldGC"}; >>>>> Here is defined special options. If define one of these options - >>>>> will be used other pattern to match output. >>>> >>>> Right. >>>> >>>>> >>>>> But it seems to me a little bit wrong. I've checked output of GC >>>>> log with different GCs and ExplicitGCInvokesConcurrent. Message >>>>> "Full GC (System.gc())" does not appear only in case of using G1 >>>>> or CMS with ExplicitGCInvokesConcurrent=true. Will fix it. >>>> >>>> OK. >>>> >>>> My main point was that I think the whole structure of the test is >>>> different than how we usually write tests that verify the log >>>> output. I would prefer if the tests look similar. Would you mind >>>> re-writing the test to look like the other tests. >>>> >>>> I much prefer that you explicitly start with the GCs you want to >>>> test than that you use the WhiteBox API to find out which GC you >>>> are running. >>>> >>>> I'm having a similar discussion with Dima who recently invented yet >>>> another way to parse the GC log output from tests. I think it gets >>>> very hard to read the tests when they do the same thing in >>>> different ways. >>>> >>>> Thanks, >>>> Bengt >>>>> >>>>> Thanks, >>>>> Michail >>>>> On 11.02.2015 16:15, Bengt Rutisson wrote: >>>>>> >>>>>> Hi Michail, >>>>>> >>>>>> On 11/02/15 13:55, Michail Chernov wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Still hoping for review! >>>>>> >>>>>> Sorry for being so late in looking at this. >>>>>> >>>>>> A couple of questions: >>>>>> >>>>>> Why does the test only test the parallel GC? DisableExplicitGC is >>>>>> valid for all GCs. >>>>>> >>>>>> What do you think about writing this test similar to other tests >>>>>> that validate the output from the GC logging? Here's an example: >>>>>> >>>>>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/file/566574421b40/test/gc/g1/TestGCLogMessages.java >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Michail >>>>>>> >>>>>>> On 05.02.2015 21:05, Michail Chernov wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Still waiting for reviews! >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Michail >>>>>>>> >>>>>>>> On 03.02.2015 20:12, Michail Chernov wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Can someone take a look on these changes, please? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Michail >>>>>>>>> >>>>>>>>> On 30.01.2015 18:33, Michail Chernov wrote: >>>>>>>>>> Hi Leonid, >>>>>>>>>> >>>>>>>>>> Issues were fixed: >>>>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Now all testcases are executed from the same VM. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Michail >>>>>>>>>> >>>>>>>>>> On 28.01.2015 18:28, Leonid Mesnik wrote: >>>>>>>>>>> Hi >>>>>>>>>>> >>>>>>>>>>> Why is it needed to start VM twice for each test. It is very >>>>>>>>>>> expensive especially for low-end devices. >>>>>>>>>>> >>>>>>>>>>> Is it possible to have driver which starts VM several times >>>>>>>>>>> with different combinations of options and check it >>>>>>>>>>> output/exit code etc? Also it would be much easier to read >>>>>>>>>>> such test. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Leonid >>>>>>>>>>> >>>>>>>>>>> On 27.01.2015 18:35, Michail Chernov wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Please review the fix with new test for DisableExplicitGC >>>>>>>>>>>> VM flag. >>>>>>>>>>>> >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8026047 >>>>>>>>>>>> >>>>>>>>>>>> There is one scenario with 6 parameters combinations. >>>>>>>>>>>> >>>>>>>>>>>> 1,2,3 scenarios test default value for DisableExplicitGC, >>>>>>>>>>>> DisableExplicitGC=true and DisableExplicitGC=false >>>>>>>>>>>> 4,5,6 scenarios check how VM works when VM changes >>>>>>>>>>>> DisableExplicitGC flag using WhiteBox. >>>>>>>>>>>> >>>>>>>>>>>> Test tries to call System.gc() and check that VM puts >>>>>>>>>>>> message to stdout. After (in case of 4,5,6 scenarios) test >>>>>>>>>>>> tries to change DisableExplicitGC value and calls >>>>>>>>>>>> System.gc() twice. >>>>>>>>>>>> >>>>>>>>>>>> Test was executed locally on linux-i586 with all available >>>>>>>>>>>> GC and several GC-related flags. Also it was executed using >>>>>>>>>>>> Aurora on other platforms. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Michail >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> > From david.lindholm at oracle.com Wed Mar 4 12:48:15 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Wed, 04 Mar 2015 13:48:15 +0100 Subject: RFR: 8073545 - Use shorter and more descriptive names for GC worker threads Message-ID: <54F6FF0F.3030609@oracle.com> Hi, Please review this small fix which changes the names of the GC threads to be shorter and more descriptive. There is a limit on 16 characters including the terminating null byte for this name, since pthread_set_name_np() is used. This change will make it easier to debug, as these names shows up in the debugger. Webrev: http://cr.openjdk.java.net/~brutisso/8073545/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8073545 Testing: Passed JPRT. Regards, David From jesper.wilhelmsson at oracle.com Wed Mar 4 13:52:29 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 04 Mar 2015 14:52:29 +0100 Subject: RFR: 8073545 - Use shorter and more descriptive names for GC worker threads In-Reply-To: <54F6FF0F.3030609@oracle.com> References: <54F6FF0F.3030609@oracle.com> Message-ID: <54F70E1D.7030101@oracle.com> Hi David, Thanks for fixing this! A couple of questions: - set_name("G1 Concurrent Refinement Thread#%d", worker_id); + set_name("G1 ConRefine#%d", worker_id); Is there any refinement threads that are not concurrent? If not, could we just call this "G1 Refine#%d" to simplify it slightly and remove an implementation detail that doesn't need to be exposed? This would also leave room for three digit numbers in case we have lots of these threads on some systems. - _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking Threads", + _parallel_workers = new FlexibleWorkGang("G1 Markers", Markers is cute, but could be misunderstood. Can we call it "G1 Mark Threads" instead? - set_name("G1 Main Concurrent Mark GC Thread"); + set_name("G1 Main Marker"); Again, "Marker" could be misunderstood. I don't have a good replacement though. - set_name("GC task thread#%d (ParallelGC)", which); + set_name("ParGC Thread#%d", which); I don't have a good suggestion for how to make this one character shorter, but currently there is only room for two digit numbers. Maybe just "GC Thread#%d". I don't think these threads will exist at the same time as any other GC threads anyway. - set_name("Gang worker#%d (%s)", id, gang->name()); + set_name("%s#%d", gang->name(), id); Is there any limitation on the length of the name()? If it's too long the number won't show. Can we add an assert to make sure it isn't too long? Thanks, /Jesper David Lindholm skrev den 4/3/15 13:48: > Hi, > > Please review this small fix which changes the names of the GC threads to be > shorter and more descriptive. There is a limit on 16 characters including the > terminating null byte for this name, since pthread_set_name_np() is used. This > change will make it easier to debug, as these names shows up in the debugger. > > Webrev: http://cr.openjdk.java.net/~brutisso/8073545/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8073545 > > Testing: Passed JPRT. > > > Regards, > David From david.lindholm at oracle.com Wed Mar 4 14:11:39 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Wed, 04 Mar 2015 15:11:39 +0100 Subject: RFR: 8073545 - Use shorter and more descriptive names for GC worker threads In-Reply-To: <54F70E1D.7030101@oracle.com> References: <54F6FF0F.3030609@oracle.com> <54F70E1D.7030101@oracle.com> Message-ID: <54F7129B.8050009@oracle.com> Hi Jesper, On 2015-03-04 14:52, Jesper Wilhelmsson wrote: > Hi David, > > Thanks for fixing this! > > A couple of questions: > > - set_name("G1 Concurrent Refinement Thread#%d", worker_id); > + set_name("G1 ConRefine#%d", worker_id); > > Is there any refinement threads that are not concurrent? If not, could > we just call this "G1 Refine#%d" to simplify it slightly and remove an > implementation detail that doesn't need to be exposed? This would also > leave room for three digit numbers in case we have lots of these > threads on some systems. I discussed this with Bengt, and his input was that Concurrent Refinement is a well known concept in G1. I have no real opinion here, I'm fine with both suggestions. > - _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking > Threads", > + _parallel_workers = new FlexibleWorkGang("G1 Markers", > > Markers is cute, but could be misunderstood. Can we call it "G1 Mark > Threads" instead? No, it is too long, the three last character with thread number won't fit (#xx). > - set_name("G1 Main Concurrent Mark GC Thread"); > + set_name("G1 Main Marker"); > > Again, "Marker" could be misunderstood. I don't have a good > replacement though. I'm open for suggestions, but I think "G1 Main Marker" works. > - set_name("GC task thread#%d (ParallelGC)", which); > + set_name("ParGC Thread#%d", which); > > I don't have a good suggestion for how to make this one character > shorter, but currently there is only room for two digit numbers. Maybe > just "GC Thread#%d". I don't think these threads will exist at the > same time as any other GC threads anyway. With your suggestion these threads would be called the same thing as the threads in sharedHeap. I think it is nice to quickly be able to see that these threads indeed belongs to the ParallelGC. > - set_name("Gang worker#%d (%s)", id, gang->name()); > + set_name("%s#%d", gang->name(), id); > > Is there any limitation on the length of the name()? If it's too long > the number won't show. Can we add an assert to make sure it isn't too > long? I have gone through our current GangWorkers, and they fit. If you want I can add an assert for <= 12 characters. OTOH it is not the end of the world if we don't see the whole number in the debugger. Thanks, David > > Thanks, > /Jesper > > > David Lindholm skrev den 4/3/15 13:48: >> Hi, >> >> Please review this small fix which changes the names of the GC >> threads to be >> shorter and more descriptive. There is a limit on 16 characters >> including the >> terminating null byte for this name, since pthread_set_name_np() is >> used. This >> change will make it easier to debug, as these names shows up in the >> debugger. >> >> Webrev: http://cr.openjdk.java.net/~brutisso/8073545/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8073545 >> >> Testing: Passed JPRT. >> >> >> Regards, >> David From jesper.wilhelmsson at oracle.com Wed Mar 4 14:25:12 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 04 Mar 2015 15:25:12 +0100 Subject: RFR: 8073545 - Use shorter and more descriptive names for GC worker threads In-Reply-To: <54F7129B.8050009@oracle.com> References: <54F6FF0F.3030609@oracle.com> <54F70E1D.7030101@oracle.com> <54F7129B.8050009@oracle.com> Message-ID: <54F715C8.2020409@oracle.com> Ok, I don't have a strong opinion. I just wanted to highlight these questions to make sure there was a conscious decision to go with what you suggests :) I do think we should try to fit three digit numbers in there though. The whole point of this change is to make the names more usable in the debugger. Thanks, /Jesper David Lindholm skrev den 4/3/15 15:11: > Hi Jesper, > > On 2015-03-04 14:52, Jesper Wilhelmsson wrote: >> Hi David, >> >> Thanks for fixing this! >> >> A couple of questions: >> >> - set_name("G1 Concurrent Refinement Thread#%d", worker_id); >> + set_name("G1 ConRefine#%d", worker_id); >> >> Is there any refinement threads that are not concurrent? If not, could we just >> call this "G1 Refine#%d" to simplify it slightly and remove an implementation >> detail that doesn't need to be exposed? This would also leave room for three >> digit numbers in case we have lots of these threads on some systems. > > I discussed this with Bengt, and his input was that Concurrent Refinement is a > well known concept in G1. I have no real opinion here, I'm fine with both > suggestions. > >> - _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking Threads", >> + _parallel_workers = new FlexibleWorkGang("G1 Markers", >> >> Markers is cute, but could be misunderstood. Can we call it "G1 Mark Threads" >> instead? > > No, it is too long, the three last character with thread number won't fit (#xx). > >> - set_name("G1 Main Concurrent Mark GC Thread"); >> + set_name("G1 Main Marker"); >> >> Again, "Marker" could be misunderstood. I don't have a good replacement though. > > I'm open for suggestions, but I think "G1 Main Marker" works. > >> - set_name("GC task thread#%d (ParallelGC)", which); >> + set_name("ParGC Thread#%d", which); >> >> I don't have a good suggestion for how to make this one character shorter, but >> currently there is only room for two digit numbers. Maybe just "GC Thread#%d". >> I don't think these threads will exist at the same time as any other GC >> threads anyway. > > With your suggestion these threads would be called the same thing as the threads > in sharedHeap. I think it is nice to quickly be able to see that these threads > indeed belongs to the ParallelGC. > >> - set_name("Gang worker#%d (%s)", id, gang->name()); >> + set_name("%s#%d", gang->name(), id); >> >> Is there any limitation on the length of the name()? If it's too long the >> number won't show. Can we add an assert to make sure it isn't too long? > > I have gone through our current GangWorkers, and they fit. If you want I can add > an assert for <= 12 characters. OTOH it is not the end of the world if we don't > see the whole number in the debugger. > > > Thanks, > David > >> >> Thanks, >> /Jesper >> >> >> David Lindholm skrev den 4/3/15 13:48: >>> Hi, >>> >>> Please review this small fix which changes the names of the GC threads to be >>> shorter and more descriptive. There is a limit on 16 characters including the >>> terminating null byte for this name, since pthread_set_name_np() is used. This >>> change will make it easier to debug, as these names shows up in the debugger. >>> >>> Webrev: http://cr.openjdk.java.net/~brutisso/8073545/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073545 >>> >>> Testing: Passed JPRT. >>> >>> >>> Regards, >>> David > From thomas.schatzl at oracle.com Wed Mar 4 15:28:24 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 04 Mar 2015 16:28:24 +0100 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp Message-ID: <1425482904.3305.27.camel@oracle.com> Hi all, can I have reviews for the following change that does some renamings in the allocation related class hierarchy, also adding a few lines of documentation. This change is intentionally limited to renames to keep it simple, in a subsequent patch there will be more cleanup changes, moving methods around. Also, if there is demand, I am open to rename the files to something different (suggestions?) in a follow-up change (to not confuse the webrev tool too much). CR: https://bugs.openjdk.java.net/browse/JDK-8073052 Webrev: http://cr.openjdk.java.net/~tschatzl/8073052/webrev.00/ Testing: jprt Thanks, Thomas From bengt.rutisson at oracle.com Wed Mar 4 15:24:23 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 04 Mar 2015 16:24:23 +0100 Subject: RFR: 8073545 - Use shorter and more descriptive names for GC worker threads In-Reply-To: <54F7129B.8050009@oracle.com> References: <54F6FF0F.3030609@oracle.com> <54F70E1D.7030101@oracle.com> <54F7129B.8050009@oracle.com> Message-ID: <54F723A7.6080008@oracle.com> Hi David and everyone, Naming is the most difficult part of computer science so I doubt that there is an easy answer here. Given that the names are for debugging I guess it is not too important exactly what the names are. More important is that they are unique. I also think that there is really no need to have "thread" in the name since it is pretty obvious that it is a thread. So, my suggestion would be to skip "thread" and to use CamelCase rather than using spaces to save some characters. I don't have strong opinions on this, but here's what I'd suggest: - _conc_workers = new YieldingFlexibleWorkGang("Parallel CMS Threads", + _conc_workers = new YieldingFlexibleWorkGang("CMS Threads", "CMSTask" - set_name("Concurrent Mark-Sweep GC Thread"); + set_name("CMS Main Thread"); "CMSMain" - set_name("G1 Concurrent Refinement Thread#%d", worker_id); + set_name("G1 ConRefine#%d", worker_id); "G1ConcRefine#%d" - _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking Threads", + _parallel_workers = new FlexibleWorkGang("G1 Markers" "G1MarkTask" - set_name("G1 Main Concurrent Mark GC Thread"); + set_name("G1 Main Marker"); "G1ConcMark" - set_name("String Deduplication Thread"); + set_name("StrDedup Thread"); "StringDedup" - set_name("GC task thread#%d (ParallelGC)", which); + set_name("ParGC Thread#%d", which); "ParGCTask" - _workers = new FlexibleWorkGang("Parallel GC Threads", ParallelGCThreads, + _workers = new FlexibleWorkGang("GC Threads", ParallelGCThreads, "GCParTask" Just my thoughts. And regarding having 3 characters left for the number in the thread name I don't know if that is too important. With the above suggestions this will be possible in most cases but not all. Personally I think that is good enough. Bengt On 2015-03-04 15:11, David Lindholm wrote: > Hi Jesper, > > On 2015-03-04 14:52, Jesper Wilhelmsson wrote: >> Hi David, >> >> Thanks for fixing this! >> >> A couple of questions: >> >> - set_name("G1 Concurrent Refinement Thread#%d", worker_id); >> + set_name("G1 ConRefine#%d", worker_id); >> >> Is there any refinement threads that are not concurrent? If not, >> could we just call this "G1 Refine#%d" to simplify it slightly and >> remove an implementation detail that doesn't need to be exposed? This >> would also leave room for three digit numbers in case we have lots of >> these threads on some systems. > > I discussed this with Bengt, and his input was that Concurrent > Refinement is a well known concept in G1. I have no real opinion here, > I'm fine with both suggestions. > >> - _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking >> Threads", >> + _parallel_workers = new FlexibleWorkGang("G1 Markers", >> >> Markers is cute, but could be misunderstood. Can we call it "G1 Mark >> Threads" instead? > > No, it is too long, the three last character with thread number won't > fit (#xx). > >> - set_name("G1 Main Concurrent Mark GC Thread"); >> + set_name("G1 Main Marker"); >> >> Again, "Marker" could be misunderstood. I don't have a good >> replacement though. > > I'm open for suggestions, but I think "G1 Main Marker" works. > >> - set_name("GC task thread#%d (ParallelGC)", which); >> + set_name("ParGC Thread#%d", which); >> >> I don't have a good suggestion for how to make this one character >> shorter, but currently there is only room for two digit numbers. >> Maybe just "GC Thread#%d". I don't think these threads will exist at >> the same time as any other GC threads anyway. > > With your suggestion these threads would be called the same thing as > the threads in sharedHeap. I think it is nice to quickly be able to > see that these threads indeed belongs to the ParallelGC. > >> - set_name("Gang worker#%d (%s)", id, gang->name()); >> + set_name("%s#%d", gang->name(), id); >> >> Is there any limitation on the length of the name()? If it's too long >> the number won't show. Can we add an assert to make sure it isn't too >> long? > > I have gone through our current GangWorkers, and they fit. If you want > I can add an assert for <= 12 characters. OTOH it is not the end of > the world if we don't see the whole number in the debugger. > > > Thanks, > David > >> >> Thanks, >> /Jesper >> >> >> David Lindholm skrev den 4/3/15 13:48: >>> Hi, >>> >>> Please review this small fix which changes the names of the GC >>> threads to be >>> shorter and more descriptive. There is a limit on 16 characters >>> including the >>> terminating null byte for this name, since pthread_set_name_np() is >>> used. This >>> change will make it easier to debug, as these names shows up in the >>> debugger. >>> >>> Webrev: http://cr.openjdk.java.net/~brutisso/8073545/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073545 >>> >>> Testing: Passed JPRT. >>> >>> >>> Regards, >>> David > From bengt.rutisson at oracle.com Wed Mar 4 15:04:34 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 04 Mar 2015 16:04:34 +0100 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: <54F5DCFA.8010900@oracle.com> References: <54F08F8A.7070901@oracle.com> <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> <54F41E05.2090905@oracle.com> <54F48C84.3060602@oracle.com> <54F5DCFA.8010900@oracle.com> Message-ID: <54F71F02.3030309@oracle.com> Hi again, Yet another update to this webrev. I realized that I can move the WorkerDataArray class from the hpp file to the cpp file. I think that's worth doing to show that it is just in internal class. Also, I renamed the GCPhase* enums and variables to GCParPhase* to make it possible to use the GCPhase* names for a possible future extension to store the "single time phases" in something similar to the _gc_phases array. Here's an updated webrev: http://cr.openjdk.java.net/~brutisso/8074037/webrev.03/ And here's the diff compared to the last one: http://cr.openjdk.java.net/~brutisso/8074037/webrev.02-03.diff/ Thanks, Bengt On 2015-03-03 17:10, Bengt Rutisson wrote: > > Hi all, > > After some testing I noticed that I had done all my testing with > StringDedup enabled. The code did not work properly with it disabled > since StringDedup reported times for full GCs and concurrent marking > even though it was not logged anywhere. I changed the code to only > report times when the times will be reported as part of a GC. > > Here's an updated webrev: > http://cr.openjdk.java.net/~brutisso/8074037/webrev.02/ > > And a diff compared to the last review: > http://cr.openjdk.java.net/~brutisso/8074037/webrev.01-02.diff/ > > Thanks, > Bengt > > On 2015-03-02 17:15, Bengt Rutisson wrote: >> >> Hi again, >> >> Here is an updated webrev: >> http://cr.openjdk.java.net/~brutisso/8074037/webrev.01/ >> >> And here's the diff compared to the last webrev: >> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00-01.diff/ >> >> I tried to clean up the seconds vs. milliseconds confusion by making >> it G1GCPhaseTimes' responsibility to handle the conversion in all >> cases. So, the interface is now that times are reported in seconds >> (for example G1GCPhaseTimes::record_time_secs()) but returned in >> milliseconds (for example G1GCPhaseTimes::average_time_ms()). I >> suffixed the method names "_secs" and "_ms" to make it easier to >> follow the code. >> >> I'm not very happy about this inconsistency, but I want it to be an >> intermediate step on the way to getting rid of os::elapsedTime() >> completely. >> >> StefanK also suggested to move the logging code out to its own class. >> This simplified the logging quite a bit I think. The class, >> G1GCPhasePrinter, has to know a lot about both G1GCPhaseTimes and >> WorkerDataArray, but I still think it is nice to have the logging >> separated out. >> >> I didn't read Thomas' email with comments until after I had prepared >> this updated webrev. But I think I have addressed the issues brought >> up there. Thanks for looking at this, Thomas! >> >> Bengt >> >> On 2015-03-02 09:23, Bengt Rutisson wrote: >>> >>> Hi Kim, >>> >>> Thanks for looking at this! >>> >>> On 2015-02-28 00:43, Kim Barrett wrote: >>>> On Feb 27, 2015, at 10:38 AM, Bengt Rutisson >>>> wrote: >>>>> Can I have a couple of reviews for this cleanup change? >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8074037 >>>>> >>>>> [?] >>>>> The patch also introduces a new class called >>>>> G1GCPhaseTimesTracker, which is a scoped object to simplify time >>>>> measurements. I've also tried to move conversion of times down to >>>>> when we print the log messages instead of when we store them. This >>>>> removes several "* 1000.0" in the code. Eventually I would like to >>>>> replace os::elapsedTime() with os::elapsed_counter(). But that >>>>> should be done as a separate patch. >>>> Before I proceed any further with this review, I feel like I'm getting >>>> lost in unit changes. In some places values of msecs used to be used >>>> but now we're using secs, right? But it seems like there might be some >>>> confusion about that, and I'm not sure whether it's me or the code >>>> that's confused. >>>> >>>> For example: >>>> >>>> src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp >>>> 1079 cost_per_card_ms = >>>> phase_times()->average_time(G1GCPhaseTimes::UpdateRS) / (double) >>>> _pending_cards; >>>> 1080 _cost_per_card_ms_seq->add(cost_per_card_ms); >>>> >>>> I think the values that have been recorded in the phase_times are >>>> secs, and average_time appears to just use the values as is. So >>>> shouldn't that now be cost_per_card_secs? And the value added to >>>> _cost_per_card_ms_seq needs to be cost_per_card_secs * 1000.0? >>> >>> Right! Good catch! I was so happy to get rid of some of the "* >>> 1000.0" statements sprinkled all over the G1 code that I forgot to >>> add some of them back ;) >>> >>> I'll send out an updated webrev soon. >>> >>> Bengt >>> >>>> >>>> Oh how I wish for a units package! >>>> >>> >> > From jesper.wilhelmsson at oracle.com Wed Mar 4 15:44:51 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 04 Mar 2015 16:44:51 +0100 Subject: RFR: 8073545 - Use shorter and more descriptive names for GC worker threads In-Reply-To: <54F723A7.6080008@oracle.com> References: <54F6FF0F.3030609@oracle.com> <54F70E1D.7030101@oracle.com> <54F7129B.8050009@oracle.com> <54F723A7.6080008@oracle.com> Message-ID: <54F72873.9040403@oracle.com> Bengt, I'm fine with CamelCase and I agree that the word thread is unnecessary. There may be some confusion between GCParTask and ParGCTask, otherwise I think your suggestions are OK. /Jesper Bengt Rutisson skrev den 4/3/15 16:24: > > Hi David and everyone, > > Naming is the most difficult part of computer science so I doubt that there is > an easy answer here. Given that the names are for debugging I guess it is not > too important exactly what the names are. More important is that they are > unique. I also think that there is really no need to have "thread" in the name > since it is pretty obvious that it is a thread. > > So, my suggestion would be to skip "thread" and to use CamelCase rather than > using spaces to save some characters. > > I don't have strong opinions on this, but here's what I'd suggest: > > - _conc_workers = new YieldingFlexibleWorkGang("Parallel CMS Threads", > + _conc_workers = new YieldingFlexibleWorkGang("CMS Threads", > > "CMSTask" > > > > - set_name("Concurrent Mark-Sweep GC Thread"); > + set_name("CMS Main Thread"); > > "CMSMain" > > > > - set_name("G1 Concurrent Refinement Thread#%d", worker_id); > + set_name("G1 ConRefine#%d", worker_id); > > "G1ConcRefine#%d" > > > > - _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking Threads", > + _parallel_workers = new FlexibleWorkGang("G1 Markers" > > "G1MarkTask" > > > > - set_name("G1 Main Concurrent Mark GC Thread"); > + set_name("G1 Main Marker"); > > "G1ConcMark" > > > > - set_name("String Deduplication Thread"); > + set_name("StrDedup Thread"); > > "StringDedup" > > > > - set_name("GC task thread#%d (ParallelGC)", which); > + set_name("ParGC Thread#%d", which); > > "ParGCTask" > > > > - _workers = new FlexibleWorkGang("Parallel GC Threads", ParallelGCThreads, > + _workers = new FlexibleWorkGang("GC Threads", ParallelGCThreads, > > "GCParTask" > > > Just my thoughts. And regarding having 3 characters left for the number in the > thread name I don't know if that is too important. With the above suggestions > this will be possible in most cases but not all. Personally I think that is good > enough. > > Bengt > > > On 2015-03-04 15:11, David Lindholm wrote: >> Hi Jesper, >> >> On 2015-03-04 14:52, Jesper Wilhelmsson wrote: >>> Hi David, >>> >>> Thanks for fixing this! >>> >>> A couple of questions: >>> >>> - set_name("G1 Concurrent Refinement Thread#%d", worker_id); >>> + set_name("G1 ConRefine#%d", worker_id); >>> >>> Is there any refinement threads that are not concurrent? If not, could we >>> just call this "G1 Refine#%d" to simplify it slightly and remove an >>> implementation detail that doesn't need to be exposed? This would also leave >>> room for three digit numbers in case we have lots of these threads on some >>> systems. >> >> I discussed this with Bengt, and his input was that Concurrent Refinement is a >> well known concept in G1. I have no real opinion here, I'm fine with both >> suggestions. >> >>> - _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking Threads", >>> + _parallel_workers = new FlexibleWorkGang("G1 Markers", >>> >>> Markers is cute, but could be misunderstood. Can we call it "G1 Mark Threads" >>> instead? >> >> No, it is too long, the three last character with thread number won't fit (#xx). >> >>> - set_name("G1 Main Concurrent Mark GC Thread"); >>> + set_name("G1 Main Marker"); >>> >>> Again, "Marker" could be misunderstood. I don't have a good replacement though. >> >> I'm open for suggestions, but I think "G1 Main Marker" works. >> >>> - set_name("GC task thread#%d (ParallelGC)", which); >>> + set_name("ParGC Thread#%d", which); >>> >>> I don't have a good suggestion for how to make this one character shorter, >>> but currently there is only room for two digit numbers. Maybe just "GC >>> Thread#%d". I don't think these threads will exist at the same time as any >>> other GC threads anyway. >> >> With your suggestion these threads would be called the same thing as the >> threads in sharedHeap. I think it is nice to quickly be able to see that these >> threads indeed belongs to the ParallelGC. >> >>> - set_name("Gang worker#%d (%s)", id, gang->name()); >>> + set_name("%s#%d", gang->name(), id); >>> >>> Is there any limitation on the length of the name()? If it's too long the >>> number won't show. Can we add an assert to make sure it isn't too long? >> >> I have gone through our current GangWorkers, and they fit. If you want I can >> add an assert for <= 12 characters. OTOH it is not the end of the world if we >> don't see the whole number in the debugger. >> >> >> Thanks, >> David >> >>> >>> Thanks, >>> /Jesper >>> >>> >>> David Lindholm skrev den 4/3/15 13:48: >>>> Hi, >>>> >>>> Please review this small fix which changes the names of the GC threads to be >>>> shorter and more descriptive. There is a limit on 16 characters including the >>>> terminating null byte for this name, since pthread_set_name_np() is used. This >>>> change will make it easier to debug, as these names shows up in the debugger. >>>> >>>> Webrev: http://cr.openjdk.java.net/~brutisso/8073545/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073545 >>>> >>>> Testing: Passed JPRT. >>>> >>>> >>>> Regards, >>>> David >> > From erik.osterlund at lnu.se Wed Mar 4 22:16:17 2015 From: erik.osterlund at lnu.se (=?Windows-1252?Q?Erik_=D6sterlund?=) Date: Wed, 4 Mar 2015 22:16:17 +0000 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases References: <54F08F8A.7070901@oracle.com> <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> <54F41E05.2090905@oracle.com> <54F48C84.3060602@oracle.com> <54F5DCFA.8010900@oracle.com> <54F71F02.3030309@oracle.com> Message-ID: Hi Bengt, I see there are changes concerning time units and conversions, milliseconds vs seconds. This has bugged me too so thought I'd just add my opinion in this matter. Whenever dealing with a logical units such as time (seconds, milliseconds, etc) or size (words, bytes) that are mixed all over the place (sometimes for good reasons), I find it less error prone to let the type system help out automatically by annotating the types with their logical unit. As motivation, in this review there have been some human errors regarding time units, and this easily happens when conversions are manually performed. So personally I would have defined a Time type, letting time have both a physical type (e.g. double, float) AND a logical unit annotation (e.g. seconds, milliseconds) looking something like this: enum TimeUnit { nanoseconds = 1000000000, microseconds = 1000000, milliseconds = 1000, seconds = 1 }; template class Time { S _quantity; static inline S convert(const S quantity, TimeUnit from, TimeUnit to) { if (from == to) { return quantity; } else { return quantity * S(to) / S(from); } } public: Time(S quantity) : _quantity(quantity) {} template Time(Time other) : _quantity(convert(other.value(), U, T)) {} template Time operator =(Time other) { _quantity = convert(other.value(), U, T); } S value() const { return _quantity; } operator S() const { return value(); } Time operator +(Time other) const { return value() + other.value(); } Time operator -(Time other) const { return value() - other.value(); } }; ...and then with some convenient type aliases: typedef Time time_default_t; typedef Time time_secs_t; typedef Time time_millis_t; typedef Time time_micros_t; typedef Time time_nanos_t; ...you could do stuff like this: time_millis_t time_ms = 100.0; // value is 100.0 double time_prim_ms = time_ms; // value is 100.0 Time time_secs = time_ms; // value is 0.1f; automatically converts [milliseconds, double] to [seconds, float] time_default_t time_default = time_ms + time_secs; // value is 0.2; default unit is [seconds, double] ...and whenever there is a mismatch between time units that you send and the units expected in a function, it will automatically be converted to the appropriate expected type/unit. If you don't want to convert units automatically because you are scared of performance issues or something, then the type system can still at the very least help finding implicit conversions that you might want to eliminate automatically and reveal bugs related to such unit mismatches rapidly at compile time instead of after error prone manual verification. I don't know if this type of solution is interesting to you as maybe you want a single universal time unit to be used instead (such as seconds) in order to solve the problem, but thought I'd throw it out there anyway. Oh and even then I think it's clearer in a solution like this what the default time unit is supposed to be by just introspecting time_default_t instead of just "double". What do you think? Thanks, /Erik On 04/03/15 16:43, Bengt Rutisson wrote: > > Hi again, > > Yet another update to this webrev. I realized that I can move the > WorkerDataArray class from the hpp file to the cpp file. I think that's > worth doing to show that it is just in internal class. > > Also, I renamed the GCPhase* enums and variables to GCParPhase* to make > it possible to use the GCPhase* names for a possible future extension to > store the "single time phases" in something similar to the _gc_phases array. > > Here's an updated webrev: > http://cr.openjdk.java.net/~brutisso/8074037/webrev.03/ > > And here's the diff compared to the last one: > http://cr.openjdk.java.net/~brutisso/8074037/webrev.02-03.diff/ > > Thanks, > Bengt > > > On 2015-03-03 17:10, Bengt Rutisson wrote: >> >> Hi all, >> >> After some testing I noticed that I had done all my testing with >> StringDedup enabled. The code did not work properly with it disabled >> since StringDedup reported times for full GCs and concurrent marking >> even though it was not logged anywhere. I changed the code to only >> report times when the times will be reported as part of a GC. >> >> Here's an updated webrev: >> http://cr.openjdk.java.net/~brutisso/8074037/webrev.02/ >> >> And a diff compared to the last review: >> http://cr.openjdk.java.net/~brutisso/8074037/webrev.01-02.diff/ >> >> Thanks, >> Bengt >> >> On 2015-03-02 17:15, Bengt Rutisson wrote: >>> >>> Hi again, >>> >>> Here is an updated webrev: >>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.01/ >>> >>> And here's the diff compared to the last webrev: >>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00-01.diff/ >>> >>> I tried to clean up the seconds vs. milliseconds confusion by making >>> it G1GCPhaseTimes' responsibility to handle the conversion in all >>> cases. So, the interface is now that times are reported in seconds >>> (for example G1GCPhaseTimes::record_time_secs()) but returned in >>> milliseconds (for example G1GCPhaseTimes::average_time_ms()). I >>> suffixed the method names "_secs" and "_ms" to make it easier to >>> follow the code. >>> >>> I'm not very happy about this inconsistency, but I want it to be an >>> intermediate step on the way to getting rid of os::elapsedTime() >>> completely. >>> >>> StefanK also suggested to move the logging code out to its own class. >>> This simplified the logging quite a bit I think. The class, >>> G1GCPhasePrinter, has to know a lot about both G1GCPhaseTimes and >>> WorkerDataArray, but I still think it is nice to have the logging >>> separated out. >>> >>> I didn't read Thomas' email with comments until after I had prepared >>> this updated webrev. But I think I have addressed the issues brought >>> up there. Thanks for looking at this, Thomas! >>> >>> Bengt >>> >>> On 2015-03-02 09:23, Bengt Rutisson wrote: >>>> >>>> Hi Kim, >>>> >>>> Thanks for looking at this! >>>> >>>> On 2015-02-28 00:43, Kim Barrett wrote: >>>>> On Feb 27, 2015, at 10:38 AM, Bengt Rutisson >>>>> wrote: >>>>>> Can I have a couple of reviews for this cleanup change? >>>>>> >>>>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8074037 >>>>>> >>>>>> [?] >>>>>> The patch also introduces a new class called >>>>>> G1GCPhaseTimesTracker, which is a scoped object to simplify time >>>>>> measurements. I've also tried to move conversion of times down to >>>>>> when we print the log messages instead of when we store them. This >>>>>> removes several "* 1000.0" in the code. Eventually I would like to >>>>>> replace os::elapsedTime() with os::elapsed_counter(). But that >>>>>> should be done as a separate patch. >>>>> Before I proceed any further with this review, I feel like I'm getting >>>>> lost in unit changes. In some places values of msecs used to be used >>>>> but now we're using secs, right? But it seems like there might be some >>>>> confusion about that, and I'm not sure whether it's me or the code >>>>> that's confused. >>>>> >>>>> For example: >>>>> >>>>> src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp >>>>> 1079 cost_per_card_ms = >>>>> phase_times()->average_time(G1GCPhaseTimes::UpdateRS) / (double) >>>>> _pending_cards; >>>>> 1080 _cost_per_card_ms_seq->add(cost_per_card_ms); >>>>> >>>>> I think the values that have been recorded in the phase_times are >>>>> secs, and average_time appears to just use the values as is. So >>>>> shouldn't that now be cost_per_card_secs? And the value added to >>>>> _cost_per_card_ms_seq needs to be cost_per_card_secs * 1000.0? >>>> >>>> Right! Good catch! I was so happy to get rid of some of the "* >>>> 1000.0" statements sprinkled all over the G1 code that I forgot to >>>> add some of them back ;) >>>> >>>> I'll send out an updated webrev soon. >>>> >>>> Bengt >>>> >>>>> >>>>> Oh how I wish for a units package! >>>>> >>>> >>> >> > > From kirk at kodewerk.com Thu Mar 5 00:26:01 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 5 Mar 2015 00:26:01 +0000 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: References: <54F08F8A.7070901@oracle.com> <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> <54F41E05.2090905@oracle.com> <54F48C84.3060602@oracle.com> <54F5DCFA.8010900@oracle.com> <54F71F02.3030309@oracle.com> Message-ID: Hi Erik, In principle I agree that times should be unified. However I am concerned that we maintain backwards compatibility and only making changes to the current format if there is a compelling reason to do My reason for this is that making little piece mean changes here and there really complicates the downstream tool chain. If you were to make one big sweeping change that fixed this every where once and for all, I?d be happy to take the downstream hit. But doing this small bits at a time would be worse than fixing this particular ?problem?. Kind regards, Kirk Pepperdine On Mar 4, 2015, at 10:16 PM, Erik ?sterlund wrote: > Hi Bengt, > > I see there are changes concerning time units and conversions, milliseconds vs seconds. This has bugged me too so thought I'd just add my opinion in this matter. > > Whenever dealing with a logical units such as time (seconds, milliseconds, etc) or size (words, bytes) that are mixed all over the place (sometimes for good reasons), I find it less error prone to let the type system help out automatically by annotating the types with their logical unit. As motivation, in this review there have been some human errors regarding time units, and this easily happens when conversions are manually performed. > > So personally I would have defined a Time type, letting time have both a physical type (e.g. double, float) AND a logical unit annotation (e.g. seconds, milliseconds) looking something like this: > > enum TimeUnit { > nanoseconds = 1000000000, > microseconds = 1000000, > milliseconds = 1000, > seconds = 1 > }; > > template > class Time { > S _quantity; > > static inline S convert(const S quantity, TimeUnit from, TimeUnit to) { > if (from == to) { > return quantity; > } else { > return quantity * S(to) / S(from); > } > } > public: > Time(S quantity) : _quantity(quantity) {} > template > Time(Time other) : _quantity(convert(other.value(), U, T)) {} > template > Time operator =(Time other) { _quantity = convert(other.value(), U, T); } > > S value() const { return _quantity; } > operator S() const { return value(); } > Time operator +(Time other) const { return value() + other.value(); } > Time operator -(Time other) const { return value() - other.value(); } > }; > > ...and then with some convenient type aliases: > > typedef Time time_default_t; > typedef Time time_secs_t; > typedef Time time_millis_t; > typedef Time time_micros_t; > typedef Time time_nanos_t; > > ...you could do stuff like this: > > time_millis_t time_ms = 100.0; // value is 100.0 > double time_prim_ms = time_ms; // value is 100.0 > Time time_secs = time_ms; // value is 0.1f; automatically converts [milliseconds, double] to [seconds, float] > time_default_t time_default = time_ms + time_secs; // value is 0.2; default unit is [seconds, double] > > ...and whenever there is a mismatch between time units that you send and the units expected in a function, it will automatically be converted to the appropriate expected type/unit. If you don't want to convert units automatically because you are scared of performance issues or something, then the type system can still at the very least help finding implicit conversions that you might want to eliminate automatically and reveal bugs related to such unit mismatches rapidly at compile time instead of after error prone manual verification. > > I don't know if this type of solution is interesting to you as maybe you want a single universal time unit to be used instead (such as seconds) in order to solve the problem, but thought I'd throw it out there anyway. Oh and even then I think it's clearer in a solution like this what the default time unit is supposed to be by just introspecting time_default_t instead of just "double". What do you think? > > Thanks, > /Erik > > On 04/03/15 16:43, Bengt Rutisson wrote: >> >> Hi again, >> >> Yet another update to this webrev. I realized that I can move the >> WorkerDataArray class from the hpp file to the cpp file. I think that's >> worth doing to show that it is just in internal class. >> >> Also, I renamed the GCPhase* enums and variables to GCParPhase* to make >> it possible to use the GCPhase* names for a possible future extension to >> store the "single time phases" in something similar to the _gc_phases array. >> >> Here's an updated webrev: >> http://cr.openjdk.java.net/~brutisso/8074037/webrev.03/ >> >> And here's the diff compared to the last one: >> http://cr.openjdk.java.net/~brutisso/8074037/webrev.02-03.diff/ >> >> Thanks, >> Bengt >> >> >> On 2015-03-03 17:10, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> After some testing I noticed that I had done all my testing with >>> StringDedup enabled. The code did not work properly with it disabled >>> since StringDedup reported times for full GCs and concurrent marking >>> even though it was not logged anywhere. I changed the code to only >>> report times when the times will be reported as part of a GC. >>> >>> Here's an updated webrev: >>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.02/ >>> >>> And a diff compared to the last review: >>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.01-02.diff/ >>> >>> Thanks, >>> Bengt >>> >>> On 2015-03-02 17:15, Bengt Rutisson wrote: >>>> >>>> Hi again, >>>> >>>> Here is an updated webrev: >>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.01/ >>>> >>>> And here's the diff compared to the last webrev: >>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00-01.diff/ >>>> >>>> I tried to clean up the seconds vs. milliseconds confusion by making >>>> it G1GCPhaseTimes' responsibility to handle the conversion in all >>>> cases. So, the interface is now that times are reported in seconds >>>> (for example G1GCPhaseTimes::record_time_secs()) but returned in >>>> milliseconds (for example G1GCPhaseTimes::average_time_ms()). I >>>> suffixed the method names "_secs" and "_ms" to make it easier to >>>> follow the code. >>>> >>>> I'm not very happy about this inconsistency, but I want it to be an >>>> intermediate step on the way to getting rid of os::elapsedTime() >>>> completely. >>>> >>>> StefanK also suggested to move the logging code out to its own class. >>>> This simplified the logging quite a bit I think. The class, >>>> G1GCPhasePrinter, has to know a lot about both G1GCPhaseTimes and >>>> WorkerDataArray, but I still think it is nice to have the logging >>>> separated out. >>>> >>>> I didn't read Thomas' email with comments until after I had prepared >>>> this updated webrev. But I think I have addressed the issues brought >>>> up there. Thanks for looking at this, Thomas! >>>> >>>> Bengt >>>> >>>> On 2015-03-02 09:23, Bengt Rutisson wrote: >>>>> >>>>> Hi Kim, >>>>> >>>>> Thanks for looking at this! >>>>> >>>>> On 2015-02-28 00:43, Kim Barrett wrote: >>>>>> On Feb 27, 2015, at 10:38 AM, Bengt Rutisson >>>>>> wrote: >>>>>>> Can I have a couple of reviews for this cleanup change? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00/ >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8074037 >>>>>>> >>>>>>> [?] >>>>>>> The patch also introduces a new class called >>>>>>> G1GCPhaseTimesTracker, which is a scoped object to simplify time >>>>>>> measurements. I've also tried to move conversion of times down to >>>>>>> when we print the log messages instead of when we store them. This >>>>>>> removes several "* 1000.0" in the code. Eventually I would like to >>>>>>> replace os::elapsedTime() with os::elapsed_counter(). But that >>>>>>> should be done as a separate patch. >>>>>> Before I proceed any further with this review, I feel like I'm getting >>>>>> lost in unit changes. In some places values of msecs used to be used >>>>>> but now we're using secs, right? But it seems like there might be some >>>>>> confusion about that, and I'm not sure whether it's me or the code >>>>>> that's confused. >>>>>> >>>>>> For example: >>>>>> >>>>>> src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp >>>>>> 1079 cost_per_card_ms = >>>>>> phase_times()->average_time(G1GCPhaseTimes::UpdateRS) / (double) >>>>>> _pending_cards; >>>>>> 1080 _cost_per_card_ms_seq->add(cost_per_card_ms); >>>>>> >>>>>> I think the values that have been recorded in the phase_times are >>>>>> secs, and average_time appears to just use the values as is. So >>>>>> shouldn't that now be cost_per_card_secs? And the value added to >>>>>> _cost_per_card_ms_seq needs to be cost_per_card_secs * 1000.0? >>>>> >>>>> Right! Good catch! I was so happy to get rid of some of the "* >>>>> 1000.0" statements sprinkled all over the G1 code that I forgot to >>>>> add some of them back ;) >>>>> >>>>> I'll send out an updated webrev soon. >>>>> >>>>> Bengt >>>>> >>>>>> >>>>>> Oh how I wish for a units package! >>>>>> >>>>> >>>> >>> >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From vitalyd at gmail.com Thu Mar 5 00:49:09 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 4 Mar 2015 19:49:09 -0500 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: References: <54F08F8A.7070901@oracle.com> <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> <54F41E05.2090905@oracle.com> <54F48C84.3060602@oracle.com> <54F5DCFA.8010900@oracle.com> <54F71F02.3030309@oracle.com> Message-ID: Maybe I missed it but where's the backwards incompatibility in Erik's proposal? It seems like a call for some internal type refactoring, but unless someone changes the units of a value that's output to the GC log (e.g. secs to ms), I'm not seeing the issue. It seems like a generally good thing to do, but likely under a separate bug/CR. The only thing I'd add is you probably don't want implicit conversions here to avoid inadvertent unit change. My $.02 sent from my phone On Mar 4, 2015 7:26 PM, "Kirk Pepperdine" wrote: > Hi Erik, > > In principle I agree that times should be unified. However I am concerned > that we maintain backwards compatibility and only making changes to the > current format if there is a compelling reason to do My reason for this is > that making little piece mean changes here and there really complicates the > downstream tool chain. If you were to make one big sweeping change that > fixed this every where once and for all, I?d be happy to take the > downstream hit. But doing this small bits at a time would be worse than > fixing this particular ?problem?. > > Kind regards, > Kirk Pepperdine > > On Mar 4, 2015, at 10:16 PM, Erik ?sterlund wrote: > > > Hi Bengt, > > > > I see there are changes concerning time units and conversions, > milliseconds vs seconds. This has bugged me too so thought I'd just add my > opinion in this matter. > > > > Whenever dealing with a logical units such as time (seconds, > milliseconds, etc) or size (words, bytes) that are mixed all over the place > (sometimes for good reasons), I find it less error prone to let the type > system help out automatically by annotating the types with their logical > unit. As motivation, in this review there have been some human errors > regarding time units, and this easily happens when conversions are manually > performed. > > > > So personally I would have defined a Time type, letting time have both a > physical type (e.g. double, float) AND a logical unit annotation (e.g. > seconds, milliseconds) looking something like this: > > > > enum TimeUnit { > > nanoseconds = 1000000000, > > microseconds = 1000000, > > milliseconds = 1000, > > seconds = 1 > > }; > > > > template > > class Time { > > S _quantity; > > > > static inline S convert(const S quantity, TimeUnit from, TimeUnit to) { > > if (from == to) { > > return quantity; > > } else { > > return quantity * S(to) / S(from); > > } > > } > > public: > > Time(S quantity) : _quantity(quantity) {} > > template > > Time(Time other) : _quantity(convert(other.value(), U, T)) {} > > template > > Time operator =(Time other) { _quantity = > convert(other.value(), U, T); } > > > > S value() const { return _quantity; } > > operator S() const { return value(); } > > Time operator +(Time other) const { return value() + > other.value(); } > > Time operator -(Time other) const { return value() - > other.value(); } > > }; > > > > ...and then with some convenient type aliases: > > > > typedef Time time_default_t; > > typedef Time time_secs_t; > > typedef Time time_millis_t; > > typedef Time time_micros_t; > > typedef Time time_nanos_t; > > > > ...you could do stuff like this: > > > > time_millis_t time_ms = 100.0; // value is 100.0 > > double time_prim_ms = time_ms; // value is 100.0 > > Time time_secs = time_ms; // value is 0.1f; > automatically converts [milliseconds, double] to [seconds, float] > > time_default_t time_default = time_ms + time_secs; // value is 0.2; > default unit is [seconds, double] > > > > ...and whenever there is a mismatch between time units that you send and > the units expected in a function, it will automatically be converted to the > appropriate expected type/unit. If you don't want to convert units > automatically because you are scared of performance issues or something, > then the type system can still at the very least help finding implicit > conversions that you might want to eliminate automatically and reveal bugs > related to such unit mismatches rapidly at compile time instead of after > error prone manual verification. > > > > I don't know if this type of solution is interesting to you as maybe you > want a single universal time unit to be used instead (such as seconds) in > order to solve the problem, but thought I'd throw it out there anyway. Oh > and even then I think it's clearer in a solution like this what the default > time unit is supposed to be by just introspecting time_default_t instead of > just "double". What do you think? > > > > Thanks, > > /Erik > > > > On 04/03/15 16:43, Bengt Rutisson wrote: > >> > >> Hi again, > >> > >> Yet another update to this webrev. I realized that I can move the > >> WorkerDataArray class from the hpp file to the cpp file. I think that's > >> worth doing to show that it is just in internal class. > >> > >> Also, I renamed the GCPhase* enums and variables to GCParPhase* to make > >> it possible to use the GCPhase* names for a possible future extension to > >> store the "single time phases" in something similar to the _gc_phases > array. > >> > >> Here's an updated webrev: > >> http://cr.openjdk.java.net/~brutisso/8074037/webrev.03/ > >> > >> And here's the diff compared to the last one: > >> http://cr.openjdk.java.net/~brutisso/8074037/webrev.02-03.diff/ > >> > >> Thanks, > >> Bengt > >> > >> > >> On 2015-03-03 17:10, Bengt Rutisson wrote: > >>> > >>> Hi all, > >>> > >>> After some testing I noticed that I had done all my testing with > >>> StringDedup enabled. The code did not work properly with it disabled > >>> since StringDedup reported times for full GCs and concurrent marking > >>> even though it was not logged anywhere. I changed the code to only > >>> report times when the times will be reported as part of a GC. > >>> > >>> Here's an updated webrev: > >>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.02/ > >>> > >>> And a diff compared to the last review: > >>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.01-02.diff/ > >>> > >>> Thanks, > >>> Bengt > >>> > >>> On 2015-03-02 17:15, Bengt Rutisson wrote: > >>>> > >>>> Hi again, > >>>> > >>>> Here is an updated webrev: > >>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.01/ > >>>> > >>>> And here's the diff compared to the last webrev: > >>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00-01.diff/ > >>>> > >>>> I tried to clean up the seconds vs. milliseconds confusion by making > >>>> it G1GCPhaseTimes' responsibility to handle the conversion in all > >>>> cases. So, the interface is now that times are reported in seconds > >>>> (for example G1GCPhaseTimes::record_time_secs()) but returned in > >>>> milliseconds (for example G1GCPhaseTimes::average_time_ms()). I > >>>> suffixed the method names "_secs" and "_ms" to make it easier to > >>>> follow the code. > >>>> > >>>> I'm not very happy about this inconsistency, but I want it to be an > >>>> intermediate step on the way to getting rid of os::elapsedTime() > >>>> completely. > >>>> > >>>> StefanK also suggested to move the logging code out to its own class. > >>>> This simplified the logging quite a bit I think. The class, > >>>> G1GCPhasePrinter, has to know a lot about both G1GCPhaseTimes and > >>>> WorkerDataArray, but I still think it is nice to have the logging > >>>> separated out. > >>>> > >>>> I didn't read Thomas' email with comments until after I had prepared > >>>> this updated webrev. But I think I have addressed the issues brought > >>>> up there. Thanks for looking at this, Thomas! > >>>> > >>>> Bengt > >>>> > >>>> On 2015-03-02 09:23, Bengt Rutisson wrote: > >>>>> > >>>>> Hi Kim, > >>>>> > >>>>> Thanks for looking at this! > >>>>> > >>>>> On 2015-02-28 00:43, Kim Barrett wrote: > >>>>>> On Feb 27, 2015, at 10:38 AM, Bengt Rutisson > >>>>>> wrote: > >>>>>>> Can I have a couple of reviews for this cleanup change? > >>>>>>> > >>>>>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00/ > >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8074037 > >>>>>>> > >>>>>>> [?] > >>>>>>> The patch also introduces a new class called > >>>>>>> G1GCPhaseTimesTracker, which is a scoped object to simplify time > >>>>>>> measurements. I've also tried to move conversion of times down to > >>>>>>> when we print the log messages instead of when we store them. This > >>>>>>> removes several "* 1000.0" in the code. Eventually I would like to > >>>>>>> replace os::elapsedTime() with os::elapsed_counter(). But that > >>>>>>> should be done as a separate patch. > >>>>>> Before I proceed any further with this review, I feel like I'm > getting > >>>>>> lost in unit changes. In some places values of msecs used to be used > >>>>>> but now we're using secs, right? But it seems like there might be > some > >>>>>> confusion about that, and I'm not sure whether it's me or the code > >>>>>> that's confused. > >>>>>> > >>>>>> For example: > >>>>>> > >>>>>> src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp > >>>>>> 1079 cost_per_card_ms = > >>>>>> phase_times()->average_time(G1GCPhaseTimes::UpdateRS) / (double) > >>>>>> _pending_cards; > >>>>>> 1080 _cost_per_card_ms_seq->add(cost_per_card_ms); > >>>>>> > >>>>>> I think the values that have been recorded in the phase_times are > >>>>>> secs, and average_time appears to just use the values as is. So > >>>>>> shouldn't that now be cost_per_card_secs? And the value added to > >>>>>> _cost_per_card_ms_seq needs to be cost_per_card_secs * 1000.0? > >>>>> > >>>>> Right! Good catch! I was so happy to get rid of some of the "* > >>>>> 1000.0" statements sprinkled all over the G1 code that I forgot to > >>>>> add some of them back ;) > >>>>> > >>>>> I'll send out an updated webrev soon. > >>>>> > >>>>> Bengt > >>>>> > >>>>>> > >>>>>> Oh how I wish for a units package! > >>>>>> > >>>>> > >>>> > >>> > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.osterlund at lnu.se Thu Mar 5 09:14:39 2015 From: erik.osterlund at lnu.se (=?Windows-1252?Q?Erik_=D6sterlund?=) Date: Thu, 5 Mar 2015 09:14:39 +0000 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases References: <54F08F8A.7070901@oracle.com> <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> <54F41E05.2090905@oracle.com> <54F48C84.3060602@oracle.com> <54F5DCFA.8010900@oracle.com> <54F71F02.3030309@oracle.com> Message-ID: Hi Kirk, Thank you for the feedback. I share your concern making small fixes at a time in general. However, as pointed out by Vitaly, this would not be an issue here. Because instead of picking a single universal time unit to be used everywhere (such as seconds) which would cause such problems, my approach is having a single unified time /type/, for which the time unit is a configurable parameter. The type knows the difference between units and can convert them (implicitly or explicitly as we prefer). Introducing such a time type is both backward compatible in logged output presented to external tools and internally in code. I think this approach is better than picking a single universal time unit, stored in "double" without further type information embedded. Because there is often a good reason why time units exist in the first place and not a single one is used. Whatever champion time unit is picked, is likely to be be awkward in some situations. :) Currently different units are passed around as primitive values ignorant of time units, instead annotated with a postfix in parameter/variable names implicitly annotating which time unit is used, and comments documenting which time unit is returned from functions. All I propose really is to strengthen the type for times to embed this knowledge explicitly and check these assumptions for us at compile time to reduce errors and improve readability/maintainability. If this is not relevant to the current change, I should perhaps make a new thread if anyone is interested in such a change? Don't want to clutter this thread too much. Thought I'd check if others drink my kind of tea first. :) Thanks, Erik On 05/03/15 01:26, Kirk Pepperdine wrote: > Hi Erik, > > In principle I agree that times should be unified. However I am concerned that we maintain backwards compatibility and only making changes to the current format if there is a compelling reason to do My reason for this is that making little piece mean changes here and there really complicates the downstream tool chain. If you were to make one big sweeping change that fixed this every where once and for all, I?d be happy to take the downstream hit. But doing this small bits at a time would be worse than fixing this particular ?problem?. > > Kind regards, > Kirk Pepperdine > > On Mar 4, 2015, at 10:16 PM, Erik ?sterlund wrote: > >> Hi Bengt, >> >> I see there are changes concerning time units and conversions, milliseconds vs seconds. This has bugged me too so thought I'd just add my opinion in this matter. >> >> Whenever dealing with a logical units such as time (seconds, milliseconds, etc) or size (words, bytes) that are mixed all over the place (sometimes for good reasons), I find it less error prone to let the type system help out automatically by annotating the types with their logical unit. As motivation, in this review there have been some human errors regarding time units, and this easily happens when conversions are manually performed. >> >> So personally I would have defined a Time type, letting time have both a physical type (e.g. double, float) AND a logical unit annotation (e.g. seconds, milliseconds) looking something like this: >> >> enum TimeUnit { >> nanoseconds = 1000000000, >> microseconds = 1000000, >> milliseconds = 1000, >> seconds = 1 >> }; >> >> template >> class Time { >> S _quantity; >> >> static inline S convert(const S quantity, TimeUnit from, TimeUnit to) { >> if (from == to) { >> return quantity; >> } else { >> return quantity * S(to) / S(from); >> } >> } >> public: >> Time(S quantity) : _quantity(quantity) {} >> template >> Time(Time other) : _quantity(convert(other.value(), U, T)) {} >> template >> Time operator =(Time other) { _quantity = convert(other.value(), U, T); } >> >> S value() const { return _quantity; } >> operator S() const { return value(); } >> Time operator +(Time other) const { return value() + other.value(); } >> Time operator -(Time other) const { return value() - other.value(); } >> }; >> >> ...and then with some convenient type aliases: >> >> typedef Time time_default_t; >> typedef Time time_secs_t; >> typedef Time time_millis_t; >> typedef Time time_micros_t; >> typedef Time time_nanos_t; >> >> ...you could do stuff like this: >> >> time_millis_t time_ms = 100.0; // value is 100.0 >> double time_prim_ms = time_ms; // value is 100.0 >> Time time_secs = time_ms; // value is 0.1f; automatically converts [milliseconds, double] to [seconds, float] >> time_default_t time_default = time_ms + time_secs; // value is 0.2; default unit is [seconds, double] >> >> ...and whenever there is a mismatch between time units that you send and the units expected in a function, it will automatically be converted to the appropriate expected type/unit. If you don't want to convert units automatically because you are scared of performance issues or something, then the type system can still at the very least help finding implicit conversions that you might want to eliminate automatically and reveal bugs related to such unit mismatches rapidly at compile time instead of after error prone manual verification. >> >> I don't know if this type of solution is interesting to you as maybe you want a single universal time unit to be used instead (such as seconds) in order to solve the problem, but thought I'd throw it out there anyway. Oh and even then I think it's clearer in a solution like this what the default time unit is supposed to be by just introspecting time_default_t instead of just "double". What do you think? >> >> Thanks, >> /Erik >> >> On 04/03/15 16:43, Bengt Rutisson wrote: >>> >>> Hi again, >>> >>> Yet another update to this webrev. I realized that I can move the >>> WorkerDataArray class from the hpp file to the cpp file. I think that's >>> worth doing to show that it is just in internal class. >>> >>> Also, I renamed the GCPhase* enums and variables to GCParPhase* to make >>> it possible to use the GCPhase* names for a possible future extension to >>> store the "single time phases" in something similar to the _gc_phases array. >>> >>> Here's an updated webrev: >>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.03/ >>> >>> And here's the diff compared to the last one: >>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.02-03.diff/ >>> >>> Thanks, >>> Bengt >>> >>> >>> On 2015-03-03 17:10, Bengt Rutisson wrote: >>>> >>>> Hi all, >>>> >>>> After some testing I noticed that I had done all my testing with >>>> StringDedup enabled. The code did not work properly with it disabled >>>> since StringDedup reported times for full GCs and concurrent marking >>>> even though it was not logged anywhere. I changed the code to only >>>> report times when the times will be reported as part of a GC. >>>> >>>> Here's an updated webrev: >>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.02/ >>>> >>>> And a diff compared to the last review: >>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.01-02.diff/ >>>> >>>> Thanks, >>>> Bengt >>>> >>>> On 2015-03-02 17:15, Bengt Rutisson wrote: >>>>> >>>>> Hi again, >>>>> >>>>> Here is an updated webrev: >>>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.01/ >>>>> >>>>> And here's the diff compared to the last webrev: >>>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00-01.diff/ >>>>> >>>>> I tried to clean up the seconds vs. milliseconds confusion by making >>>>> it G1GCPhaseTimes' responsibility to handle the conversion in all >>>>> cases. So, the interface is now that times are reported in seconds >>>>> (for example G1GCPhaseTimes::record_time_secs()) but returned in >>>>> milliseconds (for example G1GCPhaseTimes::average_time_ms()). I >>>>> suffixed the method names "_secs" and "_ms" to make it easier to >>>>> follow the code. >>>>> >>>>> I'm not very happy about this inconsistency, but I want it to be an >>>>> intermediate step on the way to getting rid of os::elapsedTime() >>>>> completely. >>>>> >>>>> StefanK also suggested to move the logging code out to its own class. >>>>> This simplified the logging quite a bit I think. The class, >>>>> G1GCPhasePrinter, has to know a lot about both G1GCPhaseTimes and >>>>> WorkerDataArray, but I still think it is nice to have the logging >>>>> separated out. >>>>> >>>>> I didn't read Thomas' email with comments until after I had prepared >>>>> this updated webrev. But I think I have addressed the issues brought >>>>> up there. Thanks for looking at this, Thomas! >>>>> >>>>> Bengt >>>>> >>>>> On 2015-03-02 09:23, Bengt Rutisson wrote: >>>>>> >>>>>> Hi Kim, >>>>>> >>>>>> Thanks for looking at this! >>>>>> >>>>>> On 2015-02-28 00:43, Kim Barrett wrote: >>>>>>> On Feb 27, 2015, at 10:38 AM, Bengt Rutisson >>>>>>> wrote: >>>>>>>> Can I have a couple of reviews for this cleanup change? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00/ >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8074037 >>>>>>>> >>>>>>>> [?] >>>>>>>> The patch also introduces a new class called >>>>>>>> G1GCPhaseTimesTracker, which is a scoped object to simplify time >>>>>>>> measurements. I've also tried to move conversion of times down to >>>>>>>> when we print the log messages instead of when we store them. This >>>>>>>> removes several "* 1000.0" in the code. Eventually I would like to >>>>>>>> replace os::elapsedTime() with os::elapsed_counter(). But that >>>>>>>> should be done as a separate patch. >>>>>>> Before I proceed any further with this review, I feel like I'm getting >>>>>>> lost in unit changes. In some places values of msecs used to be used >>>>>>> but now we're using secs, right? But it seems like there might be some >>>>>>> confusion about that, and I'm not sure whether it's me or the code >>>>>>> that's confused. >>>>>>> >>>>>>> For example: >>>>>>> >>>>>>> src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp >>>>>>> 1079 cost_per_card_ms = >>>>>>> phase_times()->average_time(G1GCPhaseTimes::UpdateRS) / (double) >>>>>>> _pending_cards; >>>>>>> 1080 _cost_per_card_ms_seq->add(cost_per_card_ms); >>>>>>> >>>>>>> I think the values that have been recorded in the phase_times are >>>>>>> secs, and average_time appears to just use the values as is. So >>>>>>> shouldn't that now be cost_per_card_secs? And the value added to >>>>>>> _cost_per_card_ms_seq needs to be cost_per_card_secs * 1000.0? >>>>>> >>>>>> Right! Good catch! I was so happy to get rid of some of the "* >>>>>> 1000.0" statements sprinkled all over the G1 code that I forgot to >>>>>> add some of them back ;) >>>>>> >>>>>> I'll send out an updated webrev soon. >>>>>> >>>>>> Bengt >>>>>> >>>>>>> >>>>>>> Oh how I wish for a units package! >>>>>>> >>>>>> >>>>> >>>> >>> >>> > From erik.helin at oracle.com Thu Mar 5 09:41:19 2015 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 5 Mar 2015 10:41:19 +0100 Subject: RFR: 8073545 - Use shorter and more descriptive names for GC worker threads In-Reply-To: <54F723A7.6080008@oracle.com> References: <54F6FF0F.3030609@oracle.com> <54F70E1D.7030101@oracle.com> <54F7129B.8050009@oracle.com> <54F723A7.6080008@oracle.com> Message-ID: <20150305094119.GC3269@ehelin.jrpg.bea.com> On 2015-03-04, Bengt Rutisson wrote: > > Hi David and everyone, > > I don't have strong opinions on this, but here's what I'd suggest: > > "CMSTask" > "CMSMain" > "G1ConcRefine#%d" > "G1MarkTask" > "G1ConcMark" > "StringDedup" > "ParGCTask" > "GCParTask" > These names looks good to me. Thanks, Erik > > On 2015-03-04 15:11, David Lindholm wrote: > >Hi Jesper, > > > >On 2015-03-04 14:52, Jesper Wilhelmsson wrote: > >>Hi David, > >> > >>Thanks for fixing this! > >> > >>A couple of questions: > >> > >>- set_name("G1 Concurrent Refinement Thread#%d", worker_id); > >>+ set_name("G1 ConRefine#%d", worker_id); > >> > >>Is there any refinement threads that are not concurrent? If not, could > >>we just call this "G1 Refine#%d" to simplify it slightly and remove an > >>implementation detail that doesn't need to be exposed? This would also > >>leave room for three digit numbers in case we have lots of these threads > >>on some systems. > > > >I discussed this with Bengt, and his input was that Concurrent Refinement > >is a well known concept in G1. I have no real opinion here, I'm fine with > >both suggestions. > > > >>- _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking > >>Threads", > >>+ _parallel_workers = new FlexibleWorkGang("G1 Markers", > >> > >>Markers is cute, but could be misunderstood. Can we call it "G1 Mark > >>Threads" instead? > > > >No, it is too long, the three last character with thread number won't fit > >(#xx). > > > >>- set_name("G1 Main Concurrent Mark GC Thread"); > >>+ set_name("G1 Main Marker"); > >> > >>Again, "Marker" could be misunderstood. I don't have a good replacement > >>though. > > > >I'm open for suggestions, but I think "G1 Main Marker" works. > > > >>- set_name("GC task thread#%d (ParallelGC)", which); > >>+ set_name("ParGC Thread#%d", which); > >> > >>I don't have a good suggestion for how to make this one character > >>shorter, but currently there is only room for two digit numbers. Maybe > >>just "GC Thread#%d". I don't think these threads will exist at the same > >>time as any other GC threads anyway. > > > >With your suggestion these threads would be called the same thing as the > >threads in sharedHeap. I think it is nice to quickly be able to see that > >these threads indeed belongs to the ParallelGC. > > > >>- set_name("Gang worker#%d (%s)", id, gang->name()); > >>+ set_name("%s#%d", gang->name(), id); > >> > >>Is there any limitation on the length of the name()? If it's too long > >>the number won't show. Can we add an assert to make sure it isn't too > >>long? > > > >I have gone through our current GangWorkers, and they fit. If you want I > >can add an assert for <= 12 characters. OTOH it is not the end of the > >world if we don't see the whole number in the debugger. > > > > > >Thanks, > >David > > > >> > >>Thanks, > >>/Jesper > >> > >> > >>David Lindholm skrev den 4/3/15 13:48: > >>>Hi, > >>> > >>>Please review this small fix which changes the names of the GC threads > >>>to be > >>>shorter and more descriptive. There is a limit on 16 characters > >>>including the > >>>terminating null byte for this name, since pthread_set_name_np() is > >>>used. This > >>>change will make it easier to debug, as these names shows up in the > >>>debugger. > >>> > >>>Webrev: http://cr.openjdk.java.net/~brutisso/8073545/webrev.00/ > >>>Bug: https://bugs.openjdk.java.net/browse/JDK-8073545 > >>> > >>>Testing: Passed JPRT. > >>> > >>> > >>>Regards, > >>>David > > > From david.lindholm at oracle.com Thu Mar 5 10:26:16 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Thu, 05 Mar 2015 11:26:16 +0100 Subject: RFR: 8073545 - Use shorter and more descriptive names for GC worker threads In-Reply-To: <54F723A7.6080008@oracle.com> References: <54F6FF0F.3030609@oracle.com> <54F70E1D.7030101@oracle.com> <54F7129B.8050009@oracle.com> <54F723A7.6080008@oracle.com> Message-ID: <54F82F48.3050005@oracle.com> Hi, Thanks for your input. To me, threads and tasks are different things. A task is something a thread can do for a while, but when it is finished with that task it can pick something else to do (another task). This view seems to be reflected in gcTaskThread.cpp (the thread for running tasks in parallelScavenge). After creation, it runs different tasks managed by gcTaskManager. These tasks are called names ending with "task". But I agree that in most cases the word Thread is unnecessary (this was why I called the Marker Thread "Marker"). But I don't have anything against using up all the 15 chars (we should not shorten the name unnecessarily). My new suggestion: "CMS Thread#xxx" "CMS Main Thread" "G1 Refine#xxx" "G1 Marker#xxx" "G1 Main Marker" "G1 StrDedup#xxx" "ParGC Thread#xx" "GC Thread#xxx" This way our threads naming scheme will be aligned with the rest of the JVM. One could argue if '#' is necessary. We could leave it out or print '-' instead. The CompilerThreads leave them out. Thanks, David On 2015-03-04 16:24, Bengt Rutisson wrote: > > Hi David and everyone, > > Naming is the most difficult part of computer science so I doubt that > there is an easy answer here. Given that the names are for debugging I > guess it is not too important exactly what the names are. More > important is that they are unique. I also think that there is really > no need to have "thread" in the name since it is pretty obvious that > it is a thread. > > So, my suggestion would be to skip "thread" and to use CamelCase > rather than using spaces to save some characters. > > I don't have strong opinions on this, but here's what I'd suggest: > > - _conc_workers = new YieldingFlexibleWorkGang("Parallel CMS > Threads", > + _conc_workers = new YieldingFlexibleWorkGang("CMS Threads", > > "CMSTask" > > > > - set_name("Concurrent Mark-Sweep GC Thread"); > + set_name("CMS Main Thread"); > > "CMSMain" > > > > - set_name("G1 Concurrent Refinement Thread#%d", worker_id); > + set_name("G1 ConRefine#%d", worker_id); > > "G1ConcRefine#%d" > > > > - _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking > Threads", > + _parallel_workers = new FlexibleWorkGang("G1 Markers" > > "G1MarkTask" > > > > - set_name("G1 Main Concurrent Mark GC Thread"); > + set_name("G1 Main Marker"); > > "G1ConcMark" > > > > - set_name("String Deduplication Thread"); > + set_name("StrDedup Thread"); > > "StringDedup" > > > > - set_name("GC task thread#%d (ParallelGC)", which); > + set_name("ParGC Thread#%d", which); > > "ParGCTask" > > > > - _workers = new FlexibleWorkGang("Parallel GC Threads", > ParallelGCThreads, > + _workers = new FlexibleWorkGang("GC Threads", ParallelGCThreads, > > "GCParTask" > > > Just my thoughts. And regarding having 3 characters left for the > number in the thread name I don't know if that is too important. With > the above suggestions this will be possible in most cases but not all. > Personally I think that is good enough. > > Bengt > > > On 2015-03-04 15:11, David Lindholm wrote: >> Hi Jesper, >> >> On 2015-03-04 14:52, Jesper Wilhelmsson wrote: >>> Hi David, >>> >>> Thanks for fixing this! >>> >>> A couple of questions: >>> >>> - set_name("G1 Concurrent Refinement Thread#%d", worker_id); >>> + set_name("G1 ConRefine#%d", worker_id); >>> >>> Is there any refinement threads that are not concurrent? If not, >>> could we just call this "G1 Refine#%d" to simplify it slightly and >>> remove an implementation detail that doesn't need to be exposed? >>> This would also leave room for three digit numbers in case we have >>> lots of these threads on some systems. >> >> I discussed this with Bengt, and his input was that Concurrent >> Refinement is a well known concept in G1. I have no real opinion >> here, I'm fine with both suggestions. >> >>> - _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking >>> Threads", >>> + _parallel_workers = new FlexibleWorkGang("G1 Markers", >>> >>> Markers is cute, but could be misunderstood. Can we call it "G1 Mark >>> Threads" instead? >> >> No, it is too long, the three last character with thread number won't >> fit (#xx). >> >>> - set_name("G1 Main Concurrent Mark GC Thread"); >>> + set_name("G1 Main Marker"); >>> >>> Again, "Marker" could be misunderstood. I don't have a good >>> replacement though. >> >> I'm open for suggestions, but I think "G1 Main Marker" works. >> >>> - set_name("GC task thread#%d (ParallelGC)", which); >>> + set_name("ParGC Thread#%d", which); >>> >>> I don't have a good suggestion for how to make this one character >>> shorter, but currently there is only room for two digit numbers. >>> Maybe just "GC Thread#%d". I don't think these threads will exist at >>> the same time as any other GC threads anyway. >> >> With your suggestion these threads would be called the same thing as >> the threads in sharedHeap. I think it is nice to quickly be able to >> see that these threads indeed belongs to the ParallelGC. >> >>> - set_name("Gang worker#%d (%s)", id, gang->name()); >>> + set_name("%s#%d", gang->name(), id); >>> >>> Is there any limitation on the length of the name()? If it's too >>> long the number won't show. Can we add an assert to make sure it >>> isn't too long? >> >> I have gone through our current GangWorkers, and they fit. If you >> want I can add an assert for <= 12 characters. OTOH it is not the end >> of the world if we don't see the whole number in the debugger. >> >> >> Thanks, >> David >> >>> >>> Thanks, >>> /Jesper >>> >>> >>> David Lindholm skrev den 4/3/15 13:48: >>>> Hi, >>>> >>>> Please review this small fix which changes the names of the GC >>>> threads to be >>>> shorter and more descriptive. There is a limit on 16 characters >>>> including the >>>> terminating null byte for this name, since pthread_set_name_np() is >>>> used. This >>>> change will make it easier to debug, as these names shows up in the >>>> debugger. >>>> >>>> Webrev: http://cr.openjdk.java.net/~brutisso/8073545/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073545 >>>> >>>> Testing: Passed JPRT. >>>> >>>> >>>> Regards, >>>> David >> > From jesper.wilhelmsson at oracle.com Thu Mar 5 10:54:12 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 05 Mar 2015 11:54:12 +0100 Subject: RFR: 8073545 - Use shorter and more descriptive names for GC worker threads In-Reply-To: <54F82F48.3050005@oracle.com> References: <54F6FF0F.3030609@oracle.com> <54F70E1D.7030101@oracle.com> <54F7129B.8050009@oracle.com> <54F723A7.6080008@oracle.com> <54F82F48.3050005@oracle.com> Message-ID: <54F835D4.1020606@oracle.com> I'm fine with this suggestion. /Jesper David Lindholm skrev den 5/3/15 11:26: > Hi, > > Thanks for your input. To me, threads and tasks are different things. A task is > something a thread can do for a while, but when it is finished with that task it > can pick something else to do (another task). This view seems to be reflected in > gcTaskThread.cpp (the thread for running tasks in parallelScavenge). After > creation, it runs different tasks managed by gcTaskManager. These tasks are > called names ending with "task". > > But I agree that in most cases the word Thread is unnecessary (this was why I > called the Marker Thread "Marker"). But I don't have anything against using up > all the 15 chars (we should not shorten the name unnecessarily). > > My new suggestion: > > "CMS Thread#xxx" > "CMS Main Thread" > "G1 Refine#xxx" > "G1 Marker#xxx" > "G1 Main Marker" > "G1 StrDedup#xxx" > "ParGC Thread#xx" > "GC Thread#xxx" > > This way our threads naming scheme will be aligned with the rest of the JVM. One > could argue if '#' is necessary. We could leave it out or print '-' instead. The > CompilerThreads leave them out. > > > Thanks, > David > > On 2015-03-04 16:24, Bengt Rutisson wrote: >> >> Hi David and everyone, >> >> Naming is the most difficult part of computer science so I doubt that there is >> an easy answer here. Given that the names are for debugging I guess it is not >> too important exactly what the names are. More important is that they are >> unique. I also think that there is really no need to have "thread" in the name >> since it is pretty obvious that it is a thread. >> >> So, my suggestion would be to skip "thread" and to use CamelCase rather than >> using spaces to save some characters. >> >> I don't have strong opinions on this, but here's what I'd suggest: >> >> - _conc_workers = new YieldingFlexibleWorkGang("Parallel CMS Threads", >> + _conc_workers = new YieldingFlexibleWorkGang("CMS Threads", >> >> "CMSTask" >> >> >> >> - set_name("Concurrent Mark-Sweep GC Thread"); >> + set_name("CMS Main Thread"); >> >> "CMSMain" >> >> >> >> - set_name("G1 Concurrent Refinement Thread#%d", worker_id); >> + set_name("G1 ConRefine#%d", worker_id); >> >> "G1ConcRefine#%d" >> >> >> >> - _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking Threads", >> + _parallel_workers = new FlexibleWorkGang("G1 Markers" >> >> "G1MarkTask" >> >> >> >> - set_name("G1 Main Concurrent Mark GC Thread"); >> + set_name("G1 Main Marker"); >> >> "G1ConcMark" >> >> >> >> - set_name("String Deduplication Thread"); >> + set_name("StrDedup Thread"); >> >> "StringDedup" >> >> >> >> - set_name("GC task thread#%d (ParallelGC)", which); >> + set_name("ParGC Thread#%d", which); >> >> "ParGCTask" >> >> >> >> - _workers = new FlexibleWorkGang("Parallel GC Threads", ParallelGCThreads, >> + _workers = new FlexibleWorkGang("GC Threads", ParallelGCThreads, >> >> "GCParTask" >> >> >> Just my thoughts. And regarding having 3 characters left for the number in the >> thread name I don't know if that is too important. With the above suggestions >> this will be possible in most cases but not all. Personally I think that is >> good enough. >> >> Bengt >> >> >> On 2015-03-04 15:11, David Lindholm wrote: >>> Hi Jesper, >>> >>> On 2015-03-04 14:52, Jesper Wilhelmsson wrote: >>>> Hi David, >>>> >>>> Thanks for fixing this! >>>> >>>> A couple of questions: >>>> >>>> - set_name("G1 Concurrent Refinement Thread#%d", worker_id); >>>> + set_name("G1 ConRefine#%d", worker_id); >>>> >>>> Is there any refinement threads that are not concurrent? If not, could we >>>> just call this "G1 Refine#%d" to simplify it slightly and remove an >>>> implementation detail that doesn't need to be exposed? This would also leave >>>> room for three digit numbers in case we have lots of these threads on some >>>> systems. >>> >>> I discussed this with Bengt, and his input was that Concurrent Refinement is >>> a well known concept in G1. I have no real opinion here, I'm fine with both >>> suggestions. >>> >>>> - _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking Threads", >>>> + _parallel_workers = new FlexibleWorkGang("G1 Markers", >>>> >>>> Markers is cute, but could be misunderstood. Can we call it "G1 Mark >>>> Threads" instead? >>> >>> No, it is too long, the three last character with thread number won't fit (#xx). >>> >>>> - set_name("G1 Main Concurrent Mark GC Thread"); >>>> + set_name("G1 Main Marker"); >>>> >>>> Again, "Marker" could be misunderstood. I don't have a good replacement though. >>> >>> I'm open for suggestions, but I think "G1 Main Marker" works. >>> >>>> - set_name("GC task thread#%d (ParallelGC)", which); >>>> + set_name("ParGC Thread#%d", which); >>>> >>>> I don't have a good suggestion for how to make this one character shorter, >>>> but currently there is only room for two digit numbers. Maybe just "GC >>>> Thread#%d". I don't think these threads will exist at the same time as any >>>> other GC threads anyway. >>> >>> With your suggestion these threads would be called the same thing as the >>> threads in sharedHeap. I think it is nice to quickly be able to see that >>> these threads indeed belongs to the ParallelGC. >>> >>>> - set_name("Gang worker#%d (%s)", id, gang->name()); >>>> + set_name("%s#%d", gang->name(), id); >>>> >>>> Is there any limitation on the length of the name()? If it's too long the >>>> number won't show. Can we add an assert to make sure it isn't too long? >>> >>> I have gone through our current GangWorkers, and they fit. If you want I can >>> add an assert for <= 12 characters. OTOH it is not the end of the world if we >>> don't see the whole number in the debugger. >>> >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> /Jesper >>>> >>>> >>>> David Lindholm skrev den 4/3/15 13:48: >>>>> Hi, >>>>> >>>>> Please review this small fix which changes the names of the GC threads to be >>>>> shorter and more descriptive. There is a limit on 16 characters including the >>>>> terminating null byte for this name, since pthread_set_name_np() is used. This >>>>> change will make it easier to debug, as these names shows up in the debugger. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~brutisso/8073545/webrev.00/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073545 >>>>> >>>>> Testing: Passed JPRT. >>>>> >>>>> >>>>> Regards, >>>>> David >>> >> > From ecki at zusammenkunft.net Thu Mar 5 11:45:24 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 5 Mar 2015 12:45:24 +0100 Subject: RFR: 8073545 - Use shorter and more descriptive names for GCworker threads In-Reply-To: <20150305094119.GC3269@ehelin.jrpg.bea.com> References: <54F6FF0F.3030609@oracle.com> <54F70E1D.7030101@oracle.com> <54F7129B.8050009@oracle.com> <54F723A7.6080008@oracle.com> <20150305094119.GC3269@ehelin.jrpg.bea.com> Message-ID: <54f841d3.72d3b40a.2995.ffffe1f6@mx.google.com> It would be good if all names contain "GC" maybe even have a Common prefix. (and a Common thread group in Java land, but that is I guess a different Topic) -- http://bernd.eckenfels.net ----- Urspr?ngliche Nachricht ----- Von: "Erik Helin" Gesendet: ?05.?03.?2015 11:41 An: "Bengt Rutisson" Cc: "hotspot-gc-dev at openjdk.java.net" Betreff: Re: RFR: 8073545 - Use shorter and more descriptive names for GCworker threads On 2015-03-04, Bengt Rutisson wrote: > > Hi David and everyone, > > I don't have strong opinions on this, but here's what I'd suggest: > > "CMSTask" > "CMSMain" > "G1ConcRefine#%d" > "G1MarkTask" > "G1ConcMark" > "StringDedup" > "ParGCTask" > "GCParTask" > These names looks good to me. Thanks, Erik > > On 2015-03-04 15:11, David Lindholm wrote: > >Hi Jesper, > > > >On 2015-03-04 14:52, Jesper Wilhelmsson wrote: > >>Hi David, > >> > >>Thanks for fixing this! > >> > >>A couple of questions: > >> > >>- set_name("G1 Concurrent Refinement Thread#%d", worker_id); > >>+ set_name("G1 ConRefine#%d", worker_id); > >> > >>Is there any refinement threads that are not concurrent? If not, could > >>we just call this "G1 Refine#%d" to simplify it slightly and remove an > >>implementation detail that doesn't need to be exposed? This would also > >>leave room for three digit numbers in case we have lots of these threads > >>on some systems. > > > >I discussed this with Bengt, and his input was that Concurrent Refinement > >is a well known concept in G1. I have no real opinion here, I'm fine with > >both suggestions. > > > >>- _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking > >>Threads", > >>+ _parallel_workers = new FlexibleWorkGang("G1 Markers", > >> > >>Markers is cute, but could be misunderstood. Can we call it "G1 Mark > >>Threads" instead? > > > >No, it is too long, the three last character with thread number won't fit > >(#xx). > > > >>- set_name("G1 Main Concurrent Mark GC Thread"); > >>+ set_name("G1 Main Marker"); > >> > >>Again, "Marker" could be misunderstood. I don't have a good replacement > >>though. > > > >I'm open for suggestions, but I think "G1 Main Marker" works. > > > >>- set_name("GC task thread#%d (ParallelGC)", which); > >>+ set_name("ParGC Thread#%d", which); > >> > >>I don't have a good suggestion for how to make this one character > >>shorter, but currently there is only room for two digit numbers. Maybe > >>just "GC Thread#%d". I don't think these threads will exist at the same > >>time as any other GC threads anyway. > > > >With your suggestion these threads would be called the same thing as the > >threads in sharedHeap. I think it is nice to quickly be able to see that > >these threads indeed belongs to the ParallelGC. > > > >>- set_name("Gang worker#%d (%s)", id, gang->name()); > >>+ set_name("%s#%d", gang->name(), id); > >> > >>Is there any limitation on the length of the name()? If it's too long > >>the number won't show. Can we add an assert to make sure it isn't too > >>long? > > > >I have gone through our current GangWorkers, and they fit. If you want I > >can add an assert for <= 12 characters. OTOH it is not the end of the > >world if we don't see the whole number in the debugger. > > > > > >Thanks, > >David > > > >> > >>Thanks, > >>/Jesper > >> > >> > >>David Lindholm skrev den 4/3/15 13:48: > >>>Hi, > >>> > >>>Please review this small fix which changes the names of the GC threads > >>>to be > >>>shorter and more descriptive. There is a limit on 16 characters > >>>including the > >>>terminating null byte for this name, since pthread_set_name_np() is > >>>used. This > >>>change will make it easier to debug, as these names shows up in the > >>>debugger. > >>> > >>>Webrev: http://cr.openjdk.java.net/~brutisso/8073545/webrev.00/ > >>>Bug: https://bugs.openjdk.java.net/browse/JDK-8073545 > >>> > >>>Testing: Passed JPRT. > >>> > >>> > >>>Regards, > >>>David > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Thu Mar 5 11:48:36 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 05 Mar 2015 12:48:36 +0100 Subject: RFR: 8073545 - Use shorter and more descriptive names for GCworker threads In-Reply-To: <54f841d3.72d3b40a.2995.ffffe1f6@mx.google.com> References: <54F6FF0F.3030609@oracle.com> <54F70E1D.7030101@oracle.com> <54F7129B.8050009@oracle.com> <54F723A7.6080008@oracle.com> <20150305094119.GC3269@ehelin.jrpg.bea.com> <54f841d3.72d3b40a.2995.ffffe1f6@mx.google.com> Message-ID: <54F84294.9080605@oracle.com> On 2015-03-05 12:45, Bernd Eckenfels wrote: > It would be good if all names contain "GC" maybe even have a Common > prefix. (and a Common thread group in Java land, but that is I guess a > different Topic) The GC threads do not (and should not IMO) have corresponding Thread objects and cannot be members of a thread group. /Mikael > > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > Von: Erik Helin > Gesendet: ?05.?03.?2015 11:41 > An: Bengt Rutisson > Cc: hotspot-gc-dev at openjdk.java.net > Betreff: Re: RFR: 8073545 - Use shorter and more descriptive names for > GCworker threads > > On 2015-03-04, Bengt Rutisson wrote: > > > > Hi David and everyone, > > > > I don't have strong opinions on this, but here's what I'd suggest: > > > > "CMSTask" > > "CMSMain" > > "G1ConcRefine#%d" > > "G1MarkTask" > > "G1ConcMark" > > "StringDedup" > > "ParGCTask" > > "GCParTask" > > > > These names looks good to me. > > Thanks, > Erik > > > > > On 2015-03-04 15:11, David Lindholm wrote: > > >Hi Jesper, > > > > > >On 2015-03-04 14:52, Jesper Wilhelmsson wrote: > > >>Hi David, > > >> > > >>Thanks for fixing this! > > >> > > >>A couple of questions: > > >> > > >>- set_name("G1 Concurrent Refinement Thread#%d", worker_id); > > >>+ set_name("G1 ConRefine#%d", worker_id); > > >> > > >>Is there any refinement threads that are not concurrent? If not, could > > >>we just call this "G1 Refine#%d" to simplify it slightly and remove an > > >>implementation detail that doesn't need to be exposed? This would also > > >>leave room for three digit numbers in case we have lots of these > threads > > >>on some systems. > > > > > >I discussed this with Bengt, and his input was that Concurrent > Refinement > > >is a well known concept in G1. I have no real opinion here, I'm fine > with > > >both suggestions. > > > > > >>- _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking > > >>Threads", > > >>+ _parallel_workers = new FlexibleWorkGang("G1 Markers", > > >> > > >>Markers is cute, but could be misunderstood. Can we call it "G1 Mark > > >>Threads" instead? > > > > > >No, it is too long, the three last character with thread number > won't fit > > >(#xx). > > > > > >>- set_name("G1 Main Concurrent Mark GC Thread"); > > >>+ set_name("G1 Main Marker"); > > >> > > >>Again, "Marker" could be misunderstood. I don't have a good replacement > > >>though. > > > > > >I'm open for suggestions, but I think "G1 Main Marker" works. > > > > > >>- set_name("GC task thread#%d (ParallelGC)", which); > > >>+ set_name("ParGC Thread#%d", which); > > >> > > >>I don't have a good suggestion for how to make this one character > > >>shorter, but currently there is only room for two digit numbers. Maybe > > >>just "GC Thread#%d". I don't think these threads will exist at the same > > >>time as any other GC threads anyway. > > > > > >With your suggestion these threads would be called the same thing as the > > >threads in sharedHeap. I think it is nice to quickly be able to see that > > >these threads indeed belongs to the ParallelGC. > > > > > >>- set_name("Gang worker#%d (%s)", id, gang->name()); > > >>+ set_name("%s#%d", gang->name(), id); > > >> > > >>Is there any limitation on the length of the name()? If it's too long > > >>the number won't show. Can we add an assert to make sure it isn't too > > >>long? > > > > > >I have gone through our current GangWorkers, and they fit. If you want I > > >can add an assert for <= 12 characters. OTOH it is not the end of the > > >world if we don't see the whole number in the debugger. > > > > > > > > >Thanks, > > >David > > > > > >> > > >>Thanks, > > >>/Jesper > > >> > > >> > > >>David Lindholm skrev den 4/3/15 13:48: > > >>>Hi, > > >>> > > >>>Please review this small fix which changes the names of the GC threads > > >>>to be > > >>>shorter and more descriptive. There is a limit on 16 characters > > >>>including the > > >>>terminating null byte for this name, since pthread_set_name_np() is > > >>>used. This > > >>>change will make it easier to debug, as these names shows up in the > > >>>debugger. > > >>> > > >>>Webrev: http://cr.openjdk.java.net/~brutisso/8073545/webrev.00/ > > >>>Bug: https://bugs.openjdk.java.net/browse/JDK-8073545 > > >>> > > >>>Testing: Passed JPRT. > > >>> > > >>> > > >>>Regards, > > >>>David > > > > > From thomas.schatzl at oracle.com Thu Mar 5 11:55:02 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 05 Mar 2015 12:55:02 +0100 Subject: RFR: 8073545 - Use shorter and more descriptive names for GC worker threads In-Reply-To: <54F715C8.2020409@oracle.com> References: <54F6FF0F.3030609@oracle.com> <54F70E1D.7030101@oracle.com> <54F7129B.8050009@oracle.com> <54F715C8.2020409@oracle.com> Message-ID: <1425556502.3140.18.camel@oracle.com> Hi, On Wed, 2015-03-04 at 15:25 +0100, Jesper Wilhelmsson wrote: > Ok, I don't have a strong opinion. I just wanted to highlight these questions to > make sure there was a conscious decision to go with what you suggests :) > > I do think we should try to fit three digit numbers in there though. The whole > point of this change is to make the names more usable in the debugger. actually I would prefer if we had even more digits to identify them :) In some cases there already are high three-digit number of threads in use. I.e. shorten G1ConcRefine#%d to something like "G1Refine#%d" (or just remove the "#" because the extra threads for refinement are always used for concurrent refinement anyway. I am not insisting on that, just mentioning this potential future gotcha. Thanks, Thomas From michail.chernov at oracle.com Thu Mar 5 12:21:32 2015 From: michail.chernov at oracle.com (Michail Chernov) Date: Thu, 05 Mar 2015 15:21:32 +0300 Subject: RFR: 8026047: [TESTBUG] add regression test for DisableExplicitGC flag In-Reply-To: <54F6C579.9020500@oracle.com> References: <54C7B051.8050808@oracle.com> <54C90036.8030506@oracle.com> <54CBA45D.8090503@oracle.com> <54D10193.3060407@oracle.com> <54D3B107.9050901@oracle.com> <54DB512A.7070003@oracle.com> <54DB55E9.2080302@oracle.com> <54DB7667.3020107@oracle.com> <54DCB396.2080807@oracle.com> <54EDC32B.7020605@oracle.com> <54F56A96.20702@oracle.com> <54F5D41C.3080009@oracle.com> <54F6C579.9020500@oracle.com> Message-ID: <54F84A4C.4040700@oracle.com> Hi Bengt, I used your approach: http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.03/ assertEQ was changed to assertLT, because different GC can produce different count of collections. For example: -XX:+UseParallelGC can produce: PS MarkSweep 1 PS Scavenge 1 -XX:+UseConcMarkSweepGC -XX:+ExplicitGCInvokesConcurrent can produce: ParNew 1 ConcurrentMarkSweep 1 Thanks, Michail On 04.03.2015 11:42, Bengt Rutisson wrote: > > Hi Michail, > > On 2015-03-03 16:32, Michail Chernov wrote: >> Hi Bengt, >> >> I checked run time of test on raspberry-pi and on some solaris host >> with -Xcomp option. On r-pi it works 2.8 seconds, on solaris host it >> works 3.5 seconds. I can set NOTIFICATION_DELAY=5 (for example) to >> speed up the test. > > This sounds like a pretty fragile approach. My opinion is that we > should always avoid tests that wait a certain amount of time for > things to happen. They almost always turn out to be unstable or take > unnecessarily long time. > >> Your approach has some cons - it does not check that System.gc() was >> real GC source. > > Agreed. But since we actually don't have any problems with the > DisbableExplicitGC flag I don't think it is worth adding a test that > is potentially unstable and complex to test it. If we feel that we > really need to test this flag I think the test must be simple and fast. > >> In case if we don't check source of GC events, we can simplify test >> more and avoid usage of JMX: >> >> import java.lang.ref.WeakReference; >> >> public class Test{ >> public static volatile WeakReference ref; >> public static Object refObject; >> public static void main(String[] args) { >> ref=new WeakReference<>(new Object()); >> refObject=ref.get(); >> if ( refObject==null) >> throw new RuntimeException("ERROR! Object was collected >> before GC"); >> refObject=null; >> System.gc(); >> refObject=ref.get(); >> if ( refObject!=null) >> throw new RuntimeException("ERROR! Object was not >> collected during GC"); >> } >> } >> >> However, this solution does not check the real cause of GC. If this >> way is applicable here, I could use this code for testing >> DisableExplicitGC flag. > > Sure, this will probably work, but I think it is kind of a strange way > to check this. I prefer a more explicit way of testing. > > Thanks, > Bengt > >> >> Thanks, >> Michail >> >> On 03.03.2015 11:02, Bengt Rutisson wrote: >>> >>> Hi Michail, >>> >>> I like the idea of using the GarbageCollectionMXBean! >>> >>> However, I am not too happy about the test waiting for 20 seconds. >>> Especially since you have the failing test which will actually wait >>> for 20 seconds. >>> >>> Instead I would suggest to just use the collection count. Attaching >>> a version of the test that use that instead. What do you think about >>> this approach? >>> >>> Thanks, >>> Bengt >>> >>> >>> >>> On 2015-02-25 13:42, Michail Chernov wrote: >>>> Hi Bengt, >>>> >>>> I've rewritten test using JMX. I don't see here any reason to use >>>> gc log for testing this flag. >>>> >>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.02/ >>>> >>>> It seems better solution because it doesn't depend on used GC or >>>> log message format. >>>> >>>> Tested locally with JDK 9 b51 using several GC. Tested using Aurora >>>> on all platforms. >>>> >>>> Thanks, >>>> Michail >>>> >>>> On 12.02.2015 17:07, Bengt Rutisson wrote: >>>>> >>>>> Hi Michail, >>>>> >>>>> On 11/02/15 16:33, Michail Chernov wrote: >>>>>> Hi Bengt, >>>>>> >>>>>> Test works with all options passed to jtreg during testing ( see >>>>>> line 97 vmOpts.addAll(0, Utils.getVmOptions());). Doesn't >>>>>> need to check all GC's, it will be done during nightly. >>>>> >>>>> Ah. I see that now. >>>>> >>>>>> >>>>>> 44 public final static String[] PARALLEL_GC_OPTIONS = >>>>>> {"UseParallelGC", "UseParallelOldGC"}; >>>>>> Here is defined special options. If define one of these options - >>>>>> will be used other pattern to match output. >>>>> >>>>> Right. >>>>> >>>>>> >>>>>> But it seems to me a little bit wrong. I've checked output of GC >>>>>> log with different GCs and ExplicitGCInvokesConcurrent. Message >>>>>> "Full GC (System.gc())" does not appear only in case of using G1 >>>>>> or CMS with ExplicitGCInvokesConcurrent=true. Will fix it. >>>>> >>>>> OK. >>>>> >>>>> My main point was that I think the whole structure of the test is >>>>> different than how we usually write tests that verify the log >>>>> output. I would prefer if the tests look similar. Would you mind >>>>> re-writing the test to look like the other tests. >>>>> >>>>> I much prefer that you explicitly start with the GCs you want to >>>>> test than that you use the WhiteBox API to find out which GC you >>>>> are running. >>>>> >>>>> I'm having a similar discussion with Dima who recently invented >>>>> yet another way to parse the GC log output from tests. I think it >>>>> gets very hard to read the tests when they do the same thing in >>>>> different ways. >>>>> >>>>> Thanks, >>>>> Bengt >>>>>> >>>>>> Thanks, >>>>>> Michail >>>>>> On 11.02.2015 16:15, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi Michail, >>>>>>> >>>>>>> On 11/02/15 13:55, Michail Chernov wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Still hoping for review! >>>>>>> >>>>>>> Sorry for being so late in looking at this. >>>>>>> >>>>>>> A couple of questions: >>>>>>> >>>>>>> Why does the test only test the parallel GC? DisableExplicitGC >>>>>>> is valid for all GCs. >>>>>>> >>>>>>> What do you think about writing this test similar to other tests >>>>>>> that validate the output from the GC logging? Here's an example: >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/file/566574421b40/test/gc/g1/TestGCLogMessages.java >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Michail >>>>>>>> >>>>>>>> On 05.02.2015 21:05, Michail Chernov wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Still waiting for reviews! >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Michail >>>>>>>>> >>>>>>>>> On 03.02.2015 20:12, Michail Chernov wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Can someone take a look on these changes, please? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Michail >>>>>>>>>> >>>>>>>>>> On 30.01.2015 18:33, Michail Chernov wrote: >>>>>>>>>>> Hi Leonid, >>>>>>>>>>> >>>>>>>>>>> Issues were fixed: >>>>>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Now all testcases are executed from the same VM. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Michail >>>>>>>>>>> >>>>>>>>>>> On 28.01.2015 18:28, Leonid Mesnik wrote: >>>>>>>>>>>> Hi >>>>>>>>>>>> >>>>>>>>>>>> Why is it needed to start VM twice for each test. It is >>>>>>>>>>>> very expensive especially for low-end devices. >>>>>>>>>>>> >>>>>>>>>>>> Is it possible to have driver which starts VM several times >>>>>>>>>>>> with different combinations of options and check it >>>>>>>>>>>> output/exit code etc? Also it would be much easier to read >>>>>>>>>>>> such test. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Leonid >>>>>>>>>>>> >>>>>>>>>>>> On 27.01.2015 18:35, Michail Chernov wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review the fix with new test for DisableExplicitGC >>>>>>>>>>>>> VM flag. >>>>>>>>>>>>> >>>>>>>>>>>>> Webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8026047 >>>>>>>>>>>>> >>>>>>>>>>>>> There is one scenario with 6 parameters combinations. >>>>>>>>>>>>> >>>>>>>>>>>>> 1,2,3 scenarios test default value for DisableExplicitGC, >>>>>>>>>>>>> DisableExplicitGC=true and DisableExplicitGC=false >>>>>>>>>>>>> 4,5,6 scenarios check how VM works when VM changes >>>>>>>>>>>>> DisableExplicitGC flag using WhiteBox. >>>>>>>>>>>>> >>>>>>>>>>>>> Test tries to call System.gc() and check that VM puts >>>>>>>>>>>>> message to stdout. After (in case of 4,5,6 scenarios) test >>>>>>>>>>>>> tries to change DisableExplicitGC value and calls >>>>>>>>>>>>> System.gc() twice. >>>>>>>>>>>>> >>>>>>>>>>>>> Test was executed locally on linux-i586 with all available >>>>>>>>>>>>> GC and several GC-related flags. Also it was executed >>>>>>>>>>>>> using Aurora on other platforms. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Michail >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >> > > > From per.liden at oracle.com Thu Mar 5 12:39:26 2015 From: per.liden at oracle.com (Per Liden) Date: Thu, 05 Mar 2015 13:39:26 +0100 Subject: RFR: 8073545 - Use shorter and more descriptive names for GC worker threads In-Reply-To: <54F82F48.3050005@oracle.com> References: <54F6FF0F.3030609@oracle.com> <54F70E1D.7030101@oracle.com> <54F7129B.8050009@oracle.com> <54F723A7.6080008@oracle.com> <54F82F48.3050005@oracle.com> Message-ID: <54F84E7D.7050506@oracle.com> Hi, On 2015-03-05 11:26, David Lindholm wrote: > Hi, > > Thanks for your input. To me, threads and tasks are different things. > A task is something a thread can do for a while, but when it is > finished with that task it can pick something else to do (another > task). This view seems to be reflected in gcTaskThread.cpp (the thread > for running tasks in parallelScavenge). After creation, it runs > different tasks managed by gcTaskManager. These tasks are called names > ending with "task". > > But I agree that in most cases the word Thread is unnecessary (this > was why I called the Marker Thread "Marker"). But I don't have > anything against using up all the 15 chars (we should not shorten the > name unnecessarily). > > My new suggestion: > > "CMS Thread#xxx" > "CMS Main Thread" > "G1 Refine#xxx" > "G1 Marker#xxx" > "G1 Main Marker" > "G1 StrDedup#xxx" You don't need the #xxx on string dedup, there's only one such thread. /Per > "ParGC Thread#xx" > "GC Thread#xxx" > > This way our threads naming scheme will be aligned with the rest of > the JVM. One could argue if '#' is necessary. We could leave it out or > print '-' instead. The CompilerThreads leave them out. > > > Thanks, > David > > On 2015-03-04 16:24, Bengt Rutisson wrote: >> >> Hi David and everyone, >> >> Naming is the most difficult part of computer science so I doubt that >> there is an easy answer here. Given that the names are for debugging >> I guess it is not too important exactly what the names are. More >> important is that they are unique. I also think that there is really >> no need to have "thread" in the name since it is pretty obvious that >> it is a thread. >> >> So, my suggestion would be to skip "thread" and to use CamelCase >> rather than using spaces to save some characters. >> >> I don't have strong opinions on this, but here's what I'd suggest: >> >> - _conc_workers = new YieldingFlexibleWorkGang("Parallel CMS >> Threads", >> + _conc_workers = new YieldingFlexibleWorkGang("CMS Threads", >> >> "CMSTask" >> >> >> >> - set_name("Concurrent Mark-Sweep GC Thread"); >> + set_name("CMS Main Thread"); >> >> "CMSMain" >> >> >> >> - set_name("G1 Concurrent Refinement Thread#%d", worker_id); >> + set_name("G1 ConRefine#%d", worker_id); >> >> "G1ConcRefine#%d" >> >> >> >> - _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking >> Threads", >> + _parallel_workers = new FlexibleWorkGang("G1 Markers" >> >> "G1MarkTask" >> >> >> >> - set_name("G1 Main Concurrent Mark GC Thread"); >> + set_name("G1 Main Marker"); >> >> "G1ConcMark" >> >> >> >> - set_name("String Deduplication Thread"); >> + set_name("StrDedup Thread"); >> >> "StringDedup" >> >> >> >> - set_name("GC task thread#%d (ParallelGC)", which); >> + set_name("ParGC Thread#%d", which); >> >> "ParGCTask" >> >> >> >> - _workers = new FlexibleWorkGang("Parallel GC Threads", >> ParallelGCThreads, >> + _workers = new FlexibleWorkGang("GC Threads", ParallelGCThreads, >> >> "GCParTask" >> >> >> Just my thoughts. And regarding having 3 characters left for the >> number in the thread name I don't know if that is too important. With >> the above suggestions this will be possible in most cases but not >> all. Personally I think that is good enough. >> >> Bengt >> >> >> On 2015-03-04 15:11, David Lindholm wrote: >>> Hi Jesper, >>> >>> On 2015-03-04 14:52, Jesper Wilhelmsson wrote: >>>> Hi David, >>>> >>>> Thanks for fixing this! >>>> >>>> A couple of questions: >>>> >>>> - set_name("G1 Concurrent Refinement Thread#%d", worker_id); >>>> + set_name("G1 ConRefine#%d", worker_id); >>>> >>>> Is there any refinement threads that are not concurrent? If not, >>>> could we just call this "G1 Refine#%d" to simplify it slightly and >>>> remove an implementation detail that doesn't need to be exposed? >>>> This would also leave room for three digit numbers in case we have >>>> lots of these threads on some systems. >>> >>> I discussed this with Bengt, and his input was that Concurrent >>> Refinement is a well known concept in G1. I have no real opinion >>> here, I'm fine with both suggestions. >>> >>>> - _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking >>>> Threads", >>>> + _parallel_workers = new FlexibleWorkGang("G1 Markers", >>>> >>>> Markers is cute, but could be misunderstood. Can we call it "G1 >>>> Mark Threads" instead? >>> >>> No, it is too long, the three last character with thread number >>> won't fit (#xx). >>> >>>> - set_name("G1 Main Concurrent Mark GC Thread"); >>>> + set_name("G1 Main Marker"); >>>> >>>> Again, "Marker" could be misunderstood. I don't have a good >>>> replacement though. >>> >>> I'm open for suggestions, but I think "G1 Main Marker" works. >>> >>>> - set_name("GC task thread#%d (ParallelGC)", which); >>>> + set_name("ParGC Thread#%d", which); >>>> >>>> I don't have a good suggestion for how to make this one character >>>> shorter, but currently there is only room for two digit numbers. >>>> Maybe just "GC Thread#%d". I don't think these threads will exist >>>> at the same time as any other GC threads anyway. >>> >>> With your suggestion these threads would be called the same thing as >>> the threads in sharedHeap. I think it is nice to quickly be able to >>> see that these threads indeed belongs to the ParallelGC. >>> >>>> - set_name("Gang worker#%d (%s)", id, gang->name()); >>>> + set_name("%s#%d", gang->name(), id); >>>> >>>> Is there any limitation on the length of the name()? If it's too >>>> long the number won't show. Can we add an assert to make sure it >>>> isn't too long? >>> >>> I have gone through our current GangWorkers, and they fit. If you >>> want I can add an assert for <= 12 characters. OTOH it is not the >>> end of the world if we don't see the whole number in the debugger. >>> >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> /Jesper >>>> >>>> >>>> David Lindholm skrev den 4/3/15 13:48: >>>>> Hi, >>>>> >>>>> Please review this small fix which changes the names of the GC >>>>> threads to be >>>>> shorter and more descriptive. There is a limit on 16 characters >>>>> including the >>>>> terminating null byte for this name, since pthread_set_name_np() >>>>> is used. This >>>>> change will make it easier to debug, as these names shows up in >>>>> the debugger. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~brutisso/8073545/webrev.00/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073545 >>>>> >>>>> Testing: Passed JPRT. >>>>> >>>>> >>>>> Regards, >>>>> David >>> >> > From kirk at kodewerk.com Thu Mar 5 13:41:20 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 5 Mar 2015 13:41:20 +0000 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: References: <54F08F8A.7070901@oracle.com> <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> <54F41E05.2090905@oracle.com> <54F48C84.3060602@oracle.com> <54F5DCFA.8010900@oracle.com> <54F71F02.3030309@oracle.com> Message-ID: Hi Vitaly, I think that Erik's proposal is very good. In fact I see this as a possible initial step of easing the problems created by the current GC log formats. I just wanted to express my concerns about making unintended or arbitrary changes in the format until if and when the issues with log formats is addressed at a broader scope. Kind regards, Kirk On Mar 5, 2015, at 12:49 AM, Vitaly Davidovich wrote: > Maybe I missed it but where's the backwards incompatibility in Erik's proposal? It seems like a call for some internal type refactoring, but unless someone changes the units of a value that's output to the GC log (e.g. secs to ms), I'm not seeing the issue. > > It seems like a generally good thing to do, but likely under a separate bug/CR. The only thing I'd add is you probably don't want implicit conversions here to avoid inadvertent unit change. > > My $.02 > > sent from my phone > > On Mar 4, 2015 7:26 PM, "Kirk Pepperdine" wrote: > Hi Erik, > > In principle I agree that times should be unified. However I am concerned that we maintain backwards compatibility and only making changes to the current format if there is a compelling reason to do My reason for this is that making little piece mean changes here and there really complicates the downstream tool chain. If you were to make one big sweeping change that fixed this every where once and for all, I?d be happy to take the downstream hit. But doing this small bits at a time would be worse than fixing this particular ?problem?. > > Kind regards, > Kirk Pepperdine > > On Mar 4, 2015, at 10:16 PM, Erik ?sterlund wrote: > > > Hi Bengt, > > > > I see there are changes concerning time units and conversions, milliseconds vs seconds. This has bugged me too so thought I'd just add my opinion in this matter. > > > > Whenever dealing with a logical units such as time (seconds, milliseconds, etc) or size (words, bytes) that are mixed all over the place (sometimes for good reasons), I find it less error prone to let the type system help out automatically by annotating the types with their logical unit. As motivation, in this review there have been some human errors regarding time units, and this easily happens when conversions are manually performed. > > > > So personally I would have defined a Time type, letting time have both a physical type (e.g. double, float) AND a logical unit annotation (e.g. seconds, milliseconds) looking something like this: > > > > enum TimeUnit { > > nanoseconds = 1000000000, > > microseconds = 1000000, > > milliseconds = 1000, > > seconds = 1 > > }; > > > > template > > class Time { > > S _quantity; > > > > static inline S convert(const S quantity, TimeUnit from, TimeUnit to) { > > if (from == to) { > > return quantity; > > } else { > > return quantity * S(to) / S(from); > > } > > } > > public: > > Time(S quantity) : _quantity(quantity) {} > > template > > Time(Time other) : _quantity(convert(other.value(), U, T)) {} > > template > > Time operator =(Time other) { _quantity = convert(other.value(), U, T); } > > > > S value() const { return _quantity; } > > operator S() const { return value(); } > > Time operator +(Time other) const { return value() + other.value(); } > > Time operator -(Time other) const { return value() - other.value(); } > > }; > > > > ...and then with some convenient type aliases: > > > > typedef Time time_default_t; > > typedef Time time_secs_t; > > typedef Time time_millis_t; > > typedef Time time_micros_t; > > typedef Time time_nanos_t; > > > > ...you could do stuff like this: > > > > time_millis_t time_ms = 100.0; // value is 100.0 > > double time_prim_ms = time_ms; // value is 100.0 > > Time time_secs = time_ms; // value is 0.1f; automatically converts [milliseconds, double] to [seconds, float] > > time_default_t time_default = time_ms + time_secs; // value is 0.2; default unit is [seconds, double] > > > > ...and whenever there is a mismatch between time units that you send and the units expected in a function, it will automatically be converted to the appropriate expected type/unit. If you don't want to convert units automatically because you are scared of performance issues or something, then the type system can still at the very least help finding implicit conversions that you might want to eliminate automatically and reveal bugs related to such unit mismatches rapidly at compile time instead of after error prone manual verification. > > > > I don't know if this type of solution is interesting to you as maybe you want a single universal time unit to be used instead (such as seconds) in order to solve the problem, but thought I'd throw it out there anyway. Oh and even then I think it's clearer in a solution like this what the default time unit is supposed to be by just introspecting time_default_t instead of just "double". What do you think? > > > > Thanks, > > /Erik > > > > On 04/03/15 16:43, Bengt Rutisson wrote: > >> > >> Hi again, > >> > >> Yet another update to this webrev. I realized that I can move the > >> WorkerDataArray class from the hpp file to the cpp file. I think that's > >> worth doing to show that it is just in internal class. > >> > >> Also, I renamed the GCPhase* enums and variables to GCParPhase* to make > >> it possible to use the GCPhase* names for a possible future extension to > >> store the "single time phases" in something similar to the _gc_phases array. > >> > >> Here's an updated webrev: > >> http://cr.openjdk.java.net/~brutisso/8074037/webrev.03/ > >> > >> And here's the diff compared to the last one: > >> http://cr.openjdk.java.net/~brutisso/8074037/webrev.02-03.diff/ > >> > >> Thanks, > >> Bengt > >> > >> > >> On 2015-03-03 17:10, Bengt Rutisson wrote: > >>> > >>> Hi all, > >>> > >>> After some testing I noticed that I had done all my testing with > >>> StringDedup enabled. The code did not work properly with it disabled > >>> since StringDedup reported times for full GCs and concurrent marking > >>> even though it was not logged anywhere. I changed the code to only > >>> report times when the times will be reported as part of a GC. > >>> > >>> Here's an updated webrev: > >>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.02/ > >>> > >>> And a diff compared to the last review: > >>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.01-02.diff/ > >>> > >>> Thanks, > >>> Bengt > >>> > >>> On 2015-03-02 17:15, Bengt Rutisson wrote: > >>>> > >>>> Hi again, > >>>> > >>>> Here is an updated webrev: > >>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.01/ > >>>> > >>>> And here's the diff compared to the last webrev: > >>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00-01.diff/ > >>>> > >>>> I tried to clean up the seconds vs. milliseconds confusion by making > >>>> it G1GCPhaseTimes' responsibility to handle the conversion in all > >>>> cases. So, the interface is now that times are reported in seconds > >>>> (for example G1GCPhaseTimes::record_time_secs()) but returned in > >>>> milliseconds (for example G1GCPhaseTimes::average_time_ms()). I > >>>> suffixed the method names "_secs" and "_ms" to make it easier to > >>>> follow the code. > >>>> > >>>> I'm not very happy about this inconsistency, but I want it to be an > >>>> intermediate step on the way to getting rid of os::elapsedTime() > >>>> completely. > >>>> > >>>> StefanK also suggested to move the logging code out to its own class. > >>>> This simplified the logging quite a bit I think. The class, > >>>> G1GCPhasePrinter, has to know a lot about both G1GCPhaseTimes and > >>>> WorkerDataArray, but I still think it is nice to have the logging > >>>> separated out. > >>>> > >>>> I didn't read Thomas' email with comments until after I had prepared > >>>> this updated webrev. But I think I have addressed the issues brought > >>>> up there. Thanks for looking at this, Thomas! > >>>> > >>>> Bengt > >>>> > >>>> On 2015-03-02 09:23, Bengt Rutisson wrote: > >>>>> > >>>>> Hi Kim, > >>>>> > >>>>> Thanks for looking at this! > >>>>> > >>>>> On 2015-02-28 00:43, Kim Barrett wrote: > >>>>>> On Feb 27, 2015, at 10:38 AM, Bengt Rutisson > >>>>>> wrote: > >>>>>>> Can I have a couple of reviews for this cleanup change? > >>>>>>> > >>>>>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00/ > >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8074037 > >>>>>>> > >>>>>>> [?] > >>>>>>> The patch also introduces a new class called > >>>>>>> G1GCPhaseTimesTracker, which is a scoped object to simplify time > >>>>>>> measurements. I've also tried to move conversion of times down to > >>>>>>> when we print the log messages instead of when we store them. This > >>>>>>> removes several "* 1000.0" in the code. Eventually I would like to > >>>>>>> replace os::elapsedTime() with os::elapsed_counter(). But that > >>>>>>> should be done as a separate patch. > >>>>>> Before I proceed any further with this review, I feel like I'm getting > >>>>>> lost in unit changes. In some places values of msecs used to be used > >>>>>> but now we're using secs, right? But it seems like there might be some > >>>>>> confusion about that, and I'm not sure whether it's me or the code > >>>>>> that's confused. > >>>>>> > >>>>>> For example: > >>>>>> > >>>>>> src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp > >>>>>> 1079 cost_per_card_ms = > >>>>>> phase_times()->average_time(G1GCPhaseTimes::UpdateRS) / (double) > >>>>>> _pending_cards; > >>>>>> 1080 _cost_per_card_ms_seq->add(cost_per_card_ms); > >>>>>> > >>>>>> I think the values that have been recorded in the phase_times are > >>>>>> secs, and average_time appears to just use the values as is. So > >>>>>> shouldn't that now be cost_per_card_secs? And the value added to > >>>>>> _cost_per_card_ms_seq needs to be cost_per_card_secs * 1000.0? > >>>>> > >>>>> Right! Good catch! I was so happy to get rid of some of the "* > >>>>> 1000.0" statements sprinkled all over the G1 code that I forgot to > >>>>> add some of them back ;) > >>>>> > >>>>> I'll send out an updated webrev soon. > >>>>> > >>>>> Bengt > >>>>> > >>>>>> > >>>>>> Oh how I wish for a units package! > >>>>>> > >>>>> > >>>> > >>> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From erik.helin at oracle.com Thu Mar 5 13:41:40 2015 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 5 Mar 2015 14:41:40 +0100 Subject: RFR: 8073545 - Use shorter and more descriptive names for GC worker threads In-Reply-To: <54F82F48.3050005@oracle.com> References: <54F6FF0F.3030609@oracle.com> <54F70E1D.7030101@oracle.com> <54F7129B.8050009@oracle.com> <54F723A7.6080008@oracle.com> <54F82F48.3050005@oracle.com> Message-ID: <20150305134140.GD3269@ehelin.jrpg.bea.com> On 2015-03-05, David Lindholm wrote: > Hi, > > Thanks for your input. To me, threads and tasks are different things. A task > is something a thread can do for a while, but when it is finished with that > task it can pick something else to do (another task). This view seems to be > reflected in gcTaskThread.cpp (the thread for running tasks in > parallelScavenge). After creation, it runs different tasks managed by > gcTaskManager. These tasks are called names ending with "task". > > But I agree that in most cases the word Thread is unnecessary (this was why > I called the Marker Thread "Marker"). But I don't have anything against > using up all the 15 chars (we should not shorten the name unnecessarily). > > My new suggestion: > > "CMS Thread#xxx" > "CMS Main Thread" > "G1 Refine#xxx" > "G1 Marker#xxx" > "G1 Main Marker" > "G1 StrDedup#xxx" > "ParGC Thread#xx" > "GC Thread#xxx" These names looks good to me. I also had a look at the patch and noticed: - set_name("GC task thread#%d (ParallelGC)", which); +// set_name("GC task thread#%d (ParallelGC)", which); Could you please remove the line you commented out? Thanks, Erik > This way our threads naming scheme will be aligned with the rest of the JVM. > One could argue if '#' is necessary. We could leave it out or print '-' > instead. The CompilerThreads leave them out. > > > Thanks, > David > > On 2015-03-04 16:24, Bengt Rutisson wrote: > > > >Hi David and everyone, > > > >Naming is the most difficult part of computer science so I doubt that > >there is an easy answer here. Given that the names are for debugging I > >guess it is not too important exactly what the names are. More important > >is that they are unique. I also think that there is really no need to have > >"thread" in the name since it is pretty obvious that it is a thread. > > > >So, my suggestion would be to skip "thread" and to use CamelCase rather > >than using spaces to save some characters. > > > >I don't have strong opinions on this, but here's what I'd suggest: > > > >- _conc_workers = new YieldingFlexibleWorkGang("Parallel CMS > >Threads", > >+ _conc_workers = new YieldingFlexibleWorkGang("CMS Threads", > > > >"CMSTask" > > > > > > > >- set_name("Concurrent Mark-Sweep GC Thread"); > >+ set_name("CMS Main Thread"); > > > >"CMSMain" > > > > > > > >- set_name("G1 Concurrent Refinement Thread#%d", worker_id); > >+ set_name("G1 ConRefine#%d", worker_id); > > > >"G1ConcRefine#%d" > > > > > > > >- _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking Threads", > >+ _parallel_workers = new FlexibleWorkGang("G1 Markers" > > > >"G1MarkTask" > > > > > > > >- set_name("G1 Main Concurrent Mark GC Thread"); > >+ set_name("G1 Main Marker"); > > > >"G1ConcMark" > > > > > > > >- set_name("String Deduplication Thread"); > >+ set_name("StrDedup Thread"); > > > >"StringDedup" > > > > > > > >- set_name("GC task thread#%d (ParallelGC)", which); > >+ set_name("ParGC Thread#%d", which); > > > >"ParGCTask" > > > > > > > >- _workers = new FlexibleWorkGang("Parallel GC Threads", > >ParallelGCThreads, > >+ _workers = new FlexibleWorkGang("GC Threads", ParallelGCThreads, > > > >"GCParTask" > > > > > >Just my thoughts. And regarding having 3 characters left for the number in > >the thread name I don't know if that is too important. With the above > >suggestions this will be possible in most cases but not all. Personally I > >think that is good enough. > > > >Bengt > > > > > >On 2015-03-04 15:11, David Lindholm wrote: > >>Hi Jesper, > >> > >>On 2015-03-04 14:52, Jesper Wilhelmsson wrote: > >>>Hi David, > >>> > >>>Thanks for fixing this! > >>> > >>>A couple of questions: > >>> > >>>- set_name("G1 Concurrent Refinement Thread#%d", worker_id); > >>>+ set_name("G1 ConRefine#%d", worker_id); > >>> > >>>Is there any refinement threads that are not concurrent? If not, could > >>>we just call this "G1 Refine#%d" to simplify it slightly and remove an > >>>implementation detail that doesn't need to be exposed? This would also > >>>leave room for three digit numbers in case we have lots of these > >>>threads on some systems. > >> > >>I discussed this with Bengt, and his input was that Concurrent > >>Refinement is a well known concept in G1. I have no real opinion here, > >>I'm fine with both suggestions. > >> > >>>- _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking > >>>Threads", > >>>+ _parallel_workers = new FlexibleWorkGang("G1 Markers", > >>> > >>>Markers is cute, but could be misunderstood. Can we call it "G1 Mark > >>>Threads" instead? > >> > >>No, it is too long, the three last character with thread number won't > >>fit (#xx). > >> > >>>- set_name("G1 Main Concurrent Mark GC Thread"); > >>>+ set_name("G1 Main Marker"); > >>> > >>>Again, "Marker" could be misunderstood. I don't have a good > >>>replacement though. > >> > >>I'm open for suggestions, but I think "G1 Main Marker" works. > >> > >>>- set_name("GC task thread#%d (ParallelGC)", which); > >>>+ set_name("ParGC Thread#%d", which); > >>> > >>>I don't have a good suggestion for how to make this one character > >>>shorter, but currently there is only room for two digit numbers. Maybe > >>>just "GC Thread#%d". I don't think these threads will exist at the > >>>same time as any other GC threads anyway. > >> > >>With your suggestion these threads would be called the same thing as the > >>threads in sharedHeap. I think it is nice to quickly be able to see that > >>these threads indeed belongs to the ParallelGC. > >> > >>>- set_name("Gang worker#%d (%s)", id, gang->name()); > >>>+ set_name("%s#%d", gang->name(), id); > >>> > >>>Is there any limitation on the length of the name()? If it's too long > >>>the number won't show. Can we add an assert to make sure it isn't too > >>>long? > >> > >>I have gone through our current GangWorkers, and they fit. If you want I > >>can add an assert for <= 12 characters. OTOH it is not the end of the > >>world if we don't see the whole number in the debugger. > >> > >> > >>Thanks, > >>David > >> > >>> > >>>Thanks, > >>>/Jesper > >>> > >>> > >>>David Lindholm skrev den 4/3/15 13:48: > >>>>Hi, > >>>> > >>>>Please review this small fix which changes the names of the GC > >>>>threads to be > >>>>shorter and more descriptive. There is a limit on 16 characters > >>>>including the > >>>>terminating null byte for this name, since pthread_set_name_np() is > >>>>used. This > >>>>change will make it easier to debug, as these names shows up in the > >>>>debugger. > >>>> > >>>>Webrev: http://cr.openjdk.java.net/~brutisso/8073545/webrev.00/ > >>>>Bug: https://bugs.openjdk.java.net/browse/JDK-8073545 > >>>> > >>>>Testing: Passed JPRT. > >>>> > >>>> > >>>>Regards, > >>>>David > >> > > > From thomas.schatzl at oracle.com Thu Mar 5 14:58:11 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 05 Mar 2015 15:58:11 +0100 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <1425482904.3305.27.camel@oracle.com> References: <1425482904.3305.27.camel@oracle.com> Message-ID: <1425567491.3140.42.camel@oracle.com> Hi all, On Wed, 2015-03-04 at 16:28 +0100, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the following change that does some renamings > in the allocation related class hierarchy, also adding a few lines of > documentation. > > This change is intentionally limited to renames to keep it simple, in a > subsequent patch there will be more cleanup changes, moving methods > around. > Also, if there is demand, I am open to rename the files to something > different (suggestions?) in a follow-up change (to not confuse the > webrev tool too much). > > CR: > https://bugs.openjdk.java.net/browse/JDK-8073052 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.00/ > Testing: I talked with Stefan Johansson a bit about the change, with the result that we keep the name of G1Allocator, since in the upcoming changes (see below for more) that class is supposed to handle all allocations within the current allocation regions. Webrev: http://cr.openjdk.java.net/~tschatzl/8073052/webrev.01 Except for undoing the renaming of G1Allocator to G1AllocRegionManager, this change - removes some methods in G1CollectedHeap that were unused and do not have any implementation any more - moves methods from G1Allocator back to G1CollectedHeap that give information about the entire heap (e.g. related to _summary_bytes_used) as G1Allocator is about managing the current allocation regions only. - moves the new_heap_region() functionality back to G1CollectedHeap; it seems to have been moved only because this allowed easy override using the extension mechanism for closed additions. Its implementation has simply been moved to the g1CollectedHeap_ext.cpp file, achieving the same effect without cluttering the G1Allocator interface. Background of the upcoming changes: This is the second change that is part of the investigation of high fragmentation and waste during gc in g1 (JDK-8030849). This particular change forms the basis for the following further changes (in that order): JDK-8073013 - Add detailed information about PLAB memory usage JDK-8040162 - Avoid reallocating PLABs between GC phases in G1 JDK-8067336 - Allow that PLAB allocations at the end of regions are flexible JDK-8067339 - PLAB reallocation might result in failure to allocate object in that recently allocated PLAB JDK-8067341 - Modify PLAB sizing algorithm to waste less JDK-8073317 - Move all region level allocation related things into AllocRegionManager JDK-8067433 - Keep waste at end of regions for further allocation during GC (There may be more intermediate steps depending on reviews). (During the investigation of JDK-8030849 even more issues were found, they might be added later, but typically they do not directly affect memory allocation performance during gc) That results in a substantial decrease in memory use during allocation, while setting higher PLAB sizes than the defaults used with -XX:-ResizePLAB. Applications that have a high number of mid-sized objects show an improvement in throughput of 5%, for others there is no measurable difference. The changes decrease the number of young gcs dramatically, allowing G1 to have more time for liveness analysis (marking). Which means that there is less possibility that g1 runs into a full gc. Since all of these CRs work in the same area I would like to avoid posting RFRs for all of them at the same time; however I put up a preliminary webrev up to and including JDK-8073317 at: http://cr.openjdk.java.net/~tschatzl/8073052/webrev.outlook Probably most interesting is the resulting interfaces in g1Allocator.hpp, at http://cr.openjdk.java.net/~tschatzl/8073052/webrev.outlook/src/share/vm/gc_implementation/g1/g1Allocator.hpp.html and how much related stuff (and friend declarations) can be removed in G1CollectedHeap: http://cr.openjdk.java.net/~tschatzl/8073052/webrev.outlook/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp.udiff.html Thanks, Thomas From david.lindholm at oracle.com Thu Mar 5 14:59:56 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Thu, 05 Mar 2015 15:59:56 +0100 Subject: RFR: 8073545 - Use shorter and more descriptive names for GC worker threads In-Reply-To: <20150305134140.GD3269@ehelin.jrpg.bea.com> References: <54F6FF0F.3030609@oracle.com> <54F70E1D.7030101@oracle.com> <54F7129B.8050009@oracle.com> <54F723A7.6080008@oracle.com> <54F82F48.3050005@oracle.com> <20150305134140.GD3269@ehelin.jrpg.bea.com> Message-ID: <54F86F6C.9040800@oracle.com> Hi, Thanks. New webrev available at: http://cr.openjdk.java.net/~mgerdin/david/8073545/webrev.01/ Regards, David On 2015-03-05 14:41, Erik Helin wrote: > On 2015-03-05, David Lindholm wrote: >> Hi, >> >> Thanks for your input. To me, threads and tasks are different things. A task >> is something a thread can do for a while, but when it is finished with that >> task it can pick something else to do (another task). This view seems to be >> reflected in gcTaskThread.cpp (the thread for running tasks in >> parallelScavenge). After creation, it runs different tasks managed by >> gcTaskManager. These tasks are called names ending with "task". >> >> But I agree that in most cases the word Thread is unnecessary (this was why >> I called the Marker Thread "Marker"). But I don't have anything against >> using up all the 15 chars (we should not shorten the name unnecessarily). >> >> My new suggestion: >> >> "CMS Thread#xxx" >> "CMS Main Thread" >> "G1 Refine#xxx" >> "G1 Marker#xxx" >> "G1 Main Marker" >> "G1 StrDedup#xxx" >> "ParGC Thread#xx" >> "GC Thread#xxx" > These names looks good to me. I also had a look at the patch and > noticed: > - set_name("GC task thread#%d (ParallelGC)", which); > +// set_name("GC task thread#%d (ParallelGC)", which); > > Could you please remove the line you commented out? > > Thanks, > Erik > >> This way our threads naming scheme will be aligned with the rest of the JVM. >> One could argue if '#' is necessary. We could leave it out or print '-' >> instead. The CompilerThreads leave them out. >> >> >> Thanks, >> David >> >> On 2015-03-04 16:24, Bengt Rutisson wrote: >>> Hi David and everyone, >>> >>> Naming is the most difficult part of computer science so I doubt that >>> there is an easy answer here. Given that the names are for debugging I >>> guess it is not too important exactly what the names are. More important >>> is that they are unique. I also think that there is really no need to have >>> "thread" in the name since it is pretty obvious that it is a thread. >>> >>> So, my suggestion would be to skip "thread" and to use CamelCase rather >>> than using spaces to save some characters. >>> >>> I don't have strong opinions on this, but here's what I'd suggest: >>> >>> - _conc_workers = new YieldingFlexibleWorkGang("Parallel CMS >>> Threads", >>> + _conc_workers = new YieldingFlexibleWorkGang("CMS Threads", >>> >>> "CMSTask" >>> >>> >>> >>> - set_name("Concurrent Mark-Sweep GC Thread"); >>> + set_name("CMS Main Thread"); >>> >>> "CMSMain" >>> >>> >>> >>> - set_name("G1 Concurrent Refinement Thread#%d", worker_id); >>> + set_name("G1 ConRefine#%d", worker_id); >>> >>> "G1ConcRefine#%d" >>> >>> >>> >>> - _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking Threads", >>> + _parallel_workers = new FlexibleWorkGang("G1 Markers" >>> >>> "G1MarkTask" >>> >>> >>> >>> - set_name("G1 Main Concurrent Mark GC Thread"); >>> + set_name("G1 Main Marker"); >>> >>> "G1ConcMark" >>> >>> >>> >>> - set_name("String Deduplication Thread"); >>> + set_name("StrDedup Thread"); >>> >>> "StringDedup" >>> >>> >>> >>> - set_name("GC task thread#%d (ParallelGC)", which); >>> + set_name("ParGC Thread#%d", which); >>> >>> "ParGCTask" >>> >>> >>> >>> - _workers = new FlexibleWorkGang("Parallel GC Threads", >>> ParallelGCThreads, >>> + _workers = new FlexibleWorkGang("GC Threads", ParallelGCThreads, >>> >>> "GCParTask" >>> >>> >>> Just my thoughts. And regarding having 3 characters left for the number in >>> the thread name I don't know if that is too important. With the above >>> suggestions this will be possible in most cases but not all. Personally I >>> think that is good enough. >>> >>> Bengt >>> >>> >>> On 2015-03-04 15:11, David Lindholm wrote: >>>> Hi Jesper, >>>> >>>> On 2015-03-04 14:52, Jesper Wilhelmsson wrote: >>>>> Hi David, >>>>> >>>>> Thanks for fixing this! >>>>> >>>>> A couple of questions: >>>>> >>>>> - set_name("G1 Concurrent Refinement Thread#%d", worker_id); >>>>> + set_name("G1 ConRefine#%d", worker_id); >>>>> >>>>> Is there any refinement threads that are not concurrent? If not, could >>>>> we just call this "G1 Refine#%d" to simplify it slightly and remove an >>>>> implementation detail that doesn't need to be exposed? This would also >>>>> leave room for three digit numbers in case we have lots of these >>>>> threads on some systems. >>>> I discussed this with Bengt, and his input was that Concurrent >>>> Refinement is a well known concept in G1. I have no real opinion here, >>>> I'm fine with both suggestions. >>>> >>>>> - _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking >>>>> Threads", >>>>> + _parallel_workers = new FlexibleWorkGang("G1 Markers", >>>>> >>>>> Markers is cute, but could be misunderstood. Can we call it "G1 Mark >>>>> Threads" instead? >>>> No, it is too long, the three last character with thread number won't >>>> fit (#xx). >>>> >>>>> - set_name("G1 Main Concurrent Mark GC Thread"); >>>>> + set_name("G1 Main Marker"); >>>>> >>>>> Again, "Marker" could be misunderstood. I don't have a good >>>>> replacement though. >>>> I'm open for suggestions, but I think "G1 Main Marker" works. >>>> >>>>> - set_name("GC task thread#%d (ParallelGC)", which); >>>>> + set_name("ParGC Thread#%d", which); >>>>> >>>>> I don't have a good suggestion for how to make this one character >>>>> shorter, but currently there is only room for two digit numbers. Maybe >>>>> just "GC Thread#%d". I don't think these threads will exist at the >>>>> same time as any other GC threads anyway. >>>> With your suggestion these threads would be called the same thing as the >>>> threads in sharedHeap. I think it is nice to quickly be able to see that >>>> these threads indeed belongs to the ParallelGC. >>>> >>>>> - set_name("Gang worker#%d (%s)", id, gang->name()); >>>>> + set_name("%s#%d", gang->name(), id); >>>>> >>>>> Is there any limitation on the length of the name()? If it's too long >>>>> the number won't show. Can we add an assert to make sure it isn't too >>>>> long? >>>> I have gone through our current GangWorkers, and they fit. If you want I >>>> can add an assert for <= 12 characters. OTOH it is not the end of the >>>> world if we don't see the whole number in the debugger. >>>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> /Jesper >>>>> >>>>> >>>>> David Lindholm skrev den 4/3/15 13:48: >>>>>> Hi, >>>>>> >>>>>> Please review this small fix which changes the names of the GC >>>>>> threads to be >>>>>> shorter and more descriptive. There is a limit on 16 characters >>>>>> including the >>>>>> terminating null byte for this name, since pthread_set_name_np() is >>>>>> used. This >>>>>> change will make it easier to debug, as these names shows up in the >>>>>> debugger. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~brutisso/8073545/webrev.00/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073545 >>>>>> >>>>>> Testing: Passed JPRT. >>>>>> >>>>>> >>>>>> Regards, >>>>>> David From thomas.schatzl at oracle.com Thu Mar 5 15:00:33 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 05 Mar 2015 16:00:33 +0100 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <1425567491.3140.42.camel@oracle.com> References: <1425482904.3305.27.camel@oracle.com> <1425567491.3140.42.camel@oracle.com> Message-ID: <1425567633.3140.44.camel@oracle.com> Hi again, please hold off on looking at this, I hit the send button too early :( Thomas On Thu, 2015-03-05 at 15:58 +0100, Thomas Schatzl wrote: > Hi all, > > On Wed, 2015-03-04 at 16:28 +0100, Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for the following change that does some renamings > > in the allocation related class hierarchy, also adding a few lines of > > documentation. > > > > This change is intentionally limited to renames to keep it simple, in a > > subsequent patch there will be more cleanup changes, moving methods > > around. > > Also, if there is demand, I am open to rename the files to something > > different (suggestions?) in a follow-up change (to not confuse the > > webrev tool too much). > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8073052 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.00/ > > Testing: > > I talked with Stefan Johansson a bit about the change, with the result > that we keep the name of G1Allocator, since in the upcoming changes (see > below for more) that class is supposed to handle all allocations within > the current allocation regions. > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.01 > > Except for undoing the renaming of G1Allocator to G1AllocRegionManager, > this change > - removes some methods in G1CollectedHeap that were unused and do not > have any implementation any more > - moves methods from G1Allocator back to G1CollectedHeap that give > information about the entire heap (e.g. related to _summary_bytes_used) > as G1Allocator is about managing the current allocation regions only. > - moves the new_heap_region() functionality back to G1CollectedHeap; it > seems to have been moved only because this allowed easy override using > the extension mechanism for closed additions. Its implementation has > simply been moved to the g1CollectedHeap_ext.cpp file, achieving the > same effect without cluttering the G1Allocator interface. > > Background of the upcoming changes: > > This is the second change that is part of the investigation of high > fragmentation and waste during gc in g1 (JDK-8030849). > > This particular change forms the basis for the following further changes > (in that order): > JDK-8073013 - Add detailed information about PLAB memory usage > JDK-8040162 - Avoid reallocating PLABs between GC phases in G1 > JDK-8067336 - Allow that PLAB allocations at the end of regions are > flexible > JDK-8067339 - PLAB reallocation might result in failure to allocate > object in that recently allocated PLAB > JDK-8067341 - Modify PLAB sizing algorithm to waste less > JDK-8073317 - Move all region level allocation related things into > AllocRegionManager > JDK-8067433 - Keep waste at end of regions for further allocation during > GC > > (There may be more intermediate steps depending on reviews). > (During the investigation of JDK-8030849 even more issues were found, > they might be added later, but typically they do not directly affect > memory allocation performance during gc) > > That results in a substantial decrease in memory use during allocation, > while setting higher PLAB sizes than the defaults used with > -XX:-ResizePLAB. Applications that have a high number of mid-sized > objects show an improvement in throughput of 5%, for others there is no > measurable difference. The changes decrease the number of young gcs > dramatically, allowing G1 to have more time for liveness analysis > (marking). Which means that there is less possibility that g1 runs into > a full gc. > > Since all of these CRs work in the same area I would like to avoid > posting RFRs for all of them at the same time; however I put up a > preliminary webrev up to and including JDK-8073317 at: > > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.outlook > > Probably most interesting is the resulting interfaces in > g1Allocator.hpp, at > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.outlook/src/share/vm/gc_implementation/g1/g1Allocator.hpp.html > and how much related stuff (and friend declarations) can be removed in > G1CollectedHeap: > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.outlook/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp.udiff.html > > Thanks, > Thomas > > From erik.helin at oracle.com Thu Mar 5 15:14:51 2015 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 5 Mar 2015 16:14:51 +0100 Subject: RFR: 8073545 - Use shorter and more descriptive names for GC worker threads In-Reply-To: <54F86F6C.9040800@oracle.com> References: <54F6FF0F.3030609@oracle.com> <54F70E1D.7030101@oracle.com> <54F7129B.8050009@oracle.com> <54F723A7.6080008@oracle.com> <54F82F48.3050005@oracle.com> <20150305134140.GD3269@ehelin.jrpg.bea.com> <54F86F6C.9040800@oracle.com> Message-ID: <20150305151451.GE3269@ehelin.jrpg.bea.com> On 2015-03-05, David Lindholm wrote: > Hi, > > Thanks. New webrev available at: > http://cr.openjdk.java.net/~mgerdin/david/8073545/webrev.01/ Looks good to me, Reviewed. Thanks, Erik > Regards, > David > > On 2015-03-05 14:41, Erik Helin wrote: > >On 2015-03-05, David Lindholm wrote: > >>Hi, > >> > >>Thanks for your input. To me, threads and tasks are different things. A task > >>is something a thread can do for a while, but when it is finished with that > >>task it can pick something else to do (another task). This view seems to be > >>reflected in gcTaskThread.cpp (the thread for running tasks in > >>parallelScavenge). After creation, it runs different tasks managed by > >>gcTaskManager. These tasks are called names ending with "task". > >> > >>But I agree that in most cases the word Thread is unnecessary (this was why > >>I called the Marker Thread "Marker"). But I don't have anything against > >>using up all the 15 chars (we should not shorten the name unnecessarily). > >> > >>My new suggestion: > >> > >>"CMS Thread#xxx" > >>"CMS Main Thread" > >>"G1 Refine#xxx" > >>"G1 Marker#xxx" > >>"G1 Main Marker" > >>"G1 StrDedup#xxx" > >>"ParGC Thread#xx" > >>"GC Thread#xxx" > >These names looks good to me. I also had a look at the patch and > >noticed: > >- set_name("GC task thread#%d (ParallelGC)", which); > >+// set_name("GC task thread#%d (ParallelGC)", which); > > > >Could you please remove the line you commented out? > > > >Thanks, > >Erik > > > >>This way our threads naming scheme will be aligned with the rest of the JVM. > >>One could argue if '#' is necessary. We could leave it out or print '-' > >>instead. The CompilerThreads leave them out. > >> > >> > >>Thanks, > >>David > >> > >>On 2015-03-04 16:24, Bengt Rutisson wrote: > >>>Hi David and everyone, > >>> > >>>Naming is the most difficult part of computer science so I doubt that > >>>there is an easy answer here. Given that the names are for debugging I > >>>guess it is not too important exactly what the names are. More important > >>>is that they are unique. I also think that there is really no need to have > >>>"thread" in the name since it is pretty obvious that it is a thread. > >>> > >>>So, my suggestion would be to skip "thread" and to use CamelCase rather > >>>than using spaces to save some characters. > >>> > >>>I don't have strong opinions on this, but here's what I'd suggest: > >>> > >>>- _conc_workers = new YieldingFlexibleWorkGang("Parallel CMS > >>>Threads", > >>>+ _conc_workers = new YieldingFlexibleWorkGang("CMS Threads", > >>> > >>>"CMSTask" > >>> > >>> > >>> > >>>- set_name("Concurrent Mark-Sweep GC Thread"); > >>>+ set_name("CMS Main Thread"); > >>> > >>>"CMSMain" > >>> > >>> > >>> > >>>- set_name("G1 Concurrent Refinement Thread#%d", worker_id); > >>>+ set_name("G1 ConRefine#%d", worker_id); > >>> > >>>"G1ConcRefine#%d" > >>> > >>> > >>> > >>>- _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking Threads", > >>>+ _parallel_workers = new FlexibleWorkGang("G1 Markers" > >>> > >>>"G1MarkTask" > >>> > >>> > >>> > >>>- set_name("G1 Main Concurrent Mark GC Thread"); > >>>+ set_name("G1 Main Marker"); > >>> > >>>"G1ConcMark" > >>> > >>> > >>> > >>>- set_name("String Deduplication Thread"); > >>>+ set_name("StrDedup Thread"); > >>> > >>>"StringDedup" > >>> > >>> > >>> > >>>- set_name("GC task thread#%d (ParallelGC)", which); > >>>+ set_name("ParGC Thread#%d", which); > >>> > >>>"ParGCTask" > >>> > >>> > >>> > >>>- _workers = new FlexibleWorkGang("Parallel GC Threads", > >>>ParallelGCThreads, > >>>+ _workers = new FlexibleWorkGang("GC Threads", ParallelGCThreads, > >>> > >>>"GCParTask" > >>> > >>> > >>>Just my thoughts. And regarding having 3 characters left for the number in > >>>the thread name I don't know if that is too important. With the above > >>>suggestions this will be possible in most cases but not all. Personally I > >>>think that is good enough. > >>> > >>>Bengt > >>> > >>> > >>>On 2015-03-04 15:11, David Lindholm wrote: > >>>>Hi Jesper, > >>>> > >>>>On 2015-03-04 14:52, Jesper Wilhelmsson wrote: > >>>>>Hi David, > >>>>> > >>>>>Thanks for fixing this! > >>>>> > >>>>>A couple of questions: > >>>>> > >>>>>- set_name("G1 Concurrent Refinement Thread#%d", worker_id); > >>>>>+ set_name("G1 ConRefine#%d", worker_id); > >>>>> > >>>>>Is there any refinement threads that are not concurrent? If not, could > >>>>>we just call this "G1 Refine#%d" to simplify it slightly and remove an > >>>>>implementation detail that doesn't need to be exposed? This would also > >>>>>leave room for three digit numbers in case we have lots of these > >>>>>threads on some systems. > >>>>I discussed this with Bengt, and his input was that Concurrent > >>>>Refinement is a well known concept in G1. I have no real opinion here, > >>>>I'm fine with both suggestions. > >>>> > >>>>>- _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking > >>>>>Threads", > >>>>>+ _parallel_workers = new FlexibleWorkGang("G1 Markers", > >>>>> > >>>>>Markers is cute, but could be misunderstood. Can we call it "G1 Mark > >>>>>Threads" instead? > >>>>No, it is too long, the three last character with thread number won't > >>>>fit (#xx). > >>>> > >>>>>- set_name("G1 Main Concurrent Mark GC Thread"); > >>>>>+ set_name("G1 Main Marker"); > >>>>> > >>>>>Again, "Marker" could be misunderstood. I don't have a good > >>>>>replacement though. > >>>>I'm open for suggestions, but I think "G1 Main Marker" works. > >>>> > >>>>>- set_name("GC task thread#%d (ParallelGC)", which); > >>>>>+ set_name("ParGC Thread#%d", which); > >>>>> > >>>>>I don't have a good suggestion for how to make this one character > >>>>>shorter, but currently there is only room for two digit numbers. Maybe > >>>>>just "GC Thread#%d". I don't think these threads will exist at the > >>>>>same time as any other GC threads anyway. > >>>>With your suggestion these threads would be called the same thing as the > >>>>threads in sharedHeap. I think it is nice to quickly be able to see that > >>>>these threads indeed belongs to the ParallelGC. > >>>> > >>>>>- set_name("Gang worker#%d (%s)", id, gang->name()); > >>>>>+ set_name("%s#%d", gang->name(), id); > >>>>> > >>>>>Is there any limitation on the length of the name()? If it's too long > >>>>>the number won't show. Can we add an assert to make sure it isn't too > >>>>>long? > >>>>I have gone through our current GangWorkers, and they fit. If you want I > >>>>can add an assert for <= 12 characters. OTOH it is not the end of the > >>>>world if we don't see the whole number in the debugger. > >>>> > >>>> > >>>>Thanks, > >>>>David > >>>> > >>>>>Thanks, > >>>>>/Jesper > >>>>> > >>>>> > >>>>>David Lindholm skrev den 4/3/15 13:48: > >>>>>>Hi, > >>>>>> > >>>>>>Please review this small fix which changes the names of the GC > >>>>>>threads to be > >>>>>>shorter and more descriptive. There is a limit on 16 characters > >>>>>>including the > >>>>>>terminating null byte for this name, since pthread_set_name_np() is > >>>>>>used. This > >>>>>>change will make it easier to debug, as these names shows up in the > >>>>>>debugger. > >>>>>> > >>>>>>Webrev: http://cr.openjdk.java.net/~brutisso/8073545/webrev.00/ > >>>>>>Bug: https://bugs.openjdk.java.net/browse/JDK-8073545 > >>>>>> > >>>>>>Testing: Passed JPRT. > >>>>>> > >>>>>> > >>>>>>Regards, > >>>>>>David > From jesper.wilhelmsson at oracle.com Thu Mar 5 16:19:23 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 05 Mar 2015 17:19:23 +0100 Subject: RFR: 8073545 - Use shorter and more descriptive names for GC worker threads In-Reply-To: <54F86F6C.9040800@oracle.com> References: <54F6FF0F.3030609@oracle.com> <54F70E1D.7030101@oracle.com> <54F7129B.8050009@oracle.com> <54F723A7.6080008@oracle.com> <54F82F48.3050005@oracle.com> <20150305134140.GD3269@ehelin.jrpg.bea.com> <54F86F6C.9040800@oracle.com> Message-ID: <54F8820B.6070604@oracle.com> Looks good! /Jesper David Lindholm skrev den 5/3/15 15:59: > Hi, > > Thanks. New webrev available at: > http://cr.openjdk.java.net/~mgerdin/david/8073545/webrev.01/ > > > Regards, > David > > On 2015-03-05 14:41, Erik Helin wrote: >> On 2015-03-05, David Lindholm wrote: >>> Hi, >>> >>> Thanks for your input. To me, threads and tasks are different things. A task >>> is something a thread can do for a while, but when it is finished with that >>> task it can pick something else to do (another task). This view seems to be >>> reflected in gcTaskThread.cpp (the thread for running tasks in >>> parallelScavenge). After creation, it runs different tasks managed by >>> gcTaskManager. These tasks are called names ending with "task". >>> >>> But I agree that in most cases the word Thread is unnecessary (this was why >>> I called the Marker Thread "Marker"). But I don't have anything against >>> using up all the 15 chars (we should not shorten the name unnecessarily). >>> >>> My new suggestion: >>> >>> "CMS Thread#xxx" >>> "CMS Main Thread" >>> "G1 Refine#xxx" >>> "G1 Marker#xxx" >>> "G1 Main Marker" >>> "G1 StrDedup#xxx" >>> "ParGC Thread#xx" >>> "GC Thread#xxx" >> These names looks good to me. I also had a look at the patch and >> noticed: >> - set_name("GC task thread#%d (ParallelGC)", which); >> +// set_name("GC task thread#%d (ParallelGC)", which); >> >> Could you please remove the line you commented out? >> >> Thanks, >> Erik >> >>> This way our threads naming scheme will be aligned with the rest of the JVM. >>> One could argue if '#' is necessary. We could leave it out or print '-' >>> instead. The CompilerThreads leave them out. >>> >>> >>> Thanks, >>> David >>> >>> On 2015-03-04 16:24, Bengt Rutisson wrote: >>>> Hi David and everyone, >>>> >>>> Naming is the most difficult part of computer science so I doubt that >>>> there is an easy answer here. Given that the names are for debugging I >>>> guess it is not too important exactly what the names are. More important >>>> is that they are unique. I also think that there is really no need to have >>>> "thread" in the name since it is pretty obvious that it is a thread. >>>> >>>> So, my suggestion would be to skip "thread" and to use CamelCase rather >>>> than using spaces to save some characters. >>>> >>>> I don't have strong opinions on this, but here's what I'd suggest: >>>> >>>> - _conc_workers = new YieldingFlexibleWorkGang("Parallel CMS >>>> Threads", >>>> + _conc_workers = new YieldingFlexibleWorkGang("CMS Threads", >>>> >>>> "CMSTask" >>>> >>>> >>>> >>>> - set_name("Concurrent Mark-Sweep GC Thread"); >>>> + set_name("CMS Main Thread"); >>>> >>>> "CMSMain" >>>> >>>> >>>> >>>> - set_name("G1 Concurrent Refinement Thread#%d", worker_id); >>>> + set_name("G1 ConRefine#%d", worker_id); >>>> >>>> "G1ConcRefine#%d" >>>> >>>> >>>> >>>> - _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking Threads", >>>> + _parallel_workers = new FlexibleWorkGang("G1 Markers" >>>> >>>> "G1MarkTask" >>>> >>>> >>>> >>>> - set_name("G1 Main Concurrent Mark GC Thread"); >>>> + set_name("G1 Main Marker"); >>>> >>>> "G1ConcMark" >>>> >>>> >>>> >>>> - set_name("String Deduplication Thread"); >>>> + set_name("StrDedup Thread"); >>>> >>>> "StringDedup" >>>> >>>> >>>> >>>> - set_name("GC task thread#%d (ParallelGC)", which); >>>> + set_name("ParGC Thread#%d", which); >>>> >>>> "ParGCTask" >>>> >>>> >>>> >>>> - _workers = new FlexibleWorkGang("Parallel GC Threads", >>>> ParallelGCThreads, >>>> + _workers = new FlexibleWorkGang("GC Threads", ParallelGCThreads, >>>> >>>> "GCParTask" >>>> >>>> >>>> Just my thoughts. And regarding having 3 characters left for the number in >>>> the thread name I don't know if that is too important. With the above >>>> suggestions this will be possible in most cases but not all. Personally I >>>> think that is good enough. >>>> >>>> Bengt >>>> >>>> >>>> On 2015-03-04 15:11, David Lindholm wrote: >>>>> Hi Jesper, >>>>> >>>>> On 2015-03-04 14:52, Jesper Wilhelmsson wrote: >>>>>> Hi David, >>>>>> >>>>>> Thanks for fixing this! >>>>>> >>>>>> A couple of questions: >>>>>> >>>>>> - set_name("G1 Concurrent Refinement Thread#%d", worker_id); >>>>>> + set_name("G1 ConRefine#%d", worker_id); >>>>>> >>>>>> Is there any refinement threads that are not concurrent? If not, could >>>>>> we just call this "G1 Refine#%d" to simplify it slightly and remove an >>>>>> implementation detail that doesn't need to be exposed? This would also >>>>>> leave room for three digit numbers in case we have lots of these >>>>>> threads on some systems. >>>>> I discussed this with Bengt, and his input was that Concurrent >>>>> Refinement is a well known concept in G1. I have no real opinion here, >>>>> I'm fine with both suggestions. >>>>> >>>>>> - _parallel_workers = new FlexibleWorkGang("G1 Parallel Marking >>>>>> Threads", >>>>>> + _parallel_workers = new FlexibleWorkGang("G1 Markers", >>>>>> >>>>>> Markers is cute, but could be misunderstood. Can we call it "G1 Mark >>>>>> Threads" instead? >>>>> No, it is too long, the three last character with thread number won't >>>>> fit (#xx). >>>>> >>>>>> - set_name("G1 Main Concurrent Mark GC Thread"); >>>>>> + set_name("G1 Main Marker"); >>>>>> >>>>>> Again, "Marker" could be misunderstood. I don't have a good >>>>>> replacement though. >>>>> I'm open for suggestions, but I think "G1 Main Marker" works. >>>>> >>>>>> - set_name("GC task thread#%d (ParallelGC)", which); >>>>>> + set_name("ParGC Thread#%d", which); >>>>>> >>>>>> I don't have a good suggestion for how to make this one character >>>>>> shorter, but currently there is only room for two digit numbers. Maybe >>>>>> just "GC Thread#%d". I don't think these threads will exist at the >>>>>> same time as any other GC threads anyway. >>>>> With your suggestion these threads would be called the same thing as the >>>>> threads in sharedHeap. I think it is nice to quickly be able to see that >>>>> these threads indeed belongs to the ParallelGC. >>>>> >>>>>> - set_name("Gang worker#%d (%s)", id, gang->name()); >>>>>> + set_name("%s#%d", gang->name(), id); >>>>>> >>>>>> Is there any limitation on the length of the name()? If it's too long >>>>>> the number won't show. Can we add an assert to make sure it isn't too >>>>>> long? >>>>> I have gone through our current GangWorkers, and they fit. If you want I >>>>> can add an assert for <= 12 characters. OTOH it is not the end of the >>>>> world if we don't see the whole number in the debugger. >>>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> /Jesper >>>>>> >>>>>> >>>>>> David Lindholm skrev den 4/3/15 13:48: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this small fix which changes the names of the GC >>>>>>> threads to be >>>>>>> shorter and more descriptive. There is a limit on 16 characters >>>>>>> including the >>>>>>> terminating null byte for this name, since pthread_set_name_np() is >>>>>>> used. This >>>>>>> change will make it easier to debug, as these names shows up in the >>>>>>> debugger. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~brutisso/8073545/webrev.00/ >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073545 >>>>>>> >>>>>>> Testing: Passed JPRT. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> David > From jon.masamitsu at oracle.com Thu Mar 5 19:24:00 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 05 Mar 2015 11:24:00 -0800 Subject: RFR: 8073545 - Use shorter and more descriptive names for GC worker threads In-Reply-To: <54F723A7.6080008@oracle.com> References: <54F6FF0F.3030609@oracle.com> <54F70E1D.7030101@oracle.com> <54F7129B.8050009@oracle.com> <54F723A7.6080008@oracle.com> Message-ID: <54F8AD50.4070301@oracle.com> My alternative for CMS. On 03/04/2015 07:24 AM, Bengt Rutisson wrote: > > Hi David and everyone, > > ... > - _conc_workers = new YieldingFlexibleWorkGang("Parallel CMS > Threads", > + _conc_workers = new YieldingFlexibleWorkGang("CMS Threads", > > "CMSTask" "CMS#%d" > > > > - set_name("Concurrent Mark-Sweep GC Thread"); > + set_name("CMS Main Thread"); > > "CMSMain" "CMS" From thomas.schatzl at oracle.com Thu Mar 5 19:53:35 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 05 Mar 2015 20:53:35 +0100 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <1425567633.3140.44.camel@oracle.com> References: <1425482904.3305.27.camel@oracle.com> <1425567491.3140.42.camel@oracle.com> <1425567633.3140.44.camel@oracle.com> Message-ID: <1425585215.3142.0.camel@oracle.com> Hi, On Thu, 2015-03-05 at 16:00 +0100, Thomas Schatzl wrote: > Hi again, > > please hold off on looking at this, I hit the send button too early :( it's good to review. The change completed jprt testing. Thanks, Thomas From kim.barrett at oracle.com Thu Mar 5 21:40:45 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 5 Mar 2015 16:40:45 -0500 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <1425567491.3140.42.camel@oracle.com> References: <1425482904.3305.27.camel@oracle.com> <1425567491.3140.42.camel@oracle.com> Message-ID: <0DD6EEE2-697B-4F57-83E5-5EC65B3CCE5B@oracle.com> On Mar 5, 2015, at 9:58 AM, Thomas Schatzl wrote: > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.01 ------------------------------------------------------------------------------ Throughout Adjusting indentation of access specifiers (e.g. "public:" &etc), changing from no indent to 1-space indent. The code base appears to have a fairly random mix of no indent and 1-space indent for these. For example, src/share/vm has ~1900 1-space "public:" and ~1100 0-space, while in the g1 directory the mix is ~70 1-space and ~200 0-space. I don't see any good reason to clutter this review with extraneous whitespace changes when there's no apparent consensus on what the whitespace usage ought to be. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1Allocator.cpp 116 HeapWord* PLABAllocator::allocate_direct_or_new_plab(InCSetState dest, 117 size_t word_sz, 118 AllocationContext_t context) { Update indentation of arguments. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1Allocator.hpp G1ParGCAllocator => PLABAllocator Not sure I like the new name here. This class allocates G1PLAB's, but the name implies allocation of "generic" PLAB's. I think G1PLABAllocator would be more appropriate. Similarly for G1DefaultPARGCAllocator => DefaultPLABAllocator. But see comments below about G1PLAB naming. ------------------------------------------------------------------------------ G1ParGCAllocBuffer => G1PLAB That seems like a nice name change. However, it makes me wish ParGCAllocBuffer could be similarly shortened. On the other hand, looking at G1PLAB (nee G1ParGCAllocBuffer), it doesn't really add much to its base class, and what it adds looks fairly generic and not G1-specific at all.. I wonder if G1PLAB could be eliminated altogether, merging the additional stuff into the base class, since it looks generally useful. That should be a separate change from a bunch of renamings though. Maybe that's already in the roadmap for these related changes, but I didn't see it there. ------------------------------------------------------------------------------ From kim.barrett at oracle.com Thu Mar 5 23:43:47 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 5 Mar 2015 18:43:47 -0500 Subject: RFR: 8051984: @ignore should be placed after @test In-Reply-To: <54EF600D.8060100@oracle.com> References: <54E20B96.90509@oracle.com> <54E20FA8.4000302@oracle.com> <54E215CD.8010704@oracle.com> <54E247D5.6020106@oracle.com> <54EF600D.8060100@oracle.com> Message-ID: <00EA1B10-DB31-4A53-BF9B-08D6B211D1C2@oracle.com> On Feb 26, 2015, at 1:03 PM, Andrey Zakharov wrote: > > Do I need another review or review of Bengt is enough? Per hotspot review guidelines, you need a second review. >>> >>> webrev: >>> http://cr.openjdk.java.net/~azakharov/8051984/webrev.02/ Looks good. From sangheon.kim at oracle.com Thu Mar 5 23:55:32 2015 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Thu, 05 Mar 2015 15:55:32 -0800 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <1425567491.3140.42.camel@oracle.com> References: <1425482904.3305.27.camel@oracle.com> <1425567491.3140.42.camel@oracle.com> Message-ID: <54F8ECF4.2000107@oracle.com> Hi Thomas, On 03/05/2015 06:58 AM, Thomas Schatzl wrote: > Hi all, > > On Wed, 2015-03-04 at 16:28 +0100, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for the following change that does some renamings >> in the allocation related class hierarchy, also adding a few lines of >> documentation. >> >> This change is intentionally limited to renames to keep it simple, in a >> subsequent patch there will be more cleanup changes, moving methods >> around. >> Also, if there is demand, I am open to rename the files to something >> different (suggestions?) in a follow-up change (to not confuse the >> webrev tool too much). >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8073052 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.00/ >> Testing: > I talked with Stefan Johansson a bit about the change, with the result > that we keep the name of G1Allocator, since in the upcoming changes (see > below for more) that class is supposed to handle all allocations within > the current allocation regions. > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.01 Change seems good. Just minor comments. - As Kim already pointed, just curious to have different indentation of access specifiers (protected:, public: ) in our source codes. - Copyright year should be updated for 4 files. (g1CollectedHeap_ext.cpp, g1ParScanThreadState.cpp / hpp and heapRegionManager.cpp) Thanks, Sangheon > Except for undoing the renaming of G1Allocator to G1AllocRegionManager, > this change > - removes some methods in G1CollectedHeap that were unused and do not > have any implementation any more > - moves methods from G1Allocator back to G1CollectedHeap that give > information about the entire heap (e.g. related to _summary_bytes_used) > as G1Allocator is about managing the current allocation regions only. > - moves the new_heap_region() functionality back to G1CollectedHeap; it > seems to have been moved only because this allowed easy override using > the extension mechanism for closed additions. Its implementation has > simply been moved to the g1CollectedHeap_ext.cpp file, achieving the > same effect without cluttering the G1Allocator interface. > > Background of the upcoming changes: > > This is the second change that is part of the investigation of high > fragmentation and waste during gc in g1 (JDK-8030849). > > This particular change forms the basis for the following further changes > (in that order): > JDK-8073013 - Add detailed information about PLAB memory usage > JDK-8040162 - Avoid reallocating PLABs between GC phases in G1 > JDK-8067336 - Allow that PLAB allocations at the end of regions are > flexible > JDK-8067339 - PLAB reallocation might result in failure to allocate > object in that recently allocated PLAB > JDK-8067341 - Modify PLAB sizing algorithm to waste less > JDK-8073317 - Move all region level allocation related things into > AllocRegionManager > JDK-8067433 - Keep waste at end of regions for further allocation during > GC > > (There may be more intermediate steps depending on reviews). > (During the investigation of JDK-8030849 even more issues were found, > they might be added later, but typically they do not directly affect > memory allocation performance during gc) > > That results in a substantial decrease in memory use during allocation, > while setting higher PLAB sizes than the defaults used with > -XX:-ResizePLAB. Applications that have a high number of mid-sized > objects show an improvement in throughput of 5%, for others there is no > measurable difference. The changes decrease the number of young gcs > dramatically, allowing G1 to have more time for liveness analysis > (marking). Which means that there is less possibility that g1 runs into > a full gc. > > Since all of these CRs work in the same area I would like to avoid > posting RFRs for all of them at the same time; however I put up a > preliminary webrev up to and including JDK-8073317 at: > > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.outlook > > Probably most interesting is the resulting interfaces in > g1Allocator.hpp, at > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.outlook/src/share/vm/gc_implementation/g1/g1Allocator.hpp.html > and how much related stuff (and friend declarations) can be removed in > G1CollectedHeap: > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.outlook/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp.udiff.html > > Thanks, > Thomas > > From sangheon.kim at oracle.com Fri Mar 6 01:23:35 2015 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Thu, 05 Mar 2015 17:23:35 -0800 Subject: RFR (XS): 8073654: Marking statistics should use size_t Message-ID: <54F90197.8020905@oracle.com> Hi all, Can I have reviews for this simple fix for changing variables for statistics from 'int' to 'size_t'. This is to avoid overflows on large heaps. CR: https://bugs.openjdk.java.net/browse/JDK-8073654 Webrev: http://cr.openjdk.java.net/~sangheki/8073654/webrev.00/ Testing: JPRT Thanks, Sangheon From stefan.johansson at oracle.com Fri Mar 6 09:00:34 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 06 Mar 2015 10:00:34 +0100 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <1425567491.3140.42.camel@oracle.com> References: <1425482904.3305.27.camel@oracle.com> <1425567491.3140.42.camel@oracle.com> Message-ID: <54F96CB2.9060107@oracle.com> Hi Thomas, On 2015-03-05 15:58, Thomas Schatzl wrote: > Hi all, > > On Wed, 2015-03-04 at 16:28 +0100, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for the following change that does some renamings >> in the allocation related class hierarchy, also adding a few lines of >> documentation. >> >> This change is intentionally limited to renames to keep it simple, in a >> subsequent patch there will be more cleanup changes, moving methods >> around. >> Also, if there is demand, I am open to rename the files to something >> different (suggestions?) in a follow-up change (to not confuse the >> webrev tool too much). >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8073052 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.00/ >> Testing: > I talked with Stefan Johansson a bit about the change, with the result > that we keep the name of G1Allocator, since in the upcoming changes (see > below for more) that class is supposed to handle all allocations within > the current allocation regions. > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.01 Generally change looks good, but I agree with Kim that PLABAllocator could still use the G1 prefix for consistency. Some other comments: --- g1CollectedHeap.hpp: + // Allocates a new heap region instance. + virtual HeapRegion* new_heap_region(uint hrs_index, MemRegion mr); No need to have this one virtual, no one extends G1CollectedHeap. --- vmStructs_g1.hpp: Since _summary_bytes_used have been moved in the native code this needs to be reflected in the Java agent as well. You need to move the functionality from G1Allocator.java to G1CollectedHeap.java. --- Thanks, Stefan > Except for undoing the renaming of G1Allocator to G1AllocRegionManager, > this change > - removes some methods in G1CollectedHeap that were unused and do not > have any implementation any more > - moves methods from G1Allocator back to G1CollectedHeap that give > information about the entire heap (e.g. related to _summary_bytes_used) > as G1Allocator is about managing the current allocation regions only. > - moves the new_heap_region() functionality back to G1CollectedHeap; it > seems to have been moved only because this allowed easy override using > the extension mechanism for closed additions. Its implementation has > simply been moved to the g1CollectedHeap_ext.cpp file, achieving the > same effect without cluttering the G1Allocator interface. > > Background of the upcoming changes: > > This is the second change that is part of the investigation of high > fragmentation and waste during gc in g1 (JDK-8030849). > > This particular change forms the basis for the following further changes > (in that order): > JDK-8073013 - Add detailed information about PLAB memory usage > JDK-8040162 - Avoid reallocating PLABs between GC phases in G1 > JDK-8067336 - Allow that PLAB allocations at the end of regions are > flexible > JDK-8067339 - PLAB reallocation might result in failure to allocate > object in that recently allocated PLAB > JDK-8067341 - Modify PLAB sizing algorithm to waste less > JDK-8073317 - Move all region level allocation related things into > AllocRegionManager > JDK-8067433 - Keep waste at end of regions for further allocation during > GC > > (There may be more intermediate steps depending on reviews). > (During the investigation of JDK-8030849 even more issues were found, > they might be added later, but typically they do not directly affect > memory allocation performance during gc) > > That results in a substantial decrease in memory use during allocation, > while setting higher PLAB sizes than the defaults used with > -XX:-ResizePLAB. Applications that have a high number of mid-sized > objects show an improvement in throughput of 5%, for others there is no > measurable difference. The changes decrease the number of young gcs > dramatically, allowing G1 to have more time for liveness analysis > (marking). Which means that there is less possibility that g1 runs into > a full gc. > > Since all of these CRs work in the same area I would like to avoid > posting RFRs for all of them at the same time; however I put up a > preliminary webrev up to and including JDK-8073317 at: > > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.outlook > > Probably most interesting is the resulting interfaces in > g1Allocator.hpp, at > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.outlook/src/share/vm/gc_implementation/g1/g1Allocator.hpp.html > and how much related stuff (and friend declarations) can be removed in > G1CollectedHeap: > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.outlook/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp.udiff.html > > Thanks, > Thomas > > From jesper.wilhelmsson at oracle.com Fri Mar 6 10:26:38 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 06 Mar 2015 11:26:38 +0100 Subject: RFR (XS): 8073654: Marking statistics should use size_t In-Reply-To: <54F90197.8020905@oracle.com> References: <54F90197.8020905@oracle.com> Message-ID: <54F980DE.80705@oracle.com> Looks good. Just curious, what motivated the first change, moving the variables in concurrentMark.cpp? Also, your webrevs would be easier to review if you used the latest version of webrev found here: http://hg.openjdk.java.net/code-tools/webrev Thanks, /Jesper Sangheon Kim skrev den 6/3/15 02:23: > Hi all, > > Can I have reviews for this simple fix for changing variables for statistics > from 'int' to 'size_t'. > This is to avoid overflows on large heaps. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8073654 > Webrev: > http://cr.openjdk.java.net/~sangheki/8073654/webrev.00/ > Testing: > JPRT > > Thanks, > Sangheon From erik.helin at oracle.com Fri Mar 6 16:15:18 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 6 Mar 2015 17:15:18 +0100 Subject: RFR: 8030646: Track collection set membership in one place In-Reply-To: <1422351140.3369.3.camel@oracle.com> References: <20150126110251.GB2775@ehelin.jrpg.bea.com> <1422351140.3369.3.camel@oracle.com> Message-ID: <20150306161518.GF3269@ehelin.jrpg.bea.com> On 2015-01-27, Thomas Schatzl wrote: > Hi, > > thanks for taking this over. Thanks for reviewing and sorry for the (very) late reply. I've uploaded new patches at: - http://cr.openjdk.java.net/~ehelin/8030646/webrev.00-01/ - http://cr.openjdk.java.net/~ehelin/8030646/webrev.01 Testing: - GCBasher - gc-test-suite - JPRT Please see comments inline. > On Mon, 2015-01-26 at 12:02 +0100, Erik Helin wrote: > > Hi all, > > > > this (rather) small patch removes the field > > HeapRegion::_in_collection_set and instead only uses the > > G1BiasedMappedArray G1CollectedHeap::_in_cset_fast_test to track > > collection set membership. Given that _in_cset_fast_test already track > > collection set membership, the _in_collection_set field in HeapRegion is > > redundant, it is only messy to keep track of this information in two > > places. > > g1CollectorPolicy.cpp:1754: superfluous whitespace after "assert(". Fixed. > heapRegion.cpp: in HeapRegion::hr_clear(), is there a reason to remove > the assert that checks whether the region is in the collection set or > not? I think it could be rewritten the new method easily. (I.e. using > the in_collection_set() method in HeapRegion) No, you are right, we can keep the assert, I've added it back. > I think this change could remove the "_fast_test" suffix of the various > methods because now there is only this location where collection set > inclusion is tracked. It's just confusing to keep this imo. > (and possibly extend "cset" to "collection_set" - this has iirc been > done because of the lengthy "fast_set" suffix). > > It would be possible to separate that renaming step if you want, but I > somehow tend to that that should be part of this change. I removed the fast_test sufffix from the G1CollectedHeap::register_*_with_in_cset_fast_test methods, but kept cset (collection_set becomes too long IMO). I did not remove the suffix from the method G1CollectedHeap::clear_cset_fast_test, because the name clear_cset is too generic. I could also remove the method G1CollectedHeap::in_cset_fast_test, that method was apparently unused. Thanks, Erik > Thanks, > Thomas > > > > From axel.siebenborn at sap.com Fri Mar 6 16:17:22 2015 From: axel.siebenborn at sap.com (Siebenborn, Axel) Date: Fri, 6 Mar 2015 16:17:22 +0000 Subject: RFR (XS): Wrong volatile qualifier for field ClassLoaderDataGraphKlassIteratorAtomic::_next_klass Message-ID: <02D5D45C1F8DB848A7AE20E80EE61A5C398F8055@DEWDFEMB20C.global.corp.sap> Hi, can I have some reviews for this small change. It fixes a serious problem as the pointer _next_klass is changed concurrently but not correctly declared as volatile. The change fixes the declaration and removes an unneeded cast. bug: https://bugs.openjdk.java.net/browse/JDK-8074561 webrev: http://cr.openjdk.java.net/~asiebenborn/8074561/webrev.00/ I need a sponsor for the change. Thanks, Axel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sangheon.kim at oracle.com Fri Mar 6 16:32:26 2015 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Fri, 06 Mar 2015 08:32:26 -0800 Subject: RFR (XS): 8073654: Marking statistics should use size_t In-Reply-To: <54F980DE.80705@oracle.com> References: <54F90197.8020905@oracle.com> <54F980DE.80705@oracle.com> Message-ID: <54F9D69A.20606@oracle.com> Hi Jesper, Thanks for reviewing this. On 03/06/2015 02:26 AM, Jesper Wilhelmsson wrote: > Looks good. > > Just curious, what motivated the first change, moving the variables in > concurrentMark.cpp? I just wanted to have same order as the declaration at the header file. > > Also, your webrevs would be easier to review if you used the latest > version of webrev found here: > http://hg.openjdk.java.net/code-tools/webrev Oh, I see. Thanks for the pointer. Sangheon > > Thanks, > /Jesper > > > Sangheon Kim skrev den 6/3/15 02:23: >> Hi all, >> >> Can I have reviews for this simple fix for changing variables for >> statistics >> from 'int' to 'size_t'. >> This is to avoid overflows on large heaps. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8073654 >> Webrev: >> http://cr.openjdk.java.net/~sangheki/8073654/webrev.00/ >> Testing: >> JPRT >> >> Thanks, >> Sangheon From derek.white at oracle.com Fri Mar 6 18:09:38 2015 From: derek.white at oracle.com (Derek White) Date: Fri, 06 Mar 2015 13:09:38 -0500 Subject: RFR (XS): 8073654: Marking statistics should use size_t In-Reply-To: <54F9D69A.20606@oracle.com> References: <54F90197.8020905@oracle.com> <54F980DE.80705@oracle.com> <54F9D69A.20606@oracle.com> Message-ID: <54F9ED62.3070802@oracle.com> Hi Sangheon, Looks good to me too. Jesper already asked the only question I had. - Derek (drwhite) On 3/6/15 11:32 AM, Sangheon Kim wrote: > Hi Jesper, > > Thanks for reviewing this. > > On 03/06/2015 02:26 AM, Jesper Wilhelmsson wrote: >> Looks good. >> >> Just curious, what motivated the first change, moving the variables >> in concurrentMark.cpp? > I just wanted to have same order as the declaration at the header file. > >> >> Also, your webrevs would be easier to review if you used the latest >> version of webrev found here: >> http://hg.openjdk.java.net/code-tools/webrev > Oh, I see. Thanks for the pointer. > > Sangheon > > >> >> Thanks, >> /Jesper >> >> >> Sangheon Kim skrev den 6/3/15 02:23: >>> Hi all, >>> >>> Can I have reviews for this simple fix for changing variables for >>> statistics >>> from 'int' to 'size_t'. >>> This is to avoid overflows on large heaps. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8073654 >>> Webrev: >>> http://cr.openjdk.java.net/~sangheki/8073654/webrev.00/ >>> Testing: >>> JPRT >>> >>> Thanks, >>> Sangheon > From kim.barrett at oracle.com Fri Mar 6 18:10:07 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 6 Mar 2015 13:10:07 -0500 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed Message-ID: Please review this change to fix a problem in the interaction between G1 concurrent marking and eager reclaim of humongous objects. I will need a sponsor for this change. The scenario we are dealing with is (1) A humongous object H is marked and added to the mark stack. (2) An evacuation pause determines H is no longer live, and reclaims it. This occurs before concurrent marking has gotten around to processing the mark stack entry for H. (3) Concurrent marking processes the mark stack entry for H, attempting to scan the now dead object. The approach being taken to solve this is to check each mark stack entry as it is about to be scanned, to filter out and discard stale entries for dead humongous objects. The filter being used tests whether the entry appears to be for an object that was allocated during the concurrent mark cycle, by comparing the "object" against the associated region's top-at-mark-start (TAMS) value. Normal marking filters out such recent objects and doesn't mark them because G1 allocates black, so there is no need to scan such objects. As a result, there normally aren't any such objects in the mark stack. When a humongous object is eagerly reclaimed, the associated start region has its TAMS reset to the region bottom. Even if the region is later (during the same concurrent mark cycle) reallocated, its TAMS value will remain fixed at region bottom. As a result, a mark stack entry not below the containing region's TAMS must be a stale entry for a reclaimed humongous object. Note that automated regression testing for this problem is hard; even a stress test with a high rate of humongous object allocation and discard can take a long time to trip over this situation. Manual stress testing with additional VM instrumentation has verified the occurrence of the described scenario. The additional test in concurrent marking imposes a small performance degradation on concurrent marking. Measurements of a program which allocates a substantial number of objects and then does nothing but repeatedly GC shows a fraction of a percent increase in concurrent mark time, which is well within the variance for even this contrived test. Aurora performance comparison showed no significant negative impact. Alternatives that preclean the mark stack when humongous objects are reclaimed get complicated when attempting to do so without extending the reclaiming evacuation pause. CR: https://bugs.openjdk.java.net/browse/JDK-8069367 Webrev: http://cr.openjdk.java.net/~kbarrett/8069367/webrev.00/ Testing: JPRT, Aurora G1 performance test, Aurora Ad-hoc GC Nightly, hand testing From sangheon.kim at oracle.com Fri Mar 6 18:29:59 2015 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Fri, 06 Mar 2015 10:29:59 -0800 Subject: RFR (XS): 8073654: Marking statistics should use size_t In-Reply-To: <54F9ED62.3070802@oracle.com> References: <54F90197.8020905@oracle.com> <54F980DE.80705@oracle.com> <54F9D69A.20606@oracle.com> <54F9ED62.3070802@oracle.com> Message-ID: <54F9F227.5040105@oracle.com> Hi Derek, Thanks for the review. It would be better if I explained about the reason of changing the order. :) Thanks, Sangheon On 03/06/2015 10:09 AM, Derek White wrote: > Hi Sangheon, > > Looks good to me too. Jesper already asked the only question I had. > > - Derek (drwhite) > > On 3/6/15 11:32 AM, Sangheon Kim wrote: >> Hi Jesper, >> >> Thanks for reviewing this. >> >> On 03/06/2015 02:26 AM, Jesper Wilhelmsson wrote: >>> Looks good. >>> >>> Just curious, what motivated the first change, moving the variables >>> in concurrentMark.cpp? >> I just wanted to have same order as the declaration at the header file. >> >>> >>> Also, your webrevs would be easier to review if you used the latest >>> version of webrev found here: >>> http://hg.openjdk.java.net/code-tools/webrev >> Oh, I see. Thanks for the pointer. >> >> Sangheon >> >> >>> >>> Thanks, >>> /Jesper >>> >>> >>> Sangheon Kim skrev den 6/3/15 02:23: >>>> Hi all, >>>> >>>> Can I have reviews for this simple fix for changing variables for >>>> statistics >>>> from 'int' to 'size_t'. >>>> This is to avoid overflows on large heaps. >>>> >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8073654 >>>> Webrev: >>>> http://cr.openjdk.java.net/~sangheki/8073654/webrev.00/ >>>> Testing: >>>> JPRT >>>> >>>> Thanks, >>>> Sangheon >> > From jon.masamitsu at oracle.com Fri Mar 6 20:02:41 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 06 Mar 2015 12:02:41 -0800 Subject: Request for review (s) - 8069004: Kitchensink hanged with 16Gb heap and GC pause >30 min Message-ID: <54FA07E1.7060202@oracle.com> 8069004: Kitchensink hanged with 16Gb heap and GC pause >30 min The cause of 8069004 is a circularity created in a list of regions. This failure has not been reproduced to help diagnose the problem further. This patch saves some information in the code that constructs the region list to aid in diagnosing the problem when it reoccurs. http://cr.openjdk.java.net/~jmasa/8069004/webrev.00/ Issue https://bugs.openjdk.java.net/browse/JDK-8074576 was created to remove this debugging code in 3 months if the problem does not reoccur. Testing: kitchensink From jwha at google.com Sat Mar 7 00:21:05 2015 From: jwha at google.com (Jungwoo Ha) Date: Fri, 6 Mar 2015 16:21:05 -0800 Subject: TenuringThreshold being adaptive when UseAdaptiveSizePolicy is off Message-ID: On CMS when UseAdaptiveSizePolicy is off, still tenuring_threshold is being changed. Is this an intended behavior? (yes. I know it is not "size" related heuristics) It would be nice to have a flag that can disable adjusting tenuring threshold, or at least set minimum threshold. When the default heuristics doesn't work, there are nothing much we can do other than changing the Max. --Jungwoo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Sat Mar 7 00:28:02 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 06 Mar 2015 16:28:02 -0800 Subject: TenuringThreshold being adaptive when UseAdaptiveSizePolicy is off In-Reply-To: References: Message-ID: <54FA4612.2070005@oracle.com> This is in jdk9? Jon On 3/6/2015 4:21 PM, Jungwoo Ha wrote: > On CMS when UseAdaptiveSizePolicy is off, still tenuring_threshold is > being changed. > Is this an intended behavior? > (yes. I know it is not "size" related heuristics) > > It would be nice to have a flag that can disable adjusting tenuring > threshold, > or at least set minimum threshold. When the default heuristics doesn't > work, > there are nothing much we can do other than changing the Max. > > --Jungwoo From jwha at google.com Sat Mar 7 02:03:17 2015 From: jwha at google.com (Jungwoo Ha) Date: Fri, 6 Mar 2015 18:03:17 -0800 Subject: TenuringThreshold being adaptive when UseAdaptiveSizePolicy is off In-Reply-To: <54FA4612.2070005@oracle.com> References: <54FA4612.2070005@oracle.com> Message-ID: I think it is the same for all JDK{7,8,9}. arguments.cpp disabled UseAdaptiveSizePolicy for CMS. parallel scavange initializes _tenuring_threshold with _tenuring_threshold = (UseAdaptiveSizePolicy) ? InitialTenuringThreshold : MaxTenuringThreshold; whereas CMS uses _tenuring_threshold = MaxTenuringThreshold; adjust_desired_tenuring_threshold() is called inside ParNewGeneration::collect(), which calls compute_tenuring_threshold. It only uses MaxTenuringThreshold and TargetSurvivorRatio. I don't see any other flags here. On Fri, Mar 6, 2015 at 4:28 PM, Jon Masamitsu wrote: > This is in jdk9? > > Jon > > > On 3/6/2015 4:21 PM, Jungwoo Ha wrote: > >> On CMS when UseAdaptiveSizePolicy is off, still tenuring_threshold is >> being changed. >> Is this an intended behavior? >> (yes. I know it is not "size" related heuristics) >> >> It would be nice to have a flag that can disable adjusting tenuring >> threshold, >> or at least set minimum threshold. When the default heuristics doesn't >> work, >> there are nothing much we can do other than changing the Max. >> >> --Jungwoo >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk at kodewerk.com Sat Mar 7 09:55:12 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Sat, 7 Mar 2015 10:55:12 +0100 Subject: TenuringThreshold being adaptive when UseAdaptiveSizePolicy is off In-Reply-To: References: Message-ID: Adaptive sizing and tenuring threshold are different things. Tenuring threshold is calculated before a ParNew is run to ensure survivor spaces are not flooded with surviving data being evacuated from Eden. Only in very special cases would you ever want to tune out this behavior. Kind regards, Kirk Pepperdine On Mar 7, 2015, at 1:21 AM, Jungwoo Ha wrote: > On CMS when UseAdaptiveSizePolicy is off, still tenuring_threshold is being changed. > Is this an intended behavior? > (yes. I know it is not "size" related heuristics) > > It would be nice to have a flag that can disable adjusting tenuring threshold, > or at least set minimum threshold. When the default heuristics doesn't work, > there are nothing much we can do other than changing the Max. > > --Jungwoo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mikael.gerdin at oracle.com Mon Mar 9 07:41:30 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 09 Mar 2015 08:41:30 +0100 Subject: RFR (XS): Wrong volatile qualifier for field ClassLoaderDataGraphKlassIteratorAtomic::_next_klass In-Reply-To: <02D5D45C1F8DB848A7AE20E80EE61A5C398F8055@DEWDFEMB20C.global.corp.sap> References: <02D5D45C1F8DB848A7AE20E80EE61A5C398F8055@DEWDFEMB20C.global.corp.sap> Message-ID: <54FD4EAA.4040500@oracle.com> Hi Axel, On 2015-03-06 17:17, Siebenborn, Axel wrote: > Hi, > > can I have some reviews for this small change. > > It fixes a serious problem as the pointer _next_klass is changed > concurrently but not correctly declared as volatile. > > The change fixes the declaration and removes an unneeded cast. > > bug: https://bugs.openjdk.java.net/browse/JDK-8074561 > > webrev: http://cr.openjdk.java.net/~asiebenborn/8074561/webrev.00/ The change looks good to me. /Mikael > > I need a sponsor for the change. > > Thanks, > > Axel > From stefan.karlsson at oracle.com Mon Mar 9 07:47:58 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 09 Mar 2015 08:47:58 +0100 Subject: RFR (XS): Wrong volatile qualifier for field ClassLoaderDataGraphKlassIteratorAtomic::_next_klass In-Reply-To: <02D5D45C1F8DB848A7AE20E80EE61A5C398F8055@DEWDFEMB20C.global.corp.sap> References: <02D5D45C1F8DB848A7AE20E80EE61A5C398F8055@DEWDFEMB20C.global.corp.sap> Message-ID: <54FD502E.5080405@oracle.com> Hi Axel, On 06/03/15 17:17, Siebenborn, Axel wrote: > > Hi, > > can I have some reviews for this small change. > > It fixes a serious problem as the pointer _next_klass is changed > concurrently but not correctly declared as volatile. > > The change fixes the declaration and removes an unneeded cast. > > bug: https://bugs.openjdk.java.net/browse/JDK-8074561 > > webrev: http://cr.openjdk.java.net/~asiebenborn/8074561/webrev.00/ > Looks good. Thanks for finding and fixing this issue. BTW, there might be a few more problematic places in the GC code: https://bugs.openjdk.java.net/browse/JDK-8033552 - Fix missing missing volatile specifiers in CAS operations in GC code > I need a sponsor for the change. > I'll sponsor the change. Thanks, StefanK > Thanks, > > Axel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Mon Mar 9 09:28:30 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 09 Mar 2015 10:28:30 +0100 Subject: RFR (XS): 8073654: Marking statistics should use size_t In-Reply-To: <54F90197.8020905@oracle.com> References: <54F90197.8020905@oracle.com> Message-ID: <1425893310.3398.4.camel@oracle.com> Hi Sangheon, On Thu, 2015-03-05 at 17:23 -0800, Sangheon Kim wrote: > Hi all, > > Can I have reviews for this simple fix for changing variables for > statistics from 'int' to 'size_t'. > This is to avoid overflows on large heaps. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8073654 > Webrev: > http://cr.openjdk.java.net/~sangheki/8073654/webrev.00/ > Testing: > JPRT > In concurrentMark.cpp, there is now an extra space at the end of line 292. I do not need a new webrev for fixing that. Looks good. I can sponsor it if you still need a sponsor. Thanks, Thomas From thomas.schatzl at oracle.com Mon Mar 9 09:52:16 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 09 Mar 2015 10:52:16 +0100 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: References: Message-ID: <1425894736.3398.22.camel@oracle.com> Hi Kim, thanks for looking into this issue... On Fri, 2015-03-06 at 13:10 -0500, Kim Barrett wrote: > Please review this change to fix a problem in the interaction between > G1 concurrent marking and eager reclaim of humongous objects. > > I will need a sponsor for this change. I can sponsor it. > > The scenario we are dealing with is > > (1) A humongous object H is marked and added to the mark stack. > > (2) An evacuation pause determines H is no longer live, and reclaims > it. This occurs before concurrent marking has gotten around to > processing the mark stack entry for H. > > (3) Concurrent marking processes the mark stack entry for H, > attempting to scan the now dead object. > > The approach being taken to solve this is to check each mark stack > entry as it is about to be scanned, to filter out and discard stale > entries for dead humongous objects. > > The filter being used tests whether the entry appears to be for an > object that was allocated during the concurrent mark cycle, by > comparing the "object" against the associated region's > top-at-mark-start (TAMS) value. > > Normal marking filters out such recent objects and doesn't mark them > because G1 allocates black, so there is no need to scan such objects. > As a result, there normally aren't any such objects in the mark stack. > > When a humongous object is eagerly reclaimed, the associated start > region has its TAMS reset to the region bottom. Even if the region is > later (during the same concurrent mark cycle) reallocated, its TAMS > value will remain fixed at region bottom. > > As a result, a mark stack entry not below the containing region's TAMS > must be a stale entry for a reclaimed humongous object. > > Note that automated regression testing for this problem is hard; even > a stress test with a high rate of humongous object allocation and > discard can take a long time to trip over this situation. Manual > stress testing with additional VM instrumentation has verified the > occurrence of the described scenario. > > The additional test in concurrent marking imposes a small performance > degradation on concurrent marking. Measurements of a program which > allocates a substantial number of objects and then does nothing but > repeatedly GC shows a fraction of a percent increase in concurrent > mark time, which is well within the variance for even this contrived > test. Aurora performance comparison showed no significant negative > impact. Alternatives that preclean the mark stack when humongous > objects are reclaimed get complicated when attempting to do so without > extending the reclaiming evacuation pause. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8069367 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8069367/webrev.00/ - concurrentMark.inline.hpp: in is_stale_humongous_queue_entry(), in the long comment, could the change add some text that mentions that "Since the humongous object has already been reclaimed, we can only check that its base address is region aligned.". - please improve the asserts by adding the failing addresses in question (and region index). This helps diagnosing issues. - it's "humongous object" and not "humongous" too in the assert. - concurrentMark.hpp: the _stale_humongous_queue_entries should be a size_t. Sangheon has reviews for the patch that changes the other related members from int's already. So maybe wait until it has been pushed for posting the new webrev. - concurrentMark.cpp: what do you think about refactoring the is_stale_humongous_queue_entry(obj) { // ignore } else { // do some asserts scan_object(); } into an extra method? This would allow unification of the asserts too. The "assert(...->is_marked(obj), ...)" is duplicated in CMTask::do_marking_step(), scan_object() already does that. Also the master_free_list assert could be moved into the scan_object() method I think. I cannot see a case where this would not be the case. Also I would personally prefer to switch the if- and else- parts of that (invert the condition). When reading if-statements, I somewhat expect the far common case of execution to not be put into the else-part. It's your call. Please add the test case used to reproduce that explicitly enables eager reclamation. While failure without the change is not 100% reproducable, it seems good enough. Thanks, Thomas From erik.helin at oracle.com Mon Mar 9 09:58:29 2015 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 9 Mar 2015 10:58:29 +0100 Subject: RFR: 8030646: Track collection set membership in one place In-Reply-To: <20150306161518.GF3269@ehelin.jrpg.bea.com> References: <20150126110251.GB2775@ehelin.jrpg.bea.com> <1422351140.3369.3.camel@oracle.com> <20150306161518.GF3269@ehelin.jrpg.bea.com> Message-ID: <20150309095829.GG3269@ehelin.jrpg.bea.com> Thomas had one additional suggestion: rename register_*_with_in_cset to register_*_with_cset. I've uploaded new patches at: - http://cr.openjdk.java.net/~ehelin/8030646/webrev.01-02/ - http://cr.openjdk.java.net/~ehelin/8030646/webrev.02 v2: - Rename register_*_with_in_cset (Thomas) v1: - Fix superfluos whitespace in assert (Thomas) - Put back removed assert (Thomas) - Remove the "_fast_test" suffix from register_*_with_in_cset methods (Thomas) Thanks, Erik On 2015-03-06, Erik Helin wrote: > On 2015-01-27, Thomas Schatzl wrote: > > Hi, > > > > thanks for taking this over. > > Thanks for reviewing and sorry for the (very) late reply. I've uploaded > new patches at: > > - http://cr.openjdk.java.net/~ehelin/8030646/webrev.00-01/ > - http://cr.openjdk.java.net/~ehelin/8030646/webrev.01 > > Testing: > - GCBasher > - gc-test-suite > - JPRT > > Please see comments inline. > > > On Mon, 2015-01-26 at 12:02 +0100, Erik Helin wrote: > > > Hi all, > > > > > > this (rather) small patch removes the field > > > HeapRegion::_in_collection_set and instead only uses the > > > G1BiasedMappedArray G1CollectedHeap::_in_cset_fast_test to track > > > collection set membership. Given that _in_cset_fast_test already track > > > collection set membership, the _in_collection_set field in HeapRegion is > > > redundant, it is only messy to keep track of this information in two > > > places. > > > > g1CollectorPolicy.cpp:1754: superfluous whitespace after "assert(". > > Fixed. > > > heapRegion.cpp: in HeapRegion::hr_clear(), is there a reason to remove > > the assert that checks whether the region is in the collection set or > > not? I think it could be rewritten the new method easily. (I.e. using > > the in_collection_set() method in HeapRegion) > > No, you are right, we can keep the assert, I've added it back. > > > I think this change could remove the "_fast_test" suffix of the various > > methods because now there is only this location where collection set > > inclusion is tracked. It's just confusing to keep this imo. > > (and possibly extend "cset" to "collection_set" - this has iirc been > > done because of the lengthy "fast_set" suffix). > > > > It would be possible to separate that renaming step if you want, but I > > somehow tend to that that should be part of this change. > > I removed the fast_test sufffix from the > G1CollectedHeap::register_*_with_in_cset_fast_test methods, but kept > cset (collection_set becomes too long IMO). I did not remove the suffix > from the method G1CollectedHeap::clear_cset_fast_test, because the name > clear_cset is too generic. > > I could also remove the method G1CollectedHeap::in_cset_fast_test, that > method was apparently unused. > > Thanks, > Erik > > > Thanks, > > Thomas > > > > > > > > From thomas.schatzl at oracle.com Mon Mar 9 10:12:17 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 09 Mar 2015 11:12:17 +0100 Subject: RFR: 8030646: Track collection set membership in one place In-Reply-To: <20150309095829.GG3269@ehelin.jrpg.bea.com> References: <20150126110251.GB2775@ehelin.jrpg.bea.com> <1422351140.3369.3.camel@oracle.com> <20150306161518.GF3269@ehelin.jrpg.bea.com> <20150309095829.GG3269@ehelin.jrpg.bea.com> Message-ID: <1425895937.3398.32.camel@oracle.com> Hi, On Mon, 2015-03-09 at 10:58 +0100, Erik Helin wrote: > Thomas had one additional suggestion: rename register_*_with_in_cset to > register_*_with_cset. I've uploaded new patches at: > > - http://cr.openjdk.java.net/~ehelin/8030646/webrev.01-02/ > - http://cr.openjdk.java.net/~ehelin/8030646/webrev.02 > > v2: > - Rename register_*_with_in_cset (Thomas) > v1: > - Fix superfluos whitespace in assert (Thomas) > - Put back removed assert (Thomas) > - Remove the "_fast_test" suffix from register_*_with_in_cset methods > (Thomas) looks good. Thanks, Thomas From thomas.schatzl at oracle.com Mon Mar 9 11:02:02 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 09 Mar 2015 12:02:02 +0100 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <54F96CB2.9060107@oracle.com> References: <1425482904.3305.27.camel@oracle.com> <1425567491.3140.42.camel@oracle.com> <54F96CB2.9060107@oracle.com> Message-ID: <1425898922.3398.35.camel@oracle.com> Hi Stefan, thanks for the review. There is a new webrev at http://cr.openjdk.java.net/~tschatzl/8073052/webrev.2 (full) http://cr.openjdk.java.net/~tschatzl/8073052/webrev.1_to_2 (diff) Further comments inline: On Fri, 2015-03-06 at 10:00 +0100, Stefan Johansson wrote: > Hi Thomas, > > On 2015-03-05 15:58, Thomas Schatzl wrote: > > Hi all, > > > > On Wed, 2015-03-04 at 16:28 +0100, Thomas Schatzl wrote: > >> Hi all, > >> > >> can I have reviews for the following change that does some renamings > >> in the allocation related class hierarchy, also adding a few lines of > >> documentation. > >> > >> This change is intentionally limited to renames to keep it simple, in a > >> subsequent patch there will be more cleanup changes, moving methods > >> around. > >> Also, if there is demand, I am open to rename the files to something > >> different (suggestions?) in a follow-up change (to not confuse the > >> webrev tool too much). > >> > >> CR: > >> https://bugs.openjdk.java.net/browse/JDK-8073052 > >> Webrev: > >> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.00/ > >> Testing: > > I talked with Stefan Johansson a bit about the change, with the result > > that we keep the name of G1Allocator, since in the upcoming changes (see > > below for more) that class is supposed to handle all allocations within > > the current allocation regions. > > > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.01 > Generally change looks good, but I agree with Kim that PLABAllocator > could still use the G1 prefix for consistency. Some other comments: Done. > --- > g1CollectedHeap.hpp: > + // Allocates a new heap region instance. > + virtual HeapRegion* new_heap_region(uint hrs_index, MemRegion mr); > > No need to have this one virtual, no one extends G1CollectedHeap. Done. > --- > vmStructs_g1.hpp: > Since _summary_bytes_used have been moved in the native code this needs > to be reflected in the Java agent as well. You need to move the > functionality from G1Allocator.java to G1CollectedHeap.java. Done. Thanks, Thomas From thomas.schatzl at oracle.com Mon Mar 9 11:03:38 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 09 Mar 2015 12:03:38 +0100 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <54F8ECF4.2000107@oracle.com> References: <1425482904.3305.27.camel@oracle.com> <1425567491.3140.42.camel@oracle.com> <54F8ECF4.2000107@oracle.com> Message-ID: <1425899018.3398.37.camel@oracle.com> Hi Sangheon, thanks for the review. :) On Thu, 2015-03-05 at 15:55 -0800, Sangheon Kim wrote: > Hi Thomas, > > On 03/05/2015 06:58 AM, Thomas Schatzl wrote: > > Hi all, > > > > On Wed, 2015-03-04 at [...] > > > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.01 > > Change seems good. > > Just minor comments. > - As Kim already pointed, just curious to have different indentation of > access specifiers (protected:, public: ) in our source codes. > - Copyright year should be updated for 4 files. > (g1CollectedHeap_ext.cpp, g1ParScanThreadState.cpp / hpp and > heapRegionManager.cpp) I removed all whitespace changes in visibility specifiers and updated the copyrights. There is a new webrev at http://cr.openjdk.java.net/~tschatzl/8073052/webrev.2 (full) http://cr.openjdk.java.net/~tschatzl/8073052/webrev.1_to_2 (diff) Thanks, Thomas From thomas.schatzl at oracle.com Mon Mar 9 11:09:58 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 09 Mar 2015 12:09:58 +0100 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <0DD6EEE2-697B-4F57-83E5-5EC65B3CCE5B@oracle.com> References: <1425482904.3305.27.camel@oracle.com> <1425567491.3140.42.camel@oracle.com> <0DD6EEE2-697B-4F57-83E5-5EC65B3CCE5B@oracle.com> Message-ID: <1425899398.3398.43.camel@oracle.com> Hi Kim, thanks for the review. There is a new webrev at http://cr.openjdk.java.net/~tschatzl/8073052/webrev.2 (full) http://cr.openjdk.java.net/~tschatzl/8073052/webrev.1_to_2 (diff) Some comments below: On Thu, 2015-03-05 at 16:40 -0500, Kim Barrett wrote: > On Mar 5, 2015, at 9:58 AM, Thomas Schatzl wrote: > > > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.01 > > ------------------------------------------------------------------------------ > Throughout > > Adjusting indentation of access specifiers (e.g. "public:" &etc), > changing from no indent to 1-space indent. The code base appears to > have a fairly random mix of no indent and 1-space indent for these. > For example, src/share/vm has ~1900 1-space "public:" and ~1100 > 0-space, while in the g1 directory the mix is ~70 1-space and ~200 > 0-space. I don't see any good reason to clutter this review with > extraneous whitespace changes when there's no apparent consensus on > what the whitespace usage ought to be. I removed the whitespace changes, we should come to a consensus about spacing of visibility identifiers. > > ------------------------------------------------------------------------------ > src/share/vm/gc_implementation/g1/g1Allocator.cpp > 116 HeapWord* PLABAllocator::allocate_direct_or_new_plab(InCSetState dest, > 117 size_t word_sz, > 118 AllocationContext_t context) { > > Update indentation of arguments. Changed the name to G1PLABAllocator, which fixes this. > ------------------------------------------------------------------------------ > G1ParGCAllocBuffer => G1PLAB > > That seems like a nice name change. However, it makes me wish > ParGCAllocBuffer could be similarly shortened. > > On the other hand, looking at G1PLAB (nee G1ParGCAllocBuffer), it > doesn't really add much to its base class, and what it adds looks > fairly generic and not G1-specific at all.. I wonder if G1PLAB could > be eliminated altogether, merging the additional stuff into the base > class, since it looks generally useful. I created a new CR for these two concerns, renaming ParGCAllocBuffer and trying to unify G1PLAB and ParGCAllocBuffer. I agree that there may be interest in adding the retirement check functionality for regular PLABs. > That should be a separate change from a bunch of renamings though. I added https://bugs.openjdk.java.net/browse/JDK-8074546 Thanks, Thomas From bengt.rutisson at oracle.com Mon Mar 9 11:49:36 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 09 Mar 2015 12:49:36 +0100 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: References: Message-ID: <54FD88D0.2000005@oracle.com> Hi Kim, On 2015-03-06 19:10, Kim Barrett wrote: > Please review this change to fix a problem in the interaction between > G1 concurrent marking and eager reclaim of humongous objects. > > I will need a sponsor for this change. > > The scenario we are dealing with is > > (1) A humongous object H is marked and added to the mark stack. > > (2) An evacuation pause determines H is no longer live, and reclaims > it. This occurs before concurrent marking has gotten around to > processing the mark stack entry for H. > > (3) Concurrent marking processes the mark stack entry for H, > attempting to scan the now dead object. > > The approach being taken to solve this is to check each mark stack > entry as it is about to be scanned, to filter out and discard stale > entries for dead humongous objects. > > The filter being used tests whether the entry appears to be for an > object that was allocated during the concurrent mark cycle, by > comparing the "object" against the associated region's > top-at-mark-start (TAMS) value. > > Normal marking filters out such recent objects and doesn't mark them > because G1 allocates black, so there is no need to scan such objects. > As a result, there normally aren't any such objects in the mark stack. > > When a humongous object is eagerly reclaimed, the associated start > region has its TAMS reset to the region bottom. Even if the region is > later (during the same concurrent mark cycle) reallocated, its TAMS > value will remain fixed at region bottom. > > As a result, a mark stack entry not below the containing region's TAMS > must be a stale entry for a reclaimed humongous object. > > Note that automated regression testing for this problem is hard; even > a stress test with a high rate of humongous object allocation and > discard can take a long time to trip over this situation. Manual > stress testing with additional VM instrumentation has verified the > occurrence of the described scenario. > > The additional test in concurrent marking imposes a small performance > degradation on concurrent marking. Measurements of a program which > allocates a substantial number of objects and then does nothing but > repeatedly GC shows a fraction of a percent increase in concurrent > mark time, which is well within the variance for even this contrived > test. Aurora performance comparison showed no significant negative > impact. Alternatives that preclean the mark stack when humongous > objects are reclaimed get complicated when attempting to do so without > extending the reclaiming evacuation pause. Thanks for providing such a detailed descriptions about the problem and solution! One question. I assume that this situation can only occur if the humongous object was live before the marking started (otherwise it would have already been filtered out since it would have TAMS == bottom) and someone has removed the reference to the humongous object while we were marking. Here's an attempt to show what I mean in a diagram: H = new Humongous(),; A.h = H; A.h = null; Is this what is happening? In that case, isn't this violating the SATB invariant that anything that was live when marking started is considered live when it ends? Your fix will make sure the marking doesn't crash, but doesn't this behavior (even prior to your fix) cause other problems? Thanks, Bengt > > CR: > https://bugs.openjdk.java.net/browse/JDK-8069367 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8069367/webrev.00/ > > Testing: > JPRT, Aurora G1 performance test, Aurora Ad-hoc GC Nightly, hand testing > From thomas.schatzl at oracle.com Mon Mar 9 12:24:15 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 09 Mar 2015 13:24:15 +0100 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <54FD88D0.2000005@oracle.com> References: <54FD88D0.2000005@oracle.com> Message-ID: <1425903855.3398.68.camel@oracle.com> Hi Bengt, On Mon, 2015-03-09 at 12:49 +0100, Bengt Rutisson wrote: > Hi Kim, > > On 2015-03-06 19:10, Kim Barrett wrote: > > Please review this change to fix a problem in the interaction between > > G1 concurrent marking and eager reclaim of humongous objects. > > > > I will need a sponsor for this change. > > > > The scenario we are dealing with is > >[...] > > > > The additional test in concurrent marking imposes a small performance > > degradation on concurrent marking. Measurements of a program which > > allocates a substantial number of objects and then does nothing but > > repeatedly GC shows a fraction of a percent increase in concurrent > > mark time, which is well within the variance for even this contrived > > test. Aurora performance comparison showed no significant negative > > impact. Alternatives that preclean the mark stack when humongous > > objects are reclaimed get complicated when attempting to do so without > > extending the reclaiming evacuation pause. > > Thanks for providing such a detailed descriptions about the problem and > solution! > > One question. I assume that this situation can only occur if the > humongous object was live before the marking started (otherwise it would > have already been filtered out since it would have TAMS == bottom) and > someone has removed the reference to the humongous object while we were > marking. > > Here's an attempt to show what I mean in a diagram: > > H = new Humongous(),; > A.h = H; > > > A.h = null; > > > > > Is this what is happening? In that case, isn't this violating the SATB > invariant that anything that was live when marking started is considered > live when it ends? Yes. That has already been a concern with the original eager reclaim. > Your fix will make sure the marking doesn't crash, > but doesn't this behavior (even prior to your fix) cause other problems? None that I know. The eager reclaim already made sure that there is no other reference from a live object to the reclaimed object on the heap, assuming the remembered sets were correct. So nobody else can dereference the object. There is the mentioned race where mark stacks had some references to these objects left. Ideally for this case, mark stacks were organized on a per region basis, so you could just drop them during eager reclaim (or if any region provably becomes known empty and unreferenced). That's what I think what Kim refers to "being complicated" to do. The conservative fix would be to disable eager reclaim during marking. This has its own disadvantages: Applications where eager reclaim matters, are often continuously marking. even if not, marking is only done when space is already tight. So disabling eager reclaim during marking seems quite counterproductive. Heap verification should be okay too: while we walk through dead objects on the heap (that may still contain references to that reclaimed humongous objects), we do not check their references. Thanks, Thomas From thomas.schatzl at oracle.com Mon Mar 9 12:26:58 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 09 Mar 2015 13:26:58 +0100 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <54F5D5E8.3060400@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> <54E4848A.2010203@oracle.com> <54EDFD38.6010002@oracle.com> <54EF5E2D.5020503@oracle.com> <1425308253.3357.90.camel@oracle.com> <54F5D5E8.3060400@oracle.com> Message-ID: <1425904018.3398.69.camel@oracle.com> Hi Andrey, On Tue, 2015-03-03 at 18:40 +0300, Andrey Zakharov wrote: > Fixed according comments. > > hotspot webrev: > http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/ > > hs-gc webrev: > http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/hs-gc/ > > testing: in progress Can you also provide the webrev for the hs-gc repository with the changes to whitebox.java? Thanks, Thomas From axel.siebenborn at sap.com Mon Mar 9 13:00:07 2015 From: axel.siebenborn at sap.com (Siebenborn, Axel) Date: Mon, 9 Mar 2015 13:00:07 +0000 Subject: RFR (XS): Wrong volatile qualifier for field ClassLoaderDataGraphKlassIteratorAtomic::_next_klass Message-ID: <02D5D45C1F8DB848A7AE20E80EE61A5C3990421F@DEWDFEMB20C.global.corp.sap> Mikael, Stefan, thanks for reviews and sponsoring. Axel On 09/03/15 08:47 Stefan Karlsson wrote: > Hi Axel, > > On 06/03/15 17:17, Siebenborn, Axel wrote: >> >> Hi, >> >> can I have some reviews for this small change. >> >> It fixes a serious problem as the pointer _next_klass is changed concurrently but not correctly declared as volatile. >> >> The change fixes the declaration and removes an unneeded cast. >> >> >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8074561 >> >> >> >> webrev: http://cr.openjdk.java.net/~asiebenborn/8074561/webrev.00/ > > Looks good. Thanks for finding and fixing this issue. > > BTW, there might be a few more problematic places in the GC code: > https://bugs.openjdk.java.net/browse/JDK-8033552 - Fix missing missing volatile specifiers in CAS operations in GC code >> >> >> >> I need a sponsor for the change. > > I'll sponsor the change. > > Thanks, > StefanK >> >> >> >> Thanks, >> >> Axel -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Mon Mar 9 12:58:04 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 09 Mar 2015 13:58:04 +0100 Subject: RFR: 8026047: [TESTBUG] add regression test for DisableExplicitGC flag In-Reply-To: <54F84A4C.4040700@oracle.com> References: <54C7B051.8050808@oracle.com> <54C90036.8030506@oracle.com> <54CBA45D.8090503@oracle.com> <54D10193.3060407@oracle.com> <54D3B107.9050901@oracle.com> <54DB512A.7070003@oracle.com> <54DB55E9.2080302@oracle.com> <54DB7667.3020107@oracle.com> <54DCB396.2080807@oracle.com> <54EDC32B.7020605@oracle.com> <54F56A96.20702@oracle.com> <54F5D41C.3080009@oracle.com> <54F6C579.9020500@oracle.com> <54F84A4C.4040700@oracle.com> Message-ID: <54FD98DC.4070100@oracle.com> Hi Michail, On 2015-03-05 13:21, Michail Chernov wrote: > Hi Bengt, > > I used your approach: > http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.03/ This looks fine to me. :) > > assertEQ was changed to assertLT, because different GC can produce > different count of collections. > > For example: > -XX:+UseParallelGC > can produce: > PS MarkSweep 1 > PS Scavenge 1 > > -XX:+UseConcMarkSweepGC -XX:+ExplicitGCInvokesConcurrent > can produce: > ParNew 1 > ConcurrentMarkSweep 1 Right. If you wanted to you could check the name of the GarbageCollectorMXBean to filter out the old GC that result from the System.GC() call. But I think the test as you have it now is better because it is simpler. Thanks, Bengt > > Thanks, > Michail > > On 04.03.2015 11:42, Bengt Rutisson wrote: >> >> Hi Michail, >> >> On 2015-03-03 16:32, Michail Chernov wrote: >>> Hi Bengt, >>> >>> I checked run time of test on raspberry-pi and on some solaris host >>> with -Xcomp option. On r-pi it works 2.8 seconds, on solaris host it >>> works 3.5 seconds. I can set NOTIFICATION_DELAY=5 (for example) to >>> speed up the test. >> >> This sounds like a pretty fragile approach. My opinion is that we >> should always avoid tests that wait a certain amount of time for >> things to happen. They almost always turn out to be unstable or take >> unnecessarily long time. >> >>> Your approach has some cons - it does not check that System.gc() was >>> real GC source. >> >> Agreed. But since we actually don't have any problems with the >> DisbableExplicitGC flag I don't think it is worth adding a test that >> is potentially unstable and complex to test it. If we feel that we >> really need to test this flag I think the test must be simple and fast. >> >>> In case if we don't check source of GC events, we can simplify test >>> more and avoid usage of JMX: >>> >>> import java.lang.ref.WeakReference; >>> >>> public class Test{ >>> public static volatile WeakReference ref; >>> public static Object refObject; >>> public static void main(String[] args) { >>> ref=new WeakReference<>(new Object()); >>> refObject=ref.get(); >>> if ( refObject==null) >>> throw new RuntimeException("ERROR! Object was collected >>> before GC"); >>> refObject=null; >>> System.gc(); >>> refObject=ref.get(); >>> if ( refObject!=null) >>> throw new RuntimeException("ERROR! Object was not >>> collected during GC"); >>> } >>> } >>> >>> However, this solution does not check the real cause of GC. If this >>> way is applicable here, I could use this code for testing >>> DisableExplicitGC flag. >> >> Sure, this will probably work, but I think it is kind of a strange >> way to check this. I prefer a more explicit way of testing. >> >> Thanks, >> Bengt >> >>> >>> Thanks, >>> Michail >>> >>> On 03.03.2015 11:02, Bengt Rutisson wrote: >>>> >>>> Hi Michail, >>>> >>>> I like the idea of using the GarbageCollectionMXBean! >>>> >>>> However, I am not too happy about the test waiting for 20 seconds. >>>> Especially since you have the failing test which will actually wait >>>> for 20 seconds. >>>> >>>> Instead I would suggest to just use the collection count. Attaching >>>> a version of the test that use that instead. What do you think >>>> about this approach? >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> >>>> On 2015-02-25 13:42, Michail Chernov wrote: >>>>> Hi Bengt, >>>>> >>>>> I've rewritten test using JMX. I don't see here any reason to use >>>>> gc log for testing this flag. >>>>> >>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.02/ >>>>> >>>>> It seems better solution because it doesn't depend on used GC or >>>>> log message format. >>>>> >>>>> Tested locally with JDK 9 b51 using several GC. Tested using >>>>> Aurora on all platforms. >>>>> >>>>> Thanks, >>>>> Michail >>>>> >>>>> On 12.02.2015 17:07, Bengt Rutisson wrote: >>>>>> >>>>>> Hi Michail, >>>>>> >>>>>> On 11/02/15 16:33, Michail Chernov wrote: >>>>>>> Hi Bengt, >>>>>>> >>>>>>> Test works with all options passed to jtreg during testing ( see >>>>>>> line 97 vmOpts.addAll(0, Utils.getVmOptions());). >>>>>>> Doesn't need to check all GC's, it will be done during nightly. >>>>>> >>>>>> Ah. I see that now. >>>>>> >>>>>>> >>>>>>> 44 public final static String[] PARALLEL_GC_OPTIONS = >>>>>>> {"UseParallelGC", "UseParallelOldGC"}; >>>>>>> Here is defined special options. If define one of these options >>>>>>> - will be used other pattern to match output. >>>>>> >>>>>> Right. >>>>>> >>>>>>> >>>>>>> But it seems to me a little bit wrong. I've checked output of GC >>>>>>> log with different GCs and ExplicitGCInvokesConcurrent. Message >>>>>>> "Full GC (System.gc())" does not appear only in case of using G1 >>>>>>> or CMS with ExplicitGCInvokesConcurrent=true. Will fix it. >>>>>> >>>>>> OK. >>>>>> >>>>>> My main point was that I think the whole structure of the test is >>>>>> different than how we usually write tests that verify the log >>>>>> output. I would prefer if the tests look similar. Would you mind >>>>>> re-writing the test to look like the other tests. >>>>>> >>>>>> I much prefer that you explicitly start with the GCs you want to >>>>>> test than that you use the WhiteBox API to find out which GC you >>>>>> are running. >>>>>> >>>>>> I'm having a similar discussion with Dima who recently invented >>>>>> yet another way to parse the GC log output from tests. I think it >>>>>> gets very hard to read the tests when they do the same thing in >>>>>> different ways. >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>>> >>>>>>> Thanks, >>>>>>> Michail >>>>>>> On 11.02.2015 16:15, Bengt Rutisson wrote: >>>>>>>> >>>>>>>> Hi Michail, >>>>>>>> >>>>>>>> On 11/02/15 13:55, Michail Chernov wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Still hoping for review! >>>>>>>> >>>>>>>> Sorry for being so late in looking at this. >>>>>>>> >>>>>>>> A couple of questions: >>>>>>>> >>>>>>>> Why does the test only test the parallel GC? DisableExplicitGC >>>>>>>> is valid for all GCs. >>>>>>>> >>>>>>>> What do you think about writing this test similar to other >>>>>>>> tests that validate the output from the GC logging? Here's an >>>>>>>> example: >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/file/566574421b40/test/gc/g1/TestGCLogMessages.java >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bengt >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Michail >>>>>>>>> >>>>>>>>> On 05.02.2015 21:05, Michail Chernov wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Still waiting for reviews! >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Michail >>>>>>>>>> >>>>>>>>>> On 03.02.2015 20:12, Michail Chernov wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Can someone take a look on these changes, please? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Michail >>>>>>>>>>> >>>>>>>>>>> On 30.01.2015 18:33, Michail Chernov wrote: >>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>> >>>>>>>>>>>> Issues were fixed: >>>>>>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Now all testcases are executed from the same VM. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Michail >>>>>>>>>>>> >>>>>>>>>>>> On 28.01.2015 18:28, Leonid Mesnik wrote: >>>>>>>>>>>>> Hi >>>>>>>>>>>>> >>>>>>>>>>>>> Why is it needed to start VM twice for each test. It is >>>>>>>>>>>>> very expensive especially for low-end devices. >>>>>>>>>>>>> >>>>>>>>>>>>> Is it possible to have driver which starts VM several >>>>>>>>>>>>> times with different combinations of options and check it >>>>>>>>>>>>> output/exit code etc? Also it would be much easier to read >>>>>>>>>>>>> such test. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Leonid >>>>>>>>>>>>> >>>>>>>>>>>>> On 27.01.2015 18:35, Michail Chernov wrote: >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review the fix with new test for DisableExplicitGC >>>>>>>>>>>>>> VM flag. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Enhancement: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8026047 >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is one scenario with 6 parameters combinations. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1,2,3 scenarios test default value for DisableExplicitGC, >>>>>>>>>>>>>> DisableExplicitGC=true and DisableExplicitGC=false >>>>>>>>>>>>>> 4,5,6 scenarios check how VM works when VM changes >>>>>>>>>>>>>> DisableExplicitGC flag using WhiteBox. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Test tries to call System.gc() and check that VM puts >>>>>>>>>>>>>> message to stdout. After (in case of 4,5,6 scenarios) >>>>>>>>>>>>>> test tries to change DisableExplicitGC value and calls >>>>>>>>>>>>>> System.gc() twice. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Test was executed locally on linux-i586 with all >>>>>>>>>>>>>> available GC and several GC-related flags. Also it was >>>>>>>>>>>>>> executed using Aurora on other platforms. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Michail >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> >> > From bengt.rutisson at oracle.com Mon Mar 9 13:19:57 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 09 Mar 2015 14:19:57 +0100 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <1425903855.3398.68.camel@oracle.com> References: <54FD88D0.2000005@oracle.com> <1425903855.3398.68.camel@oracle.com> Message-ID: <54FD9DFD.7030300@oracle.com> On 2015-03-09 13:24, Thomas Schatzl wrote: > Hi Bengt, > > On Mon, 2015-03-09 at 12:49 +0100, Bengt Rutisson wrote: >> Hi Kim, >> >> On 2015-03-06 19:10, Kim Barrett wrote: >>> Please review this change to fix a problem in the interaction between >>> G1 concurrent marking and eager reclaim of humongous objects. >>> >>> I will need a sponsor for this change. >>> >>> The scenario we are dealing with is >>> [...] >>> >>> The additional test in concurrent marking imposes a small performance >>> degradation on concurrent marking. Measurements of a program which >>> allocates a substantial number of objects and then does nothing but >>> repeatedly GC shows a fraction of a percent increase in concurrent >>> mark time, which is well within the variance for even this contrived >>> test. Aurora performance comparison showed no significant negative >>> impact. Alternatives that preclean the mark stack when humongous >>> objects are reclaimed get complicated when attempting to do so without >>> extending the reclaiming evacuation pause. >> Thanks for providing such a detailed descriptions about the problem and >> solution! >> >> One question. I assume that this situation can only occur if the >> humongous object was live before the marking started (otherwise it would >> have already been filtered out since it would have TAMS == bottom) and >> someone has removed the reference to the humongous object while we were >> marking. >> >> Here's an attempt to show what I mean in a diagram: >> >> H = new Humongous(),; >> A.h = H; >> >> >> A.h = null; >> >> >> >> >> Is this what is happening? In that case, isn't this violating the SATB >> invariant that anything that was live when marking started is considered >> live when it ends? > Yes. That has already been a concern with the original eager reclaim. > >> Your fix will make sure the marking doesn't crash, >> but doesn't this behavior (even prior to your fix) cause other problems? > None that I know. The eager reclaim already made sure that there is no > other reference from a live object to the reclaimed object on the heap, > assuming the remembered sets were correct. So nobody else can > dereference the object. > There is the mentioned race where mark stacks had some references to > these objects left. Ok. So, what happens if I modify the example a little bit? H = new Object[BIGNUMBER]; H[4711] = new B(); A.h = H; A.h = A.h[4711]; Who will discover B and mark it live? Thanks, Bengt > > Ideally for this case, mark stacks were organized on a per region basis, > so you could just drop them during eager reclaim (or if any region > provably becomes known empty and unreferenced). That's what I think what > Kim refers to "being complicated" to do. > > The conservative fix would be to disable eager reclaim during marking. > This has its own disadvantages: Applications where eager reclaim > matters, are often continuously marking. even if not, marking is only > done when space is already tight. So disabling eager reclaim during > marking seems quite counterproductive. > > Heap verification should be okay too: while we walk through dead objects > on the heap (that may still contain references to that reclaimed > humongous objects), we do not check their references. > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Mon Mar 9 13:42:20 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 09 Mar 2015 14:42:20 +0100 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <54FD9DFD.7030300@oracle.com> References: <54FD88D0.2000005@oracle.com> <1425903855.3398.68.camel@oracle.com> <54FD9DFD.7030300@oracle.com> Message-ID: <1425908540.3398.84.camel@oracle.com> Hi Bengt, On Mon, 2015-03-09 at 14:19 +0100, Bengt Rutisson wrote: > On 2015-03-09 13:24, Thomas Schatzl wrote: > > Hi Bengt, > > > > On Mon, 2015-03-09 at 12:49 +0100, Bengt Rutisson wrote: > >> Hi Kim, [...] > > > >> Your fix will make sure the marking doesn't crash, > >> but doesn't this behavior (even prior to your fix) cause other problems? > > None that I know. The eager reclaim already made sure that there is no > > other reference from a live object to the reclaimed object on the heap, > > assuming the remembered sets were correct. So nobody else can > > dereference the object. > > There is the mentioned race where mark stacks had some references to > > these objects left. > > Ok. So, what happens if I modify the example a little bit? > > H = new Object[BIGNUMBER]; > H[4711] = new B(); > A.h = H; > > > A.h = A.h[4711]; > > > > > Who will discover B and mark it live? Nobody. This situation cannot occur because we do not reclaim humongous object arrays. See https://bugs.openjdk.java.net/browse/JDK-8048180 for some thoughts on how this could be done. We do not want to reclaim humongous regular objects with references either (CR: https://bugs.openjdk.java.net/browse/JDK-8073288) for the similar reason, although this is buggy at the moment. See https://bugs.openjdk.java.net/browse/JDK-8072598 for a proposed fix. There is no problem with class unloading either in this case (we need to keep alive the j.l.Class/j.l.Classloader of these objects) because the j.l.Classloader of large arrays of primitive data lives in the system/NULL class loader which is always live. The situation is a bit trickier if you want to remove large humongous regular objects without references (with e.g. j.l.Class X), but it would be okay too as far as I can see, because: - if the j.l.Classloader is reachable by at least one other j.l.Class of the same j.l.ClassLoader, j.l.Class X will stay alive because the j.l.ClassLoader keeps references to all j.l.Class'es it has loaded. (This is not what the spec says, but it's what a VM needs to do). - if the j.l.Class referenced by this object that we reclaim has really been the last j.l.Class of the j.l.Classloader (and neither has been marked yet), we are free to unload it because it has really ben unreachable. Thanks, Thomas From bengt.rutisson at oracle.com Mon Mar 9 13:59:59 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 09 Mar 2015 14:59:59 +0100 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <1425908540.3398.84.camel@oracle.com> References: <54FD88D0.2000005@oracle.com> <1425903855.3398.68.camel@oracle.com> <54FD9DFD.7030300@oracle.com> <1425908540.3398.84.camel@oracle.com> Message-ID: <54FDA75F.2010702@oracle.com> On 09/03/15 14:42, Thomas Schatzl wrote: > Hi Bengt, > > On Mon, 2015-03-09 at 14:19 +0100, Bengt Rutisson wrote: >> On 2015-03-09 13:24, Thomas Schatzl wrote: >>> Hi Bengt, >>> >>> On Mon, 2015-03-09 at 12:49 +0100, Bengt Rutisson wrote: >>>> Hi Kim, > [...] >>>> Your fix will make sure the marking doesn't crash, >>>> but doesn't this behavior (even prior to your fix) cause other problems? >>> None that I know. The eager reclaim already made sure that there is no >>> other reference from a live object to the reclaimed object on the heap, >>> assuming the remembered sets were correct. So nobody else can >>> dereference the object. >>> There is the mentioned race where mark stacks had some references to >>> these objects left. >> Ok. So, what happens if I modify the example a little bit? >> >> H = new Object[BIGNUMBER]; >> H[4711] = new B(); >> A.h = H; >> >> >> A.h = A.h[4711]; >> >> >> >> >> Who will discover B and mark it live? > Nobody. This situation cannot occur because we do not reclaim humongous > object arrays. Right. Sorry. That's the bit of the puzzle that I was missing. I forgot that we don't reclaim object arrays or objects with references. In that case I guess this approach will work. One request for the webrev though. The method CMTask::is_stale_humongous_queue_entry() does not check that obj is a humongous object and I don't think it has any chance of doing that either. It can just check that the object looks like it is newly allocated and that could only ahppen for reclaimed humongous objects. Given that I think I would prefer to not have the method called something with humongous. If we do what Thomas suggested to avoid code duplication, which was to move these lines into a separate method: 3822 3823 if (is_stale_humongous_queue_entry(obj)) { 3824 statsOnly( ++stale_humongous_queue_entries ); 3825 } else { 3826 assert(!_g1h->is_on_master_free_list( 3827 _g1h->heap_region_containing(obj)), "invariant"); 3828 scan_object(obj); 3829 } 3830 Then maybe we can just inline the code from is_stale_humongous_queue_entry() to avoid having to give it a somewhat confusing name. Thanks, Bengt > > See https://bugs.openjdk.java.net/browse/JDK-8048180 for some thoughts > on how this could be done. > > We do not want to reclaim humongous regular objects with references > either (CR: https://bugs.openjdk.java.net/browse/JDK-8073288) for the > similar reason, although this is buggy at the moment. See > https://bugs.openjdk.java.net/browse/JDK-8072598 for a proposed fix. > > There is no problem with class unloading either in this case (we need to > keep alive the j.l.Class/j.l.Classloader of these objects) because the > j.l.Classloader of large arrays of primitive data lives in the > system/NULL class loader which is always live. > > The situation is a bit trickier if you want to remove large humongous > regular objects without references (with e.g. j.l.Class X), but it would > be okay too as far as I can see, because: > - if the j.l.Classloader is reachable by at least one other j.l.Class of > the same j.l.ClassLoader, j.l.Class X will stay alive because the > j.l.ClassLoader keeps references to all j.l.Class'es it has loaded. > (This is not what the spec says, but it's what a VM needs to do). > - if the j.l.Class referenced by this object that we reclaim has really > been the last j.l.Class of the j.l.Classloader (and neither has been > marked yet), we are free to unload it because it has really ben > unreachable. > > Thanks, > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Mon Mar 9 15:24:44 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 09 Mar 2015 08:24:44 -0700 Subject: Request for review (s) - 8069004: Kitchensink hanged with 16Gb heap and GC pause >30 min In-Reply-To: <54FA07E1.7060202@oracle.com> References: <54FA07E1.7060202@oracle.com> Message-ID: <54FDBB3C.60300@oracle.com> I've had a suggestion for an better fix (thanks, Kim) and will be implementing that and sending out another review request. Jon On 03/06/2015 12:02 PM, Jon Masamitsu wrote: > 8069004: Kitchensink hanged with 16Gb heap and GC pause >30 min > > The cause of 8069004 is a circularity created in a list of regions. > This failure has not been reproduced to help diagnose the problem > further. This patch saves some information in the code that > constructs the > region list to aid in diagnosing the problem when it reoccurs. > > http://cr.openjdk.java.net/~jmasa/8069004/webrev.00/ > > Issue > > https://bugs.openjdk.java.net/browse/JDK-8074576 > > was created to remove this debugging code in 3 months > if the problem does not reoccur. > > Testing: kitchensink > From sangheon.kim at oracle.com Mon Mar 9 16:36:20 2015 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Mon, 09 Mar 2015 09:36:20 -0700 Subject: RFR (XS): 8073654: Marking statistics should use size_t In-Reply-To: <1425893310.3398.4.camel@oracle.com> References: <54F90197.8020905@oracle.com> <1425893310.3398.4.camel@oracle.com> Message-ID: <54FDCC04.1020003@oracle.com> Hi Thomas, Thank you for reviewing and sponsoring this! I'll send the full changeset after removing extra space. Thanks, Sangheon On 03/09/2015 02:28 AM, Thomas Schatzl wrote: > Hi Sangheon, > > > On Thu, 2015-03-05 at 17:23 -0800, Sangheon Kim wrote: >> Hi all, >> >> Can I have reviews for this simple fix for changing variables for >> statistics from 'int' to 'size_t'. >> This is to avoid overflows on large heaps. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8073654 >> Webrev: >> http://cr.openjdk.java.net/~sangheki/8073654/webrev.00/ >> Testing: >> JPRT >> > In concurrentMark.cpp, there is now an extra space at the end of line > 292. I do not need a new webrev for fixing that. > > Looks good. > > I can sponsor it if you still need a sponsor. > > Thanks, > Thomas > > > From jon.masamitsu at oracle.com Mon Mar 9 18:27:16 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 09 Mar 2015 11:27:16 -0700 Subject: TenuringThreshold being adaptive when UseAdaptiveSizePolicy is off In-Reply-To: References: <54FA4612.2070005@oracle.com> Message-ID: <54FDE604.2030500@oracle.com> Jungwoo, On 03/06/2015 06:03 PM, Jungwoo Ha wrote: > I think it is the same for all JDK{7,8,9}. > > arguments.cpp disabled UseAdaptiveSizePolicy for CMS. > parallel scavange initializes _tenuring_threshold with > _tenuring_threshold = (UseAdaptiveSizePolicy) ? > InitialTenuringThreshold : MaxTenuringThreshold; > whereas CMS uses > _tenuring_threshold = MaxTenuringThreshold; > > adjust_desired_tenuring_threshold() is called inside > ParNewGeneration::collect(), which calls compute_tenuring_threshold. > It only uses MaxTenuringThreshold and TargetSurvivorRatio. > I don't see any other flags here. Yes, this is the intended behavior. You're saying we're sometimes wasting survivor space? Jon > > On Fri, Mar 6, 2015 at 4:28 PM, Jon Masamitsu > > wrote: > > This is in jdk9? > > Jon > > > On 3/6/2015 4:21 PM, Jungwoo Ha wrote: > > On CMS when UseAdaptiveSizePolicy is off, still > tenuring_threshold is being changed. > Is this an intended behavior? > (yes. I know it is not "size" related heuristics) > > It would be nice to have a flag that can disable adjusting > tenuring threshold, > or at least set minimum threshold. When the default heuristics > doesn't work, > there are nothing much we can do other than changing the Max. > > --Jungwoo > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwha at google.com Tue Mar 10 05:39:58 2015 From: jwha at google.com (Jungwoo Ha) Date: Mon, 9 Mar 2015 22:39:58 -0700 Subject: TenuringThreshold being adaptive when UseAdaptiveSizePolicy is off In-Reply-To: <54FDE604.2030500@oracle.com> References: <54FA4612.2070005@oracle.com> <54FDE604.2030500@oracle.com> Message-ID: We were investigating some features and figured out that ParallelScavange and ParNew has different TenuringTreshold heuristics. We thought it would be nice to have a flag that can control the adaptiveness, so that we can fix it on purpose to isolate other performance factors. --Jungwoo On Mon, Mar 9, 2015 at 11:27 AM, Jon Masamitsu wrote: > Jungwoo, > > On 03/06/2015 06:03 PM, Jungwoo Ha wrote: > > I think it is the same for all JDK{7,8,9}. > > arguments.cpp disabled UseAdaptiveSizePolicy for CMS. > parallel scavange initializes _tenuring_threshold with > _tenuring_threshold = (UseAdaptiveSizePolicy) ? InitialTenuringThreshold > : MaxTenuringThreshold; > whereas CMS uses > _tenuring_threshold = MaxTenuringThreshold; > > adjust_desired_tenuring_threshold() is called inside > ParNewGeneration::collect(), which calls compute_tenuring_threshold. > It only uses MaxTenuringThreshold and TargetSurvivorRatio. > I don't see any other flags here. > > > Yes, this is the intended behavior. > > You're saying we're sometimes wasting survivor space? > > Jon > > > On Fri, Mar 6, 2015 at 4:28 PM, Jon Masamitsu > wrote: > >> This is in jdk9? >> >> Jon >> >> >> On 3/6/2015 4:21 PM, Jungwoo Ha wrote: >> >>> On CMS when UseAdaptiveSizePolicy is off, still tenuring_threshold is >>> being changed. >>> Is this an intended behavior? >>> (yes. I know it is not "size" related heuristics) >>> >>> It would be nice to have a flag that can disable adjusting tenuring >>> threshold, >>> or at least set minimum threshold. When the default heuristics doesn't >>> work, >>> there are nothing much we can do other than changing the Max. >>> >>> --Jungwoo >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Tue Mar 10 06:07:19 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 09 Mar 2015 23:07:19 -0700 Subject: TenuringThreshold being adaptive when UseAdaptiveSizePolicy is off In-Reply-To: References: <54FA4612.2070005@oracle.com> <54FDE604.2030500@oracle.com> Message-ID: <54FE8A17.1090702@oracle.com> On 3/9/2015 10:39 PM, Jungwoo Ha wrote: > We were investigating some features and figured out that > ParallelScavange and ParNew has different TenuringTreshold heuristics. > We thought it would be nice to have a flag that can control the > adaptiveness, so that we can fix it on purpose to isolate other > performance factors. Do you use UsePSAdaptiveSurvivorSizePolicy to turn off the survivor space resizing and tenuring threshold adaptiveness for ParallelGC? Jon > --Jungwoo > > On Mon, Mar 9, 2015 at 11:27 AM, Jon Masamitsu > > wrote: > > Jungwoo, > > On 03/06/2015 06:03 PM, Jungwoo Ha wrote: >> I think it is the same for all JDK{7,8,9}. >> >> arguments.cpp disabled UseAdaptiveSizePolicy for CMS. >> parallel scavange initializes _tenuring_threshold with >> _tenuring_threshold = (UseAdaptiveSizePolicy) ? >> InitialTenuringThreshold : MaxTenuringThreshold; >> whereas CMS uses >> _tenuring_threshold = MaxTenuringThreshold; >> >> adjust_desired_tenuring_threshold() is called inside >> ParNewGeneration::collect(), which calls compute_tenuring_threshold. >> It only uses MaxTenuringThreshold and TargetSurvivorRatio. >> I don't see any other flags here. > > Yes, this is the intended behavior. > > You're saying we're sometimes wasting survivor space? > > Jon > >> >> On Fri, Mar 6, 2015 at 4:28 PM, Jon Masamitsu >> > wrote: >> >> This is in jdk9? >> >> Jon >> >> >> On 3/6/2015 4:21 PM, Jungwoo Ha wrote: >> >> On CMS when UseAdaptiveSizePolicy is off, still >> tenuring_threshold is being changed. >> Is this an intended behavior? >> (yes. I know it is not "size" related heuristics) >> >> It would be nice to have a flag that can disable >> adjusting tenuring threshold, >> or at least set minimum threshold. When the default >> heuristics doesn't work, >> there are nothing much we can do other than changing the Max. >> >> --Jungwoo >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk at kodewerk.com Tue Mar 10 07:01:37 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 10 Mar 2015 08:01:37 +0100 Subject: TenuringThreshold being adaptive when UseAdaptiveSizePolicy is off In-Reply-To: <54FE8A17.1090702@oracle.com> References: <54FA4612.2070005@oracle.com> <54FDE604.2030500@oracle.com> <54FE8A17.1090702@oracle.com> Message-ID: <22636B3C-4309-4AD0-97CA-BFE200EAB808@kodewerk.com> Hi Jon, Slightly off topic. This question triggered me to once again take a closer look at psAdaptiveSizePolicy and CMSAdaptiveSizePolicy. What I saw is that uint PSAdaptiveSizePolicy::compute_survivor_space_size_and_threshold( bool is_survivor_overflow, uint tenuring_threshold, size_t survivor_limit) { and uint CMSAdaptiveSizePolicy::compute_survivor_space_size_and_threshold( bool is_survivor_overflow, uint tenuring_threshold, size_t survivor_limit) { are cut and paste copies of each other. In fact the amount of common code in both classes suggests they were a complete cut and paste copy of each other. Yes there are a couple of minor differences but not enough to warrant two separate classes. It?s also a bit scary to see this level of cut and paste in the JVM source code. Maybe it was intentional, if so it should have been justified with a comment but ? I?ll say no more on this topic. As I?ve mentioned before, AdaptiveSize can get into this degenerative pathological condition in low free heap conditions. It starts with higher GC frequencies slowing the allocation rates from the mutator threads. These lower allocation rates when feed back into adaptive sizing, are a signal to shrink the size of heap which is exactly the opposite of what you?d like to see in this condition. I have offered to work on a patch to fix this but I?ve been told by several people that they have a patch to correct this behavior so no need to do so. My question is, can we get one of these patches released so that we can correct this behavior? Kind regards, Kirk On Mar 10, 2015, at 7:07 AM, Jon Masamitsu wrote: > > On 3/9/2015 10:39 PM, Jungwoo Ha wrote: >> We were investigating some features and figured out that ParallelScavange and ParNew has different TenuringTreshold heuristics. >> We thought it would be nice to have a flag that can control the adaptiveness, so that we can fix it on purpose to isolate other performance factors. > > Do you use UsePSAdaptiveSurvivorSizePolicy to turn off the > survivor space resizing and tenuring threshold adaptiveness > for ParallelGC? > > Jon > >> --Jungwoo >> >> On Mon, Mar 9, 2015 at 11:27 AM, Jon Masamitsu wrote: >> Jungwoo, >> >> On 03/06/2015 06:03 PM, Jungwoo Ha wrote: >>> I think it is the same for all JDK{7,8,9}. >>> >>> arguments.cpp disabled UseAdaptiveSizePolicy for CMS. >>> parallel scavange initializes _tenuring_threshold with >>> _tenuring_threshold = (UseAdaptiveSizePolicy) ? InitialTenuringThreshold : MaxTenuringThreshold; >>> whereas CMS uses >>> _tenuring_threshold = MaxTenuringThreshold; >>> >>> adjust_desired_tenuring_threshold() is called inside ParNewGeneration::collect(), which calls compute_tenuring_threshold. >>> It only uses MaxTenuringThreshold and TargetSurvivorRatio. >>> I don't see any other flags here. >> >> Yes, this is the intended behavior. >> >> You're saying we're sometimes wasting survivor space? >> >> Jon >> >>> >>> On Fri, Mar 6, 2015 at 4:28 PM, Jon Masamitsu wrote: >>> This is in jdk9? >>> >>> Jon >>> >>> >>> On 3/6/2015 4:21 PM, Jungwoo Ha wrote: >>> On CMS when UseAdaptiveSizePolicy is off, still tenuring_threshold is being changed. >>> Is this an intended behavior? >>> (yes. I know it is not "size" related heuristics) >>> >>> It would be nice to have a flag that can disable adjusting tenuring threshold, >>> or at least set minimum threshold. When the default heuristics doesn't work, >>> there are nothing much we can do other than changing the Max. >>> >>> --Jungwoo >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From yiyeguhu at gmail.com Tue Mar 10 07:23:11 2015 From: yiyeguhu at gmail.com (Tao Mao) Date: Tue, 10 Mar 2015 00:23:11 -0700 Subject: TenuringThreshold being adaptive when UseAdaptiveSizePolicy is off In-Reply-To: References: <54FA4612.2070005@oracle.com> <54FDE604.2030500@oracle.com> Message-ID: Hi Jungwoo, Would fixing InitialTenuringThreshold and MaxTenuringThreshold to the same value work for you? Thanks. Tao Mao On Mon, Mar 9, 2015 at 10:39 PM, Jungwoo Ha wrote: > We were investigating some features and figured out that ParallelScavange > and ParNew has different TenuringTreshold heuristics. > We thought it would be nice to have a flag that can control the > adaptiveness, so that we can fix it on purpose to isolate other performance > factors. > --Jungwoo > > On Mon, Mar 9, 2015 at 11:27 AM, Jon Masamitsu > wrote: > >> Jungwoo, >> >> On 03/06/2015 06:03 PM, Jungwoo Ha wrote: >> >> I think it is the same for all JDK{7,8,9}. >> >> arguments.cpp disabled UseAdaptiveSizePolicy for CMS. >> parallel scavange initializes _tenuring_threshold with >> _tenuring_threshold = (UseAdaptiveSizePolicy) ? >> InitialTenuringThreshold : MaxTenuringThreshold; >> whereas CMS uses >> _tenuring_threshold = MaxTenuringThreshold; >> >> adjust_desired_tenuring_threshold() is called inside >> ParNewGeneration::collect(), which calls compute_tenuring_threshold. >> It only uses MaxTenuringThreshold and TargetSurvivorRatio. >> I don't see any other flags here. >> >> >> Yes, this is the intended behavior. >> >> You're saying we're sometimes wasting survivor space? >> >> Jon >> >> >> On Fri, Mar 6, 2015 at 4:28 PM, Jon Masamitsu >> wrote: >> >>> This is in jdk9? >>> >>> Jon >>> >>> >>> On 3/6/2015 4:21 PM, Jungwoo Ha wrote: >>> >>>> On CMS when UseAdaptiveSizePolicy is off, still tenuring_threshold is >>>> being changed. >>>> Is this an intended behavior? >>>> (yes. I know it is not "size" related heuristics) >>>> >>>> It would be nice to have a flag that can disable adjusting tenuring >>>> threshold, >>>> or at least set minimum threshold. When the default heuristics doesn't >>>> work, >>>> there are nothing much we can do other than changing the Max. >>>> >>>> --Jungwoo >>>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Tue Mar 10 09:48:08 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 10 Mar 2015 10:48:08 +0100 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: References: <54F08F8A.7070901@oracle.com> <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> <54F41E05.2090905@oracle.com> <54F48C84.3060602@oracle.com> <54F5DCFA.8010900@oracle.com> <54F71F02.3030309@oracle.com> Message-ID: <54FEBDD8.4060102@oracle.com> Hi Erik, Sorry for the late reply. I was on vacation for a couple of days. On 2015-03-05 10:14, Erik ?sterlund wrote: > Hi Kirk, > > Thank you for the feedback. > > I share your concern making small fixes at a time in general. However, as pointed out by Vitaly, this would not be an issue here. Because instead of picking a single universal time unit to be used everywhere (such as seconds) which would cause such problems, my approach is having a single unified time /type/, for which the time unit is a configurable parameter. The type knows the difference between units and can convert them (implicitly or explicitly as we prefer). Introducing such a time type is both backward compatible in logged output presented to external tools and internally in code. > > I think this approach is better than picking a single universal time unit, stored in "double" without further type information embedded. Because there is often a good reason why time units exist in the first place and not a single one is used. Whatever champion time unit is picked, is likely to be be awkward in some situations. :) > > Currently different units are passed around as primitive values ignorant of time units, instead annotated with a postfix in parameter/variable names implicitly annotating which time unit is used, and comments documenting which time unit is returned from functions. All I propose really is to strengthen the type for times to embed this knowledge explicitly and check these assumptions for us at compile time to reduce errors and improve readability/maintainability. > > If this is not relevant to the current change, I should perhaps make a new thread if anyone is interested in such a change? Don't want to clutter this thread too much. Thought I'd check if others drink my kind of tea first. :) I like the idea of having the type system help out with managing the time units. However, as suggested by you and others, I think that should be handled as a separate issue. Please file a bug for it - or let me know if I should file the bug. To get this email thread back on track - I'm still looking for reviews for the latest webrev: http://cr.openjdk.java.net/~brutisso/8074037/webrev.03/ Thanks, Bengt > > Thanks, > Erik > > On 05/03/15 01:26, Kirk Pepperdine wrote: >> Hi Erik, >> >> In principle I agree that times should be unified. However I am concerned that we maintain backwards compatibility and only making changes to the current format if there is a compelling reason to do My reason for this is that making little piece mean changes here and there really complicates the downstream tool chain. If you were to make one big sweeping change that fixed this every where once and for all, I?d be happy to take the downstream hit. But doing this small bits at a time would be worse than fixing this particular ?problem?. >> >> Kind regards, >> Kirk Pepperdine >> >> On Mar 4, 2015, at 10:16 PM, Erik ?sterlund wrote: >> >>> Hi Bengt, >>> >>> I see there are changes concerning time units and conversions, milliseconds vs seconds. This has bugged me too so thought I'd just add my opinion in this matter. >>> >>> Whenever dealing with a logical units such as time (seconds, milliseconds, etc) or size (words, bytes) that are mixed all over the place (sometimes for good reasons), I find it less error prone to let the type system help out automatically by annotating the types with their logical unit. As motivation, in this review there have been some human errors regarding time units, and this easily happens when conversions are manually performed. >>> >>> So personally I would have defined a Time type, letting time have both a physical type (e.g. double, float) AND a logical unit annotation (e.g. seconds, milliseconds) looking something like this: >>> >>> enum TimeUnit { >>> nanoseconds = 1000000000, >>> microseconds = 1000000, >>> milliseconds = 1000, >>> seconds = 1 >>> }; >>> >>> template >>> class Time { >>> S _quantity; >>> >>> static inline S convert(const S quantity, TimeUnit from, TimeUnit to) { >>> if (from == to) { >>> return quantity; >>> } else { >>> return quantity * S(to) / S(from); >>> } >>> } >>> public: >>> Time(S quantity) : _quantity(quantity) {} >>> template >>> Time(Time other) : _quantity(convert(other.value(), U, T)) {} >>> template >>> Time operator =(Time other) { _quantity = convert(other.value(), U, T); } >>> >>> S value() const { return _quantity; } >>> operator S() const { return value(); } >>> Time operator +(Time other) const { return value() + other.value(); } >>> Time operator -(Time other) const { return value() - other.value(); } >>> }; >>> >>> ...and then with some convenient type aliases: >>> >>> typedef Time time_default_t; >>> typedef Time time_secs_t; >>> typedef Time time_millis_t; >>> typedef Time time_micros_t; >>> typedef Time time_nanos_t; >>> >>> ...you could do stuff like this: >>> >>> time_millis_t time_ms = 100.0; // value is 100.0 >>> double time_prim_ms = time_ms; // value is 100.0 >>> Time time_secs = time_ms; // value is 0.1f; automatically converts [milliseconds, double] to [seconds, float] >>> time_default_t time_default = time_ms + time_secs; // value is 0.2; default unit is [seconds, double] >>> >>> ...and whenever there is a mismatch between time units that you send and the units expected in a function, it will automatically be converted to the appropriate expected type/unit. If you don't want to convert units automatically because you are scared of performance issues or something, then the type system can still at the very least help finding implicit conversions that you might want to eliminate automatically and reveal bugs related to such unit mismatches rapidly at compile time instead of after error prone manual verification. >>> >>> I don't know if this type of solution is interesting to you as maybe you want a single universal time unit to be used instead (such as seconds) in order to solve the problem, but thought I'd throw it out there anyway. Oh and even then I think it's clearer in a solution like this what the default time unit is supposed to be by just introspecting time_default_t instead of just "double". What do you think? >>> >>> Thanks, >>> /Erik >>> >>> On 04/03/15 16:43, Bengt Rutisson wrote: >>>> Hi again, >>>> >>>> Yet another update to this webrev. I realized that I can move the >>>> WorkerDataArray class from the hpp file to the cpp file. I think that's >>>> worth doing to show that it is just in internal class. >>>> >>>> Also, I renamed the GCPhase* enums and variables to GCParPhase* to make >>>> it possible to use the GCPhase* names for a possible future extension to >>>> store the "single time phases" in something similar to the _gc_phases array. >>>> >>>> Here's an updated webrev: >>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.03/ >>>> >>>> And here's the diff compared to the last one: >>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.02-03.diff/ >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> On 2015-03-03 17:10, Bengt Rutisson wrote: >>>>> Hi all, >>>>> >>>>> After some testing I noticed that I had done all my testing with >>>>> StringDedup enabled. The code did not work properly with it disabled >>>>> since StringDedup reported times for full GCs and concurrent marking >>>>> even though it was not logged anywhere. I changed the code to only >>>>> report times when the times will be reported as part of a GC. >>>>> >>>>> Here's an updated webrev: >>>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.02/ >>>>> >>>>> And a diff compared to the last review: >>>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.01-02.diff/ >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> On 2015-03-02 17:15, Bengt Rutisson wrote: >>>>>> Hi again, >>>>>> >>>>>> Here is an updated webrev: >>>>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.01/ >>>>>> >>>>>> And here's the diff compared to the last webrev: >>>>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00-01.diff/ >>>>>> >>>>>> I tried to clean up the seconds vs. milliseconds confusion by making >>>>>> it G1GCPhaseTimes' responsibility to handle the conversion in all >>>>>> cases. So, the interface is now that times are reported in seconds >>>>>> (for example G1GCPhaseTimes::record_time_secs()) but returned in >>>>>> milliseconds (for example G1GCPhaseTimes::average_time_ms()). I >>>>>> suffixed the method names "_secs" and "_ms" to make it easier to >>>>>> follow the code. >>>>>> >>>>>> I'm not very happy about this inconsistency, but I want it to be an >>>>>> intermediate step on the way to getting rid of os::elapsedTime() >>>>>> completely. >>>>>> >>>>>> StefanK also suggested to move the logging code out to its own class. >>>>>> This simplified the logging quite a bit I think. The class, >>>>>> G1GCPhasePrinter, has to know a lot about both G1GCPhaseTimes and >>>>>> WorkerDataArray, but I still think it is nice to have the logging >>>>>> separated out. >>>>>> >>>>>> I didn't read Thomas' email with comments until after I had prepared >>>>>> this updated webrev. But I think I have addressed the issues brought >>>>>> up there. Thanks for looking at this, Thomas! >>>>>> >>>>>> Bengt >>>>>> >>>>>> On 2015-03-02 09:23, Bengt Rutisson wrote: >>>>>>> Hi Kim, >>>>>>> >>>>>>> Thanks for looking at this! >>>>>>> >>>>>>> On 2015-02-28 00:43, Kim Barrett wrote: >>>>>>>> On Feb 27, 2015, at 10:38 AM, Bengt Rutisson >>>>>>>> wrote: >>>>>>>>> Can I have a couple of reviews for this cleanup change? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.00/ >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8074037 >>>>>>>>> >>>>>>>>> [?] >>>>>>>>> The patch also introduces a new class called >>>>>>>>> G1GCPhaseTimesTracker, which is a scoped object to simplify time >>>>>>>>> measurements. I've also tried to move conversion of times down to >>>>>>>>> when we print the log messages instead of when we store them. This >>>>>>>>> removes several "* 1000.0" in the code. Eventually I would like to >>>>>>>>> replace os::elapsedTime() with os::elapsed_counter(). But that >>>>>>>>> should be done as a separate patch. >>>>>>>> Before I proceed any further with this review, I feel like I'm getting >>>>>>>> lost in unit changes. In some places values of msecs used to be used >>>>>>>> but now we're using secs, right? But it seems like there might be some >>>>>>>> confusion about that, and I'm not sure whether it's me or the code >>>>>>>> that's confused. >>>>>>>> >>>>>>>> For example: >>>>>>>> >>>>>>>> src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp >>>>>>>> 1079 cost_per_card_ms = >>>>>>>> phase_times()->average_time(G1GCPhaseTimes::UpdateRS) / (double) >>>>>>>> _pending_cards; >>>>>>>> 1080 _cost_per_card_ms_seq->add(cost_per_card_ms); >>>>>>>> >>>>>>>> I think the values that have been recorded in the phase_times are >>>>>>>> secs, and average_time appears to just use the values as is. So >>>>>>>> shouldn't that now be cost_per_card_secs? And the value added to >>>>>>>> _cost_per_card_ms_seq needs to be cost_per_card_secs * 1000.0? >>>>>>> Right! Good catch! I was so happy to get rid of some of the "* >>>>>>> 1000.0" statements sprinkled all over the G1 code that I forgot to >>>>>>> add some of them back ;) >>>>>>> >>>>>>> I'll send out an updated webrev soon. >>>>>>> >>>>>>> Bengt >>>>>>> >>>>>>>> Oh how I wish for a units package! >>>>>>>> >>>> From thomas.schatzl at oracle.com Tue Mar 10 10:39:14 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 10 Mar 2015 11:39:14 +0100 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: <54FEBDD8.4060102@oracle.com> References: <54F08F8A.7070901@oracle.com> <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> <54F41E05.2090905@oracle.com> <54F48C84.3060602@oracle.com> <54F5DCFA.8010900@oracle.com> <54F71F02.3030309@oracle.com> <54FEBDD8.4060102@oracle.com> Message-ID: <1425983954.3344.26.camel@oracle.com> Hi Bengt, On Tue, 2015-03-10 at 10:48 +0100, Bengt Rutisson wrote: > Hi Erik, [...] > To get this email thread back on track - I'm still looking for reviews > for the latest webrev: > http://cr.openjdk.java.net/~brutisso/8074037/webrev.03/ > - g1CollectedHeap.cpp:3754, active_workers should be a uint I think to match the parameter types. - minor style issue (feel free to ignore): the change stores the G1GCPhaseTimes instances into local variables a few times. That variable is sometimes called "timer", "phase_times". Also e.g. G1CLDClosure may benefit from introducing a local variable. - another (feel free to ignore): in the long sum starting with g1CollectorPolicy.cpp:1134 the operators are sometimes at the end of the preceding line, sometimes before. I would prefer them at the end of the preceding line. - thanks for removing the PRAGMA's in g1GCPhaseTimes.cpp. :) Looks good otherwise. Thanks, Thomas From bengt.rutisson at oracle.com Tue Mar 10 11:32:20 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 10 Mar 2015 12:32:20 +0100 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: <1425983954.3344.26.camel@oracle.com> References: <54F08F8A.7070901@oracle.com> <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> <54F41E05.2090905@oracle.com> <54F48C84.3060602@oracle.com> <54F5DCFA.8010900@oracle.com> <54F71F02.3030309@oracle.com> <54FEBDD8.4060102@oracle.com> <1425983954.3344.26.camel@oracle.com> Message-ID: <54FED644.7090404@oracle.com> Hi Thomas, On 2015-03-10 11:39, Thomas Schatzl wrote: > Hi Bengt, > > On Tue, 2015-03-10 at 10:48 +0100, Bengt Rutisson wrote: >> Hi Erik, > [...] >> To get this email thread back on track - I'm still looking for reviews >> for the latest webrev: >> http://cr.openjdk.java.net/~brutisso/8074037/webrev.03/ >> > - g1CollectedHeap.cpp:3754, active_workers should be a uint I think to > match the parameter types. Good catch. > > - minor style issue (feel free to ignore): the change stores the > G1GCPhaseTimes instances into local variables a few times. That variable > is sometimes called "timer", "phase_times". Also e.g. G1CLDClosure may > benefit from introducing a local variable. Fixed. > > - another (feel free to ignore): in the long sum starting with > g1CollectorPolicy.cpp:1134 the operators are sometimes at the end of the > preceding line, sometimes before. I would prefer them at the end of the > preceding line. Fixed. > - thanks for removing the PRAGMA's in g1GCPhaseTimes.cpp. :) Yes, nice to get rid of this. > Looks good otherwise. Thanks! Here's an updated webrev: http://cr.openjdk.java.net/~brutisso/8074037/webrev.04/ And a diff compared to last time: http://cr.openjdk.java.net/~brutisso/8074037/webrev.03-04.diff/ Bengt > > Thanks, > Thomas > > > From jwha at google.com Tue Mar 10 11:58:13 2015 From: jwha at google.com (Jungwoo Ha) Date: Tue, 10 Mar 2015 04:58:13 -0700 Subject: TenuringThreshold being adaptive when UseAdaptiveSizePolicy is off In-Reply-To: <54FE8A17.1090702@oracle.com> References: <54FA4612.2070005@oracle.com> <54FDE604.2030500@oracle.com> <54FE8A17.1090702@oracle.com> Message-ID: Yes. That's it. Likewise, it would be nice to have a flag to turn off tenuring threshold adaptiveness on CMS. On Mon, Mar 9, 2015 at 11:07 PM, Jon Masamitsu wrote: > > On 3/9/2015 10:39 PM, Jungwoo Ha wrote: > > We were investigating some features and figured out that ParallelScavange > and ParNew has different TenuringTreshold heuristics. > We thought it would be nice to have a flag that can control the > adaptiveness, so that we can fix it on purpose to isolate other performance > factors. > > > Do you use UsePSAdaptiveSurvivorSizePolicy to turn off the > survivor space resizing and tenuring threshold adaptiveness > for ParallelGC? > > Jon > > > --Jungwoo > > On Mon, Mar 9, 2015 at 11:27 AM, Jon Masamitsu > wrote: > >> Jungwoo, >> >> On 03/06/2015 06:03 PM, Jungwoo Ha wrote: >> >> I think it is the same for all JDK{7,8,9}. >> >> arguments.cpp disabled UseAdaptiveSizePolicy for CMS. >> parallel scavange initializes _tenuring_threshold with >> _tenuring_threshold = (UseAdaptiveSizePolicy) ? >> InitialTenuringThreshold : MaxTenuringThreshold; >> whereas CMS uses >> _tenuring_threshold = MaxTenuringThreshold; >> >> adjust_desired_tenuring_threshold() is called inside >> ParNewGeneration::collect(), which calls compute_tenuring_threshold. >> It only uses MaxTenuringThreshold and TargetSurvivorRatio. >> I don't see any other flags here. >> >> >> Yes, this is the intended behavior. >> >> You're saying we're sometimes wasting survivor space? >> >> Jon >> >> >> On Fri, Mar 6, 2015 at 4:28 PM, Jon Masamitsu >> wrote: >> >>> This is in jdk9? >>> >>> Jon >>> >>> >>> On 3/6/2015 4:21 PM, Jungwoo Ha wrote: >>> >>>> On CMS when UseAdaptiveSizePolicy is off, still tenuring_threshold is >>>> being changed. >>>> Is this an intended behavior? >>>> (yes. I know it is not "size" related heuristics) >>>> >>>> It would be nice to have a flag that can disable adjusting tenuring >>>> threshold, >>>> or at least set minimum threshold. When the default heuristics doesn't >>>> work, >>>> there are nothing much we can do other than changing the Max. >>>> >>>> --Jungwoo >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwha at google.com Tue Mar 10 11:59:27 2015 From: jwha at google.com (Jungwoo Ha) Date: Tue, 10 Mar 2015 04:59:27 -0700 Subject: TenuringThreshold being adaptive when UseAdaptiveSizePolicy is off In-Reply-To: References: <54FA4612.2070005@oracle.com> <54FDE604.2030500@oracle.com> Message-ID: Tao, CMS no longer use InitialTenuringThreshold. IIRC, even before when CMS used InitialTenuringThreshold, setting initial and max the same value didn't turn off the adaptiveness. On Tue, Mar 10, 2015 at 12:23 AM, Tao Mao wrote: > Hi Jungwoo, > > Would fixing InitialTenuringThreshold and MaxTenuringThreshold to the same > value work for you? > > Thanks. > Tao Mao > > > On Mon, Mar 9, 2015 at 10:39 PM, Jungwoo Ha wrote: > >> We were investigating some features and figured out that ParallelScavange >> and ParNew has different TenuringTreshold heuristics. >> We thought it would be nice to have a flag that can control the >> adaptiveness, so that we can fix it on purpose to isolate other performance >> factors. >> --Jungwoo >> >> On Mon, Mar 9, 2015 at 11:27 AM, Jon Masamitsu >> wrote: >> >>> Jungwoo, >>> >>> On 03/06/2015 06:03 PM, Jungwoo Ha wrote: >>> >>> I think it is the same for all JDK{7,8,9}. >>> >>> arguments.cpp disabled UseAdaptiveSizePolicy for CMS. >>> parallel scavange initializes _tenuring_threshold with >>> _tenuring_threshold = (UseAdaptiveSizePolicy) ? >>> InitialTenuringThreshold : MaxTenuringThreshold; >>> whereas CMS uses >>> _tenuring_threshold = MaxTenuringThreshold; >>> >>> adjust_desired_tenuring_threshold() is called inside >>> ParNewGeneration::collect(), which calls compute_tenuring_threshold. >>> It only uses MaxTenuringThreshold and TargetSurvivorRatio. >>> I don't see any other flags here. >>> >>> >>> Yes, this is the intended behavior. >>> >>> You're saying we're sometimes wasting survivor space? >>> >>> Jon >>> >>> >>> On Fri, Mar 6, 2015 at 4:28 PM, Jon Masamitsu >>> wrote: >>> >>>> This is in jdk9? >>>> >>>> Jon >>>> >>>> >>>> On 3/6/2015 4:21 PM, Jungwoo Ha wrote: >>>> >>>>> On CMS when UseAdaptiveSizePolicy is off, still tenuring_threshold is >>>>> being changed. >>>>> Is this an intended behavior? >>>>> (yes. I know it is not "size" related heuristics) >>>>> >>>>> It would be nice to have a flag that can disable adjusting tenuring >>>>> threshold, >>>>> or at least set minimum threshold. When the default heuristics doesn't >>>>> work, >>>>> there are nothing much we can do other than changing the Max. >>>>> >>>>> --Jungwoo >>>>> >>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Tue Mar 10 16:26:50 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 10 Mar 2015 09:26:50 -0700 Subject: Request for review (s) : 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads Message-ID: <54FF1B4A.9020609@oracle.com> 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads https://bugs.openjdk.java.net/browse/JDK-8017462 When fewer than the maximum number of threads was being used for a parallel section, phase times for the threads that did not execute and averages for the phase were misleading. The fix passes the active number of GC threads to the G1 phase timers. http://cr.openjdk.java.net/~jmasa/8017462/webrev.00/ Tested with gc_test_suite. From derek.white at oracle.com Tue Mar 10 16:43:55 2015 From: derek.white at oracle.com (Derek White) Date: Tue, 10 Mar 2015 12:43:55 -0400 Subject: Request for review (s) : 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads In-Reply-To: <54FF1B4A.9020609@oracle.com> References: <54FF1B4A.9020609@oracle.com> Message-ID: <54FF1F4B.9090609@oracle.com> On 3/10/15 12:26 PM, Jon Masamitsu wrote: > 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads > > https://bugs.openjdk.java.net/browse/JDK-8017462 > > When fewer than the maximum number of threads was being used for > a parallel section, phase times for the threads that did not execute and > averages for the phase were misleading. The fix passes the active > number of > GC threads to the G1 phase timers. > > http://cr.openjdk.java.net/~jmasa/8017462/webrev.00/ > > Tested with gc_test_suite. Hi Jon, Looks good to me. Just a question: In g1StringDedup.cpp: void G1StringDedup::unlink_or_oops_do(BoolObjectClosure* is_alive, OopClosure* keep_alive, bool allow_resize_and_rehash) { assert(is_enabled(), "String deduplication not enabled"); - G1CollectorPolicy* g1p = G1CollectedHeap::heap()->g1_policy(); - g1p->phase_times()->note_string_dedup_fixup_start(); + G1CollectedHeap* g1h = G1CollectedHeap::heap(); + G1CollectorPolicy* g1p = g1h->g1_policy(); + uint active_workers = g1h->workers()->active_workers(); + g1p->phase_times()->note_string_dedup_fixup_start(active_workers); double fixup_start = os::elapsedTime(); G1StringDedupUnlinkOrOopsDoTask task(is_alive, keep_alive, allow_resize_and_rehash); - G1CollectedHeap* g1h = G1CollectedHeap::heap(); - g1h->set_par_threads(); + g1h->set_par_threads(active_workers); You switched from not changing the number of active workers "set_par_threads()" to explicitly setting the number "g1h->set_par_threads(active_workers)". Do you expect to get a different number of active threads this way, or are you just making the code clearer by making the count explicit? - Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Tue Mar 10 18:27:38 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 10 Mar 2015 11:27:38 -0700 Subject: TenuringThreshold being adaptive when UseAdaptiveSizePolicy is off In-Reply-To: <22636B3C-4309-4AD0-97CA-BFE200EAB808@kodewerk.com> References: <54FA4612.2070005@oracle.com> <54FDE604.2030500@oracle.com> <54FE8A17.1090702@oracle.com> <22636B3C-4309-4AD0-97CA-BFE200EAB808@kodewerk.com> Message-ID: <54FF379A.8020203@oracle.com> On 3/10/2015 12:01 AM, Kirk Pepperdine wrote: > Hi Jon, > > Slightly off topic. > > This question triggered me to once again take a closer look at > psAdaptiveSizePolicy and CMSAdaptiveSizePolicy. What I saw is that > > uint PSAdaptiveSizePolicy::compute_survivor_space_size_and_threshold( > bool is_survivor_overflow, > uint tenuring_threshold, > size_t survivor_limit) { > > and > > uint CMSAdaptiveSizePolicy::compute_survivor_space_size_and_threshold( > bool is_survivor_overflow, > uint tenuring_threshold, > size_t survivor_limit) { > > are cut and paste copies of each other. In fact the amount of common > code in both classes suggests they were a complete cut and paste copy > of each other. Yes there are a couple of minor differences but not > enough to warrant two separate classes. It?s also a bit scary to see > this level of cut and paste in the JVM source code. Maybe it was > intentional, if so it should have been justified with a comment but ? > I?ll say no more on this topic. That was a project that was never completed. We're removing it in 9. > > As I?ve mentioned before, AdaptiveSize can get into this degenerative > pathological condition in low free heap conditions. It starts with > higher GC frequencies slowing the allocation rates from the mutator > threads. These lower allocation rates when feed back into adaptive > sizing, are a signal to shrink the size of heap which is exactly the > opposite of what you?d like to see in this condition. I have offered > to work on a patch to fix this but I?ve been told by several people > that they have a patch to correct this behavior so no need to do so. If I was one of those people, I apologize but don't recall the conversation. Was I? > > My question is, can we get one of these patches released so that we > can correct this behavior? Generally speaking we're not doing much work on CMS these days. We are still accepting patches for improvements, of course. Jon > > Kind regards, > Kirk > > On Mar 10, 2015, at 7:07 AM, Jon Masamitsu > wrote: > >> >> On 3/9/2015 10:39 PM, Jungwoo Ha wrote: >>> We were investigating some features and figured out that >>> ParallelScavange and ParNew has different TenuringTreshold heuristics. >>> We thought it would be nice to have a flag that can control the >>> adaptiveness, so that we can fix it on purpose to isolate other >>> performance factors. >> >> Do you use UsePSAdaptiveSurvivorSizePolicy to turn off the >> survivor space resizing and tenuring threshold adaptiveness >> for ParallelGC? >> >> Jon >> >>> --Jungwoo >>> >>> On Mon, Mar 9, 2015 at 11:27 AM, Jon Masamitsu >>> > wrote: >>> >>> Jungwoo, >>> >>> On 03/06/2015 06:03 PM, Jungwoo Ha wrote: >>>> I think it is the same for all JDK{7,8,9}. >>>> >>>> arguments.cpp disabled UseAdaptiveSizePolicy for CMS. >>>> parallel scavange initializes _tenuring_threshold with >>>> _tenuring_threshold = (UseAdaptiveSizePolicy) ? >>>> InitialTenuringThreshold : MaxTenuringThreshold; >>>> whereas CMS uses >>>> _tenuring_threshold = MaxTenuringThreshold; >>>> >>>> adjust_desired_tenuring_threshold() is called inside >>>> ParNewGeneration::collect(), which calls >>>> compute_tenuring_threshold. >>>> It only uses MaxTenuringThreshold and TargetSurvivorRatio. >>>> I don't see any other flags here. >>> >>> Yes, this is the intended behavior. >>> >>> You're saying we're sometimes wasting survivor space? >>> >>> Jon >>> >>>> >>>> On Fri, Mar 6, 2015 at 4:28 PM, Jon Masamitsu >>>> > wrote: >>>> >>>> This is in jdk9? >>>> >>>> Jon >>>> >>>> >>>> On 3/6/2015 4:21 PM, Jungwoo Ha wrote: >>>> >>>> On CMS when UseAdaptiveSizePolicy is off, still >>>> tenuring_threshold is being changed. >>>> Is this an intended behavior? >>>> (yes. I know it is not "size" related heuristics) >>>> >>>> It would be nice to have a flag that can disable >>>> adjusting tenuring threshold, >>>> or at least set minimum threshold. When the default >>>> heuristics doesn't work, >>>> there are nothing much we can do other than changing >>>> the Max. >>>> >>>> --Jungwoo >>>> >>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Tue Mar 10 18:32:58 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 10 Mar 2015 11:32:58 -0700 Subject: Request for review (s) : 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads In-Reply-To: <54FF1F4B.9090609@oracle.com> References: <54FF1B4A.9020609@oracle.com> <54FF1F4B.9090609@oracle.com> Message-ID: <54FF38DA.4020805@oracle.com> On 3/10/2015 9:43 AM, Derek White wrote: > On 3/10/15 12:26 PM, Jon Masamitsu wrote: >> 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads >> >> https://bugs.openjdk.java.net/browse/JDK-8017462 >> >> When fewer than the maximum number of threads was being used for >> a parallel section, phase times for the threads that did not execute and >> averages for the phase were misleading. The fix passes the active >> number of >> GC threads to the G1 phase timers. >> >> http://cr.openjdk.java.net/~jmasa/8017462/webrev.00/ >> >> Tested with gc_test_suite. > Hi Jon, > > Looks good to me. > > Just a question: In g1StringDedup.cpp: > void G1StringDedup::unlink_or_oops_do(BoolObjectClosure* is_alive, OopClosure* keep_alive, bool allow_resize_and_rehash) { > assert(is_enabled(), "String deduplication not enabled"); > - G1CollectorPolicy* g1p = G1CollectedHeap::heap()->g1_policy(); > - g1p->phase_times()->note_string_dedup_fixup_start(); > + G1CollectedHeap* g1h = G1CollectedHeap::heap(); > + G1CollectorPolicy* g1p = g1h->g1_policy(); > + uint active_workers = g1h->workers()->active_workers(); > + g1p->phase_times()->note_string_dedup_fixup_start(active_workers); > double fixup_start = os::elapsedTime(); > > G1StringDedupUnlinkOrOopsDoTask task(is_alive, keep_alive, allow_resize_and_rehash); > - G1CollectedHeap* g1h = G1CollectedHeap::heap(); > - g1h->set_par_threads(); > + g1h->set_par_threads(active_workers); > > You switched from not changing the number of active workers > "set_par_threads()" to explicitly setting the > number "g1h->set_par_threads(active_workers)". > > Do you expect to get a different number of active threads this way, or > are you just making the code clearer by > making the count explicit? I expect to get a different number of active workers. The policy for number of GC workers depends on the number of Java threads and the size of the heap that has been committed. Either/both can change so the number of GC workers can change. Does that answer the question? Thanks for the review. Jon > > - Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Tue Mar 10 18:37:01 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 10 Mar 2015 11:37:01 -0700 Subject: TenuringThreshold being adaptive when UseAdaptiveSizePolicy is off In-Reply-To: References: <54FA4612.2070005@oracle.com> <54FDE604.2030500@oracle.com> Message-ID: <54FF39CD.4040708@oracle.com> On 3/10/2015 4:59 AM, Jungwoo Ha wrote: > Tao, > > CMS no longer use InitialTenuringThreshold. > IIRC, even before when CMS used InitialTenuringThreshold, setting > initial and max the same value didn't turn off the adaptiveness. I think we're removing that code from CMS in jdk9 compute_survivor_space_size_and_threshold() The implementation of adaptive size policy for CMS never worked correctly. Too many times it does the exact wrong thing. Jon > > > On Tue, Mar 10, 2015 at 12:23 AM, Tao Mao > wrote: > > Hi Jungwoo, > > Would fixing InitialTenuringThreshold and MaxTenuringThreshold to > the same value work for you? > > Thanks. > Tao Mao > > > On Mon, Mar 9, 2015 at 10:39 PM, Jungwoo Ha > wrote: > > We were investigating some features and figured out that > ParallelScavange and ParNew has different TenuringTreshold > heuristics. > We thought it would be nice to have a flag that can control > the adaptiveness, so that we can fix it on purpose to isolate > other performance factors. > --Jungwoo > > On Mon, Mar 9, 2015 at 11:27 AM, Jon Masamitsu > > > wrote: > > Jungwoo, > > On 03/06/2015 06:03 PM, Jungwoo Ha wrote: >> I think it is the same for all JDK{7,8,9}. >> >> arguments.cpp disabled UseAdaptiveSizePolicy for CMS. >> parallel scavange initializes _tenuring_threshold with >> _tenuring_threshold = (UseAdaptiveSizePolicy) ? >> InitialTenuringThreshold : MaxTenuringThreshold; >> whereas CMS uses >> _tenuring_threshold = MaxTenuringThreshold; >> >> adjust_desired_tenuring_threshold() is called inside >> ParNewGeneration::collect(), which calls >> compute_tenuring_threshold. >> It only uses MaxTenuringThreshold and TargetSurvivorRatio. >> I don't see any other flags here. > > Yes, this is the intended behavior. > > You're saying we're sometimes wasting survivor space? > > Jon > >> >> On Fri, Mar 6, 2015 at 4:28 PM, Jon Masamitsu >> > > wrote: >> >> This is in jdk9? >> >> Jon >> >> >> On 3/6/2015 4:21 PM, Jungwoo Ha wrote: >> >> On CMS when UseAdaptiveSizePolicy is off, still >> tenuring_threshold is being changed. >> Is this an intended behavior? >> (yes. I know it is not "size" related heuristics) >> >> It would be nice to have a flag that can disable >> adjusting tenuring threshold, >> or at least set minimum threshold. When the >> default heuristics doesn't work, >> there are nothing much we can do other than >> changing the Max. >> >> --Jungwoo >> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Tue Mar 10 18:45:00 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 10 Mar 2015 19:45:00 +0100 Subject: Request for review (s) : 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads In-Reply-To: <54FF1B4A.9020609@oracle.com> References: <54FF1B4A.9020609@oracle.com> Message-ID: <1426013100.3128.12.camel@oracle.com> Hi Jon, On Tue, 2015-03-10 at 09:26 -0700, Jon Masamitsu wrote: > 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads > > https://bugs.openjdk.java.net/browse/JDK-8017462 > > When fewer than the maximum number of threads was being used for > a parallel section, phase times for the threads that did not execute and > averages for the phase were misleading. The fix passes the active number of > GC threads to the G1 phase timers. > > http://cr.openjdk.java.net/~jmasa/8017462/webrev.00/ > > Tested with gc_test_suite. - I would somewhat prefer if _active_threads would not be stored in every WorkerDataArray. This seems a waste of space. G1GCPhaseTimes already stores it, so it could easily passed to WorkerDataArray::verify()/print() instead which seems cleaner to me. This would also avoid the additional parameter in note_string_dedup_fixup_start(). - WorkerDataArray::reset() is PRODUCT_RETURN. That means that in a product VM, WorkerDataArray::_active_length is seemingly never assigned to then as far as I can see. - is it possible to create a test for G1 that runs with G1LogLevel=finest and parses and verifies output of one GC phase that takes at least some time? I.e. that you have active_workers amount of durations in that line and the sum matches more or less. - Bengt is currently also changing this code significantly (see the review for 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases). Somebody will have to do a significant amount of merging :/ Thanks, Thomas From derek.white at oracle.com Tue Mar 10 19:13:04 2015 From: derek.white at oracle.com (Derek White) Date: Tue, 10 Mar 2015 15:13:04 -0400 Subject: Request for review (s) : 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads In-Reply-To: <54FF38DA.4020805@oracle.com> References: <54FF1B4A.9020609@oracle.com> <54FF1F4B.9090609@oracle.com> <54FF38DA.4020805@oracle.com> Message-ID: <54FF4240.9040005@oracle.com> On 3/10/15 2:32 PM, Jon Masamitsu wrote: > > On 3/10/2015 9:43 AM, Derek White wrote: >> On 3/10/15 12:26 PM, Jon Masamitsu wrote: >>> 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads >>> >>> https://bugs.openjdk.java.net/browse/JDK-8017462 >>> >>> When fewer than the maximum number of threads was being used for >>> a parallel section, phase times for the threads that did not execute >>> and >>> averages for the phase were misleading. The fix passes the active >>> number of >>> GC threads to the G1 phase timers. >>> >>> http://cr.openjdk.java.net/~jmasa/8017462/webrev.00/ >>> >>> Tested with gc_test_suite. >> Hi Jon, >> >> Looks good to me. >> >> Just a question: In g1StringDedup.cpp: >> void G1StringDedup::unlink_or_oops_do(BoolObjectClosure* is_alive, OopClosure* keep_alive, bool allow_resize_and_rehash) { >> assert(is_enabled(), "String deduplication not enabled"); >> - G1CollectorPolicy* g1p = G1CollectedHeap::heap()->g1_policy(); >> - g1p->phase_times()->note_string_dedup_fixup_start(); >> + G1CollectedHeap* g1h = G1CollectedHeap::heap(); >> + G1CollectorPolicy* g1p = g1h->g1_policy(); >> + uint active_workers = g1h->workers()->active_workers(); >> + g1p->phase_times()->note_string_dedup_fixup_start(active_workers); >> double fixup_start = os::elapsedTime(); >> >> G1StringDedupUnlinkOrOopsDoTask task(is_alive, keep_alive, allow_resize_and_rehash); >> - G1CollectedHeap* g1h = G1CollectedHeap::heap(); >> - g1h->set_par_threads(); >> + g1h->set_par_threads(active_workers); >> >> You switched from not changing the number of active workers >> "set_par_threads()" to explicitly setting the >> number "g1h->set_par_threads(active_workers)". >> >> Do you expect to get a different number of active threads this way, >> or are you just making the code clearer by >> making the count explicit? > > I expect to get a different number of active workers. The policy for > number of GC workers depends > on the number of Java threads and the size of the heap that has been > committed. Either/both can > change so the number of GC workers can change. Does that answer the > question? OK, Thanks for the info Jon. So I guess there could be a slight performance difference then. To extent that the new active count is more up to date, it could be a tiny win. - Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.provino at oracle.com Tue Mar 10 19:15:33 2015 From: joseph.provino at oracle.com (Joseph Provino) Date: Tue, 10 Mar 2015 15:15:33 -0400 Subject: Request for review (XXS) : 8067891 Remove vestigal G1SATBCT barrier set kind In-Reply-To: <54FF1F4B.9090609@oracle.com> References: <54FF1B4A.9020609@oracle.com> <54FF1F4B.9090609@oracle.com> Message-ID: <54FF42D5.1080005@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8067891 Remove vestigal G1SATBCT barrier set kind G1SATBCT still needs to be defined but there is no concrete class which uses it. This means that all instances of "case BarrierSet::G1SATBCT" can be removed which is what this change does. Tested with JPRT. Webrev: http://cr.openjdk.java.net/~jprovino/8067891/webrev.01 I will need someone to commit the changes for me. thanks. joe From kim.barrett at oracle.com Tue Mar 10 20:00:16 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 10 Mar 2015 16:00:16 -0400 Subject: Request for review (XXS) : 8067891 Remove vestigal G1SATBCT barrier set kind In-Reply-To: <54FF42D5.1080005@oracle.com> References: <54FF1B4A.9020609@oracle.com> <54FF1F4B.9090609@oracle.com> <54FF42D5.1080005@oracle.com> Message-ID: On Mar 10, 2015, at 3:15 PM, Joseph Provino wrote: > > https://bugs.openjdk.java.net/browse/JDK-8067891 > Remove vestigal G1SATBCT barrier set kind > > G1SATBCT still needs to be defined but there is no concrete class > which uses it. This means that all instances of > > "case BarrierSet::G1SATBCT" > > can be removed which is what this change does. > > Tested with JPRT. > > Webrev: http://cr.openjdk.java.net/~jprovino/8067891/webrev.01 > > I will need someone to commit the changes for me. > > thanks. > > joe Looks like you missed these: ./src/cpu/aarch64/vm/templateTable_aarch64.cpp: case BarrierSet::G1SATBCT: ./src/cpu/aarch64/vm/stubGenerator_aarch64.cpp: case BarrierSet::G1SATBCT: ./src/cpu/aarch64/vm/stubGenerator_aarch64.cpp: case BarrierSet::G1SATBCT: Presumably your local repo is a little out of date. From joseph.provino at oracle.com Tue Mar 10 20:19:32 2015 From: joseph.provino at oracle.com (Joseph Provino) Date: Tue, 10 Mar 2015 16:19:32 -0400 Subject: Request for review (XXS) : 8067891 Remove vestigal G1SATBCT barrier set kind In-Reply-To: References: <54FF1B4A.9020609@oracle.com> <54FF1F4B.9090609@oracle.com> <54FF42D5.1080005@oracle.com> Message-ID: <54FF51D4.5020609@oracle.com> Indeed my repo was out of date. New webrev is here: http://cr.openjdk.java.net/~jprovino/8067891/webrev.02/ resubmitting to jprt now. thanks. joe On 3/10/2015 4:00 PM, Kim Barrett wrote: > On Mar 10, 2015, at 3:15 PM, Joseph Provino wrote: >> https://bugs.openjdk.java.net/browse/JDK-8067891 >> Remove vestigal G1SATBCT barrier set kind >> >> G1SATBCT still needs to be defined but there is no concrete class >> which uses it. This means that all instances of >> >> "case BarrierSet::G1SATBCT" >> >> can be removed which is what this change does. >> >> Tested with JPRT. >> >> Webrev: http://cr.openjdk.java.net/~jprovino/8067891/webrev.01 >> >> I will need someone to commit the changes for me. >> >> thanks. >> >> joe > > Looks like you missed these: > > ./src/cpu/aarch64/vm/templateTable_aarch64.cpp: case BarrierSet::G1SATBCT: > ./src/cpu/aarch64/vm/stubGenerator_aarch64.cpp: case BarrierSet::G1SATBCT: > ./src/cpu/aarch64/vm/stubGenerator_aarch64.cpp: case BarrierSet::G1SATBCT: > > Presumably your local repo is a little out of date. > From kim.barrett at oracle.com Tue Mar 10 23:10:14 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 10 Mar 2015 19:10:14 -0400 Subject: Request for review (XXS) : 8067891 Remove vestigal G1SATBCT barrier set kind In-Reply-To: <54FF51D4.5020609@oracle.com> References: <54FF1B4A.9020609@oracle.com> <54FF1F4B.9090609@oracle.com> <54FF42D5.1080005@oracle.com> <54FF51D4.5020609@oracle.com> Message-ID: <31E486EB-329F-4B67-805C-46348B21B48D@oracle.com> On Mar 10, 2015, at 4:19 PM, Joseph Provino wrote: > > Indeed my repo was out of date. > > New webrev is here: http://cr.openjdk.java.net/~jprovino/8067891/webrev.02/ > > resubmitting to jprt now. Looks good. From kim.barrett at oracle.com Tue Mar 10 23:23:20 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 10 Mar 2015 19:23:20 -0400 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <1425894736.3398.22.camel@oracle.com> References: <1425894736.3398.22.camel@oracle.com> Message-ID: <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> On Mar 9, 2015, at 5:52 AM, Thomas Schatzl wrote: > > Hi Kim, > > thanks for looking into this issue? Thanks for all your help with this. > On Fri, 2015-03-06 at 13:10 -0500, Kim Barrett wrote: >> Please review this change to fix a problem in the interaction between >> G1 concurrent marking and eager reclaim of humongous objects. >> >> I will need a sponsor for this change. > > I can sponsor it. Thanks. >> [?] >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8069367 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8069367/webrev.00/ > > - concurrentMark.inline.hpp: in is_stale_humongous_queue_entry(), in the > long comment, could the change add some text that mentions that "Since > the humongous object has already been reclaimed, we can only check that > its base address is region aligned.?. OK. > - please improve the asserts by adding the failing addresses in question > (and region index). This helps diagnosing issues. OK. > - it's "humongous object" and not "humongous" too in the assert. OK. > - concurrentMark.hpp: the _stale_humongous_queue_entries should be a > size_t. Sangheon has reviews for the patch that changes the other > related members from int's already. So maybe wait until it has been > pushed for posting the new webrev. Yes, I saw that review request. Looks like it?s been pushed. > - concurrentMark.cpp: what do you think about refactoring the > > is_stale_humongous_queue_entry(obj) { > // ignore > } else { > // do some asserts > scan_object(); > } > > into an extra method? This would allow unification of the asserts too. > The "assert(...->is_marked(obj), ...)" is duplicated in > CMTask::do_marking_step(), scan_object() already does that. Also the > master_free_list assert could be moved into the scan_object() method I > think. I cannot see a case where this would not be the case. I was trying to minimize the changes, probably overly so. I?ve rearranged the asserts a bit and added a helper function. Note that it does not directly include the code for is_stale_? and eliminate that predicate; it turns out there?s another place that needs that predicate, in VerifyNoCSetOopsClosure. > Also I would personally prefer to switch the if- and else- parts of that > (invert the condition). When reading if-statements, I somewhat expect > the far common case of execution to not be put into the else-part. It's > your call. I see it as a filter with the base case being the scan. Writing it that way also avoids needing to negate the predicate result, which I find easier to read. This *is* a place where I might wish for an UNLIKELY-style macro. > Please add the test case used to reproduce that explicitly enables eager > reclamation. While failure without the change is not 100% reproducable, > it seems good enough. It was somewhat difficult to produce, but I?ve now got a reduced test case that usually fails pretty quickly on two quite different machine configurations. It will be included in the next webrev. From kim.barrett at oracle.com Tue Mar 10 23:32:04 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 10 Mar 2015 19:32:04 -0400 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <54FDA75F.2010702@oracle.com> References: <54FD88D0.2000005@oracle.com> <1425903855.3398.68.camel@oracle.com> <54FD9DFD.7030300@oracle.com> <1425908540.3398.84.camel@oracle.com> <54FDA75F.2010702@oracle.com> Message-ID: <69C503E7-A31D-4212-8699-A6373BCA74AE@oracle.com> On Mar 9, 2015, at 9:59 AM, Bengt Rutisson wrote: > > One request for the webrev though. The method CMTask::is_stale_humongous_queue_entry() does not check that obj is a humongous object and I don't think it has any chance of doing that either. It can just check that the object looks like it is newly allocated and that could only ahppen for reclaimed humongous objects. Given that I think I would prefer to not have the method called something with humongous. > > If we do what Thomas suggested to avoid code duplication, which was to move these lines into a separate method: > > > 3822 > 3823 if (is_stale_humongous_queue_entry(obj)) { > 3824 statsOnly( ++stale_humongous_queue_entries ); > 3825 } else { > 3826 assert(!_g1h->is_on_master_free_list( > 3827 _g1h->heap_region_containing(obj)), "invariant"); > 3828 scan_object(obj); > 3829 } > 3830 > > Then maybe we can just inline the code from is_stale_humongous_queue_entry() to avoid having to give it a somewhat confusing name. I?ve added the helper function that Thomas suggested. However, the is_stale? predicate ended up not getting hoisted into it and eliminated as a named function. I?m not sure I would have done that anyway, but it turned out that predicate is needed in another place. As for the name of the predicate, it was chosen to describe the semantics of the test being performed. Then there?s an implementation comment describing the ?tricky? way it accomplishes this. If it was named according to it?s implementation then readers of the call sites would be left scratching their heads about why we?re doing that. I did end up renaming it slightly, and also moved it, because of the newly discovered caller. It?s now ConcurrentMark::is_stale_humongous_marked_entry, which tests an entry from a (local or global) mark stack for staleness. From bengt.rutisson at oracle.com Wed Mar 11 08:32:40 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 11 Mar 2015 09:32:40 +0100 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <69C503E7-A31D-4212-8699-A6373BCA74AE@oracle.com> References: <54FD88D0.2000005@oracle.com> <1425903855.3398.68.camel@oracle.com> <54FD9DFD.7030300@oracle.com> <1425908540.3398.84.camel@oracle.com> <54FDA75F.2010702@oracle.com> <69C503E7-A31D-4212-8699-A6373BCA74AE@oracle.com> Message-ID: <54FFFDA8.2030600@oracle.com> Hi Kim, On 2015-03-11 00:32, Kim Barrett wrote: > On Mar 9, 2015, at 9:59 AM, Bengt Rutisson wrote: >> One request for the webrev though. The method CMTask::is_stale_humongous_queue_entry() does not check that obj is a humongous object and I don't think it has any chance of doing that either. It can just check that the object looks like it is newly allocated and that could only ahppen for reclaimed humongous objects. Given that I think I would prefer to not have the method called something with humongous. >> >> If we do what Thomas suggested to avoid code duplication, which was to move these lines into a separate method: >> >> >> 3822 >> 3823 if (is_stale_humongous_queue_entry(obj)) { >> 3824 statsOnly( ++stale_humongous_queue_entries ); >> 3825 } else { >> 3826 assert(!_g1h->is_on_master_free_list( >> 3827 _g1h->heap_region_containing(obj)), "invariant"); >> 3828 scan_object(obj); >> 3829 } >> 3830 >> >> Then maybe we can just inline the code from is_stale_humongous_queue_entry() to avoid having to give it a somewhat confusing name. > I?ve added the helper function that Thomas suggested. However, the is_stale? predicate > ended up not getting hoisted into it and eliminated as a named function. I?m not sure I would > have done that anyway, but it turned out that predicate is needed in another place. > > As for the name of the predicate, it was chosen to describe the semantics of the test being > performed. Then there?s an implementation comment describing the ?tricky? way it accomplishes > this. If it was named according to it?s implementation then readers of the call sites would be left > scratching their heads about why we?re doing that. > > I did end up renaming it slightly, and also moved it, because of the newly discovered caller. It?s > now ConcurrentMark::is_stale_humongous_marked_entry, which tests an entry from a > (local or global) mark stack for staleness. Ok. That's fine. I'll take a look at the updated webrev when you send it out. Thanks, Bengt > From thomas.schatzl at oracle.com Wed Mar 11 09:50:48 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 11 Mar 2015 10:50:48 +0100 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> Message-ID: <1426067448.3171.8.camel@oracle.com> Hi, On Tue, 2015-03-10 at 19:23 -0400, Kim Barrett wrote: > On Mar 9, 2015, at 5:52 AM, Thomas Schatzl wrote: > > > > Hi Kim, > > [...] > > - concurrentMark.hpp: the _stale_humongous_queue_entries should be a > > size_t. Sangheon has reviews for the patch that changes the other > > related members from int's already. So maybe wait until it has been > > pushed for posting the new webrev. > > Yes, I saw that review request. Looks like it?s been pushed. Yes :) > > > - concurrentMark.cpp: what do you think about refactoring the > > > > is_stale_humongous_queue_entry(obj) { > > // ignore > > } else { > > // do some asserts > > scan_object(); > > } > > > > into an extra method? This would allow unification of the asserts too. > > The "assert(...->is_marked(obj), ...)" is duplicated in > > CMTask::do_marking_step(), scan_object() already does that. Also the > > master_free_list assert could be moved into the scan_object() method I > > think. I cannot see a case where this would not be the case. > > I was trying to minimize the changes, probably overly so. I?ve rearranged > the asserts a bit and added a helper function. Note that it does not > directly include the code for is_stale_? and eliminate that predicate; > it turns out there?s another place that needs that predicate, in > VerifyNoCSetOopsClosure. Okay. > > Also I would personally prefer to switch the if- and else- parts of that > > (invert the condition). When reading if-statements, I somewhat expect > > the far common case of execution to not be put into the else-part. It's > > your call. > > I see it as a filter with the base case being the scan. Writing it that way also > avoids needing to negate the predicate result, which I find easier to read. > This *is* a place where I might wish for an UNLIKELY-style macro. I am not insisting on changing this. I did some experiments with a LIKELY/UNLIKELY macro just recently (for 8060025) on gcc, and I was only able to make performance worse (in the memory allocation part of the code). This mechanism seems way too brittle to be really useful: also considering that it most likely requires regular maintenance. > > Please add the test case used to reproduce that explicitly enables eager > > reclamation. While failure without the change is not 100% reproducable, > > it seems good enough. > > It was somewhat difficult to produce, but I?ve now got a reduced test case that > usually fails pretty quickly on two quite different machine configurations. It will > be included in the next webrev. Great :) Looking forward to it. Thanks, Thomas From bengt.rutisson at oracle.com Wed Mar 11 12:07:19 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 11 Mar 2015 13:07:19 +0100 Subject: Request for review (s) : 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads In-Reply-To: <1426013100.3128.12.camel@oracle.com> References: <54FF1B4A.9020609@oracle.com> <1426013100.3128.12.camel@oracle.com> Message-ID: <55002FF7.30706@oracle.com> Hi Jon and Thomas, On 2015-03-10 19:45, Thomas Schatzl wrote: > Hi Jon, > > On Tue, 2015-03-10 at 09:26 -0700, Jon Masamitsu wrote: >> 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads >> >> https://bugs.openjdk.java.net/browse/JDK-8017462 >> >> When fewer than the maximum number of threads was being used for >> a parallel section, phase times for the threads that did not execute and >> averages for the phase were misleading. The fix passes the active number of >> GC threads to the G1 phase timers. >> >> http://cr.openjdk.java.net/~jmasa/8017462/webrev.00/ >> >> Tested with gc_test_suite. > - I would somewhat prefer if _active_threads would not be stored in > every WorkerDataArray. This seems a waste of space. G1GCPhaseTimes > already stores it, so it could easily passed to > WorkerDataArray::verify()/print() instead which seems cleaner to me. > > This would also avoid the additional parameter in > note_string_dedup_fixup_start(). > > - WorkerDataArray::reset() is PRODUCT_RETURN. That means that in a > product VM, WorkerDataArray::_active_length is seemingly never assigned > to then as far as I can see. > > - is it possible to create a test for G1 that runs with > G1LogLevel=finest and parses and verifies output of one GC phase that > takes at least some time? I.e. that you have active_workers amount of > durations in that line and the sum matches more or less. > > - Bengt is currently also changing this code significantly (see the > review for 8074037: Refactor the G1GCPhaseTime logging to make it easier > to add new phases). Somebody will have to do a significant amount of > merging :/ Right. This will conflict with my changes. On the other hand I agree with Thomas that it doesn't really look good to store the active thread value in the WorkerDataArray. So, if we skip that and base the changes on top of my patch I think you can do a much less intrusive change. Here's a webrev that also passes the test that you wrote (TestDynamicNumberOfGCThreads.java): http://cr.openjdk.java.net/~brutisso/8017462/webrev.01/ It reuses the active thread value from the G1GCPhaseTimes instance and thus all changes can be contained within one file. Jon, what do you think about this solution instead? If we go with this, is it ok that I push my changes first? Thanks, Bengt > > Thanks, > Thomas > > From michail.chernov at oracle.com Wed Mar 11 12:55:14 2015 From: michail.chernov at oracle.com (Michail Chernov) Date: Wed, 11 Mar 2015 15:55:14 +0300 Subject: RFR: 8026047: [TESTBUG] add regression test for DisableExplicitGC flag In-Reply-To: <54FD98DC.4070100@oracle.com> References: <54C7B051.8050808@oracle.com> <54C90036.8030506@oracle.com> <54CBA45D.8090503@oracle.com> <54D10193.3060407@oracle.com> <54D3B107.9050901@oracle.com> <54DB512A.7070003@oracle.com> <54DB55E9.2080302@oracle.com> <54DB7667.3020107@oracle.com> <54DCB396.2080807@oracle.com> <54EDC32B.7020605@oracle.com> <54F56A96.20702@oracle.com> <54F5D41C.3080009@oracle.com> <54F6C579.9020500@oracle.com> <54F84A4C.4040700@oracle.com> <54FD98DC.4070100@oracle.com> Message-ID: <55003B32.9070908@oracle.com> Hi, Thanks, Bengt! Could someone else have a look on this change please? Thanks, Michail On 09.03.2015 15:58, Bengt Rutisson wrote: > > Hi Michail, > > On 2015-03-05 13:21, Michail Chernov wrote: >> Hi Bengt, >> >> I used your approach: >> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.03/ > > This looks fine to me. :) > >> >> assertEQ was changed to assertLT, because different GC can produce >> different count of collections. >> >> For example: >> -XX:+UseParallelGC >> can produce: >> PS MarkSweep 1 >> PS Scavenge 1 >> >> -XX:+UseConcMarkSweepGC -XX:+ExplicitGCInvokesConcurrent >> can produce: >> ParNew 1 >> ConcurrentMarkSweep 1 > > Right. If you wanted to you could check the name of the > GarbageCollectorMXBean to filter out the old GC that result from the > System.GC() call. But I think the test as you have it now is better > because it is simpler. > > Thanks, > Bengt > >> >> Thanks, >> Michail >> >> On 04.03.2015 11:42, Bengt Rutisson wrote: >>> >>> Hi Michail, >>> >>> On 2015-03-03 16:32, Michail Chernov wrote: >>>> Hi Bengt, >>>> >>>> I checked run time of test on raspberry-pi and on some solaris host >>>> with -Xcomp option. On r-pi it works 2.8 seconds, on solaris host >>>> it works 3.5 seconds. I can set NOTIFICATION_DELAY=5 (for example) >>>> to speed up the test. >>> >>> This sounds like a pretty fragile approach. My opinion is that we >>> should always avoid tests that wait a certain amount of time for >>> things to happen. They almost always turn out to be unstable or take >>> unnecessarily long time. >>> >>>> Your approach has some cons - it does not check that System.gc() >>>> was real GC source. >>> >>> Agreed. But since we actually don't have any problems with the >>> DisbableExplicitGC flag I don't think it is worth adding a test that >>> is potentially unstable and complex to test it. If we feel that we >>> really need to test this flag I think the test must be simple and fast. >>> >>>> In case if we don't check source of GC events, we can simplify test >>>> more and avoid usage of JMX: >>>> >>>> import java.lang.ref.WeakReference; >>>> >>>> public class Test{ >>>> public static volatile WeakReference ref; >>>> public static Object refObject; >>>> public static void main(String[] args) { >>>> ref=new WeakReference<>(new Object()); >>>> refObject=ref.get(); >>>> if ( refObject==null) >>>> throw new RuntimeException("ERROR! Object was collected >>>> before GC"); >>>> refObject=null; >>>> System.gc(); >>>> refObject=ref.get(); >>>> if ( refObject!=null) >>>> throw new RuntimeException("ERROR! Object was not >>>> collected during GC"); >>>> } >>>> } >>>> >>>> However, this solution does not check the real cause of GC. If this >>>> way is applicable here, I could use this code for testing >>>> DisableExplicitGC flag. >>> >>> Sure, this will probably work, but I think it is kind of a strange >>> way to check this. I prefer a more explicit way of testing. >>> >>> Thanks, >>> Bengt >>> >>>> >>>> Thanks, >>>> Michail >>>> >>>> On 03.03.2015 11:02, Bengt Rutisson wrote: >>>>> >>>>> Hi Michail, >>>>> >>>>> I like the idea of using the GarbageCollectionMXBean! >>>>> >>>>> However, I am not too happy about the test waiting for 20 seconds. >>>>> Especially since you have the failing test which will actually >>>>> wait for 20 seconds. >>>>> >>>>> Instead I would suggest to just use the collection count. >>>>> Attaching a version of the test that use that instead. What do you >>>>> think about this approach? >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> >>>>> >>>>> On 2015-02-25 13:42, Michail Chernov wrote: >>>>>> Hi Bengt, >>>>>> >>>>>> I've rewritten test using JMX. I don't see here any reason to use >>>>>> gc log for testing this flag. >>>>>> >>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.02/ >>>>>> >>>>>> It seems better solution because it doesn't depend on used GC or >>>>>> log message format. >>>>>> >>>>>> Tested locally with JDK 9 b51 using several GC. Tested using >>>>>> Aurora on all platforms. >>>>>> >>>>>> Thanks, >>>>>> Michail >>>>>> >>>>>> On 12.02.2015 17:07, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi Michail, >>>>>>> >>>>>>> On 11/02/15 16:33, Michail Chernov wrote: >>>>>>>> Hi Bengt, >>>>>>>> >>>>>>>> Test works with all options passed to jtreg during testing ( >>>>>>>> see line 97 vmOpts.addAll(0, Utils.getVmOptions());). >>>>>>>> Doesn't need to check all GC's, it will be done during nightly. >>>>>>> >>>>>>> Ah. I see that now. >>>>>>> >>>>>>>> >>>>>>>> 44 public final static String[] PARALLEL_GC_OPTIONS = >>>>>>>> {"UseParallelGC", "UseParallelOldGC"}; >>>>>>>> Here is defined special options. If define one of these options >>>>>>>> - will be used other pattern to match output. >>>>>>> >>>>>>> Right. >>>>>>> >>>>>>>> >>>>>>>> But it seems to me a little bit wrong. I've checked output of >>>>>>>> GC log with different GCs and ExplicitGCInvokesConcurrent. >>>>>>>> Message "Full GC (System.gc())" does not appear only in case of >>>>>>>> using G1 or CMS with ExplicitGCInvokesConcurrent=true. Will fix >>>>>>>> it. >>>>>>> >>>>>>> OK. >>>>>>> >>>>>>> My main point was that I think the whole structure of the test >>>>>>> is different than how we usually write tests that verify the log >>>>>>> output. I would prefer if the tests look similar. Would you mind >>>>>>> re-writing the test to look like the other tests. >>>>>>> >>>>>>> I much prefer that you explicitly start with the GCs you want to >>>>>>> test than that you use the WhiteBox API to find out which GC you >>>>>>> are running. >>>>>>> >>>>>>> I'm having a similar discussion with Dima who recently invented >>>>>>> yet another way to parse the GC log output from tests. I think >>>>>>> it gets very hard to read the tests when they do the same thing >>>>>>> in different ways. >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Michail >>>>>>>> On 11.02.2015 16:15, Bengt Rutisson wrote: >>>>>>>>> >>>>>>>>> Hi Michail, >>>>>>>>> >>>>>>>>> On 11/02/15 13:55, Michail Chernov wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Still hoping for review! >>>>>>>>> >>>>>>>>> Sorry for being so late in looking at this. >>>>>>>>> >>>>>>>>> A couple of questions: >>>>>>>>> >>>>>>>>> Why does the test only test the parallel GC? DisableExplicitGC >>>>>>>>> is valid for all GCs. >>>>>>>>> >>>>>>>>> What do you think about writing this test similar to other >>>>>>>>> tests that validate the output from the GC logging? Here's an >>>>>>>>> example: >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/file/566574421b40/test/gc/g1/TestGCLogMessages.java >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Bengt >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Michail >>>>>>>>>> >>>>>>>>>> On 05.02.2015 21:05, Michail Chernov wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Still waiting for reviews! >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Michail >>>>>>>>>>> >>>>>>>>>>> On 03.02.2015 20:12, Michail Chernov wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Can someone take a look on these changes, please? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Michail >>>>>>>>>>>> >>>>>>>>>>>> On 30.01.2015 18:33, Michail Chernov wrote: >>>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>>> >>>>>>>>>>>>> Issues were fixed: >>>>>>>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Now all testcases are executed from the same VM. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Michail >>>>>>>>>>>>> >>>>>>>>>>>>> On 28.01.2015 18:28, Leonid Mesnik wrote: >>>>>>>>>>>>>> Hi >>>>>>>>>>>>>> >>>>>>>>>>>>>> Why is it needed to start VM twice for each test. It is >>>>>>>>>>>>>> very expensive especially for low-end devices. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is it possible to have driver which starts VM several >>>>>>>>>>>>>> times with different combinations of options and check it >>>>>>>>>>>>>> output/exit code etc? Also it would be much easier to >>>>>>>>>>>>>> read such test. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Leonid >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 27.01.2015 18:35, Michail Chernov wrote: >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review the fix with new test for >>>>>>>>>>>>>>> DisableExplicitGC VM flag. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Enhancement: >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8026047 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is one scenario with 6 parameters combinations. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1,2,3 scenarios test default value for >>>>>>>>>>>>>>> DisableExplicitGC, DisableExplicitGC=true and >>>>>>>>>>>>>>> DisableExplicitGC=false >>>>>>>>>>>>>>> 4,5,6 scenarios check how VM works when VM changes >>>>>>>>>>>>>>> DisableExplicitGC flag using WhiteBox. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Test tries to call System.gc() and check that VM puts >>>>>>>>>>>>>>> message to stdout. After (in case of 4,5,6 scenarios) >>>>>>>>>>>>>>> test tries to change DisableExplicitGC value and calls >>>>>>>>>>>>>>> System.gc() twice. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Test was executed locally on linux-i586 with all >>>>>>>>>>>>>>> available GC and several GC-related flags. Also it was >>>>>>>>>>>>>>> executed using Aurora on other platforms. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Michail >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >> > > > From yasuenag at gmail.com Wed Mar 11 13:13:27 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 11 Mar 2015 22:13:27 +0900 Subject: RFR: JDK-8072913: [REDO] GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <54DF4956.7030709@gmail.com> References: <54DB6113.4080104@gmail.com> <54DDEF20.6010501@oracle.com> <54DF4956.7030709@gmail.com> Message-ID: <55003F77.80606@gmail.com> Hi all, > So I think we can remove _jvmti_force_gc from is_user_requested_gc() and add _dcmd_gc_run > to it. I've uploaded new webrev, and I've applied it to new patch. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.01/ I also updated jtreg testcase. It works fine in my environment. Thanks, Yasumasa On 2015/02/14 22:10, Yasumasa Suenaga wrote: > Hi Mikael, > >> I'd prefer if you could add a GCCause::is_system_gc_equivalent() which returns true for some set of GCCause enum values, such as _java_lang_system_gc and _dcmd_gc_run > > Can I add _dcmd_gc_run to GCCause::is_user_requested_gc() ? > This function is used with GCCause::is_serviceability_requested_gc() . > CMSCollector::is_external_interruption() and AdaptiveSizePolicy::check_gc_overhead_limit() > > is_user_requested_gc() and is_serviceability_requested_gc() checkes _jvmti_force_gc > is selected. > So I think we can remove _jvmti_force_gc from is_user_requested_gc() and add _dcmd_gc_run > to it. > >> A "grep" for _java_lang_system_gc should yield more places where updates may be necessary. > > We can use GCCause::is_user_requested_gc() if the proposal in above is accepted. > > > Thanks > > Yasumasa > > > > On 2015/02/13 21:33, Mikael Gerdin wrote: >> Hi Yasumasa, >> >> On 2015-02-11 15:02, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I've committed JDK-8068589 to add new GCCause - Diagnostic Command. >>> However, it has been backouted because test is failed [1] and it is not considered >>> about concurrent GC: -XX:+ExplicitGCInvokesConcurrent [2]. >>> >>> I've created patch for this enhancement. >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.00/ >> >> I'd prefer if you could add a GCCause::is_system_gc_equivalent() which returns true for some set of GCCause enum values, such as _java_lang_system_gc and _dcmd_gc_run >> >> Given that the documentation of the GC.run command is: >> "GC.run >> Call java.lang.System.gc(). >> >> Impact: Medium: Depends on Java heap size and content. >> >> Syntax: GC.run" >> >> I interpret the documentation that the GC is supposed to be (for all intents and purposes) equivalent to the application invoking System.gc(). >> >> This would also require updates to other places where we refer to the _java_lang_system_gc GCCause, such as UseAdaptiveSizePolicyWithSystemGC >> >> A "grep" for _java_lang_system_gc should yield more places where updates may be necessary. >> >> /Mikael >> >>> >>> >>> I'm jdk9 committer, but I'm not employee at Oracle. >>> So I need a Sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011957.html >>> [2] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011962.html >>> From eric.caspole at oracle.com Wed Mar 11 13:43:23 2015 From: eric.caspole at oracle.com (Eric Caspole) Date: Wed, 11 Mar 2015 06:43:23 -0700 (PDT) Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases Message-ID: Hi Bengt, Sorry I am late getting to this this. My only comment on this change is that it took me a while to figure out "_sub_count" -- it's an optional extra statistic or detail about that phase where it is used. Could _sub_count be named _phase_detail or _thread_work_items or something that better shows what it's used for? Thanks, Eric ----- Original Message ----- From: bengt.rutisson at oracle.com To: thomas.schatzl at oracle.com Cc: hotspot-gc-dev at openjdk.java.net Sent: Tuesday, March 10, 2015 7:37:14 AM GMT -05:00 US/Canada Eastern Subject: Re: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases Hi Thomas, On 2015-03-10 11:39, Thomas Schatzl wrote: > Hi Bengt, > > On Tue, 2015-03-10 at 10:48 +0100, Bengt Rutisson wrote: >> Hi Erik, > [...] >> To get this email thread back on track - I'm still looking for reviews >> for the latest webrev: >> http://cr.openjdk.java.net/~brutisso/8074037/webrev.03/ >> > - g1CollectedHeap.cpp:3754, active_workers should be a uint I think to > match the parameter types. Good catch. > > - minor style issue (feel free to ignore): the change stores the > G1GCPhaseTimes instances into local variables a few times. That variable > is sometimes called "timer", "phase_times". Also e.g. G1CLDClosure may > benefit from introducing a local variable. Fixed. > > - another (feel free to ignore): in the long sum starting with > g1CollectorPolicy.cpp:1134 the operators are sometimes at the end of the > preceding line, sometimes before. I would prefer them at the end of the > preceding line. Fixed. > - thanks for removing the PRAGMA's in g1GCPhaseTimes.cpp. :) Yes, nice to get rid of this. > Looks good otherwise. Thanks! Here's an updated webrev: http://cr.openjdk.java.net/~brutisso/8074037/webrev.04/ And a diff compared to last time: http://cr.openjdk.java.net/~brutisso/8074037/webrev.03-04.diff/ Bengt > > Thanks, > Thomas > > > From mikael.gerdin at oracle.com Wed Mar 11 14:04:32 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 11 Mar 2015 15:04:32 +0100 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: <54FED644.7090404@oracle.com> References: <54F08F8A.7070901@oracle.com> <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> <54F41E05.2090905@oracle.com> <54F48C84.3060602@oracle.com> <54F5DCFA.8010900@oracle.com> <54F71F02.3030309@oracle.com> <54FEBDD8.4060102@oracle.com> <1425983954.3344.26.camel@oracle.com> <54FED644.7090404@oracle.com> Message-ID: <55004B70.7020900@oracle.com> Hi Bengt, On 2015-03-10 12:32, Bengt Rutisson wrote: > > Hi Thomas, > > On 2015-03-10 11:39, Thomas Schatzl wrote: >> Hi Bengt, >> >> On Tue, 2015-03-10 at 10:48 +0100, Bengt Rutisson wrote: >>> Hi Erik, >> [...] >>> To get this email thread back on track - I'm still looking for reviews >>> for the latest webrev: >>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.03/ >>> >> - g1CollectedHeap.cpp:3754, active_workers should be a uint I think to >> match the parameter types. > > Good catch. > >> >> - minor style issue (feel free to ignore): the change stores the >> G1GCPhaseTimes instances into local variables a few times. That variable >> is sometimes called "timer", "phase_times". Also e.g. G1CLDClosure may >> benefit from introducing a local variable. > > Fixed. > >> >> - another (feel free to ignore): in the long sum starting with >> g1CollectorPolicy.cpp:1134 the operators are sometimes at the end of the >> preceding line, sometimes before. I would prefer them at the end of the >> preceding line. > > Fixed. > >> - thanks for removing the PRAGMA's in g1GCPhaseTimes.cpp. :) > > Yes, nice to get rid of this. > >> Looks good otherwise. > > Thanks! > > Here's an updated webrev: > http://cr.openjdk.java.net/~brutisso/8074037/webrev.04/ Overall the change looks good, but with the logging the devil is in the details :) I have just a few stylistic issues, I don't need to re-review the change if you want to push it. in g1GCPhaseTimes.cpp void G1GCPhaseTimes::note_gc_end() { You call ->verify() after the calculations instead of before in g1StringDedup.cpp void G1StringDedup::unlink_or_oops_do(BoolObjectClosure* is_alive, OopClosure* keep_alive, bool allow_resize_and_rehash, G1GCPhaseTimes* phase_times) { The parameters are not lined up properly. /Mikael > > And a diff compared to last time: > http://cr.openjdk.java.net/~brutisso/8074037/webrev.03-04.diff/ > > Bengt > >> >> Thanks, >> Thomas >> >> >> > From mikael.gerdin at oracle.com Wed Mar 11 14:05:32 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 11 Mar 2015 15:05:32 +0100 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: References: Message-ID: <55004BAC.3030406@oracle.com> On 2015-03-11 14:43, Eric Caspole wrote: > Hi Bengt, > Sorry I am late getting to this this. My only comment on this change is that it took me a while to figure out "_sub_count" -- it's an optional extra statistic or detail about that phase where it is used. Could _sub_count be named _phase_detail or _thread_work_items or something that better shows what it's used for? +1 on this, rename and potentially add a comment as well. I forgot to mention this in my review. /Mikael > Thanks, > Eric > > > ----- Original Message ----- > From: bengt.rutisson at oracle.com > To: thomas.schatzl at oracle.com > Cc: hotspot-gc-dev at openjdk.java.net > Sent: Tuesday, March 10, 2015 7:37:14 AM GMT -05:00 US/Canada Eastern > Subject: Re: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases > > > Hi Thomas, > > On 2015-03-10 11:39, Thomas Schatzl wrote: >> Hi Bengt, >> >> On Tue, 2015-03-10 at 10:48 +0100, Bengt Rutisson wrote: >>> Hi Erik, >> [...] >>> To get this email thread back on track - I'm still looking for reviews >>> for the latest webrev: >>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.03/ >>> >> - g1CollectedHeap.cpp:3754, active_workers should be a uint I think to >> match the parameter types. > > Good catch. > >> >> - minor style issue (feel free to ignore): the change stores the >> G1GCPhaseTimes instances into local variables a few times. That variable >> is sometimes called "timer", "phase_times". Also e.g. G1CLDClosure may >> benefit from introducing a local variable. > > Fixed. > >> >> - another (feel free to ignore): in the long sum starting with >> g1CollectorPolicy.cpp:1134 the operators are sometimes at the end of the >> preceding line, sometimes before. I would prefer them at the end of the >> preceding line. > > Fixed. > >> - thanks for removing the PRAGMA's in g1GCPhaseTimes.cpp. :) > > Yes, nice to get rid of this. > >> Looks good otherwise. > > Thanks! > > Here's an updated webrev: > http://cr.openjdk.java.net/~brutisso/8074037/webrev.04/ > > And a diff compared to last time: > http://cr.openjdk.java.net/~brutisso/8074037/webrev.03-04.diff/ > > Bengt > >> >> Thanks, >> Thomas >> >> >> > From bengt.rutisson at oracle.com Wed Mar 11 14:30:46 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 11 Mar 2015 15:30:46 +0100 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: <55004B70.7020900@oracle.com> References: <54F08F8A.7070901@oracle.com> <0EC3483F-B5D9-4B1D-9CC4-DECE9390344E@oracle.com> <54F41E05.2090905@oracle.com> <54F48C84.3060602@oracle.com> <54F5DCFA.8010900@oracle.com> <54F71F02.3030309@oracle.com> <54FEBDD8.4060102@oracle.com> <1425983954.3344.26.camel@oracle.com> <54FED644.7090404@oracle.com> <55004B70.7020900@oracle.com> Message-ID: <55005196.3080006@oracle.com> Hi Mikael, On 11/03/15 15:04, Mikael Gerdin wrote: > Hi Bengt, > > On 2015-03-10 12:32, Bengt Rutisson wrote: >> >> Hi Thomas, >> >> On 2015-03-10 11:39, Thomas Schatzl wrote: >>> Hi Bengt, >>> >>> On Tue, 2015-03-10 at 10:48 +0100, Bengt Rutisson wrote: >>>> Hi Erik, >>> [...] >>>> To get this email thread back on track - I'm still looking for reviews >>>> for the latest webrev: >>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.03/ >>>> >>> - g1CollectedHeap.cpp:3754, active_workers should be a uint I think to >>> match the parameter types. >> >> Good catch. >> >>> >>> - minor style issue (feel free to ignore): the change stores the >>> G1GCPhaseTimes instances into local variables a few times. That >>> variable >>> is sometimes called "timer", "phase_times". Also e.g. G1CLDClosure may >>> benefit from introducing a local variable. >> >> Fixed. >> >>> >>> - another (feel free to ignore): in the long sum starting with >>> g1CollectorPolicy.cpp:1134 the operators are sometimes at the end of >>> the >>> preceding line, sometimes before. I would prefer them at the end of the >>> preceding line. >> >> Fixed. >> >>> - thanks for removing the PRAGMA's in g1GCPhaseTimes.cpp. :) >> >> Yes, nice to get rid of this. >> >>> Looks good otherwise. >> >> Thanks! >> >> Here's an updated webrev: >> http://cr.openjdk.java.net/~brutisso/8074037/webrev.04/ > > Overall the change looks good, but with the logging the devil is in > the details :) Agreed. I did try to verify that the actual log output has not changed at all. :) > > I have just a few stylistic issues, I don't need to re-review the > change if you want to push it. > > > in g1GCPhaseTimes.cpp > void G1GCPhaseTimes::note_gc_end() { > > You call ->verify() after the calculations instead of before > > in g1StringDedup.cpp > void G1StringDedup::unlink_or_oops_do(BoolObjectClosure* is_alive, > OopClosure* keep_alive, > bool allow_resize_and_rehash, > G1GCPhaseTimes* phase_times) { > > The parameters are not lined up properly. Good. I'll fix this before I push. Thanks for the review! Bengt > > /Mikael > >> >> And a diff compared to last time: >> http://cr.openjdk.java.net/~brutisso/8074037/webrev.03-04.diff/ >> >> Bengt >> >>> >>> Thanks, >>> Thomas >>> >>> >>> >> From bengt.rutisson at oracle.com Wed Mar 11 14:35:22 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 11 Mar 2015 15:35:22 +0100 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: References: Message-ID: <550052AA.3020600@oracle.com> Hi Eric, Thanks for looking at this! On 11/03/15 14:43, Eric Caspole wrote: > Hi Bengt, > Sorry I am late getting to this this. My only comment on this change is that it took me a while to figure out "_sub_count" -- it's an optional extra statistic or detail about that phase where it is used. Could _sub_count be named _phase_detail or _thread_work_items or something that better shows what it's used for? Yes, I was struggling a bit with that name. The reason I picked count was that it is currently always some kind of "count" - number of buffers processed for example. For that reason I think your suggestion of _thread_work_items is better than _phase_detail since that latter does not say much about how to use this. I'll change to _thread_work_items. Thanks, Bengt > Thanks, > Eric > > > ----- Original Message ----- > From: bengt.rutisson at oracle.com > To: thomas.schatzl at oracle.com > Cc: hotspot-gc-dev at openjdk.java.net > Sent: Tuesday, March 10, 2015 7:37:14 AM GMT -05:00 US/Canada Eastern > Subject: Re: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases > > > Hi Thomas, > > On 2015-03-10 11:39, Thomas Schatzl wrote: >> Hi Bengt, >> >> On Tue, 2015-03-10 at 10:48 +0100, Bengt Rutisson wrote: >>> Hi Erik, >> [...] >>> To get this email thread back on track - I'm still looking for reviews >>> for the latest webrev: >>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.03/ >>> >> - g1CollectedHeap.cpp:3754, active_workers should be a uint I think to >> match the parameter types. > Good catch. > >> - minor style issue (feel free to ignore): the change stores the >> G1GCPhaseTimes instances into local variables a few times. That variable >> is sometimes called "timer", "phase_times". Also e.g. G1CLDClosure may >> benefit from introducing a local variable. > Fixed. > >> - another (feel free to ignore): in the long sum starting with >> g1CollectorPolicy.cpp:1134 the operators are sometimes at the end of the >> preceding line, sometimes before. I would prefer them at the end of the >> preceding line. > Fixed. > >> - thanks for removing the PRAGMA's in g1GCPhaseTimes.cpp. :) > Yes, nice to get rid of this. > >> Looks good otherwise. > Thanks! > > Here's an updated webrev: > http://cr.openjdk.java.net/~brutisso/8074037/webrev.04/ > > And a diff compared to last time: > http://cr.openjdk.java.net/~brutisso/8074037/webrev.03-04.diff/ > > Bengt > >> Thanks, >> Thomas >> >> >> From jesper.wilhelmsson at oracle.com Wed Mar 11 17:14:29 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 11 Mar 2015 18:14:29 +0100 Subject: RFR: 8026047: [TESTBUG] add regression test for DisableExplicitGC flag In-Reply-To: <55003B32.9070908@oracle.com> References: <54C7B051.8050808@oracle.com> <54C90036.8030506@oracle.com> <54CBA45D.8090503@oracle.com> <54D10193.3060407@oracle.com> <54D3B107.9050901@oracle.com> <54DB512A.7070003@oracle.com> <54DB55E9.2080302@oracle.com> <54DB7667.3020107@oracle.com> <54DCB396.2080807@oracle.com> <54EDC32B.7020605@oracle.com> <54F56A96.20702@oracle.com> <54F5D41C.3080009@oracle.com> <54F6C579.9020500@oracle.com> <54F84A4C.4040700@oracle.com> <54FD98DC.4070100@oracle.com> <55003B32.9070908@oracle.com> Message-ID: <550077F5.4030609@oracle.com> Hi Misha, I guess you could save a couple of lines by merging 41 long collectionCountBefore = 0; 42 collectionCountBefore = getCollectionCount(list); into 41 long collectionCountBefore = getCollectionCount(list); And in lines 44, 45 as well. Besides that it looks good. I don't need to see a new webrev if you decide to do this change. Thanks, /Jesper Michail Chernov skrev den 11/3/15 13:55: > Hi, > > Thanks, Bengt! > > Could someone else have a look on this change please? > > Thanks, > Michail > > On 09.03.2015 15:58, Bengt Rutisson wrote: >> >> Hi Michail, >> >> On 2015-03-05 13:21, Michail Chernov wrote: >>> Hi Bengt, >>> >>> I used your approach: >>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.03/ >> >> This looks fine to me. :) >> >>> >>> assertEQ was changed to assertLT, because different GC can produce different >>> count of collections. >>> >>> For example: >>> -XX:+UseParallelGC >>> can produce: >>> PS MarkSweep 1 >>> PS Scavenge 1 >>> >>> -XX:+UseConcMarkSweepGC -XX:+ExplicitGCInvokesConcurrent >>> can produce: >>> ParNew 1 >>> ConcurrentMarkSweep 1 >> >> Right. If you wanted to you could check the name of the GarbageCollectorMXBean >> to filter out the old GC that result from the System.GC() call. But I think >> the test as you have it now is better because it is simpler. >> >> Thanks, >> Bengt >> >>> >>> Thanks, >>> Michail >>> >>> On 04.03.2015 11:42, Bengt Rutisson wrote: >>>> >>>> Hi Michail, >>>> >>>> On 2015-03-03 16:32, Michail Chernov wrote: >>>>> Hi Bengt, >>>>> >>>>> I checked run time of test on raspberry-pi and on some solaris host with >>>>> -Xcomp option. On r-pi it works 2.8 seconds, on solaris host it works 3.5 >>>>> seconds. I can set NOTIFICATION_DELAY=5 (for example) to speed up the test. >>>> >>>> This sounds like a pretty fragile approach. My opinion is that we should >>>> always avoid tests that wait a certain amount of time for things to happen. >>>> They almost always turn out to be unstable or take unnecessarily long time. >>>> >>>>> Your approach has some cons - it does not check that System.gc() was real >>>>> GC source. >>>> >>>> Agreed. But since we actually don't have any problems with the >>>> DisbableExplicitGC flag I don't think it is worth adding a test that is >>>> potentially unstable and complex to test it. If we feel that we really need >>>> to test this flag I think the test must be simple and fast. >>>> >>>>> In case if we don't check source of GC events, we can simplify test more >>>>> and avoid usage of JMX: >>>>> >>>>> import java.lang.ref.WeakReference; >>>>> >>>>> public class Test{ >>>>> public static volatile WeakReference ref; >>>>> public static Object refObject; >>>>> public static void main(String[] args) { >>>>> ref=new WeakReference<>(new Object()); >>>>> refObject=ref.get(); >>>>> if ( refObject==null) >>>>> throw new RuntimeException("ERROR! Object was collected before >>>>> GC"); >>>>> refObject=null; >>>>> System.gc(); >>>>> refObject=ref.get(); >>>>> if ( refObject!=null) >>>>> throw new RuntimeException("ERROR! Object was not collected >>>>> during GC"); >>>>> } >>>>> } >>>>> >>>>> However, this solution does not check the real cause of GC. If this way is >>>>> applicable here, I could use this code for testing DisableExplicitGC flag. >>>> >>>> Sure, this will probably work, but I think it is kind of a strange way to >>>> check this. I prefer a more explicit way of testing. >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> >>>>> Thanks, >>>>> Michail >>>>> >>>>> On 03.03.2015 11:02, Bengt Rutisson wrote: >>>>>> >>>>>> Hi Michail, >>>>>> >>>>>> I like the idea of using the GarbageCollectionMXBean! >>>>>> >>>>>> However, I am not too happy about the test waiting for 20 seconds. >>>>>> Especially since you have the failing test which will actually wait for 20 >>>>>> seconds. >>>>>> >>>>>> Instead I would suggest to just use the collection count. Attaching a >>>>>> version of the test that use that instead. What do you think about this >>>>>> approach? >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>> >>>>>> >>>>>> On 2015-02-25 13:42, Michail Chernov wrote: >>>>>>> Hi Bengt, >>>>>>> >>>>>>> I've rewritten test using JMX. I don't see here any reason to use gc log >>>>>>> for testing this flag. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.02/ >>>>>>> >>>>>>> It seems better solution because it doesn't depend on used GC or log >>>>>>> message format. >>>>>>> >>>>>>> Tested locally with JDK 9 b51 using several GC. Tested using Aurora on >>>>>>> all platforms. >>>>>>> >>>>>>> Thanks, >>>>>>> Michail >>>>>>> >>>>>>> On 12.02.2015 17:07, Bengt Rutisson wrote: >>>>>>>> >>>>>>>> Hi Michail, >>>>>>>> >>>>>>>> On 11/02/15 16:33, Michail Chernov wrote: >>>>>>>>> Hi Bengt, >>>>>>>>> >>>>>>>>> Test works with all options passed to jtreg during testing ( see line >>>>>>>>> 97 vmOpts.addAll(0, Utils.getVmOptions());). Doesn't need to >>>>>>>>> check all GC's, it will be done during nightly. >>>>>>>> >>>>>>>> Ah. I see that now. >>>>>>>> >>>>>>>>> >>>>>>>>> 44 public final static String[] PARALLEL_GC_OPTIONS = >>>>>>>>> {"UseParallelGC", "UseParallelOldGC"}; >>>>>>>>> Here is defined special options. If define one of these options - will >>>>>>>>> be used other pattern to match output. >>>>>>>> >>>>>>>> Right. >>>>>>>> >>>>>>>>> >>>>>>>>> But it seems to me a little bit wrong. I've checked output of GC log >>>>>>>>> with different GCs and ExplicitGCInvokesConcurrent. Message "Full GC >>>>>>>>> (System.gc())" does not appear only in case of using G1 or CMS with >>>>>>>>> ExplicitGCInvokesConcurrent=true. Will fix it. >>>>>>>> >>>>>>>> OK. >>>>>>>> >>>>>>>> My main point was that I think the whole structure of the test is >>>>>>>> different than how we usually write tests that verify the log output. I >>>>>>>> would prefer if the tests look similar. Would you mind re-writing the >>>>>>>> test to look like the other tests. >>>>>>>> >>>>>>>> I much prefer that you explicitly start with the GCs you want to test >>>>>>>> than that you use the WhiteBox API to find out which GC you are running. >>>>>>>> >>>>>>>> I'm having a similar discussion with Dima who recently invented yet >>>>>>>> another way to parse the GC log output from tests. I think it gets very >>>>>>>> hard to read the tests when they do the same thing in different ways. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bengt >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Michail >>>>>>>>> On 11.02.2015 16:15, Bengt Rutisson wrote: >>>>>>>>>> >>>>>>>>>> Hi Michail, >>>>>>>>>> >>>>>>>>>> On 11/02/15 13:55, Michail Chernov wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Still hoping for review! >>>>>>>>>> >>>>>>>>>> Sorry for being so late in looking at this. >>>>>>>>>> >>>>>>>>>> A couple of questions: >>>>>>>>>> >>>>>>>>>> Why does the test only test the parallel GC? DisableExplicitGC is >>>>>>>>>> valid for all GCs. >>>>>>>>>> >>>>>>>>>> What do you think about writing this test similar to other tests that >>>>>>>>>> validate the output from the GC logging? Here's an example: >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/file/566574421b40/test/gc/g1/TestGCLogMessages.java >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Bengt >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Michail >>>>>>>>>>> >>>>>>>>>>> On 05.02.2015 21:05, Michail Chernov wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Still waiting for reviews! >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Michail >>>>>>>>>>>> >>>>>>>>>>>> On 03.02.2015 20:12, Michail Chernov wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Can someone take a look on these changes, please? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Michail >>>>>>>>>>>>> >>>>>>>>>>>>> On 30.01.2015 18:33, Michail Chernov wrote: >>>>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Issues were fixed: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Now all testcases are executed from the same VM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Michail >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 28.01.2015 18:28, Leonid Mesnik wrote: >>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Why is it needed to start VM twice for each test. It is very >>>>>>>>>>>>>>> expensive especially for low-end devices. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is it possible to have driver which starts VM several times with >>>>>>>>>>>>>>> different combinations of options and check it output/exit code >>>>>>>>>>>>>>> etc? Also it would be much easier to read such test. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Leonid >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 27.01.2015 18:35, Michail Chernov wrote: >>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review the fix with new test for DisableExplicitGC VM flag. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.00/ >>>>>>>>>>>>>>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8026047 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is one scenario with 6 parameters combinations. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1,2,3 scenarios test default value for DisableExplicitGC, >>>>>>>>>>>>>>>> DisableExplicitGC=true and DisableExplicitGC=false >>>>>>>>>>>>>>>> 4,5,6 scenarios check how VM works when VM changes >>>>>>>>>>>>>>>> DisableExplicitGC flag using WhiteBox. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Test tries to call System.gc() and check that VM puts message to >>>>>>>>>>>>>>>> stdout. After (in case of 4,5,6 scenarios) test tries to change >>>>>>>>>>>>>>>> DisableExplicitGC value and calls System.gc() twice. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Test was executed locally on linux-i586 with all available GC >>>>>>>>>>>>>>>> and several GC-related flags. Also it was executed using Aurora >>>>>>>>>>>>>>>> on other platforms. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Michail >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> > From andrey.x.zakharov at oracle.com Wed Mar 11 17:17:45 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Wed, 11 Mar 2015 20:17:45 +0300 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <1425904018.3398.69.camel@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> <54E4848A.2010203@oracle.com> <54EDFD38.6010002@oracle.com> <54EF5E2D.5020503@oracle.com> <1425308253.3357.90.camel@oracle.com> <54F5D5E8.3060400@oracle.com> <1425904018.3398.69.camel@oracle.com> Message-ID: <550078B9.9060405@oracle.com> 09.03.2015 15:26, Thomas Schatzl ?????: > Hi Andrey, > > On Tue, 2015-03-03 at 18:40 +0300, Andrey Zakharov wrote: >> Fixed according comments. >> >> hotspot webrev: >> http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/ >> >> hs-gc webrev: >> http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/hs-gc/ >> >> testing: in progress > Can you also provide the webrev for the hs-gc repository with the > changes to whitebox.java? Its provided. testing looks good, latest on sthjprt as 2015-03-11-152816.gtee.auxdata Thanks. > Thanks, > Thomas > > > From kim.barrett at oracle.com Wed Mar 11 21:16:38 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 11 Mar 2015 17:16:38 -0400 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <1426067448.3171.8.camel@oracle.com> References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> Message-ID: <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> Here?s the new webrev: Full: http://cr.openjdk.java.net/~kbarrett/8069367/webrev.01/ Incremental: http://cr.openjdk.java.net/~kbarrett/8069367/webrev.01.incr/ I haven?t done a full Aurora performance run with this new version, but the synthetic benchmark Thomas gave me isn?t showing any degradation. (In fact, once again today, the new version is running a tiny bit faster on that benchmark, e.g. the real difference is pretty much in the noise.) From bengt.rutisson at oracle.com Thu Mar 12 08:32:50 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 12 Mar 2015 09:32:50 +0100 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> Message-ID: <55014F32.3030400@oracle.com> Hi Kim and Thomas, On 2015-03-11 22:16, Kim Barrett wrote: > Here?s the new webrev: > > Full: > http://cr.openjdk.java.net/~kbarrett/8069367/webrev.01/ > > Incremental: > http://cr.openjdk.java.net/~kbarrett/8069367/webrev.01.incr/ > > I haven?t done a full Aurora performance run with this new version, but the synthetic benchmark > Thomas gave me isn?t showing any degradation. (In fact, once again today, the new version > is running a tiny bit faster on that benchmark, e.g. the real difference is pretty much in the noise.) I've been thinking a bit about the approach to solve the mark issue and I have to admit that I don't really have a good feeling about how this is currently solved. The eager reclamation knowledge is leaked in to a lot of places and we don't have any explicit way of checking what has actuallly happened. All we can do is guess that it was eager reclamation that caused things to look in unexpected ways. To me this is very fragile an might even hide other real problems that cause similar symptoms. Can we find some other way of handling this more explicitly? One thought I had was if we can note the fact that we push a humongous object on to a mark stack. Then the young GC can just check if any mark stack contains a humongous object and in that case either skip reclaiming that object or go and fix the mark stack after it has been reclaimed. Thanks, Bengt > > From bengt.rutisson at oracle.com Thu Mar 12 09:08:44 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 12 Mar 2015 10:08:44 +0100 Subject: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases In-Reply-To: <550052AA.3020600@oracle.com> References: <550052AA.3020600@oracle.com> Message-ID: <5501579C.1080309@oracle.com> Hi everyone, Here's an updated webrev that fixes the issues that Mikael brought up and the renaming that Eric suggested: http://cr.openjdk.java.net/~brutisso/8074037/webrev.05/ And the diff compared to the last webrev: http://cr.openjdk.java.net/~brutisso/8074037/webrev.04-05.diff/ Since these were all minor things and renaming I'll go ahead and push this. If there are any more comments about the latest webrev I'm happy to push a separate cleanup change to fix those comments. Thanks, Bengt On 2015-03-11 15:35, Bengt Rutisson wrote: > > Hi Eric, > > Thanks for looking at this! > > On 11/03/15 14:43, Eric Caspole wrote: >> Hi Bengt, >> Sorry I am late getting to this this. My only comment on this change >> is that it took me a while to figure out "_sub_count" -- it's an >> optional extra statistic or detail about that phase where it is used. >> Could _sub_count be named _phase_detail or _thread_work_items or >> something that better shows what it's used for? > > Yes, I was struggling a bit with that name. The reason I picked count > was that it is currently always some kind of "count" - number of > buffers processed for example. For that reason I think your suggestion > of _thread_work_items is better than _phase_detail since that latter > does not say much about how to use this. > > I'll change to _thread_work_items. > > Thanks, > Bengt > >> Thanks, >> Eric >> >> >> ----- Original Message ----- >> From: bengt.rutisson at oracle.com >> To: thomas.schatzl at oracle.com >> Cc: hotspot-gc-dev at openjdk.java.net >> Sent: Tuesday, March 10, 2015 7:37:14 AM GMT -05:00 US/Canada Eastern >> Subject: Re: RFR (M): 8074037: Refactor the G1GCPhaseTime logging to >> make it easier to add new phases >> >> >> Hi Thomas, >> >> On 2015-03-10 11:39, Thomas Schatzl wrote: >>> Hi Bengt, >>> >>> On Tue, 2015-03-10 at 10:48 +0100, Bengt Rutisson wrote: >>>> Hi Erik, >>> [...] >>>> To get this email thread back on track - I'm still looking for reviews >>>> for the latest webrev: >>>> http://cr.openjdk.java.net/~brutisso/8074037/webrev.03/ >>>> >>> - g1CollectedHeap.cpp:3754, active_workers should be a uint I think to >>> match the parameter types. >> Good catch. >> >>> - minor style issue (feel free to ignore): the change stores the >>> G1GCPhaseTimes instances into local variables a few times. That >>> variable >>> is sometimes called "timer", "phase_times". Also e.g. G1CLDClosure may >>> benefit from introducing a local variable. >> Fixed. >> >>> - another (feel free to ignore): in the long sum starting with >>> g1CollectorPolicy.cpp:1134 the operators are sometimes at the end of >>> the >>> preceding line, sometimes before. I would prefer them at the end of the >>> preceding line. >> Fixed. >> >>> - thanks for removing the PRAGMA's in g1GCPhaseTimes.cpp. :) >> Yes, nice to get rid of this. >> >>> Looks good otherwise. >> Thanks! >> >> Here's an updated webrev: >> http://cr.openjdk.java.net/~brutisso/8074037/webrev.04/ >> >> And a diff compared to last time: >> http://cr.openjdk.java.net/~brutisso/8074037/webrev.03-04.diff/ >> >> Bengt >> >>> Thanks, >>> Thomas >>> >>> >>> > From bengt.rutisson at oracle.com Thu Mar 12 10:19:41 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 12 Mar 2015 11:19:41 +0100 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <55014F32.3030400@oracle.com> References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> <55014F32.3030400@oracle.com> Message-ID: <5501683D.2000905@oracle.com> Hi again, On 2015-03-12 09:32, Bengt Rutisson wrote: > > Hi Kim and Thomas, > > On 2015-03-11 22:16, Kim Barrett wrote: >> Here?s the new webrev: >> >> Full: >> http://cr.openjdk.java.net/~kbarrett/8069367/webrev.01/ >> >> Incremental: >> http://cr.openjdk.java.net/~kbarrett/8069367/webrev.01.incr/ >> >> I haven?t done a full Aurora performance run with this new version, >> but the synthetic benchmark >> Thomas gave me isn?t showing any degradation. (In fact, once again >> today, the new version >> is running a tiny bit faster on that benchmark, e.g. the real >> difference is pretty much in the noise.) > > I've been thinking a bit about the approach to solve the mark issue > and I have to admit that I don't really have a good feeling about how > this is currently solved. The eager reclamation knowledge is leaked in > to a lot of places and we don't have any explicit way of checking what > has actuallly happened. All we can do is guess that it was eager > reclamation that caused things to look in unexpected ways. To me this > is very fragile an might even hide other real problems that cause > similar symptoms. > > Can we find some other way of handling this more explicitly? > > One thought I had was if we can note the fact that we push a humongous > object on to a mark stack. Then the young GC can just check if any > mark stack contains a humongous object and in that case either skip > reclaiming that object or go and fix the mark stack after it has been > reclaimed. I talked a bit to Mikael and StefanK about this. A more stable approach that would actually allow us to enforce the SATB invariant might be to: 1) Change G1FreeHumongousRegionClosure::doHeapRegion() to not reset the mark value for a humongous object but instead skip reclaiming objects that have the mark set. 2) Make the SATB filtering (ObjPtrQueue::filter()) note when a humongous object is pushed on a SATB queue. This information can be stored in a separate strucuture. The G1FreeHumongousRegionClosure::doHeapRegion() would have to look at this structure and avoid reclaiming any humongous objects that have appeared on the SATB queues. Not sure, but maybe this structure could be the HumongousIsLiveBiasedMappedArray that we already have. That is, when the SATB filtering detects a humongous object it will mark it as live in the HumongousIsLiveBiasedMappedArray. What do you think about this? Is it doable? Thanks, Bengt > > Thanks, > Bengt > >> >> > From andrey.x.zakharov at oracle.com Thu Mar 12 11:51:39 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Thu, 12 Mar 2015 14:51:39 +0300 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <550078B9.9060405@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> <54E4848A.2010203@oracle.com> <54EDFD38.6010002@oracle.com> <54EF5E2D.5020503@oracle.com> <1425308253.3357.90.camel@oracle.com> <54F5D5E8.3060400@oracle.com> <1425904018.3398.69.camel@oracle.com> <550078B9.9060405@oracle.com> Message-ID: <55017DCB.7050807@oracle.com> Tested in aurora as 742910.VMSQE.adhoc.JPRT.full. Looks good. Thanks. 11.03.2015 20:17, Andrey Zakharov ?????: > > 09.03.2015 15:26, Thomas Schatzl ?????: >> Hi Andrey, >> >> On Tue, 2015-03-03 at 18:40 +0300, Andrey Zakharov wrote: >>> Fixed according comments. >>> >>> hotspot webrev: >>> http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/ >>> >>> hs-gc webrev: >>> http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/hs-gc/ >>> >>> testing: in progress >> Can you also provide the webrev for the hs-gc repository with the >> changes to whitebox.java? > Its provided. > testing looks good, latest on sthjprt as 2015-03-11-152816.gtee.auxdata > Thanks. > >> Thanks, >> Thomas >> >> >> > From mikael.gerdin at oracle.com Thu Mar 12 12:55:39 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 12 Mar 2015 13:55:39 +0100 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <55017DCB.7050807@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> <54E4848A.2010203@oracle.com> <54EDFD38.6010002@oracle.com> <54EF5E2D.5020503@oracle.com> <1425308253.3357.90.camel@oracle.com> <54F5D5E8.3060400@oracle.com> <1425904018.3398.69.camel@oracle.com> <550078B9.9060405@oracle.com> <55017DCB.7050807@oracle.com> Message-ID: <55018CCB.2020204@oracle.com> Andrey, On 2015-03-12 12:51, Andrey Zakharov wrote: > Tested in aurora as 742910.VMSQE.adhoc.JPRT.full. Looks good. > Thanks. > > 11.03.2015 20:17, Andrey Zakharov ?????: >> >> 09.03.2015 15:26, Thomas Schatzl ?????: >>> Hi Andrey, >>> >>> On Tue, 2015-03-03 at 18:40 +0300, Andrey Zakharov wrote: >>>> Fixed according comments. >>>> >>>> hotspot webrev: >>>> http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/ The following code is not correct with regards to the safepoint protocol. You should not perform the ToNativeFromVM transition until you have received the data from the VM. After the transition a GC pause may occur while you are executing in get_auxillary_data_memory_usage and you can get strange results. 328 WB_ENTRY(jobject, WB_G1AuxiliaryMemoryUsage(JNIEnv* env)) 329 ResourceMark rm(THREAD); 330 ThreadToNativeFromVM ttn(thread); 331 G1CollectedHeap* g1h = G1CollectedHeap::heap(); 332 MemoryUsage mu = g1h->get_auxiliary_data_memory_usage(); 333 334 jclass jclass_memory_usage = env->FindClass("java/lang/management/MemoryUsage"); 335 CHECK_JNI_EXCEPTION_(env, NULL); 336 if (jclass_memory_usage == NULL) { I just found out that there is an existing function which creates a java.lang.management.MemoryUsage from a C++ MemoryUsage object, MemoryService::create_MemoryUsage_obj(MemoryUsage usage, TRAPS) Using this you can get rid of the state transition altogether and do something like: WB_ENTRY(jobject, WB_G1AuxiliaryMemoryUsage(JNIEnv* env)) G1CollectedHeap* g1h = G1CollectedHeap::heap(); MemoryUsage mu = g1h->get_auxiliary_data_memory_usage(); Handle h = MemoryService::create_MemoryUsage_obj(usage, CHECK_NULL); return JNIHandles::make_local(env, h()); WB_END This code is almost the same as jmm_GetMemoryPoolUsage in management.cpp so if it doesn't compile see if I've missed something. I'm pretty sure you don't need a ResourceMark for this function since it does not allocate any memory in the resource area. /Mikael >>>> >>>> hs-gc webrev: >>>> http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/hs-gc/ >>>> >>>> testing: in progress >>> Can you also provide the webrev for the hs-gc repository with the >>> changes to whitebox.java? >> Its provided. >> testing looks good, latest on sthjprt as 2015-03-11-152816.gtee.auxdata >> Thanks. >> >>> Thanks, >>> Thomas >>> >>> >>> >> > From mikael.gerdin at oracle.com Thu Mar 12 12:57:54 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 12 Mar 2015 13:57:54 +0100 Subject: RFR: JDK-8072913: [REDO] GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <55003F77.80606@gmail.com> References: <54DB6113.4080104@gmail.com> <54DDEF20.6010501@oracle.com> <54DF4956.7030709@gmail.com> <55003F77.80606@gmail.com> Message-ID: <55018D52.9060003@oracle.com> Hi, On 2015-03-11 14:13, Yasumasa Suenaga wrote: > Hi all, > >> So I think we can remove _jvmti_force_gc from is_user_requested_gc() >> and add _dcmd_gc_run >> to it. > > I've uploaded new webrev, and I've applied it to new patch. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.01/ Sorry for the delay, I've been pretty busy lately. Does anyone have time to look at this change? /Mikael > > I also updated jtreg testcase. > It works fine in my environment. > > > Thanks, > > Yasumasa > > > On 2015/02/14 22:10, Yasumasa Suenaga wrote: >> Hi Mikael, >> >>> I'd prefer if you could add a GCCause::is_system_gc_equivalent() >>> which returns true for some set of GCCause enum values, such as >>> _java_lang_system_gc and _dcmd_gc_run >> >> Can I add _dcmd_gc_run to GCCause::is_user_requested_gc() ? >> This function is used with GCCause::is_serviceability_requested_gc() . >> CMSCollector::is_external_interruption() and >> AdaptiveSizePolicy::check_gc_overhead_limit() >> >> is_user_requested_gc() and is_serviceability_requested_gc() checkes >> _jvmti_force_gc >> is selected. >> So I think we can remove _jvmti_force_gc from is_user_requested_gc() >> and add _dcmd_gc_run >> to it. >> >>> A "grep" for _java_lang_system_gc should yield more places where >>> updates may be necessary. >> >> We can use GCCause::is_user_requested_gc() if the proposal in above is >> accepted. >> >> >> Thanks >> >> Yasumasa >> >> >> >> On 2015/02/13 21:33, Mikael Gerdin wrote: >>> Hi Yasumasa, >>> >>> On 2015-02-11 15:02, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> I've committed JDK-8068589 to add new GCCause - Diagnostic Command. >>>> However, it has been backouted because test is failed [1] and it is >>>> not considered >>>> about concurrent GC: -XX:+ExplicitGCInvokesConcurrent [2]. >>>> >>>> I've created patch for this enhancement. >>>> Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.00/ >>> >>> I'd prefer if you could add a GCCause::is_system_gc_equivalent() >>> which returns true for some set of GCCause enum values, such as >>> _java_lang_system_gc and _dcmd_gc_run >>> >>> Given that the documentation of the GC.run command is: >>> "GC.run >>> Call java.lang.System.gc(). >>> >>> Impact: Medium: Depends on Java heap size and content. >>> >>> Syntax: GC.run" >>> >>> I interpret the documentation that the GC is supposed to be (for all >>> intents and purposes) equivalent to the application invoking >>> System.gc(). >>> >>> This would also require updates to other places where we refer to the >>> _java_lang_system_gc GCCause, such as UseAdaptiveSizePolicyWithSystemGC >>> >>> A "grep" for _java_lang_system_gc should yield more places where >>> updates may be necessary. >>> >>> /Mikael >>> >>>> >>>> >>>> I'm jdk9 committer, but I'm not employee at Oracle. >>>> So I need a Sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011957.html >>>> >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011962.html >>>> >>>> From andrey.x.zakharov at oracle.com Thu Mar 12 13:16:42 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Thu, 12 Mar 2015 16:16:42 +0300 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <55018CCB.2020204@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> <54E4848A.2010203@oracle.com> <54EDFD38.6010002@oracle.com> <54EF5E2D.5020503@oracle.com> <1425308253.3357.90.camel@oracle.com> <54F5D5E8.3060400@oracle.com> <1425904018.3398.69.camel@oracle.com> <550078B9.9060405@oracle.com> <55017DCB.7050807@oracle.com> <55018CCB.2020204@oracle.com> Message-ID: <550191BA.4070300@oracle.com> 12.03.2015 15:55, Mikael Gerdin ?????: > Andrey, > > On 2015-03-12 12:51, Andrey Zakharov wrote: >> Tested in aurora as 742910.VMSQE.adhoc.JPRT.full. Looks good. >> Thanks. >> >> 11.03.2015 20:17, Andrey Zakharov ?????: >>> >>> 09.03.2015 15:26, Thomas Schatzl ?????: >>>> Hi Andrey, >>>> >>>> On Tue, 2015-03-03 at 18:40 +0300, Andrey Zakharov wrote: >>>>> Fixed according comments. >>>>> >>>>> hotspot webrev: >>>>> http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/ > > The following code is not correct with regards to the safepoint > protocol. You should not perform the ToNativeFromVM transition until > you have received the data from the VM. After the transition a GC > pause may occur while you are executing in > get_auxillary_data_memory_usage and you can get strange results. > > 328 WB_ENTRY(jobject, WB_G1AuxiliaryMemoryUsage(JNIEnv* env)) > 329 ResourceMark rm(THREAD); > 330 ThreadToNativeFromVM ttn(thread); > 331 G1CollectedHeap* g1h = G1CollectedHeap::heap(); > 332 MemoryUsage mu = g1h->get_auxiliary_data_memory_usage(); > 333 > 334 jclass jclass_memory_usage = > env->FindClass("java/lang/management/MemoryUsage"); > 335 CHECK_JNI_EXCEPTION_(env, NULL); > 336 if (jclass_memory_usage == NULL) { > > I just found out that there is an existing function which creates a > java.lang.management.MemoryUsage from a C++ MemoryUsage object, > MemoryService::create_MemoryUsage_obj(MemoryUsage usage, TRAPS) > > Using this you can get rid of the state transition altogether and do > something like: > > WB_ENTRY(jobject, WB_G1AuxiliaryMemoryUsage(JNIEnv* env)) > G1CollectedHeap* g1h = G1CollectedHeap::heap(); > MemoryUsage mu = g1h->get_auxiliary_data_memory_usage(); > Handle h = MemoryService::create_MemoryUsage_obj(usage, CHECK_NULL); > return JNIHandles::make_local(env, h()); > WB_END > > This code is almost the same as jmm_GetMemoryPoolUsage in > management.cpp so if it doesn't compile see if I've missed something. > I'm pretty sure you don't need a ResourceMark for this function since > it does not allocate any memory in the resource area. > > /Mikael Hi, Mikael. Thanks for the tip. It makes things better here. But I'm in doubt about needless of ResourceMark. It exists in mentioned *jmm_GetMemoryPoolUsage: *JVM_ENTRY(jobject, jmm_GetMemoryPoolUsage(JNIEnv* env, jobject obj)) * ResourceMark rm(THREAD);* MemoryPool* pool = get_memory_pool_from_jobject(obj, CHECK_NULL); if (pool != NULL) { MemoryUsage usage = pool->get_memory_usage(); Handle h = MemoryService::create_MemoryUsage_obj(usage, CHECK_NULL); return JNIHandles::make_local(env, h()); } else { return NULL; } JVM_END* ** * > >>>>> >>>>> hs-gc webrev: >>>>> http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/hs-gc/ >>>>> >>>>> testing: in progress >>>> Can you also provide the webrev for the hs-gc repository with the >>>> changes to whitebox.java? >>> Its provided. >>> testing looks good, latest on sthjprt as 2015-03-11-152816.gtee.auxdata >>> Thanks. >>> >>>> Thanks, >>>> Thomas >>>> >>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Thu Mar 12 13:33:08 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 12 Mar 2015 14:33:08 +0100 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <550191BA.4070300@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> <54E4848A.2010203@oracle.com> <54EDFD38.6010002@oracle.com> <54EF5E2D.5020503@oracle.com> <1425308253.3357.90.camel@oracle.com> <54F5D5E8.3060400@oracle.com> <1425904018.3398.69.camel@oracle.com> <550078B9.9060405@oracle.com> <55017DCB.7050807@oracle.com> <55018CCB.2020204@oracle.com> <550191BA.4070300@oracle.com> Message-ID: <55019594.9000309@oracle.com> Andrey, On 2015-03-12 14:16, Andrey Zakharov wrote: > > 12.03.2015 15:55, Mikael Gerdin ?????: >> Andrey, >> >> On 2015-03-12 12:51, Andrey Zakharov wrote: >>> Tested in aurora as 742910.VMSQE.adhoc.JPRT.full. Looks good. >>> Thanks. >>> >>> 11.03.2015 20:17, Andrey Zakharov ?????: >>>> >>>> 09.03.2015 15:26, Thomas Schatzl ?????: >>>>> Hi Andrey, >>>>> >>>>> On Tue, 2015-03-03 at 18:40 +0300, Andrey Zakharov wrote: >>>>>> Fixed according comments. >>>>>> >>>>>> hotspot webrev: >>>>>> http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/ >> >> The following code is not correct with regards to the safepoint >> protocol. You should not perform the ToNativeFromVM transition until >> you have received the data from the VM. After the transition a GC >> pause may occur while you are executing in >> get_auxillary_data_memory_usage and you can get strange results. >> >> 328 WB_ENTRY(jobject, WB_G1AuxiliaryMemoryUsage(JNIEnv* env)) >> 329 ResourceMark rm(THREAD); >> 330 ThreadToNativeFromVM ttn(thread); >> 331 G1CollectedHeap* g1h = G1CollectedHeap::heap(); >> 332 MemoryUsage mu = g1h->get_auxiliary_data_memory_usage(); >> 333 >> 334 jclass jclass_memory_usage = >> env->FindClass("java/lang/management/MemoryUsage"); >> 335 CHECK_JNI_EXCEPTION_(env, NULL); >> 336 if (jclass_memory_usage == NULL) { >> >> I just found out that there is an existing function which creates a >> java.lang.management.MemoryUsage from a C++ MemoryUsage object, >> MemoryService::create_MemoryUsage_obj(MemoryUsage usage, TRAPS) >> >> Using this you can get rid of the state transition altogether and do >> something like: >> >> WB_ENTRY(jobject, WB_G1AuxiliaryMemoryUsage(JNIEnv* env)) >> G1CollectedHeap* g1h = G1CollectedHeap::heap(); >> MemoryUsage mu = g1h->get_auxiliary_data_memory_usage(); >> Handle h = MemoryService::create_MemoryUsage_obj(usage, CHECK_NULL); >> return JNIHandles::make_local(env, h()); >> WB_END >> >> This code is almost the same as jmm_GetMemoryPoolUsage in >> management.cpp so if it doesn't compile see if I've missed something. >> I'm pretty sure you don't need a ResourceMark for this function since >> it does not allocate any memory in the resource area. >> >> /Mikael > > Hi, Mikael. Thanks for the tip. It makes things better here. But I'm in > doubt about needless of ResourceMark. It exists in mentioned > *jmm_GetMemoryPoolUsage: Yes, but that code may be incorrect as well. Anyway, keep the ResourceMark if you like. /Mikael > > *JVM_ENTRY(jobject, jmm_GetMemoryPoolUsage(JNIEnv* env, jobject obj)) > * ResourceMark rm(THREAD);* > > MemoryPool* pool = get_memory_pool_from_jobject(obj, CHECK_NULL); > if (pool != NULL) { > MemoryUsage usage = pool->get_memory_usage(); > Handle h = MemoryService::create_MemoryUsage_obj(usage, CHECK_NULL); > return JNIHandles::make_local(env, h()); > } else { > return NULL; > } > JVM_END* > > ** > * >> >>>>>> >>>>>> hs-gc webrev: >>>>>> http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/hs-gc/ >>>>>> >>>>>> testing: in progress >>>>> Can you also provide the webrev for the hs-gc repository with the >>>>> changes to whitebox.java? >>>> Its provided. >>>> testing looks good, latest on sthjprt as 2015-03-11-152816.gtee.auxdata >>>> Thanks. >>>> >>>>> Thanks, >>>>> Thomas >>>>> >>>>> >>>>> >>>> >>> > From david.lindholm at oracle.com Thu Mar 12 15:03:23 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Thu, 12 Mar 2015 16:03:23 +0100 Subject: RFR(S) - 8073463: G1 does not mangle freed heap regions Message-ID: <5501AABB.7010806@oracle.com> Hi, Please review this small fix which mangles freed heap regions in G1. I took the opportunity to make mangle_unused_area() and mangle_unused_area_complete() pure virtual, and null-implemented them in compactibleFreeListSpace instead. I also removed Space::mangle_region(MemRegion mr) which was never called. Webrev: http://cr.openjdk.java.net/~mgerdin/david/8073463/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8073463 Testing done: JPRT Thanks, David From andrey.x.zakharov at oracle.com Thu Mar 12 16:46:35 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Thu, 12 Mar 2015 19:46:35 +0300 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <550191BA.4070300@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> <54E4848A.2010203@oracle.com> <54EDFD38.6010002@oracle.com> <54EF5E2D.5020503@oracle.com> <1425308253.3357.90.camel@oracle.com> <54F5D5E8.3060400@oracle.com> <1425904018.3398.69.camel@oracle.com> <550078B9.9060405@oracle.com> <55017DCB.7050807@oracle.com> <55018CCB.2020204@oracle.com> <550191BA.4070300@oracle.com> Message-ID: <5501C2EB.1070208@oracle.com> Fixed webrev: http://cr.openjdk.java.net/~azakharov/8061715/webrev.07/ hs-gc is same: http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/hs-gc/ Testing on the run: STH queue - 2015-03-12-160604.gtee.auxdata Thanks. 12.03.2015 16:16, Andrey Zakharov ?????: > The following code is not correct with regards to the safepoint > protocol. You should not perform the ToNativeFromVM transition until > you have received the data from the VM. After the transition a GC > pause may occur while you are executing in > get_auxillary_data_memory_usage and you can get strange results. >> >> 328 WB_ENTRY(jobject, WB_G1AuxiliaryMemoryUsage(JNIEnv* env)) >> 329 ResourceMark rm(THREAD); >> 330 ThreadToNativeFromVM ttn(thread); >> 331 G1CollectedHeap* g1h = G1CollectedHeap::heap(); >> 332 MemoryUsage mu = g1h->get_auxiliary_data_memory_usage(); >> 333 >> 334 jclass jclass_memory_usage = >> env->FindClass("java/lang/management/MemoryUsage"); >> 335 CHECK_JNI_EXCEPTION_(env, NULL); >> 336 if (jclass_memory_usage == NULL) { >> >> I just found out that there is an existing function which creates a >> java.lang.management.MemoryUsage from a C++ MemoryUsage object, >> MemoryService::create_MemoryUsage_obj(MemoryUsage usage, TRAPS) >> >> Using this you can get rid of the state transition altogether and do >> something like: >> >> WB_ENTRY(jobject, WB_G1AuxiliaryMemoryUsage(JNIEnv* env)) >> G1CollectedHeap* g1h = G1CollectedHeap::heap(); >> MemoryUsage mu = g1h->get_auxiliary_data_memory_usage(); >> Handle h = MemoryService::create_MemoryUsage_obj(usage, CHECK_NULL); >> return JNIHandles::make_local(env, h()); >> WB_END >> >> This code is almost the same as jmm_GetMemoryPoolUsage in >> management.cpp so if it doesn't compile see if I've missed something. >> I'm pretty sure you don't need a ResourceMark for this function since >> it does not allocate any memory in the resource area. >> >> /Mikael > > Hi, Mikael. Thanks for the tip. It makes things better here. But I'm > in doubt about needless of ResourceMark. It exists in mentioned > *jmm_GetMemoryPoolUsage: > > *JVM_ENTRY(jobject, jmm_GetMemoryPoolUsage(JNIEnv* env, jobject obj)) > * ResourceMark rm(THREAD);* > > MemoryPool* pool = get_memory_pool_from_jobject(obj, CHECK_NULL); > if (pool != NULL) { > MemoryUsage usage = pool->get_memory_usage(); > Handle h = MemoryService::create_MemoryUsage_obj(usage, CHECK_NULL); > return JNIHandles::make_local(env, h()); > } else { > return NULL; > } > JVM_END* > > * -------------- next part -------------- An HTML attachment was scrubbed... URL: From wessam at google.com Thu Mar 12 17:49:14 2015 From: wessam at google.com (Wessam Hassanein) Date: Thu, 12 Mar 2015 10:49:14 -0700 Subject: TenuringThreshold being adaptive when UseAdaptiveSizePolicy is off In-Reply-To: <54FF39CD.4040708@oracle.com> References: <54FA4612.2070005@oracle.com> <54FDE604.2030500@oracle.com> <54FF39CD.4040708@oracle.com> Message-ID: Jungwoo, I think the answer to your question of fixing the tenuring threshold in CMS for jdk8 is to set the TargetSurvivorRatio to 100. This will result in always using the MaxTenuringThreshold as the tenuring threshold and the desired_survivor_size as the full survivor_capacity which would match ParallelScavange with UseAdaptiveSizePolicy disabled. Regards, Wessam On Tue, Mar 10, 2015 at 11:37 AM, Jon Masamitsu wrote: > > On 3/10/2015 4:59 AM, Jungwoo Ha wrote: > > Tao, > > CMS no longer use InitialTenuringThreshold. > IIRC, even before when CMS used InitialTenuringThreshold, setting initial > and max the same value didn't turn off the adaptiveness. > > > I think we're removing that code from CMS in jdk9 > > compute_survivor_space_size_and_threshold() > > The implementation of adaptive size policy for CMS never > worked correctly. Too many times it does the exact wrong > thing. > > Jon > > > > > On Tue, Mar 10, 2015 at 12:23 AM, Tao Mao wrote: > >> Hi Jungwoo, >> >> Would fixing InitialTenuringThreshold and MaxTenuringThreshold to the >> same value work for you? >> >> Thanks. >> Tao Mao >> >> >> On Mon, Mar 9, 2015 at 10:39 PM, Jungwoo Ha wrote: >> >>> We were investigating some features and figured out that >>> ParallelScavange and ParNew has different TenuringTreshold heuristics. >>> We thought it would be nice to have a flag that can control the >>> adaptiveness, so that we can fix it on purpose to isolate other performance >>> factors. >>> --Jungwoo >>> >>> On Mon, Mar 9, 2015 at 11:27 AM, Jon Masamitsu >> > wrote: >>> >>>> Jungwoo, >>>> >>>> On 03/06/2015 06:03 PM, Jungwoo Ha wrote: >>>> >>>> I think it is the same for all JDK{7,8,9}. >>>> >>>> arguments.cpp disabled UseAdaptiveSizePolicy for CMS. >>>> parallel scavange initializes _tenuring_threshold with >>>> _tenuring_threshold = (UseAdaptiveSizePolicy) ? >>>> InitialTenuringThreshold : MaxTenuringThreshold; >>>> whereas CMS uses >>>> _tenuring_threshold = MaxTenuringThreshold; >>>> >>>> adjust_desired_tenuring_threshold() is called inside >>>> ParNewGeneration::collect(), which calls compute_tenuring_threshold. >>>> It only uses MaxTenuringThreshold and TargetSurvivorRatio. >>>> I don't see any other flags here. >>>> >>>> >>>> Yes, this is the intended behavior. >>>> >>>> You're saying we're sometimes wasting survivor space? >>>> >>>> Jon >>>> >>>> >>>> On Fri, Mar 6, 2015 at 4:28 PM, Jon Masamitsu >>> > wrote: >>>> >>>>> This is in jdk9? >>>>> >>>>> Jon >>>>> >>>>> >>>>> On 3/6/2015 4:21 PM, Jungwoo Ha wrote: >>>>> >>>>>> On CMS when UseAdaptiveSizePolicy is off, still tenuring_threshold is >>>>>> being changed. >>>>>> Is this an intended behavior? >>>>>> (yes. I know it is not "size" related heuristics) >>>>>> >>>>>> It would be nice to have a flag that can disable adjusting tenuring >>>>>> threshold, >>>>>> or at least set minimum threshold. When the default heuristics >>>>>> doesn't work, >>>>>> there are nothing much we can do other than changing the Max. >>>>>> >>>>>> --Jungwoo >>>>>> >>>>> >>>>> >>>> >>>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Thu Mar 12 21:12:32 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 12 Mar 2015 17:12:32 -0400 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <55014F32.3030400@oracle.com> References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> <55014F32.3030400@oracle.com> Message-ID: <7210F363-1473-42EC-98B9-B0AAB8F74B42@oracle.com> On Mar 12, 2015, at 4:32 AM, Bengt Rutisson wrote: > > > Hi Kim and Thomas, > > On 2015-03-11 22:16, Kim Barrett wrote: >> Here?s the new webrev: >> >> Full: >> http://cr.openjdk.java.net/~kbarrett/8069367/webrev.01/ >> >> Incremental: >> http://cr.openjdk.java.net/~kbarrett/8069367/webrev.01.incr/ >> >> I haven?t done a full Aurora performance run with this new version, but the synthetic benchmark >> Thomas gave me isn?t showing any degradation. (In fact, once again today, the new version >> is running a tiny bit faster on that benchmark, e.g. the real difference is pretty much in the noise.) > > I've been thinking a bit about the approach to solve the mark issue and I have to admit that I don't really have a good feeling about how this is currently solved. The eager reclamation knowledge is leaked in to a lot of places and we don't have any explicit way of checking what has actuallly happened. All we can do is guess that it was eager reclamation that caused things to look in unexpected ways. To me this is very fragile an might even hide other real problems that cause similar symptoms. > > Can we find some other way of handling this more explicitly? I have a somewhat similar reaction. One thing to keep in mind is that we probably want to backport a fix for this to 8u60. > One thought I had was if we can note the fact that we push a humongous object on to a mark stack. Then the young GC can just check if any mark stack contains a humongous object and in that case either skip reclaiming that object or go and fix the mark stack after it has been reclaimed. That's easy to say, but I think not so easy to do in an acceptable way. A key point is that we don't want to increase pause times to deal with this. Simply looking through the mark stacks (global and CMTask-local) as part of reclaiming a humongous object probably doesn't cut it. Thomas and I've spent some time talking about alternatives. Thomas suggested splitting up the currently single global mark stack to be per-region. That would allow easily discarding the associated (at most one) mark stack entry when eagerly reclaiming a humongous object. It might have other locality benefits too. That would still leave the CMTask-local entries to deal with. Those might be addressed by purging them at CMTask abort time, transferring their contents back to the global mark stack(s). That introduces some additional delay and possibly lock contention to that abort process, and some startup cost to pull data back in when the task is continued. Rather than purging at abort, we could filter the CMTask-local entries at continuation. That would require some care to deal with one task attempting to steal entries from another that hasn't completed the filtering process. However, anothing along this line still requires a filtering predicate, e.g. is_stale_humongous_marked_entry. This is the sort of thing I was talking about when I referred to alternatives "being complicated". Segregating (potentially reclaimable) humongous objects from others in the mark stack (in order to limit the mark stack cleanup work) will add overhead to the marking process too. We could try to make is_stale_humongous_marked_entry less heuristic. Perhaps a bit per region; all clear at the start of a concurrent marking cycle. When eagerly reclaiming a humongous object, set the bit for the start region. Filter by testing the bit. (Actual implementation might be a byte, to avoid additional bit manipulation overhead.) This could be done independently of any changes related to the mark stacks. The answer *should* be the same either way, but a more direct mechanism might better survive future changes. From kim.barrett at oracle.com Thu Mar 12 21:16:36 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 12 Mar 2015 17:16:36 -0400 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <5501683D.2000905@oracle.com> References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> <55014F32.3030400@oracle.com> <5501683D.2000905@oracle.com> Message-ID: <58A2D320-A2E7-4304-90CA-CC1C768DA52C@oracle.com> On Mar 12, 2015, at 6:19 AM, Bengt Rutisson wrote: > > A more stable approach that would actually allow us to enforce the SATB invariant might be to: The SATB invariant doesn't matter at present, because we aren't eagerly reclaiming humongous objects that contain references (up to needing to fix https://bugs.openjdk.java.net/browse/JDK-8072598). It will matter if/when we attempt to address JDK-8073288 or JDK-8048180. But as is said in JDK-8048180 However, the early reclaim mechanism should be seen as something for picking low-hanging fruits, not a replacement for the global marking, ... I'm sure there are counter examples (no matter how crazy some behavior seems, some application somwhere will exhibit it), but I suspect the vast majority of humongous objects that can even potentially be reclaimed via this mechanism are basically byte blobs of one kind or another. If that's true then having eager reclaimation only apply to such byte blobs (e.g. is_typeArray() is true) is sufficient for a large fraction of the problem. From kim.barrett at oracle.com Thu Mar 12 21:36:04 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 12 Mar 2015 17:36:04 -0400 Subject: Request for review (XXS) : 8067891 Remove vestigal G1SATBCT barrier set kind In-Reply-To: <31E486EB-329F-4B67-805C-46348B21B48D@oracle.com> References: <54FF1B4A.9020609@oracle.com> <54FF1F4B.9090609@oracle.com> <54FF42D5.1080005@oracle.com> <54FF51D4.5020609@oracle.com> <31E486EB-329F-4B67-805C-46348B21B48D@oracle.com> Message-ID: <06B5F7A3-B7ED-4B7E-8A45-E4176C762438@oracle.com> On Mar 10, 2015, at 7:10 PM, Kim Barrett wrote: > > On Mar 10, 2015, at 4:19 PM, Joseph Provino wrote: >> >> Indeed my repo was out of date. >> >> New webrev is here: http://cr.openjdk.java.net/~jprovino/8067891/webrev.02/ >> >> resubmitting to jprt now. > > Looks good. Except this touches both of the following files: src/cpu/x86/vm/templateTable_x86_64.cpp src/cpu/x86/vm/templateTable_x86_32.cpp which have been merged together by Max (JDK-8013393). That change has been pushed to hs-rt, but hasn?t propagated through to the other repos yet. You should wait until that change has propagated through and deal with the merging with your changes directly, rather than inflicting that merge on the folks who deal with the transfers between repos. From jwha at google.com Thu Mar 12 22:30:39 2015 From: jwha at google.com (Jungwoo Ha) Date: Thu, 12 Mar 2015 15:30:39 -0700 Subject: TenuringThreshold being adaptive when UseAdaptiveSizePolicy is off In-Reply-To: References: <54FA4612.2070005@oracle.com> <54FDE604.2030500@oracle.com> <54FF39CD.4040708@oracle.com> Message-ID: Nice finding. Thank you Wessam. On Thu, Mar 12, 2015 at 10:49 AM, Wessam Hassanein wrote: > Jungwoo, I think the answer to your question of fixing the tenuring > threshold in CMS for jdk8 is to set the TargetSurvivorRatio to 100. This > will result in always using the MaxTenuringThreshold as the tenuring > threshold and the desired_survivor_size as the full survivor_capacity > which would match ParallelScavange with UseAdaptiveSizePolicy disabled. > > Regards, > > Wessam > > On Tue, Mar 10, 2015 at 11:37 AM, Jon Masamitsu > wrote: > >> >> On 3/10/2015 4:59 AM, Jungwoo Ha wrote: >> >> Tao, >> >> CMS no longer use InitialTenuringThreshold. >> IIRC, even before when CMS used InitialTenuringThreshold, setting initial >> and max the same value didn't turn off the adaptiveness. >> >> >> I think we're removing that code from CMS in jdk9 >> >> compute_survivor_space_size_and_threshold() >> >> The implementation of adaptive size policy for CMS never >> worked correctly. Too many times it does the exact wrong >> thing. >> >> Jon >> >> >> >> >> On Tue, Mar 10, 2015 at 12:23 AM, Tao Mao wrote: >> >>> Hi Jungwoo, >>> >>> Would fixing InitialTenuringThreshold and MaxTenuringThreshold to the >>> same value work for you? >>> >>> Thanks. >>> Tao Mao >>> >>> >>> On Mon, Mar 9, 2015 at 10:39 PM, Jungwoo Ha wrote: >>> >>>> We were investigating some features and figured out that >>>> ParallelScavange and ParNew has different TenuringTreshold heuristics. >>>> We thought it would be nice to have a flag that can control the >>>> adaptiveness, so that we can fix it on purpose to isolate other performance >>>> factors. >>>> --Jungwoo >>>> >>>> On Mon, Mar 9, 2015 at 11:27 AM, Jon Masamitsu < >>>> jon.masamitsu at oracle.com> wrote: >>>> >>>>> Jungwoo, >>>>> >>>>> On 03/06/2015 06:03 PM, Jungwoo Ha wrote: >>>>> >>>>> I think it is the same for all JDK{7,8,9}. >>>>> >>>>> arguments.cpp disabled UseAdaptiveSizePolicy for CMS. >>>>> parallel scavange initializes _tenuring_threshold with >>>>> _tenuring_threshold = (UseAdaptiveSizePolicy) ? >>>>> InitialTenuringThreshold : MaxTenuringThreshold; >>>>> whereas CMS uses >>>>> _tenuring_threshold = MaxTenuringThreshold; >>>>> >>>>> adjust_desired_tenuring_threshold() is called inside >>>>> ParNewGeneration::collect(), which calls compute_tenuring_threshold. >>>>> It only uses MaxTenuringThreshold and TargetSurvivorRatio. >>>>> I don't see any other flags here. >>>>> >>>>> >>>>> Yes, this is the intended behavior. >>>>> >>>>> You're saying we're sometimes wasting survivor space? >>>>> >>>>> Jon >>>>> >>>>> >>>>> On Fri, Mar 6, 2015 at 4:28 PM, Jon Masamitsu < >>>>> jon.masamitsu at oracle.com> wrote: >>>>> >>>>>> This is in jdk9? >>>>>> >>>>>> Jon >>>>>> >>>>>> >>>>>> On 3/6/2015 4:21 PM, Jungwoo Ha wrote: >>>>>> >>>>>>> On CMS when UseAdaptiveSizePolicy is off, still tenuring_threshold >>>>>>> is being changed. >>>>>>> Is this an intended behavior? >>>>>>> (yes. I know it is not "size" related heuristics) >>>>>>> >>>>>>> It would be nice to have a flag that can disable adjusting tenuring >>>>>>> threshold, >>>>>>> or at least set minimum threshold. When the default heuristics >>>>>>> doesn't work, >>>>>>> there are nothing much we can do other than changing the Max. >>>>>>> >>>>>>> --Jungwoo >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Fri Mar 13 08:45:03 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 13 Mar 2015 09:45:03 +0100 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <58A2D320-A2E7-4304-90CA-CC1C768DA52C@oracle.com> References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> <55014F32.3030400@oracle.com> <5501683D.2000905@oracle.com> <58A2D320-A2E7-4304-90CA-CC1C768DA52C@oracle.com> Message-ID: <5502A38F.7000000@oracle.com> On 2015-03-12 22:16, Kim Barrett wrote: > On Mar 12, 2015, at 6:19 AM, Bengt Rutisson wrote: >> A more stable approach that would actually allow us to enforce the SATB invariant might be to: > The SATB invariant doesn't matter at present, because we aren't > eagerly reclaiming humongous objects that contain references Maybe I am splitting hairs here, but I do think the SATB invariant matter. The reason we have the bug you are trying to fix is due to the fact that early reclaim breaks the SATB invariant. You didn't really comment on my suggested way of addressing the problem. Do you think it would be doable? I think it would be more stable. Another alternative would be to let initial marking note all humongous objects that were live after initial mark. Then we can just make sure that early reclaim does not reclaim any of those humongous objects while marking is active. That should be a pretty simple fix that can be backported if necessary. Thanks, Bengt > (up to > needing to fix https://bugs.openjdk.java.net/browse/JDK-8072598). It > will matter if/when we attempt to address JDK-8073288 or JDK-8048180. > But as is said in JDK-8048180 > > However, the early reclaim mechanism should be seen as something > for picking low-hanging fruits, not a replacement for the global > marking, ... > > I'm sure there are counter examples (no matter how crazy some behavior > seems, some application somwhere will exhibit it), but I suspect the > vast majority of humongous objects that can even potentially be > reclaimed via this mechanism are basically byte blobs of one kind or > another. If that's true then having eager reclaimation only apply to > such byte blobs (e.g. is_typeArray() is true) is sufficient for a > large fraction of the problem. > From andrey.x.zakharov at oracle.com Fri Mar 13 12:00:40 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Fri, 13 Mar 2015 15:00:40 +0300 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <5501C2EB.1070208@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> <54E4848A.2010203@oracle.com> <54EDFD38.6010002@oracle.com> <54EF5E2D.5020503@oracle.com> <1425308253.3357.90.camel@oracle.com> <54F5D5E8.3060400@oracle.com> <1425904018.3398.69.camel@oracle.com> <550078B9.9060405@oracle.com> <55017DCB.7050807@oracle.com> <55018CCB.2020204@oracle.com> <550191BA.4070300@oracle.com> <5501C2EB.1070208@oracle.com> Message-ID: <5502D168.4030703@oracle.com> Hi, team Last one webrev.07 was with sad mistake - not removed ToNativeFromVM call. here is fixed webrev: http://cr.openjdk.java.net/~azakharov/8061715/webrev.08/ hs-gc same: http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/hs-gc/ testing: ok on STH queue 2015-03-13-103151.gtee.auxdata Thanks. 12.03.2015 19:46, Andrey Zakharov ?????: > Fixed > webrev: http://cr.openjdk.java.net/~azakharov/8061715/webrev.07/ > > hs-gc is same: > http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/hs-gc/ > > Testing on the run: STH queue - 2015-03-12-160604.gtee.auxdata > > Thanks. > > 12.03.2015 16:16, Andrey Zakharov ?????: >> The following code is not correct with regards to the safepoint >> protocol. You should not perform the ToNativeFromVM transition until >> you have received the data from the VM. After the transition a GC >> pause may occur while you are executing in >> get_auxillary_data_memory_usage and you can get strange results. >>> >>> 328 WB_ENTRY(jobject, WB_G1AuxiliaryMemoryUsage(JNIEnv* env)) >>> 329 ResourceMark rm(THREAD); >>> 330 ThreadToNativeFromVM ttn(thread); >>> 331 G1CollectedHeap* g1h = G1CollectedHeap::heap(); >>> 332 MemoryUsage mu = g1h->get_auxiliary_data_memory_usage(); >>> 333 >>> 334 jclass jclass_memory_usage = >>> env->FindClass("java/lang/management/MemoryUsage"); >>> 335 CHECK_JNI_EXCEPTION_(env, NULL); >>> 336 if (jclass_memory_usage == NULL) { >>> >>> I just found out that there is an existing function which creates a >>> java.lang.management.MemoryUsage from a C++ MemoryUsage object, >>> MemoryService::create_MemoryUsage_obj(MemoryUsage usage, TRAPS) >>> >>> Using this you can get rid of the state transition altogether and do >>> something like: >>> >>> WB_ENTRY(jobject, WB_G1AuxiliaryMemoryUsage(JNIEnv* env)) >>> G1CollectedHeap* g1h = G1CollectedHeap::heap(); >>> MemoryUsage mu = g1h->get_auxiliary_data_memory_usage(); >>> Handle h = MemoryService::create_MemoryUsage_obj(usage, CHECK_NULL); >>> return JNIHandles::make_local(env, h()); >>> WB_END >>> >>> This code is almost the same as jmm_GetMemoryPoolUsage in >>> management.cpp so if it doesn't compile see if I've missed something. >>> I'm pretty sure you don't need a ResourceMark for this function >>> since it does not allocate any memory in the resource area. >>> >>> /Mikael >> >> Hi, Mikael. Thanks for the tip. It makes things better here. But I'm >> in doubt about needless of ResourceMark. It exists in mentioned >> *jmm_GetMemoryPoolUsage: >> >> *JVM_ENTRY(jobject, jmm_GetMemoryPoolUsage(JNIEnv* env, jobject obj)) >> * ResourceMark rm(THREAD);* >> >> MemoryPool* pool = get_memory_pool_from_jobject(obj, CHECK_NULL); >> if (pool != NULL) { >> MemoryUsage usage = pool->get_memory_usage(); >> Handle h = MemoryService::create_MemoryUsage_obj(usage, CHECK_NULL); >> return JNIHandles::make_local(env, h()); >> } else { >> return NULL; >> } >> JVM_END* >> >> * > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Fri Mar 13 12:32:59 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 13 Mar 2015 13:32:59 +0100 Subject: RFR(S) - 8073463: G1 does not mangle freed heap regions In-Reply-To: <5501AABB.7010806@oracle.com> References: <5501AABB.7010806@oracle.com> Message-ID: <5502D8FB.10909@oracle.com> Hi David, On 2015-03-12 16:03, David Lindholm wrote: > Hi, > > Please review this small fix which mangles freed heap regions in G1. I > took the opportunity to make mangle_unused_area() and > mangle_unused_area_complete() pure virtual, and null-implemented them in > compactibleFreeListSpace instead. I also removed > Space::mangle_region(MemRegion mr) which was never called. > > > Webrev: http://cr.openjdk.java.net/~mgerdin/david/8073463/webrev/ Looks good to me, Reviewed. /Mikael > Bug: https://bugs.openjdk.java.net/browse/JDK-8073463 > > Testing done: JPRT > > > Thanks, > David From jesper.wilhelmsson at oracle.com Fri Mar 13 13:20:24 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 13 Mar 2015 14:20:24 +0100 Subject: RFR(S) - 8073463: G1 does not mangle freed heap regions In-Reply-To: <5501AABB.7010806@oracle.com> References: <5501AABB.7010806@oracle.com> Message-ID: <5502E418.2080504@oracle.com> Looks good! /Jesper David Lindholm skrev den 12/3/15 16:03: > Hi, > > Please review this small fix which mangles freed heap regions in G1. I took the > opportunity to make mangle_unused_area() and mangle_unused_area_complete() pure > virtual, and null-implemented them in compactibleFreeListSpace instead. I also > removed Space::mangle_region(MemRegion mr) which was never called. > > > Webrev: http://cr.openjdk.java.net/~mgerdin/david/8073463/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8073463 > > Testing done: JPRT > > > Thanks, > David From kim.barrett at oracle.com Fri Mar 13 17:51:12 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 13 Mar 2015 13:51:12 -0400 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <5502A38F.7000000@oracle.com> References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> <55014F32.3030400@oracle.com> <5501683D.2000905@oracle.com> <58A2D320-A2E7-4304-90CA-CC1C768DA52C@oracle.com> <5502A38F.7000000@oracle.com> Message-ID: On Mar 13, 2015, at 4:45 AM, Bengt Rutisson wrote: > > Another alternative would be to let initial marking note all humongous objects that were live after initial mark. Then we can just make sure that early reclaim does not reclaim any of those humongous objects while marking is active. That should be a pretty simple fix that can be backported if necessary. Bengt and I talked about this some more; I?m going to have a look at the code for this, as it seems likely better. From jesper.wilhelmsson at oracle.com Mon Mar 16 10:19:45 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 16 Mar 2015 11:19:45 +0100 Subject: RFR: JDK-8057632 - Remove auxiliary code used to handle the generations array In-Reply-To: <54F4AA70.5070003@oracle.com> References: <54F4AA70.5070003@oracle.com> Message-ID: <5506AE41.40708@oracle.com> Ping? Needs one Review, Kim has approved it. Latest version is in: http://cr.openjdk.java.net/~jwilhelm/8057632/webrev.03/ This change is blocking eight other cleanups following the generation array removal so it would be nice to get it in. Thanks, /Jesper Jesper Wilhelmsson skrev den 2/3/15 19:22: > Hi, > > The generation array removal enabled several other cleanups. I have several > changes in queue to perform these cleanups one at a time. > > In this change the methods next_gen(), prev_gen() and get_gen() are removed and > calls are replaced with explicit calls to young_gen() and old_gen(). > > Please have a look. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8057632 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8057632/webrev.02/ > > Thanks! > /Jesper From thomas.schatzl at oracle.com Mon Mar 16 12:02:32 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 16 Mar 2015 13:02:32 +0100 Subject: RFR: JDK-8057632 - Remove auxiliary code used to handle the generations array In-Reply-To: <5506AE41.40708@oracle.com> References: <54F4AA70.5070003@oracle.com> <5506AE41.40708@oracle.com> Message-ID: <1426507352.3188.47.camel@oracle.com> Hi Jesper, On Mon, 2015-03-16 at 11:19 +0100, Jesper Wilhelmsson wrote: > Ping? > > Needs one Review, Kim has approved it. > > Latest version is in: http://cr.openjdk.java.net/~jwilhelm/8057632/webrev.03/ > looks good. Thanks, Thomas From jesper.wilhelmsson at oracle.com Mon Mar 16 12:19:59 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 16 Mar 2015 13:19:59 +0100 Subject: RFR: JDK-8057632 - Remove auxiliary code used to handle the generations array In-Reply-To: <1426507352.3188.47.camel@oracle.com> References: <54F4AA70.5070003@oracle.com> <5506AE41.40708@oracle.com> <1426507352.3188.47.camel@oracle.com> Message-ID: <5506CA6F.20103@oracle.com> Thank you Thomas! /Jesper Thomas Schatzl skrev den 16/3/15 13:02: > Hi Jesper, > > On Mon, 2015-03-16 at 11:19 +0100, Jesper Wilhelmsson wrote: >> Ping? >> >> Needs one Review, Kim has approved it. >> >> Latest version is in: http://cr.openjdk.java.net/~jwilhelm/8057632/webrev.03/ >> > > looks good. > > Thanks, > Thomas > From andrey.x.zakharov at oracle.com Mon Mar 16 12:57:32 2015 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Mon, 16 Mar 2015 15:57:32 +0300 Subject: RFR: 8073669: gc/TestSoftReferencesBehaviorOnOOME.java times out in nightlies Message-ID: <5506D33C.40101@oracle.com> Hi, team. I've changed test scenario to more straight-forward one, added tricks to prevent compiler optimizations and added checks when OOME didn't thrown as expected. webrev: http://cr.openjdk.java.net/~azakharov/8073669/webrev/ testbug: https://bugs.openjdk.java.net/browse/JDK-8073669 testing: done in jprt, looks good now. Thanks. From thomas.schatzl at oracle.com Mon Mar 16 13:21:04 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 16 Mar 2015 14:21:04 +0100 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <5502D168.4030703@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> <54E4848A.2010203@oracle.com> <54EDFD38.6010002@oracle.com> <54EF5E2D.5020503@oracle.com> <1425308253.3357.90.camel@oracle.com> <54F5D5E8.3060400@oracle.com> <1425904018.3398.69.camel@oracle.com> <550078B9.9060405@oracle.com> <55017DCB.7050807@oracle.com> <55018CCB.2020204@oracle.com> <550191BA.4070300@oracle.com> <5501C2EB.1070208@oracle.com> <5502D168.4030703@oracle.com> Message-ID: <1426512064.3188.55.camel@oracle.com> Hi Andrey, On Fri, 2015-03-13 at 15:00 +0300, Andrey Zakharov wrote: > Hi, team > > Last one webrev.07 was with sad mistake - not removed ToNativeFromVM > call. > here is fixed > > webrev: > http://cr.openjdk.java.net/~azakharov/8061715/webrev.08/ > > hs-gc same: > http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/hs-gc/ > > testing: ok on STH queue 2015-03-13-103151.gtee.auxdata seems okay. Thanks, Thomas From jesper.wilhelmsson at oracle.com Mon Mar 16 13:28:49 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 16 Mar 2015 14:28:49 +0100 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <1426512064.3188.55.camel@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> <54E4848A.2010203@oracle.com> <54EDFD38.6010002@oracle.com> <54EF5E2D.5020503@oracle.com> <1425308253.3357.90.camel@oracle.com> <54F5D5E8.3060400@oracle.com> <1425904018.3398.69.camel@oracle.com> <550078B9.9060405@oracle.com> <55017DCB.7050807@oracle.com> <55018CCB.2020204@oracle.com> <550191BA.4070300@oracle.com> <5501C2EB.1070208@oracle.com> <5502D168.4030703@oracle.com> <1426512064.3188.55.camel@oracle.com> Message-ID: <5506DA91.4010905@oracle.com> Looks good. /Jesper Thomas Schatzl skrev den 16/3/15 14:21: > Hi Andrey, > > On Fri, 2015-03-13 at 15:00 +0300, Andrey Zakharov wrote: >> Hi, team >> >> Last one webrev.07 was with sad mistake - not removed ToNativeFromVM >> call. >> here is fixed >> >> webrev: >> http://cr.openjdk.java.net/~azakharov/8061715/webrev.08/ >> >> hs-gc same: >> http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/hs-gc/ >> >> testing: ok on STH queue 2015-03-13-103151.gtee.auxdata > > seems okay. > > Thanks, > Thomas > > From mikael.gerdin at oracle.com Mon Mar 16 13:37:22 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 16 Mar 2015 14:37:22 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap Message-ID: <5506DC92.7090609@oracle.com> Hi all! Currently SharedHeap::process_strong_roots is called both by the GenCollectedHeap based collectors (CMS, Serial) and G1. Since G1 needs special cases for several pieces of the root processing SharedHeap needs to allow for that while attempting to maintain some layer of abstraction. This makes the SharedHeap code unnecessarily complex and makes it very difficult to reason about which combination of parameters are valid and possible. As a first step to improve the code I suggest that we copy the root processing code to a separate class for G1 and move the SharedHeap root processing to GenCollectedHeap. For now I think it's worth it to introduce slightly more duplication of the root processing code in order to reduce the complexity of the shared code path. Overall the change is consists of 15 files changed, 597 insertions(+), 551 deletions(-) Where the insertions include two new copies of the GPL license header. An additional goal for this change is to make it easier to get rid of SharedHeap altogether at some future point, there's really no point in having a shared abstract base class between G1 and GenCollectedHeap. If we want to we can also modify G1RootProcessor at some future point to allow it to be used for all root processing, including ParallelGC and JVMTI. For example the generic root processor could be implemented as some kind of class template, where function objects are passed as template parameters to control claiming of tasks and which roots to visit. In order to make it easier to review I've split up the change into 3 phases: 1. Copy SharedHeap::process_roots and G1CollectedHeap::g1_process_roots to G1RootProcessor::process_roots and convert G1's evacuation code to use G1RootProcessor. 2. Convert the rest of G1 (verification and G1MarkSweep) to use G1RootProcessor. Split G1RootProcessor::process_roots in order to allow for the different needs of different callers. 3. Move SharedHeap::process_roots to GenCollectedHeap since it's now the only caller of the code. Get rid of the ScanOption operator| since we never or them any longer. Bug: https://bugs.openjdk.java.net/browse/JDK-8075210 Webrevs: http://cr.openjdk.java.net/~mgerdin/8075210/phase-1/webrev http://cr.openjdk.java.net/~mgerdin/8075210/phase-2/webrev http://cr.openjdk.java.net/~mgerdin/8075210/phase-3/webrev Full webrev: http://cr.openjdk.java.net/~mgerdin/8075210/full/webrev Testing: JPRT /Mikael From mikael.gerdin at oracle.com Mon Mar 16 14:10:16 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 16 Mar 2015 15:10:16 +0100 Subject: [RFR] 8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before In-Reply-To: <5506D5F9.4090503@oracle.com> References: <54DCB21A.2000203@oracle.com> <1424254560.3335.5.camel@oracle.com> <54E4848A.2010203@oracle.com> <54EDFD38.6010002@oracle.com> <54EF5E2D.5020503@oracle.com> <1425308253.3357.90.camel@oracle.com> <54F5D5E8.3060400@oracle.com> <1425904018.3398.69.camel@oracle.com> <550078B9.9060405@oracle.com> <55017DCB.7050807@oracle.com> <55018CCB.2020204@oracle.com> <550191BA.4070300@oracle.com> <5501C2EB.1070208@oracle.com> <5502D168.4030703@oracle.com> <5506D5F9.4090503@oracle.com> Message-ID: <5506E448.60009@oracle.com> Forgot to include hotspot-gc-dev. Also, my statement below about "jobject o" is incorrect. It corresponds to "this", the whitebox instance. /Mikael On 2015-03-16 14:09, Mikael Gerdin wrote: > Hi Andrey, > > On 2015-03-13 13:00, Andrey Zakharov wrote: >> Hi, team >> >> Last one webrev.07 was with sad mistake - not removed ToNativeFromVM >> call. >> here is fixed >> >> webrev: >> http://cr.openjdk.java.net/~azakharov/8061715/webrev.08/ > > I think it looks good. > A minor issue is that WB_G1NumMaxRegions is not declared to take a > parameter but still has a "jobject o" in the parameter list. > This problem exists for several other G1 related WB functions so let's > leave that for a separate cleanup. > > >> >> hs-gc same: >> http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/hs-gc/ > > Looks good as well. > I think this is ready to go now. > > /Mikael > >> >> testing: ok on STH queue 2015-03-13-103151.gtee.auxdata >> >> Thanks. >> >> 12.03.2015 19:46, Andrey Zakharov ?????: >>> Fixed >>> webrev: http://cr.openjdk.java.net/~azakharov/8061715/webrev.07/ >>> >>> hs-gc is same: >>> http://cr.openjdk.java.net/~azakharov/8061715/webrev.06/hs-gc/ >>> >>> Testing on the run: STH queue - 2015-03-12-160604.gtee.auxdata >>> >>> Thanks. >>> >>> 12.03.2015 16:16, Andrey Zakharov ?????: >>>> The following code is not correct with regards to the safepoint >>>> protocol. You should not perform the ToNativeFromVM transition until >>>> you have received the data from the VM. After the transition a GC >>>> pause may occur while you are executing in >>>> get_auxillary_data_memory_usage and you can get strange results. >> >>>>> >>>>> 328 WB_ENTRY(jobject, WB_G1AuxiliaryMemoryUsage(JNIEnv* env)) >>>>> 329 ResourceMark rm(THREAD); >>>>> 330 ThreadToNativeFromVM ttn(thread); >>>>> 331 G1CollectedHeap* g1h = G1CollectedHeap::heap(); >>>>> 332 MemoryUsage mu = g1h->get_auxiliary_data_memory_usage(); >>>>> 333 >>>>> 334 jclass jclass_memory_usage = >>>>> env->FindClass("java/lang/management/MemoryUsage"); >>>>> 335 CHECK_JNI_EXCEPTION_(env, NULL); >>>>> 336 if (jclass_memory_usage == NULL) { >>>>> >>>>> I just found out that there is an existing function which creates a >>>>> java.lang.management.MemoryUsage from a C++ MemoryUsage object, >>>>> MemoryService::create_MemoryUsage_obj(MemoryUsage usage, TRAPS) >>>>> >>>>> Using this you can get rid of the state transition altogether and do >>>>> something like: >>>>> >>>>> WB_ENTRY(jobject, WB_G1AuxiliaryMemoryUsage(JNIEnv* env)) >>>>> G1CollectedHeap* g1h = G1CollectedHeap::heap(); >>>>> MemoryUsage mu = g1h->get_auxiliary_data_memory_usage(); >>>>> Handle h = MemoryService::create_MemoryUsage_obj(usage, CHECK_NULL); >>>>> return JNIHandles::make_local(env, h()); >>>>> WB_END >>>>> >>>>> This code is almost the same as jmm_GetMemoryPoolUsage in >>>>> management.cpp so if it doesn't compile see if I've missed something. >>>>> I'm pretty sure you don't need a ResourceMark for this function >>>>> since it does not allocate any memory in the resource area. >>>>> >>>>> /Mikael >>>> >>>> Hi, Mikael. Thanks for the tip. It makes things better here. But I'm >>>> in doubt about needless of ResourceMark. It exists in mentioned >>>> *jmm_GetMemoryPoolUsage: >>>> >>>> *JVM_ENTRY(jobject, jmm_GetMemoryPoolUsage(JNIEnv* env, jobject obj)) >>>> * ResourceMark rm(THREAD);* >>>> >>>> MemoryPool* pool = get_memory_pool_from_jobject(obj, CHECK_NULL); >>>> if (pool != NULL) { >>>> MemoryUsage usage = pool->get_memory_usage(); >>>> Handle h = MemoryService::create_MemoryUsage_obj(usage, >>>> CHECK_NULL); >>>> return JNIHandles::make_local(env, h()); >>>> } else { >>>> return NULL; >>>> } >>>> JVM_END* >>>> >>>> * >>> >> From bengt.rutisson at oracle.com Mon Mar 16 14:55:55 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 16 Mar 2015 15:55:55 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <5506DC92.7090609@oracle.com> References: <5506DC92.7090609@oracle.com> Message-ID: <5506EEFB.5050504@oracle.com> Hi Mikael, Nice cleanup! Thanks for splitting the webrev up into several parts. Made it much easier to review. Looks good to me. One minor thing is that the comment at the top of sharedHeap.hpp uses G1CollectedHeap::g1_process_roots() as an example for how to use a FlexibleWorkGang. Maybe we should update that comment. Also, in g1CollectedHeap.cpp, there is this code: 3111 G1RootProcessor root_processor(this, /* trace_metadata */ false); I'm more used to see the comment after the value then before. I.e: G1RootProcessor root_processor(this, false /* trace_metadata */); Thanks, Bengt On 2015-03-16 14:37, Mikael Gerdin wrote: > Hi all! > > Currently SharedHeap::process_strong_roots is called both by the > GenCollectedHeap based collectors (CMS, Serial) and G1. > > Since G1 needs special cases for several pieces of the root processing > SharedHeap needs to allow for that while attempting to maintain some > layer of abstraction. This makes the SharedHeap code unnecessarily > complex and makes it very difficult to reason about which combination > of parameters are valid and possible. > > As a first step to improve the code I suggest that we copy the root > processing code to a separate class for G1 and move the SharedHeap > root processing to GenCollectedHeap. For now I think it's worth it to > introduce slightly more duplication of the root processing code in > order to reduce the complexity of the shared code path. > > Overall the change is consists of > 15 files changed, 597 insertions(+), 551 deletions(-) > Where the insertions include two new copies of the GPL license header. > > An additional goal for this change is to make it easier to get rid of > SharedHeap altogether at some future point, there's really no point in > having a shared abstract base class between G1 and GenCollectedHeap. > > If we want to we can also modify G1RootProcessor at some future point > to allow it to be used for all root processing, including ParallelGC > and JVMTI. For example the generic root processor could be implemented > as some kind of class template, where function objects are passed as > template parameters to control claiming of tasks and which roots to > visit. > > In order to make it easier to review I've split up the change into 3 > phases: > 1. Copy SharedHeap::process_roots and > G1CollectedHeap::g1_process_roots to G1RootProcessor::process_roots > and convert G1's evacuation code to use G1RootProcessor. > 2. Convert the rest of G1 (verification and G1MarkSweep) to use > G1RootProcessor. Split G1RootProcessor::process_roots in order to > allow for the different needs of different callers. > 3. Move SharedHeap::process_roots to GenCollectedHeap since it's now > the only caller of the code. Get rid of the ScanOption operator| since > we never or them any longer. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8075210 > > Webrevs: > http://cr.openjdk.java.net/~mgerdin/8075210/phase-1/webrev > http://cr.openjdk.java.net/~mgerdin/8075210/phase-2/webrev > http://cr.openjdk.java.net/~mgerdin/8075210/phase-3/webrev > > Full webrev: > http://cr.openjdk.java.net/~mgerdin/8075210/full/webrev > > Testing: > JPRT > > /Mikael From mikael.gerdin at oracle.com Mon Mar 16 15:22:11 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 16 Mar 2015 16:22:11 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <5506EEFB.5050504@oracle.com> References: <5506DC92.7090609@oracle.com> <5506EEFB.5050504@oracle.com> Message-ID: <5506F523.9090609@oracle.com> Hi Bengt, On 2015-03-16 15:55, Bengt Rutisson wrote: > > Hi Mikael, > > Nice cleanup! Thanks for splitting the webrev up into several parts. > Made it much easier to review. > > Looks good to me. > > One minor thing is that the comment at the top of sharedHeap.hpp uses > G1CollectedHeap::g1_process_roots() as an example for how to use a > FlexibleWorkGang. Maybe we should update that comment. I updated the comment. > > Also, in g1CollectedHeap.cpp, there is this code: > > 3111 G1RootProcessor root_processor(this, /* trace_metadata */ false); > > I'm more used to see the comment after the value then before. I.e: > > G1RootProcessor root_processor(this, false /* trace_metadata */); Ok, I handn't noticed the distinction. Fixed. The comment updates are in an incremental webrev at: http://cr.openjdk.java.net/~mgerdin/8075210/comments/webrev/ /Mikael > > Thanks, > Bengt > > > On 2015-03-16 14:37, Mikael Gerdin wrote: >> Hi all! >> >> Currently SharedHeap::process_strong_roots is called both by the >> GenCollectedHeap based collectors (CMS, Serial) and G1. >> >> Since G1 needs special cases for several pieces of the root processing >> SharedHeap needs to allow for that while attempting to maintain some >> layer of abstraction. This makes the SharedHeap code unnecessarily >> complex and makes it very difficult to reason about which combination >> of parameters are valid and possible. >> >> As a first step to improve the code I suggest that we copy the root >> processing code to a separate class for G1 and move the SharedHeap >> root processing to GenCollectedHeap. For now I think it's worth it to >> introduce slightly more duplication of the root processing code in >> order to reduce the complexity of the shared code path. >> >> Overall the change is consists of >> 15 files changed, 597 insertions(+), 551 deletions(-) >> Where the insertions include two new copies of the GPL license header. >> >> An additional goal for this change is to make it easier to get rid of >> SharedHeap altogether at some future point, there's really no point in >> having a shared abstract base class between G1 and GenCollectedHeap. >> >> If we want to we can also modify G1RootProcessor at some future point >> to allow it to be used for all root processing, including ParallelGC >> and JVMTI. For example the generic root processor could be implemented >> as some kind of class template, where function objects are passed as >> template parameters to control claiming of tasks and which roots to >> visit. >> >> In order to make it easier to review I've split up the change into 3 >> phases: >> 1. Copy SharedHeap::process_roots and >> G1CollectedHeap::g1_process_roots to G1RootProcessor::process_roots >> and convert G1's evacuation code to use G1RootProcessor. >> 2. Convert the rest of G1 (verification and G1MarkSweep) to use >> G1RootProcessor. Split G1RootProcessor::process_roots in order to >> allow for the different needs of different callers. >> 3. Move SharedHeap::process_roots to GenCollectedHeap since it's now >> the only caller of the code. Get rid of the ScanOption operator| since >> we never or them any longer. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8075210 >> >> Webrevs: >> http://cr.openjdk.java.net/~mgerdin/8075210/phase-1/webrev >> http://cr.openjdk.java.net/~mgerdin/8075210/phase-2/webrev >> http://cr.openjdk.java.net/~mgerdin/8075210/phase-3/webrev >> >> Full webrev: >> http://cr.openjdk.java.net/~mgerdin/8075210/full/webrev >> >> Testing: >> JPRT >> >> /Mikael > From bengt.rutisson at oracle.com Mon Mar 16 15:31:17 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 16 Mar 2015 16:31:17 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <5506F523.9090609@oracle.com> References: <5506DC92.7090609@oracle.com> <5506EEFB.5050504@oracle.com> <5506F523.9090609@oracle.com> Message-ID: <5506F745.1050008@oracle.com> On 2015-03-16 16:22, Mikael Gerdin wrote: > Hi Bengt, > > On 2015-03-16 15:55, Bengt Rutisson wrote: >> >> Hi Mikael, >> >> Nice cleanup! Thanks for splitting the webrev up into several parts. >> Made it much easier to review. >> >> Looks good to me. >> >> One minor thing is that the comment at the top of sharedHeap.hpp uses >> G1CollectedHeap::g1_process_roots() as an example for how to use a >> FlexibleWorkGang. Maybe we should update that comment. > > I updated the comment. > >> >> Also, in g1CollectedHeap.cpp, there is this code: >> >> 3111 G1RootProcessor root_processor(this, /* trace_metadata */ >> false); >> >> I'm more used to see the comment after the value then before. I.e: >> >> G1RootProcessor root_processor(this, false /* trace_metadata */); > > Ok, I handn't noticed the distinction. Fixed. > > > The comment updates are in an incremental webrev at: > http://cr.openjdk.java.net/~mgerdin/8075210/comments/webrev/ Thanks for fixing these things! Looks good. Bengt > > /Mikael > >> >> Thanks, >> Bengt >> >> >> On 2015-03-16 14:37, Mikael Gerdin wrote: >>> Hi all! >>> >>> Currently SharedHeap::process_strong_roots is called both by the >>> GenCollectedHeap based collectors (CMS, Serial) and G1. >>> >>> Since G1 needs special cases for several pieces of the root processing >>> SharedHeap needs to allow for that while attempting to maintain some >>> layer of abstraction. This makes the SharedHeap code unnecessarily >>> complex and makes it very difficult to reason about which combination >>> of parameters are valid and possible. >>> >>> As a first step to improve the code I suggest that we copy the root >>> processing code to a separate class for G1 and move the SharedHeap >>> root processing to GenCollectedHeap. For now I think it's worth it to >>> introduce slightly more duplication of the root processing code in >>> order to reduce the complexity of the shared code path. >>> >>> Overall the change is consists of >>> 15 files changed, 597 insertions(+), 551 deletions(-) >>> Where the insertions include two new copies of the GPL license header. >>> >>> An additional goal for this change is to make it easier to get rid of >>> SharedHeap altogether at some future point, there's really no point in >>> having a shared abstract base class between G1 and GenCollectedHeap. >>> >>> If we want to we can also modify G1RootProcessor at some future point >>> to allow it to be used for all root processing, including ParallelGC >>> and JVMTI. For example the generic root processor could be implemented >>> as some kind of class template, where function objects are passed as >>> template parameters to control claiming of tasks and which roots to >>> visit. >>> >>> In order to make it easier to review I've split up the change into 3 >>> phases: >>> 1. Copy SharedHeap::process_roots and >>> G1CollectedHeap::g1_process_roots to G1RootProcessor::process_roots >>> and convert G1's evacuation code to use G1RootProcessor. >>> 2. Convert the rest of G1 (verification and G1MarkSweep) to use >>> G1RootProcessor. Split G1RootProcessor::process_roots in order to >>> allow for the different needs of different callers. >>> 3. Move SharedHeap::process_roots to GenCollectedHeap since it's now >>> the only caller of the code. Get rid of the ScanOption operator| since >>> we never or them any longer. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8075210 >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-1/webrev >>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-2/webrev >>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-3/webrev >>> >>> Full webrev: >>> http://cr.openjdk.java.net/~mgerdin/8075210/full/webrev >>> >>> Testing: >>> JPRT >>> >>> /Mikael >> From stefan.karlsson at oracle.com Mon Mar 16 15:45:09 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 16 Mar 2015 16:45:09 +0100 Subject: 8075242: Remove SpecializationStats Message-ID: <5506FA85.809@oracle.com> Hi, I propose that we remove the SpecializationStats from the oop_oop_iterate infrastructure. This will make it easier for a future conversion of the oop_oop_iterate macros into template functions. Some indications that this feature isn't used that much, is that it doesn't compile when turned on and the code in InstanceMirrorKlass and InstanceClassLoaderKlass both records that the calls are coming from InstanceRefKlass. Also, the non-inlined, virtual do_oop() calls will show up in a profiler, if they have a significant affect on the performance. http://cr.openjdk.java.net/~stefank/8075242 https://bugs.openjdk.java.net/browse/JDK-8075242 Thanks, StefanK From bengt.rutisson at oracle.com Mon Mar 16 15:54:02 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 16 Mar 2015 16:54:02 +0100 Subject: 8075242: Remove SpecializationStats In-Reply-To: <5506FA85.809@oracle.com> References: <5506FA85.809@oracle.com> Message-ID: <5506FC9A.5010906@oracle.com> Hi Stefan, On 2015-03-16 16:45, Stefan Karlsson wrote: > Hi, > > I propose that we remove the SpecializationStats from the > oop_oop_iterate infrastructure. > > This will make it easier for a future conversion of the > oop_oop_iterate macros into template functions. > > Some indications that this feature isn't used that much, is that it > doesn't compile when turned on and the code in InstanceMirrorKlass and > InstanceClassLoaderKlass both records that the calls are coming from > InstanceRefKlass. > > Also, the non-inlined, virtual do_oop() calls will show up in a > profiler, if they have a significant affect on the performance. > > http://cr.openjdk.java.net/~stefank/8075242 > https://bugs.openjdk.java.net/browse/JDK-8075242 Looks good. Thanks, Bengt > > Thanks, > StefanK From stefan.karlsson at oracle.com Mon Mar 16 16:04:41 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 16 Mar 2015 17:04:41 +0100 Subject: RFR: 8075247: Cleanup specialized_oop_closures.hpp Message-ID: <5506FF19.9010903@oracle.com> Hi, Please review this patch to rename and simplify some macros in specialized_oop_closures.hpp and g1_specialized_oop_closures.hpp. The patch contains the following changes: 1) The FURTHER_SPECIALIZED* macros are only used by G1, so they have been renamed into SPECIALIZED_*G1. 2) Removed some unnecessary #ifdefs. The compile will catch the error if we try to redefine the macro. 3) Gather all CMS specific macros inside a new SPECIALIZED_OOP_OOP_ITERATE_CLOSURES_CMS macro. http://cr.openjdk.java.net/~stefank/8075247/webrev.01 https://bugs.openjdk.java.net/browse/JDK-8075247 Thanks, StefanK From stefan.karlsson at oracle.com Mon Mar 16 16:05:02 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 16 Mar 2015 17:05:02 +0100 Subject: 8075242: Remove SpecializationStats In-Reply-To: <5506FC9A.5010906@oracle.com> References: <5506FA85.809@oracle.com> <5506FC9A.5010906@oracle.com> Message-ID: <5506FF2E.1030608@oracle.com> On 2015-03-16 16:54, Bengt Rutisson wrote: > > Hi Stefan, > > On 2015-03-16 16:45, Stefan Karlsson wrote: >> Hi, >> >> I propose that we remove the SpecializationStats from the >> oop_oop_iterate infrastructure. >> >> This will make it easier for a future conversion of the >> oop_oop_iterate macros into template functions. >> >> Some indications that this feature isn't used that much, is that it >> doesn't compile when turned on and the code in InstanceMirrorKlass >> and InstanceClassLoaderKlass both records that the calls are coming >> from InstanceRefKlass. >> >> Also, the non-inlined, virtual do_oop() calls will show up in a >> profiler, if they have a significant affect on the performance. >> >> http://cr.openjdk.java.net/~stefank/8075242 >> https://bugs.openjdk.java.net/browse/JDK-8075242 > > Looks good. Thanks, Bengt. StefanK > > Thanks, > Bengt > >> >> Thanks, >> StefanK > From mikael.gerdin at oracle.com Mon Mar 16 16:09:15 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 16 Mar 2015 17:09:15 +0100 Subject: 8075242: Remove SpecializationStats In-Reply-To: <5506FA85.809@oracle.com> References: <5506FA85.809@oracle.com> Message-ID: <5507002B.8000608@oracle.com> Hi Stefan, On 2015-03-16 16:45, Stefan Karlsson wrote: > Hi, > > I propose that we remove the SpecializationStats from the > oop_oop_iterate infrastructure. > > This will make it easier for a future conversion of the oop_oop_iterate > macros into template functions. > > Some indications that this feature isn't used that much, is that it > doesn't compile when turned on and the code in InstanceMirrorKlass and > InstanceClassLoaderKlass both records that the calls are coming from > InstanceRefKlass. > > Also, the non-inlined, virtual do_oop() calls will show up in a > profiler, if they have a significant affect on the performance. > > http://cr.openjdk.java.net/~stefank/8075242 Good riddance. The change looks good, Reviewed. /Mikael > https://bugs.openjdk.java.net/browse/JDK-8075242 > > Thanks, > StefanK From mikael.gerdin at oracle.com Mon Mar 16 16:11:22 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 16 Mar 2015 17:11:22 +0100 Subject: RFR: 8075247: Cleanup specialized_oop_closures.hpp In-Reply-To: <5506FF19.9010903@oracle.com> References: <5506FF19.9010903@oracle.com> Message-ID: <550700AA.80302@oracle.com> Hi Stefan, On 2015-03-16 17:04, Stefan Karlsson wrote: > Hi, > > Please review this patch to rename and simplify some macros in > specialized_oop_closures.hpp and g1_specialized_oop_closures.hpp. > > The patch contains the following changes: > 1) The FURTHER_SPECIALIZED* macros are only used by G1, so they have > been renamed into SPECIALIZED_*G1. > 2) Removed some unnecessary #ifdefs. The compile will catch the error if > we try to redefine the macro. > 3) Gather all CMS specific macros inside a new > SPECIALIZED_OOP_OOP_ITERATE_CLOSURES_CMS macro. > > http://cr.openjdk.java.net/~stefank/8075247/webrev.01 Looks good, Reviewed. /Mikael > https://bugs.openjdk.java.net/browse/JDK-8075247 > > Thanks, > StefanK From stefan.karlsson at oracle.com Mon Mar 16 16:19:08 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 16 Mar 2015 17:19:08 +0100 Subject: 8075242: Remove SpecializationStats In-Reply-To: <5507002B.8000608@oracle.com> References: <5506FA85.809@oracle.com> <5507002B.8000608@oracle.com> Message-ID: <5507027C.5020109@oracle.com> On 2015-03-16 17:09, Mikael Gerdin wrote: > Hi Stefan, > > On 2015-03-16 16:45, Stefan Karlsson wrote: >> Hi, >> >> I propose that we remove the SpecializationStats from the >> oop_oop_iterate infrastructure. >> >> This will make it easier for a future conversion of the oop_oop_iterate >> macros into template functions. >> >> Some indications that this feature isn't used that much, is that it >> doesn't compile when turned on and the code in InstanceMirrorKlass and >> InstanceClassLoaderKlass both records that the calls are coming from >> InstanceRefKlass. >> >> Also, the non-inlined, virtual do_oop() calls will show up in a >> profiler, if they have a significant affect on the performance. >> >> http://cr.openjdk.java.net/~stefank/8075242 > > Good riddance. > The change looks good, Reviewed. Thanks, Mikael. StefanK > > /Mikael > >> https://bugs.openjdk.java.net/browse/JDK-8075242 >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Mon Mar 16 16:19:25 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 16 Mar 2015 17:19:25 +0100 Subject: RFR: 8075247: Cleanup specialized_oop_closures.hpp In-Reply-To: <550700AA.80302@oracle.com> References: <5506FF19.9010903@oracle.com> <550700AA.80302@oracle.com> Message-ID: <5507028D.60208@oracle.com> On 2015-03-16 17:11, Mikael Gerdin wrote: > Hi Stefan, > > On 2015-03-16 17:04, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to rename and simplify some macros in >> specialized_oop_closures.hpp and g1_specialized_oop_closures.hpp. >> >> The patch contains the following changes: >> 1) The FURTHER_SPECIALIZED* macros are only used by G1, so they have >> been renamed into SPECIALIZED_*G1. >> 2) Removed some unnecessary #ifdefs. The compile will catch the error if >> we try to redefine the macro. >> 3) Gather all CMS specific macros inside a new >> SPECIALIZED_OOP_OOP_ITERATE_CLOSURES_CMS macro. >> >> http://cr.openjdk.java.net/~stefank/8075247/webrev.01 > > Looks good, Reviewed. Thanks, Mikael. StefanK > > /Mikael > >> https://bugs.openjdk.java.net/browse/JDK-8075247 >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Mon Mar 16 16:22:35 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 16 Mar 2015 17:22:35 +0100 Subject: RFR: 8075249: Cleanup forward_to_atomic and ClaimedForwardPtr Message-ID: <5507034B.1020602@oracle.com> Hi, Please remove this patch to remove some coupling between ParNew, G1, and ParCompact. oopDesc::forward_to_atomic is used by ParNew and G1, but it contains a call to ParNew specific code. It's defined in oop.pcgc.inline.hpp, which is a ParCompact specific file. I propose that we fix both issues by moving forward_to_atomic to oop.inline.hpp and move the ParNew specific code out to ParNew. http://cr.openjdk.java.net/~stefank/8075249/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8075249 Thanks, StefanK From kim.barrett at oracle.com Mon Mar 16 17:50:17 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 16 Mar 2015 13:50:17 -0400 Subject: RFR: 8075249: Cleanup forward_to_atomic and ClaimedForwardPtr In-Reply-To: <5507034B.1020602@oracle.com> References: <5507034B.1020602@oracle.com> Message-ID: <8E67A396-7705-4104-B50F-DBBF7DF24B2D@oracle.com> On Mar 16, 2015, at 12:22 PM, Stefan Karlsson wrote: > > Hi, > > Please remove this patch to remove some coupling between ParNew, G1, and ParCompact. > > oopDesc::forward_to_atomic is used by ParNew and G1, but it contains a call to ParNew specific code. > > It's defined in oop.pcgc.inline.hpp, which is a ParCompact specific file. > > I propose that we fix both issues by moving forward_to_atomic to oop.inline.hpp and move the ParNew specific code out to ParNew. > > http://cr.openjdk.java.net/~stefank/8075249/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8075249 Looks good. Need to update copyrights on several files. From eric.caspole at oracle.com Mon Mar 16 18:28:49 2015 From: eric.caspole at oracle.com (Eric Caspole) Date: Mon, 16 Mar 2015 11:28:49 -0700 (PDT) Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap Message-ID: <80566fe9-0494-4eea-af4c-51457faa5e72@default> This isn't something introduced with this changeset but I found the names _n_workers_done_with_threads/mark_worker_done_with_threads() pretty confusing. I see that it means "Threads::oops_do has happened by now", but if you look at it out of context it is hard to tell if "thread" is referring to the java threads being gc-ed or the gc worker threads. May I lobby for a better name for that, maybe mark_worker_processed_java_threads() etc, or at least a comment near the declaration? Thanks, Eric ----- Original Message ----- From: bengt.rutisson at oracle.com To: mikael.gerdin at oracle.com, hotspot-gc-dev at openjdk.java.net Sent: Monday, March 16, 2015 11:36:37 AM GMT -05:00 US/Canada Eastern Subject: Re: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap On 2015-03-16 16:22, Mikael Gerdin wrote: > Hi Bengt, > > On 2015-03-16 15:55, Bengt Rutisson wrote: >> >> Hi Mikael, >> >> Nice cleanup! Thanks for splitting the webrev up into several parts. >> Made it much easier to review. >> >> Looks good to me. >> >> One minor thing is that the comment at the top of sharedHeap.hpp uses >> G1CollectedHeap::g1_process_roots() as an example for how to use a >> FlexibleWorkGang. Maybe we should update that comment. > > I updated the comment. > >> >> Also, in g1CollectedHeap.cpp, there is this code: >> >> 3111 G1RootProcessor root_processor(this, /* trace_metadata */ >> false); >> >> I'm more used to see the comment after the value then before. I.e: >> >> G1RootProcessor root_processor(this, false /* trace_metadata */); > > Ok, I handn't noticed the distinction. Fixed. > > > The comment updates are in an incremental webrev at: > http://cr.openjdk.java.net/~mgerdin/8075210/comments/webrev/ Thanks for fixing these things! Looks good. Bengt > > /Mikael > >> >> Thanks, >> Bengt >> >> >> On 2015-03-16 14:37, Mikael Gerdin wrote: >>> Hi all! >>> >>> Currently SharedHeap::process_strong_roots is called both by the >>> GenCollectedHeap based collectors (CMS, Serial) and G1. >>> >>> Since G1 needs special cases for several pieces of the root processing >>> SharedHeap needs to allow for that while attempting to maintain some >>> layer of abstraction. This makes the SharedHeap code unnecessarily >>> complex and makes it very difficult to reason about which combination >>> of parameters are valid and possible. >>> >>> As a first step to improve the code I suggest that we copy the root >>> processing code to a separate class for G1 and move the SharedHeap >>> root processing to GenCollectedHeap. For now I think it's worth it to >>> introduce slightly more duplication of the root processing code in >>> order to reduce the complexity of the shared code path. >>> >>> Overall the change is consists of >>> 15 files changed, 597 insertions(+), 551 deletions(-) >>> Where the insertions include two new copies of the GPL license header. >>> >>> An additional goal for this change is to make it easier to get rid of >>> SharedHeap altogether at some future point, there's really no point in >>> having a shared abstract base class between G1 and GenCollectedHeap. >>> >>> If we want to we can also modify G1RootProcessor at some future point >>> to allow it to be used for all root processing, including ParallelGC >>> and JVMTI. For example the generic root processor could be implemented >>> as some kind of class template, where function objects are passed as >>> template parameters to control claiming of tasks and which roots to >>> visit. >>> >>> In order to make it easier to review I've split up the change into 3 >>> phases: >>> 1. Copy SharedHeap::process_roots and >>> G1CollectedHeap::g1_process_roots to G1RootProcessor::process_roots >>> and convert G1's evacuation code to use G1RootProcessor. >>> 2. Convert the rest of G1 (verification and G1MarkSweep) to use >>> G1RootProcessor. Split G1RootProcessor::process_roots in order to >>> allow for the different needs of different callers. >>> 3. Move SharedHeap::process_roots to GenCollectedHeap since it's now >>> the only caller of the code. Get rid of the ScanOption operator| since >>> we never or them any longer. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8075210 >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-1/webrev >>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-2/webrev >>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-3/webrev >>> >>> Full webrev: >>> http://cr.openjdk.java.net/~mgerdin/8075210/full/webrev >>> >>> Testing: >>> JPRT >>> >>> /Mikael >> From thomas.schatzl at oracle.com Mon Mar 16 20:45:08 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 16 Mar 2015 21:45:08 +0100 Subject: RFR: 8075247: Cleanup specialized_oop_closures.hpp In-Reply-To: <5506FF19.9010903@oracle.com> References: <5506FF19.9010903@oracle.com> Message-ID: <1426538708.3346.8.camel@oracle.com> Hi, On Mon, 2015-03-16 at 17:04 +0100, Stefan Karlsson wrote: > Hi, > > Please review this patch to rename and simplify some macros in > specialized_oop_closures.hpp and g1_specialized_oop_closures.hpp. > > The patch contains the following changes: > 1) The FURTHER_SPECIALIZED* macros are only used by G1, so they have > been renamed into SPECIALIZED_*G1. > 2) Removed some unnecessary #ifdefs. The compile will catch the error if > we try to redefine the macro. > 3) Gather all CMS specific macros inside a new > SPECIALIZED_OOP_OOP_ITERATE_CLOSURES_CMS macro. > > http://cr.openjdk.java.net/~stefank/8075247/webrev.01 > https://bugs.openjdk.java.net/browse/JDK-8075247 I am not completely sure why in many files touched in this change both cpp and the corresponding hpp files include specialized_oop_closures.hpp. Is there a particular reason to do so? Thanks, Thomas From thomas.schatzl at oracle.com Mon Mar 16 20:48:59 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 16 Mar 2015 21:48:59 +0100 Subject: RFR: 8075249: Cleanup forward_to_atomic and ClaimedForwardPtr In-Reply-To: <5507034B.1020602@oracle.com> References: <5507034B.1020602@oracle.com> Message-ID: <1426538939.3346.9.camel@oracle.com> Hi, On Mon, 2015-03-16 at 17:22 +0100, Stefan Karlsson wrote: > Hi, > > Please remove this patch to remove some coupling between ParNew, G1, > and ParCompact. > > oopDesc::forward_to_atomic is used by ParNew and G1, but it contains a > call to ParNew specific code. > > It's defined in oop.pcgc.inline.hpp, which is a ParCompact specific file. > > I propose that we fix both issues by moving forward_to_atomic to > oop.inline.hpp and move the ParNew specific code out to ParNew. > > http://cr.openjdk.java.net/~stefank/8075249/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8075249 > looks good. Thanks, Thomas From stefan.karlsson at oracle.com Mon Mar 16 21:12:07 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 16 Mar 2015 22:12:07 +0100 Subject: RFR: 8075247: Cleanup specialized_oop_closures.hpp In-Reply-To: <1426538708.3346.8.camel@oracle.com> References: <5506FF19.9010903@oracle.com> <1426538708.3346.8.camel@oracle.com> Message-ID: <55074727.7050202@oracle.com> Hi Thomas, On 2015-03-16 21:45, Thomas Schatzl wrote: > Hi, > > On Mon, 2015-03-16 at 17:04 +0100, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to rename and simplify some macros in >> specialized_oop_closures.hpp and g1_specialized_oop_closures.hpp. >> >> The patch contains the following changes: >> 1) The FURTHER_SPECIALIZED* macros are only used by G1, so they have >> been renamed into SPECIALIZED_*G1. >> 2) Removed some unnecessary #ifdefs. The compile will catch the error if >> we try to redefine the macro. >> 3) Gather all CMS specific macros inside a new >> SPECIALIZED_OOP_OOP_ITERATE_CLOSURES_CMS macro. >> >> http://cr.openjdk.java.net/~stefank/8075247/webrev.01 >> https://bugs.openjdk.java.net/browse/JDK-8075247 > I am not completely sure why in many files touched in this change both > cpp and the corresponding hpp files include > specialized_oop_closures.hpp. Is there a particular reason to do so? Yes. All files should, preferably, explicitly include the files that they rely on. Sometimes, that's not done and the dependency is resolved via the transitive closure of the include files, but relying on that gives us a more fragile include hierarchy where seemingly unrelated changes cause compile errors when includes are changed/removed. One example from this patch: ALL_OOP_OOP_ITERATE_CLOSURES_1 from specialized_oop_closures.hpp is used by both instanceClassLoaderKlass.cpp and instanceClassLoaderKlass.hpp: http://cr.openjdk.java.net/~stefank/8075247/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.cpp.frames.html ALL_OOP_OOP_ITERATE_CLOSURES_1(InstanceClassLoaderKlass_OOP_OOP_ITERATE_DEFN) http://cr.openjdk.java.net/~stefank/8075247/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.hpp.frames.html ALL_OOP_OOP_ITERATE_CLOSURES_1(InstanceClassLoaderKlass_OOP_OOP_ITERATE_DECL) I hope this clarifies why I wanted to add the specialized_oop_closures.hpp includes in all those files. Thanks, StefanK > > Thanks, > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Mon Mar 16 21:13:06 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 16 Mar 2015 22:13:06 +0100 Subject: RFR: 8075249: Cleanup forward_to_atomic and ClaimedForwardPtr In-Reply-To: <8E67A396-7705-4104-B50F-DBBF7DF24B2D@oracle.com> References: <5507034B.1020602@oracle.com> <8E67A396-7705-4104-B50F-DBBF7DF24B2D@oracle.com> Message-ID: <55074762.30208@oracle.com> On 2015-03-16 18:50, Kim Barrett wrote: > On Mar 16, 2015, at 12:22 PM, Stefan Karlsson wrote: >> Hi, >> >> Please remove this patch to remove some coupling between ParNew, G1, and ParCompact. >> >> oopDesc::forward_to_atomic is used by ParNew and G1, but it contains a call to ParNew specific code. >> >> It's defined in oop.pcgc.inline.hpp, which is a ParCompact specific file. >> >> I propose that we fix both issues by moving forward_to_atomic to oop.inline.hpp and move the ParNew specific code out to ParNew. >> >> http://cr.openjdk.java.net/~stefank/8075249/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8075249 > Looks good. Thanks, Kim. > > Need to update copyrights on several files. I'll fix before I push this change. Thanks, StefanK > > From stefan.karlsson at oracle.com Mon Mar 16 21:25:42 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 16 Mar 2015 22:25:42 +0100 Subject: RFR: 8075249: Cleanup forward_to_atomic and ClaimedForwardPtr In-Reply-To: <1426538939.3346.9.camel@oracle.com> References: <5507034B.1020602@oracle.com> <1426538939.3346.9.camel@oracle.com> Message-ID: <55074A56.8000700@oracle.com> On 2015-03-16 21:48, Thomas Schatzl wrote: > Hi, > > > On Mon, 2015-03-16 at 17:22 +0100, Stefan Karlsson wrote: >> Hi, >> >> Please remove this patch to remove some coupling between ParNew, G1, >> and ParCompact. >> >> oopDesc::forward_to_atomic is used by ParNew and G1, but it contains a >> call to ParNew specific code. >> >> It's defined in oop.pcgc.inline.hpp, which is a ParCompact specific file. >> >> I propose that we fix both issues by moving forward_to_atomic to >> oop.inline.hpp and move the ParNew specific code out to ParNew. >> >> http://cr.openjdk.java.net/~stefank/8075249/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8075249 >> > looks good. Thanks, Thomas. StefanK > > Thanks, > Thomas > From eric.caspole at oracle.com Mon Mar 16 22:06:19 2015 From: eric.caspole at oracle.com (Eric Caspole) Date: Mon, 16 Mar 2015 15:06:19 -0700 (PDT) Subject: RFR: JDK-8060017: Report heap sizing time Message-ID: Hi, Please review this fix for showing the details of heap expansion time in the PrintGCDetails. https://bugs.openjdk.java.net/browse/JDK-8060017 http://cr.openjdk.java.net/~ecaspole/JDK-8060017/02/webrev/ The time to expand the heap is shown in the "Other" section at the end of each GC cycle info. I tested this with a smallish app with a high allocation rate which does a lot of heap expands depending on the command line options used. Also, passes JPRT. The output shows up and graphs correctly in the gc log app. Thanks, Eric From mikael.gerdin at oracle.com Tue Mar 17 08:02:27 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 17 Mar 2015 09:02:27 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <80566fe9-0494-4eea-af4c-51457faa5e72@default> References: <80566fe9-0494-4eea-af4c-51457faa5e72@default> Message-ID: <5507DF93.3010909@oracle.com> Hi Eric, On 2015-03-16 19:28, Eric Caspole wrote: > This isn't something introduced with this changeset but I found the names _n_workers_done_with_threads/mark_worker_done_with_threads() pretty confusing. I see that it means "Threads::oops_do has happened by now", but if you look at it out of context it is hard to tell if "thread" is referring to the java threads being gc-ed or the gc worker threads. > > May I lobby for a better name for that, maybe mark_worker_processed_java_threads() etc, or at least a comment near the declaration? That's an excellent suggestion. I'll look into it. /Mikael > Thanks, > Eric > > ----- Original Message ----- > From: bengt.rutisson at oracle.com > To: mikael.gerdin at oracle.com, hotspot-gc-dev at openjdk.java.net > Sent: Monday, March 16, 2015 11:36:37 AM GMT -05:00 US/Canada Eastern > Subject: Re: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap > > > On 2015-03-16 16:22, Mikael Gerdin wrote: >> Hi Bengt, >> >> On 2015-03-16 15:55, Bengt Rutisson wrote: >>> >>> Hi Mikael, >>> >>> Nice cleanup! Thanks for splitting the webrev up into several parts. >>> Made it much easier to review. >>> >>> Looks good to me. >>> >>> One minor thing is that the comment at the top of sharedHeap.hpp uses >>> G1CollectedHeap::g1_process_roots() as an example for how to use a >>> FlexibleWorkGang. Maybe we should update that comment. >> >> I updated the comment. >> >>> >>> Also, in g1CollectedHeap.cpp, there is this code: >>> >>> 3111 G1RootProcessor root_processor(this, /* trace_metadata */ >>> false); >>> >>> I'm more used to see the comment after the value then before. I.e: >>> >>> G1RootProcessor root_processor(this, false /* trace_metadata */); >> >> Ok, I handn't noticed the distinction. Fixed. >> >> >> The comment updates are in an incremental webrev at: >> http://cr.openjdk.java.net/~mgerdin/8075210/comments/webrev/ > > Thanks for fixing these things! > > Looks good. > > Bengt > >> >> /Mikael >> >>> >>> Thanks, >>> Bengt >>> >>> >>> On 2015-03-16 14:37, Mikael Gerdin wrote: >>>> Hi all! >>>> >>>> Currently SharedHeap::process_strong_roots is called both by the >>>> GenCollectedHeap based collectors (CMS, Serial) and G1. >>>> >>>> Since G1 needs special cases for several pieces of the root processing >>>> SharedHeap needs to allow for that while attempting to maintain some >>>> layer of abstraction. This makes the SharedHeap code unnecessarily >>>> complex and makes it very difficult to reason about which combination >>>> of parameters are valid and possible. >>>> >>>> As a first step to improve the code I suggest that we copy the root >>>> processing code to a separate class for G1 and move the SharedHeap >>>> root processing to GenCollectedHeap. For now I think it's worth it to >>>> introduce slightly more duplication of the root processing code in >>>> order to reduce the complexity of the shared code path. >>>> >>>> Overall the change is consists of >>>> 15 files changed, 597 insertions(+), 551 deletions(-) >>>> Where the insertions include two new copies of the GPL license header. >>>> >>>> An additional goal for this change is to make it easier to get rid of >>>> SharedHeap altogether at some future point, there's really no point in >>>> having a shared abstract base class between G1 and GenCollectedHeap. >>>> >>>> If we want to we can also modify G1RootProcessor at some future point >>>> to allow it to be used for all root processing, including ParallelGC >>>> and JVMTI. For example the generic root processor could be implemented >>>> as some kind of class template, where function objects are passed as >>>> template parameters to control claiming of tasks and which roots to >>>> visit. >>>> >>>> In order to make it easier to review I've split up the change into 3 >>>> phases: >>>> 1. Copy SharedHeap::process_roots and >>>> G1CollectedHeap::g1_process_roots to G1RootProcessor::process_roots >>>> and convert G1's evacuation code to use G1RootProcessor. >>>> 2. Convert the rest of G1 (verification and G1MarkSweep) to use >>>> G1RootProcessor. Split G1RootProcessor::process_roots in order to >>>> allow for the different needs of different callers. >>>> 3. Move SharedHeap::process_roots to GenCollectedHeap since it's now >>>> the only caller of the code. Get rid of the ScanOption operator| since >>>> we never or them any longer. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8075210 >>>> >>>> Webrevs: >>>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-1/webrev >>>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-2/webrev >>>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-3/webrev >>>> >>>> Full webrev: >>>> http://cr.openjdk.java.net/~mgerdin/8075210/full/webrev >>>> >>>> Testing: >>>> JPRT >>>> >>>> /Mikael >>> > From bengt.rutisson at oracle.com Tue Mar 17 13:03:31 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 17 Mar 2015 14:03:31 +0100 Subject: RFR: 8075247: Cleanup specialized_oop_closures.hpp In-Reply-To: <5506FF19.9010903@oracle.com> References: <5506FF19.9010903@oracle.com> Message-ID: <55082623.3080909@oracle.com> Hi Stefan, On 2015-03-16 17:04, Stefan Karlsson wrote: > Hi, > > Please review this patch to rename and simplify some macros in > specialized_oop_closures.hpp and g1_specialized_oop_closures.hpp. > > The patch contains the following changes: > 1) The FURTHER_SPECIALIZED* macros are only used by G1, so they have > been renamed into SPECIALIZED_*G1. > 2) Removed some unnecessary #ifdefs. The compile will catch the error > if we try to redefine the macro. > 3) Gather all CMS specific macros inside a new > SPECIALIZED_OOP_OOP_ITERATE_CLOSURES_CMS macro. > > http://cr.openjdk.java.net/~stefank/8075247/webrev.01 > https://bugs.openjdk.java.net/browse/JDK-8075247 Looks good. Thanks, Bengt > > Thanks, > StefanK From stefan.karlsson at oracle.com Tue Mar 17 13:16:38 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 17 Mar 2015 14:16:38 +0100 Subject: RFR: 8075247: Cleanup specialized_oop_closures.hpp In-Reply-To: <55082623.3080909@oracle.com> References: <5506FF19.9010903@oracle.com> <55082623.3080909@oracle.com> Message-ID: <55082936.9060208@oracle.com> On 2015-03-17 14:03, Bengt Rutisson wrote: > > Hi Stefan, > > On 2015-03-16 17:04, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to rename and simplify some macros in >> specialized_oop_closures.hpp and g1_specialized_oop_closures.hpp. >> >> The patch contains the following changes: >> 1) The FURTHER_SPECIALIZED* macros are only used by G1, so they have >> been renamed into SPECIALIZED_*G1. >> 2) Removed some unnecessary #ifdefs. The compile will catch the error >> if we try to redefine the macro. >> 3) Gather all CMS specific macros inside a new >> SPECIALIZED_OOP_OOP_ITERATE_CLOSURES_CMS macro. >> >> http://cr.openjdk.java.net/~stefank/8075247/webrev.01 >> https://bugs.openjdk.java.net/browse/JDK-8075247 > > Looks good. Thanks, Bengt. StefanK > > Thanks, > Bengt > >> >> Thanks, >> StefanK > From thomas.schatzl at oracle.com Tue Mar 17 13:20:31 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 17 Mar 2015 14:20:31 +0100 Subject: RFR: 8075247: Cleanup specialized_oop_closures.hpp In-Reply-To: <55074727.7050202@oracle.com> References: <5506FF19.9010903@oracle.com> <1426538708.3346.8.camel@oracle.com> <55074727.7050202@oracle.com> Message-ID: <1426598431.3090.32.camel@oracle.com> Hi, On Mon, 2015-03-16 at 22:12 +0100, Stefan Karlsson wrote: > Hi Thomas, > > On 2015-03-16 21:45, Thomas Schatzl wrote: > > > Hi, > > > > On Mon, 2015-03-16 at 17:04 +0100, Stefan Karlsson wrote: > > > Hi, > > > > > > Please review this patch to rename and simplify some macros in > > > specialized_oop_closures.hpp and g1_specialized_oop_closures.hpp. > > > > > > The patch contains the following changes: > > > 1) The FURTHER_SPECIALIZED* macros are only used by G1, so they have > > > been renamed into SPECIALIZED_*G1. > > > 2) Removed some unnecessary #ifdefs. The compile will catch the error if > > > we try to redefine the macro. > > > 3) Gather all CMS specific macros inside a new > > > SPECIALIZED_OOP_OOP_ITERATE_CLOSURES_CMS macro. > > > > > > http://cr.openjdk.java.net/~stefank/8075247/webrev.01 > > > https://bugs.openjdk.java.net/browse/JDK-8075247 > > I am not completely sure why in many files touched in this change both > > cpp and the corresponding hpp files include > > specialized_oop_closures.hpp. Is there a particular reason to do so? > > Yes. All files should, preferably, explicitly include the files that > they rely on. Sometimes, that's not done and the dependency is > resolved via the transitive closure of the include files, but relying > on that gives us a more fragile include hierarchy where seemingly > unrelated changes cause compile errors when includes are > changed/removed. Okay - I was not aware that this should also be the case for includes by the header file corresponding to the given cpp file. Btw, do you know of a tool to find out missing includes (or just find ones only included transitively)? Looks good. Thanks, Thomas From stefan.karlsson at oracle.com Tue Mar 17 13:25:12 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 17 Mar 2015 14:25:12 +0100 Subject: RFR: 8075247: Cleanup specialized_oop_closures.hpp In-Reply-To: <1426598431.3090.32.camel@oracle.com> References: <5506FF19.9010903@oracle.com> <1426538708.3346.8.camel@oracle.com> <55074727.7050202@oracle.com> <1426598431.3090.32.camel@oracle.com> Message-ID: <55082B38.3020307@oracle.com> Hi, On 2015-03-17 14:20, Thomas Schatzl wrote: > Hi, > > On Mon, 2015-03-16 at 22:12 +0100, Stefan Karlsson wrote: >> Hi Thomas, >> >> On 2015-03-16 21:45, Thomas Schatzl wrote: >> >>> Hi, >>> >>> On Mon, 2015-03-16 at 17:04 +0100, Stefan Karlsson wrote: >>>> Hi, >>>> >>>> Please review this patch to rename and simplify some macros in >>>> specialized_oop_closures.hpp and g1_specialized_oop_closures.hpp. >>>> >>>> The patch contains the following changes: >>>> 1) The FURTHER_SPECIALIZED* macros are only used by G1, so they have >>>> been renamed into SPECIALIZED_*G1. >>>> 2) Removed some unnecessary #ifdefs. The compile will catch the error if >>>> we try to redefine the macro. >>>> 3) Gather all CMS specific macros inside a new >>>> SPECIALIZED_OOP_OOP_ITERATE_CLOSURES_CMS macro. >>>> >>>> http://cr.openjdk.java.net/~stefank/8075247/webrev.01 >>>> https://bugs.openjdk.java.net/browse/JDK-8075247 >>> I am not completely sure why in many files touched in this change both >>> cpp and the corresponding hpp files include >>> specialized_oop_closures.hpp. Is there a particular reason to do so? >> Yes. All files should, preferably, explicitly include the files that >> they rely on. Sometimes, that's not done and the dependency is >> resolved via the transitive closure of the include files, but relying >> on that gives us a more fragile include hierarchy where seemingly >> unrelated changes cause compile errors when includes are >> changed/removed. > Okay - I was not aware that this should also be the case for includes by > the header file corresponding to the given cpp file. > > Btw, do you know of a tool to find out missing includes (or just find > ones only included transitively)? No, I don't know of any tool that will do it for you automatically. I sometimes use 'g++ -H' to look at the included hierarchy: $ man g++ ... -H Print the name of each header file used, in addition to other normal activities. Each name is indented to show how deep in the #include stack it is. Precompiled header files are also printed, even if they are found to be invalid; an invalid precompiled header file is printed with ...x and a valid one with ...! . ... The eclipse Include Browser can also be used too look at the includes. > > Looks good. Thanks, StefanK > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Tue Mar 17 14:26:06 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 17 Mar 2015 15:26:06 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <5506DC92.7090609@oracle.com> References: <5506DC92.7090609@oracle.com> Message-ID: <1426602366.3090.60.camel@oracle.com> Hi Mikael, some comments for the full change: On Mon, 2015-03-16 at 14:37 +0100, Mikael Gerdin wrote: > Hi all! > > Currently SharedHeap::process_strong_roots is called both by the > GenCollectedHeap based collectors (CMS, Serial) and G1. [...] > Bug: > https://bugs.openjdk.java.net/browse/JDK-8075210 > > Webrevs: > http://cr.openjdk.java.net/~mgerdin/8075210/phase-1/webrev > http://cr.openjdk.java.net/~mgerdin/8075210/phase-2/webrev > http://cr.openjdk.java.net/~mgerdin/8075210/phase-3/webrev > > Full webrev: > http://cr.openjdk.java.net/~mgerdin/8075210/full/webrev - I think allocation.inline.hpp does not seem to be required in the include list for the hpp file (but in the cpp file). - class forward declarations for G1CollectorPolicy, G1RemSet, ReferenceProcessor are not required. Ones (or includes) for the various closures are missing. - is it possible to add at least a few lines of documentation to the public methods of G1RootProcessor? To me it is not evidently clear what e.g. the difference between evacuate_roots, and process_strong_roots is. Also, G1CollectedHeap::g1_process_roots() did have at least some documentation. Or what G1RootProcessor actually is supposed to do. Please also mention that the G1RootProcessor is a scoped object that does some serious work in the constructor/destructor. I almost suggested (again :)) to just remove the StrongRootScope :) - g1RootProcessor.?pp copyrights are from 2014. - in g1collectedheap.cpp:lines 4489-4492 the parameters for the call to evacuate_roots() are not aligned properly. - the comment in line 5501-5505 in g1CollectedHeap.cpp is outdated, mentioning the StrongRootsScope object that moved to the g1rootprocessor. - there should imo be a warning in G1CollectedHeap::set_n_termination() why this is an empty method. - I think Bengt already mentioned this, but g1CollectedHeap.cpp:98 still mentions g1_process_roots(). The entire paragraph seems outdated now. I do not think anything noted there is true any more. - comment in g1CollectedHeap.hpp:1007+ is outdated. - please add braces for every if-statement in GenCollectedHeap::process_roots(). In the G1RootProcessor this has been done. - I think the instantiation of G1RootsProcessor in G1CollectedHeap::verify() should be scoped, i.e. it and the call to process_all_roots() enclosed with braces. I will need another round because I am somewhat confused about the changes regarding setting the number of threads in the various locations. Thanks, Thomas From erik.helin at oracle.com Tue Mar 17 15:56:56 2015 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 17 Mar 2015 16:56:56 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <5506DC92.7090609@oracle.com> References: <5506DC92.7090609@oracle.com> Message-ID: <20150317155656.GA20878@ehelin.jrpg.bea.com> On 2015-03-16, Mikael Gerdin wrote: > Full webrev: > http://cr.openjdk.java.net/~mgerdin/8075210/full/webrev In general, the patch looks good, thanks for refactoring this! I agree with Thomas' comments and also have one of my own: it looks like G1RootProcessor::_trace_metadata only is used by G1RootProcessor::evacuate_roots, could trace_metadata become an parameter to G1RootProcessor::evacuate_roots instead of being a paramater to the constructor? Also, since set_n_termination has been removed from SharedHeap, can't we just remove it from G1CollectedHeap as well? Thanks, Erik From mikael.gerdin at oracle.com Tue Mar 17 15:59:42 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 17 Mar 2015 16:59:42 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <5507DF93.3010909@oracle.com> References: <80566fe9-0494-4eea-af4c-51457faa5e72@default> <5507DF93.3010909@oracle.com> Message-ID: <55084F6E.6070606@oracle.com> Hi Eric, On 2015-03-17 09:02, Mikael Gerdin wrote: > Hi Eric, > > On 2015-03-16 19:28, Eric Caspole wrote: >> This isn't something introduced with this changeset but I found the >> names _n_workers_done_with_threads/mark_worker_done_with_threads() >> pretty confusing. I see that it means "Threads::oops_do has happened >> by now", but if you look at it out of context it is hard to tell if >> "thread" is referring to the java threads being gc-ed or the gc worker >> threads. >> >> May I lobby for a better name for that, maybe >> mark_worker_processed_java_threads() etc, or at least a comment near >> the declaration? > > That's an excellent suggestion. I'll look into it. Incremental webrev incorporating the renaming: http://cr.openjdk.java.net/~mgerdin/8075210/done_with_threads/webrev/ See my reply to Thomas' review for an updated full webrev. /Mikael > > /Mikael > >> Thanks, >> Eric >> >> ----- Original Message ----- >> From: bengt.rutisson at oracle.com >> To: mikael.gerdin at oracle.com, hotspot-gc-dev at openjdk.java.net >> Sent: Monday, March 16, 2015 11:36:37 AM GMT -05:00 US/Canada Eastern >> Subject: Re: RFR (M) 8075210: Refactor strong root processing in order >> to allow G1 to evolve separately from GenCollectedHeap >> >> >> On 2015-03-16 16:22, Mikael Gerdin wrote: >>> Hi Bengt, >>> >>> On 2015-03-16 15:55, Bengt Rutisson wrote: >>>> >>>> Hi Mikael, >>>> >>>> Nice cleanup! Thanks for splitting the webrev up into several parts. >>>> Made it much easier to review. >>>> >>>> Looks good to me. >>>> >>>> One minor thing is that the comment at the top of sharedHeap.hpp uses >>>> G1CollectedHeap::g1_process_roots() as an example for how to use a >>>> FlexibleWorkGang. Maybe we should update that comment. >>> >>> I updated the comment. >>> >>>> >>>> Also, in g1CollectedHeap.cpp, there is this code: >>>> >>>> 3111 G1RootProcessor root_processor(this, /* trace_metadata */ >>>> false); >>>> >>>> I'm more used to see the comment after the value then before. I.e: >>>> >>>> G1RootProcessor root_processor(this, false /* trace_metadata */); >>> >>> Ok, I handn't noticed the distinction. Fixed. >>> >>> >>> The comment updates are in an incremental webrev at: >>> http://cr.openjdk.java.net/~mgerdin/8075210/comments/webrev/ >> >> Thanks for fixing these things! >> >> Looks good. >> >> Bengt >> >>> >>> /Mikael >>> >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> On 2015-03-16 14:37, Mikael Gerdin wrote: >>>>> Hi all! >>>>> >>>>> Currently SharedHeap::process_strong_roots is called both by the >>>>> GenCollectedHeap based collectors (CMS, Serial) and G1. >>>>> >>>>> Since G1 needs special cases for several pieces of the root processing >>>>> SharedHeap needs to allow for that while attempting to maintain some >>>>> layer of abstraction. This makes the SharedHeap code unnecessarily >>>>> complex and makes it very difficult to reason about which combination >>>>> of parameters are valid and possible. >>>>> >>>>> As a first step to improve the code I suggest that we copy the root >>>>> processing code to a separate class for G1 and move the SharedHeap >>>>> root processing to GenCollectedHeap. For now I think it's worth it to >>>>> introduce slightly more duplication of the root processing code in >>>>> order to reduce the complexity of the shared code path. >>>>> >>>>> Overall the change is consists of >>>>> 15 files changed, 597 insertions(+), 551 deletions(-) >>>>> Where the insertions include two new copies of the GPL license header. >>>>> >>>>> An additional goal for this change is to make it easier to get rid of >>>>> SharedHeap altogether at some future point, there's really no point in >>>>> having a shared abstract base class between G1 and GenCollectedHeap. >>>>> >>>>> If we want to we can also modify G1RootProcessor at some future point >>>>> to allow it to be used for all root processing, including ParallelGC >>>>> and JVMTI. For example the generic root processor could be implemented >>>>> as some kind of class template, where function objects are passed as >>>>> template parameters to control claiming of tasks and which roots to >>>>> visit. >>>>> >>>>> In order to make it easier to review I've split up the change into 3 >>>>> phases: >>>>> 1. Copy SharedHeap::process_roots and >>>>> G1CollectedHeap::g1_process_roots to G1RootProcessor::process_roots >>>>> and convert G1's evacuation code to use G1RootProcessor. >>>>> 2. Convert the rest of G1 (verification and G1MarkSweep) to use >>>>> G1RootProcessor. Split G1RootProcessor::process_roots in order to >>>>> allow for the different needs of different callers. >>>>> 3. Move SharedHeap::process_roots to GenCollectedHeap since it's now >>>>> the only caller of the code. Get rid of the ScanOption operator| since >>>>> we never or them any longer. >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8075210 >>>>> >>>>> Webrevs: >>>>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-1/webrev >>>>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-2/webrev >>>>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-3/webrev >>>>> >>>>> Full webrev: >>>>> http://cr.openjdk.java.net/~mgerdin/8075210/full/webrev >>>>> >>>>> Testing: >>>>> JPRT >>>>> >>>>> /Mikael >>>> >> > From mikael.gerdin at oracle.com Tue Mar 17 16:00:59 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 17 Mar 2015 17:00:59 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <1426602366.3090.60.camel@oracle.com> References: <5506DC92.7090609@oracle.com> <1426602366.3090.60.camel@oracle.com> Message-ID: <55084FBB.5040605@oracle.com> On 2015-03-17 15:26, Thomas Schatzl wrote: > Hi Mikael, > > some comments for the full change: > > On Mon, 2015-03-16 at 14:37 +0100, Mikael Gerdin wrote: >> Hi all! >> >> Currently SharedHeap::process_strong_roots is called both by the >> GenCollectedHeap based collectors (CMS, Serial) and G1. > [...] >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8075210 >> >> Webrevs: >> http://cr.openjdk.java.net/~mgerdin/8075210/phase-1/webrev >> http://cr.openjdk.java.net/~mgerdin/8075210/phase-2/webrev >> http://cr.openjdk.java.net/~mgerdin/8075210/phase-3/webrev >> >> Full webrev: >> http://cr.openjdk.java.net/~mgerdin/8075210/full/webrev > > - I think allocation.inline.hpp does not seem to be required in the > include list for the hpp file (but in the cpp file). Fixed. > > - class forward declarations for G1CollectorPolicy, G1RemSet, > ReferenceProcessor are not required. Ones (or includes) for the various > closures are missing. Fixed. > > - is it possible to add at least a few lines of documentation to the > public methods of G1RootProcessor? To me it is not evidently clear what > e.g. the difference between evacuate_roots, and process_strong_roots is. > Also, G1CollectedHeap::g1_process_roots() did have at least some > documentation. > Or what G1RootProcessor actually is supposed to do. > Please also mention that the G1RootProcessor is a scoped object that > does some serious work in the constructor/destructor. I almost suggested > (again :)) to just remove the StrongRootScope :) I added a few comments in g1RootProcessor.hpp I also want to get rid of StrongRootsScope, but I'm unsure of what to replace it with? > > - g1RootProcessor.?pp copyrights are from 2014. Fixed. > > - in g1collectedheap.cpp:lines 4489-4492 the parameters for the call to > evacuate_roots() are not aligned properly. Fixed (not visible in webrev, see patch file). > > - the comment in line 5501-5505 in g1CollectedHeap.cpp is outdated, > mentioning the StrongRootsScope object that moved to the > g1rootprocessor. Updated the comment. > > - there should imo be a warning in G1CollectedHeap::set_n_termination() > why this is an empty method. I don't think it's needed at all, I removed it. > > - I think Bengt already mentioned this, but g1CollectedHeap.cpp:98 still > mentions g1_process_roots(). The entire paragraph seems outdated now. I > do not think anything noted there is true any more. I removed the entire comment. It seemed weird to keep the part about ParVerifyTask when no other parallel tasks were being described. > > - comment in g1CollectedHeap.hpp:1007+ is outdated. Removed. > > - please add braces for every if-statement in > GenCollectedHeap::process_roots(). In the G1RootProcessor this has been > done. Done. > > - I think the instantiation of G1RootsProcessor in > G1CollectedHeap::verify() should be scoped, i.e. it and the call to > process_all_roots() enclosed with braces. Fixed. > > I will need another round because I am somewhat confused about the > changes regarding setting the number of threads in the various > locations. No problem. Here's an incremental webrev incorporating your suggestions: http://cr.openjdk.java.net/~mgerdin/8075210/thomas-comments/webrev/ It's based on http://cr.openjdk.java.net/~mgerdin/8075210/done_with_threads/webrev/ which incorporates Eric's renaming request. New full webrev at: http://cr.openjdk.java.net/~mgerdin/8075210/full2/webrev/ /Mikael > > Thanks, > Thomas > > From dmitry.fazunenko at oracle.com Tue Mar 17 17:11:24 2015 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Tue, 17 Mar 2015 20:11:24 +0300 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <55084FBB.5040605@oracle.com> References: <5506DC92.7090609@oracle.com> <1426602366.3090.60.camel@oracle.com> <55084FBB.5040605@oracle.com> Message-ID: <5508603C.1010708@oracle.com> Hi Mikael, Sorry for boring question, but how did you test the fix? This change doesn't look like a trivial one, so how can you guarantee that it will not break anything? I know you guys are monsters and you can verify changes just looking at webrev. But what about simple unit tests verifying basic invariants? Thanks, Dima On 17.03.2015 19:00, Mikael Gerdin wrote: > On 2015-03-17 15:26, Thomas Schatzl wrote: >> Hi Mikael, >> >> some comments for the full change: >> >> On Mon, 2015-03-16 at 14:37 +0100, Mikael Gerdin wrote: >>> Hi all! >>> >>> Currently SharedHeap::process_strong_roots is called both by the >>> GenCollectedHeap based collectors (CMS, Serial) and G1. >> [...] >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8075210 >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-1/webrev >>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-2/webrev >>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-3/webrev >>> >>> Full webrev: >>> http://cr.openjdk.java.net/~mgerdin/8075210/full/webrev >> >> - I think allocation.inline.hpp does not seem to be required in the >> include list for the hpp file (but in the cpp file). > > Fixed. > >> >> - class forward declarations for G1CollectorPolicy, G1RemSet, >> ReferenceProcessor are not required. Ones (or includes) for the various >> closures are missing. > > Fixed. > >> >> - is it possible to add at least a few lines of documentation to the >> public methods of G1RootProcessor? To me it is not evidently clear what >> e.g. the difference between evacuate_roots, and process_strong_roots is. >> Also, G1CollectedHeap::g1_process_roots() did have at least some >> documentation. >> Or what G1RootProcessor actually is supposed to do. >> Please also mention that the G1RootProcessor is a scoped object that >> does some serious work in the constructor/destructor. I almost suggested >> (again :)) to just remove the StrongRootScope :) > > I added a few comments in g1RootProcessor.hpp > > I also want to get rid of StrongRootsScope, but I'm unsure of what to > replace it with? > >> >> - g1RootProcessor.?pp copyrights are from 2014. > > Fixed. > >> >> - in g1collectedheap.cpp:lines 4489-4492 the parameters for the call to >> evacuate_roots() are not aligned properly. > > Fixed (not visible in webrev, see patch file). > >> >> - the comment in line 5501-5505 in g1CollectedHeap.cpp is outdated, >> mentioning the StrongRootsScope object that moved to the >> g1rootprocessor. > > Updated the comment. > >> >> - there should imo be a warning in G1CollectedHeap::set_n_termination() >> why this is an empty method. > > I don't think it's needed at all, I removed it. > >> >> - I think Bengt already mentioned this, but g1CollectedHeap.cpp:98 still >> mentions g1_process_roots(). The entire paragraph seems outdated now. I >> do not think anything noted there is true any more. > > I removed the entire comment. It seemed weird to keep the part about > ParVerifyTask when no other parallel tasks were being described. > >> >> - comment in g1CollectedHeap.hpp:1007+ is outdated. > > Removed. > >> >> - please add braces for every if-statement in >> GenCollectedHeap::process_roots(). In the G1RootProcessor this has been >> done. > > Done. > >> >> - I think the instantiation of G1RootsProcessor in >> G1CollectedHeap::verify() should be scoped, i.e. it and the call to >> process_all_roots() enclosed with braces. > > Fixed. > >> >> I will need another round because I am somewhat confused about the >> changes regarding setting the number of threads in the various >> locations. > > No problem. > > Here's an incremental webrev incorporating your suggestions: > http://cr.openjdk.java.net/~mgerdin/8075210/thomas-comments/webrev/ > It's based on > http://cr.openjdk.java.net/~mgerdin/8075210/done_with_threads/webrev/ > which incorporates Eric's renaming request. > > New full webrev at: > http://cr.openjdk.java.net/~mgerdin/8075210/full2/webrev/ > > /Mikael > >> >> Thanks, >> Thomas >> >> > From jon.masamitsu at oracle.com Tue Mar 17 17:33:22 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 17 Mar 2015 10:33:22 -0700 Subject: Request for review (s) : 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads In-Reply-To: <1426013100.3128.12.camel@oracle.com> References: <54FF1B4A.9020609@oracle.com> <1426013100.3128.12.camel@oracle.com> Message-ID: <55086562.9050102@oracle.com> On 03/10/2015 11:45 AM, Thomas Schatzl wrote: > Hi Jon, > > On Tue, 2015-03-10 at 09:26 -0700, Jon Masamitsu wrote: >> 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads >> >> https://bugs.openjdk.java.net/browse/JDK-8017462 >> >> When fewer than the maximum number of threads was being used for >> a parallel section, phase times for the threads that did not execute and >> averages for the phase were misleading. The fix passes the active number of >> GC threads to the G1 phase timers. >> >> http://cr.openjdk.java.net/~jmasa/8017462/webrev.00/ >> >> Tested with gc_test_suite. > - I would somewhat prefer if _active_threads would not be stored in > every WorkerDataArray. This seems a waste of space. G1GCPhaseTimes > already stores it, so it could easily passed to > WorkerDataArray::verify()/print() instead which seems cleaner to me. Having seen Bengt's patch for this, I agree and will abandon my fix. > > This would also avoid the additional parameter in > note_string_dedup_fixup_start(). > > - WorkerDataArray::reset() is PRODUCT_RETURN. That means that in a > product VM, WorkerDataArray::_active_length is seemingly never assigned > to then as far as I can see. > > - is it possible to create a test for G1 that runs with > G1LogLevel=finest and parses and verifies output of one GC phase that > takes at least some time? I.e. that you have active_workers amount of > durations in that line and the sum matches more or less. Let me look into this. Parsing the output is worrisome to me. I'll look to see if I can add assertion check to check the sum. Jon > > - Bengt is currently also changing this code significantly (see the > review for 8074037: Refactor the G1GCPhaseTime logging to make it easier > to add new phases). Somebody will have to do a significant amount of > merging :/ > > Thanks, > Thomas > > From jon.masamitsu at oracle.com Tue Mar 17 17:34:51 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 17 Mar 2015 10:34:51 -0700 Subject: Request for review (s) : 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads In-Reply-To: <55002FF7.30706@oracle.com> References: <54FF1B4A.9020609@oracle.com> <1426013100.3128.12.camel@oracle.com> <55002FF7.30706@oracle.com> Message-ID: <550865BB.9070104@oracle.com> On 03/11/2015 05:07 AM, Bengt Rutisson wrote: > > Hi Jon and Thomas, > > On 2015-03-10 19:45, Thomas Schatzl wrote: >> Hi Jon, >> >> On Tue, 2015-03-10 at 09:26 -0700, Jon Masamitsu wrote: >>> 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads >>> >>> https://bugs.openjdk.java.net/browse/JDK-8017462 >>> >>> When fewer than the maximum number of threads was being used for >>> a parallel section, phase times for the threads that did not execute >>> and >>> averages for the phase were misleading. The fix passes the active >>> number of >>> GC threads to the G1 phase timers. >>> >>> http://cr.openjdk.java.net/~jmasa/8017462/webrev.00/ >>> >>> Tested with gc_test_suite. >> - I would somewhat prefer if _active_threads would not be stored in >> every WorkerDataArray. This seems a waste of space. G1GCPhaseTimes >> already stores it, so it could easily passed to >> WorkerDataArray::verify()/print() instead which seems cleaner to me. >> >> This would also avoid the additional parameter in >> note_string_dedup_fixup_start(). >> >> - WorkerDataArray::reset() is PRODUCT_RETURN. That means that in a >> product VM, WorkerDataArray::_active_length is seemingly never assigned >> to then as far as I can see. >> >> - is it possible to create a test for G1 that runs with >> G1LogLevel=finest and parses and verifies output of one GC phase that >> takes at least some time? I.e. that you have active_workers amount of >> durations in that line and the sum matches more or less. >> >> - Bengt is currently also changing this code significantly (see the >> review for 8074037: Refactor the G1GCPhaseTime logging to make it easier >> to add new phases). Somebody will have to do a significant amount of >> merging :/ > > Right. This will conflict with my changes. > > On the other hand I agree with Thomas that it doesn't really look good > to store the active thread value in the WorkerDataArray. So, if we > skip that and base the changes on top of my patch I think you can do a > much less intrusive change. > > Here's a webrev that also passes the test that you wrote > (TestDynamicNumberOfGCThreads.java): > > http://cr.openjdk.java.net/~brutisso/8017462/webrev.01/ I'll adopt your patch. Thanks. > > It reuses the active thread value from the G1GCPhaseTimes instance and > thus all changes can be contained within one file. > > Jon, what do you think about this solution instead? > > If we go with this, is it ok that I push my changes first? I see you wisely pushed your change already. Jon > > Thanks, > Bengt > >> >> Thanks, >> Thomas >> >> > From eric.caspole at oracle.com Tue Mar 17 18:34:57 2015 From: eric.caspole at oracle.com (Eric Caspole) Date: Tue, 17 Mar 2015 11:34:57 -0700 (PDT) Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap Message-ID: <35e26db5-b99c-4a33-a2d9-0f760998afd0@default> Big improvement, thanks! Eric ----- Original Message ----- From: mikael.gerdin at oracle.com To: eric.caspole at oracle.com, bengt.rutisson at oracle.com Cc: hotspot-gc-dev at openjdk.java.net Sent: Tuesday, March 17, 2015 11:59:54 AM GMT -05:00 US/Canada Eastern Subject: Re: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap Hi Eric, On 2015-03-17 09:02, Mikael Gerdin wrote: > Hi Eric, > > On 2015-03-16 19:28, Eric Caspole wrote: >> This isn't something introduced with this changeset but I found the >> names _n_workers_done_with_threads/mark_worker_done_with_threads() >> pretty confusing. I see that it means "Threads::oops_do has happened >> by now", but if you look at it out of context it is hard to tell if >> "thread" is referring to the java threads being gc-ed or the gc worker >> threads. >> >> May I lobby for a better name for that, maybe >> mark_worker_processed_java_threads() etc, or at least a comment near >> the declaration? > > That's an excellent suggestion. I'll look into it. Incremental webrev incorporating the renaming: http://cr.openjdk.java.net/~mgerdin/8075210/done_with_threads/webrev/ See my reply to Thomas' review for an updated full webrev. /Mikael > > /Mikael > >> Thanks, >> Eric >> >> ----- Original Message ----- >> From: bengt.rutisson at oracle.com >> To: mikael.gerdin at oracle.com, hotspot-gc-dev at openjdk.java.net >> Sent: Monday, March 16, 2015 11:36:37 AM GMT -05:00 US/Canada Eastern >> Subject: Re: RFR (M) 8075210: Refactor strong root processing in order >> to allow G1 to evolve separately from GenCollectedHeap >> >> >> On 2015-03-16 16:22, Mikael Gerdin wrote: >>> Hi Bengt, >>> >>> On 2015-03-16 15:55, Bengt Rutisson wrote: >>>> >>>> Hi Mikael, >>>> >>>> Nice cleanup! Thanks for splitting the webrev up into several parts. >>>> Made it much easier to review. >>>> >>>> Looks good to me. >>>> >>>> One minor thing is that the comment at the top of sharedHeap.hpp uses >>>> G1CollectedHeap::g1_process_roots() as an example for how to use a >>>> FlexibleWorkGang. Maybe we should update that comment. >>> >>> I updated the comment. >>> >>>> >>>> Also, in g1CollectedHeap.cpp, there is this code: >>>> >>>> 3111 G1RootProcessor root_processor(this, /* trace_metadata */ >>>> false); >>>> >>>> I'm more used to see the comment after the value then before. I.e: >>>> >>>> G1RootProcessor root_processor(this, false /* trace_metadata */); >>> >>> Ok, I handn't noticed the distinction. Fixed. >>> >>> >>> The comment updates are in an incremental webrev at: >>> http://cr.openjdk.java.net/~mgerdin/8075210/comments/webrev/ >> >> Thanks for fixing these things! >> >> Looks good. >> >> Bengt >> >>> >>> /Mikael >>> >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> On 2015-03-16 14:37, Mikael Gerdin wrote: >>>>> Hi all! >>>>> >>>>> Currently SharedHeap::process_strong_roots is called both by the >>>>> GenCollectedHeap based collectors (CMS, Serial) and G1. >>>>> >>>>> Since G1 needs special cases for several pieces of the root processing >>>>> SharedHeap needs to allow for that while attempting to maintain some >>>>> layer of abstraction. This makes the SharedHeap code unnecessarily >>>>> complex and makes it very difficult to reason about which combination >>>>> of parameters are valid and possible. >>>>> >>>>> As a first step to improve the code I suggest that we copy the root >>>>> processing code to a separate class for G1 and move the SharedHeap >>>>> root processing to GenCollectedHeap. For now I think it's worth it to >>>>> introduce slightly more duplication of the root processing code in >>>>> order to reduce the complexity of the shared code path. >>>>> >>>>> Overall the change is consists of >>>>> 15 files changed, 597 insertions(+), 551 deletions(-) >>>>> Where the insertions include two new copies of the GPL license header. >>>>> >>>>> An additional goal for this change is to make it easier to get rid of >>>>> SharedHeap altogether at some future point, there's really no point in >>>>> having a shared abstract base class between G1 and GenCollectedHeap. >>>>> >>>>> If we want to we can also modify G1RootProcessor at some future point >>>>> to allow it to be used for all root processing, including ParallelGC >>>>> and JVMTI. For example the generic root processor could be implemented >>>>> as some kind of class template, where function objects are passed as >>>>> template parameters to control claiming of tasks and which roots to >>>>> visit. >>>>> >>>>> In order to make it easier to review I've split up the change into 3 >>>>> phases: >>>>> 1. Copy SharedHeap::process_roots and >>>>> G1CollectedHeap::g1_process_roots to G1RootProcessor::process_roots >>>>> and convert G1's evacuation code to use G1RootProcessor. >>>>> 2. Convert the rest of G1 (verification and G1MarkSweep) to use >>>>> G1RootProcessor. Split G1RootProcessor::process_roots in order to >>>>> allow for the different needs of different callers. >>>>> 3. Move SharedHeap::process_roots to GenCollectedHeap since it's now >>>>> the only caller of the code. Get rid of the ScanOption operator| since >>>>> we never or them any longer. >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8075210 >>>>> >>>>> Webrevs: >>>>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-1/webrev >>>>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-2/webrev >>>>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-3/webrev >>>>> >>>>> Full webrev: >>>>> http://cr.openjdk.java.net/~mgerdin/8075210/full/webrev >>>>> >>>>> Testing: >>>>> JPRT >>>>> >>>>> /Mikael >>>> >> > From kim.barrett at oracle.com Tue Mar 17 21:30:03 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 17 Mar 2015 17:30:03 -0400 Subject: RFR: JDK-8060017: Report heap sizing time In-Reply-To: References: Message-ID: <1B46B485-4F7C-47BC-9B7E-51AE29FD7738@oracle.com> On Mar 16, 2015, at 6:06 PM, Eric Caspole wrote: > > Hi, > Please review this fix for showing the details of heap expansion time in the PrintGCDetails. > > https://bugs.openjdk.java.net/browse/JDK-8060017 > http://cr.openjdk.java.net/~ecaspole/JDK-8060017/02/webrev/ > > The time to expand the heap is shown in the "Other" section at the end of each GC cycle info. > > I tested this with a smallish app with a high allocation rate which does a lot of heap expands depending on the command line options used. Also, passes JPRT. The output shows up and graphs correctly in the gc log app. > Thanks, > Eric Looks good. A few copyrights need to be updated. From kim.barrett at oracle.com Tue Mar 17 21:23:28 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 17 Mar 2015 17:23:28 -0400 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> <55014F32.3030400@oracle.com> <5501683D.2000905@oracle.com> <58A2D320-A2E7-4304-90CA-CC1C768DA52C@oracle.com> <5502A38F.7000000@oracle.com> Message-ID: On Mar 13, 2015, at 1:51 PM, Kim Barrett wrote: > > On Mar 13, 2015, at 4:45 AM, Bengt Rutisson wrote: >> >> Another alternative would be to let initial marking note all humongous objects that were live after initial mark. Then we can just make sure that early reclaim does not reclaim any of those humongous objects while marking is active. That should be a pretty simple fix that can be backported if necessary. > > Bengt and I talked about this some more; I?m going to have a look at the code for this, as it seems likely better. Here?s a new webrev, following Bengt?s suggestion. CR: https://bugs.openjdk.java.net/browse/JDK-8069367 Webrev: http://cr.openjdk.java.net/~kbarrett/8069367/webrev.02/ No incremental webrev, since the approach (and so the changes) are entirely different. As a reminder, the scenario we are dealing with is (1) A humongous object H is marked and added to the mark stack. (2) An evacuation pause determines H is no longer live, and reclaims it. This occurs before concurrent marking has gotten around to processing the mark stack entry for H. (3) Concurrent marking processes the mark stack entry for H, attempting to scan the now dead object. The new approach is to create a set of candidates at the start of the collection pause, remove candidates as they are reached from roots or from the young generation, and release any remaining candidates with empty remsets. (This is similar to before.) The difference is in how we create the set of candidates. Previously, all humongous objects satisfying certain type restrictions and remset size limits were treated as candidates. Now, when concurrent marking is in progress, we also exclude from the initial candidate set any objects that were live at the start of marking, determined by comparing the object against its region?s TAMS value. Such objects are excluded because they must be scanned because of SATB. Because we now exclude objects that were live at start of marking when marking is in progress, the scenario we?re trying to deal with simply can?t occur. If H gets marked and added to the mark stack, it was necessarily live at start of mark; the marking process filters out objects that were allocated since marking started, e.g. we allocate black while marking, so such objects aren?t added to the mark stack. Since the objects that can be added to the mark stack are excluded from the reclaim candidate set, the problematic situation cannot arise. Since I was rewriting the relevant code anyway, I've also changed the type restriction for candidacy. Previously it was !is_objArray() and has been changed to is_typeArray(). This addresses https://bugs.openjdk.java.net/browse/JDK-8072598. Note that we can?t yet eagerly reclaim humongous objects containing references, because there are remset entries from such objects that need to be dealt with. [I think this is (part of?) https://bugs.openjdk.java.net/browse/JDK-8071913.] Testing: JPRT, Aurora ad hoc GC Nightly and other tests with -XX:+UseG1GC From kim.barrett at oracle.com Tue Mar 17 21:23:28 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 17 Mar 2015 17:23:28 -0400 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> <55014F32.3030400@oracle.com> <5501683D.2000905@oracle.com> <58A2D320-A2E7-4304-90CA-CC1C768DA52C@oracle.com> <5502A38F.7000000@oracle.com> Message-ID: On Mar 13, 2015, at 1:51 PM, Kim Barrett wrote: > > On Mar 13, 2015, at 4:45 AM, Bengt Rutisson wrote: >> >> Another alternative would be to let initial marking note all humongous objects that were live after initial mark. Then we can just make sure that early reclaim does not reclaim any of those humongous objects while marking is active. That should be a pretty simple fix that can be backported if necessary. > > Bengt and I talked about this some more; I?m going to have a look at the code for this, as it seems likely better. Here?s a new webrev, following Bengt?s suggestion. CR: https://bugs.openjdk.java.net/browse/JDK-8069367 Webrev: http://cr.openjdk.java.net/~kbarrett/8069367/webrev.02/ No incremental webrev, since the approach (and so the changes) are entirely different. As a reminder, the scenario we are dealing with is (1) A humongous object H is marked and added to the mark stack. (2) An evacuation pause determines H is no longer live, and reclaims it. This occurs before concurrent marking has gotten around to processing the mark stack entry for H. (3) Concurrent marking processes the mark stack entry for H, attempting to scan the now dead object. The new approach is to create a set of candidates at the start of the collection pause, remove candidates as they are reached from roots or from the young generation, and release any remaining candidates with empty remsets. (This is similar to before.) The difference is in how we create the set of candidates. Previously, all humongous objects satisfying certain type restrictions and remset size limits were treated as candidates. Now, when concurrent marking is in progress, we also exclude from the initial candidate set any objects that were live at the start of marking, determined by comparing the object against its region?s TAMS value. Such objects are excluded because they must be scanned because of SATB. Because we now exclude objects that were live at start of marking when marking is in progress, the scenario we?re trying to deal with simply can?t occur. If H gets marked and added to the mark stack, it was necessarily live at start of mark; the marking process filters out objects that were allocated since marking started, e.g. we allocate black while marking, so such objects aren?t added to the mark stack. Since the objects that can be added to the mark stack are excluded from the reclaim candidate set, the problematic situation cannot arise. Since I was rewriting the relevant code anyway, I've also changed the type restriction for candidacy. Previously it was !is_objArray() and has been changed to is_typeArray(). This addresses https://bugs.openjdk.java.net/browse/JDK-8072598. Note that we can?t yet eagerly reclaim humongous objects containing references, because there are remset entries from such objects that need to be dealt with. [I think this is (part of?) https://bugs.openjdk.java.net/browse/JDK-8071913.] Testing: JPRT, Aurora ad hoc GC Nightly and other tests with -XX:+UseG1GC From kim.barrett at oracle.com Wed Mar 18 00:20:09 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 17 Mar 2015 20:20:09 -0400 Subject: RFR: 8075401: Remove DiscoveredListIterator::update_discovered() Message-ID: Please review this change to remove unnecessary calls to DiscoveredListIterator::update_discovered(), and remove the now unused function. Details are in the CR. I will need a sponsor for this change. CR: https://bugs.openjdk.java.net/browse/JDK-8075401 Webrev: http://cr.openjdk.java.net/~kbarrett/8075401/webrev.00/ Testing: JPRT, Aurora ad hoc GC Nightly and other tests, local JTREG of hotspot/tests/[closed/]{runtime,gc}, RefWorkload with -XX:+UseG1GC, -XX:+UseParallelOldGC, -XX:+UseConcMarkSweepGC From mikael.gerdin at oracle.com Wed Mar 18 08:50:32 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 18 Mar 2015 09:50:32 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <20150317155656.GA20878@ehelin.jrpg.bea.com> References: <5506DC92.7090609@oracle.com> <20150317155656.GA20878@ehelin.jrpg.bea.com> Message-ID: <55093C58.4050100@oracle.com> Hi Erik, On 2015-03-17 16:56, Erik Helin wrote: > On 2015-03-16, Mikael Gerdin wrote: >> Full webrev: >> http://cr.openjdk.java.net/~mgerdin/8075210/full/webrev > > In general, the patch looks good, thanks for refactoring this! > > I agree with Thomas' comments and also have one of my own: it looks like > G1RootProcessor::_trace_metadata only is used by > G1RootProcessor::evacuate_roots, could trace_metadata become an > parameter to G1RootProcessor::evacuate_roots instead of being a > paramater to the constructor? Excellent suggestion! Incremental webrev at: http://cr.openjdk.java.net/~mgerdin/8075210/eriks-comments/webrev/ > > Also, since set_n_termination has been removed from SharedHeap, can't we > just remove it from G1CollectedHeap as well? I've removed it in a previous patch (thomas-comments/webrev) /Mikael > > Thanks, > Erik > From mikael.gerdin at oracle.com Wed Mar 18 09:44:33 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 18 Mar 2015 10:44:33 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <5508603C.1010708@oracle.com> References: <5506DC92.7090609@oracle.com> <1426602366.3090.60.camel@oracle.com> <55084FBB.5040605@oracle.com> <5508603C.1010708@oracle.com> Message-ID: <55094901.2030800@oracle.com> Hi Dima, On 2015-03-17 18:11, Dmitry Fazunenko wrote: > Hi Mikael, > > Sorry for boring question, but how did you test the fix? It's not a boring question! I've been running the phase-1 part of the change when developing a separate feature. I've also tested the change with JPRT, which found some bugs in an earlier version of the pathces. > This change doesn't look like a trivial one, so how can you guarantee > that it will not break anything? I've tested the G1 change in two parts: In phase-1 I changed the standard GC pauses to use the new code while having the verification code call the old variant. Hopefully this shows that the new code in G1RootProcessor does not break anything. In phase-2 I switched the verification code to use the new code as well, as I was satisfied that it was performing correctly. In phase-3 I simply cut-pasted a bunch of code to another class in order to clean it up. > > I know you guys are monsters and you can verify changes just looking at > webrev. But what about simple unit tests verifying basic invariants? There are no basic invariants. This code is inherently stateful and touches a lot of global objects. Without a framework for mocking the entire JVM around G1RootProcessor I have a hard time figuring out how to test it. /Mikael > > Thanks, > Dima > > On 17.03.2015 19:00, Mikael Gerdin wrote: >> On 2015-03-17 15:26, Thomas Schatzl wrote: >>> Hi Mikael, >>> >>> some comments for the full change: >>> >>> On Mon, 2015-03-16 at 14:37 +0100, Mikael Gerdin wrote: >>>> Hi all! >>>> >>>> Currently SharedHeap::process_strong_roots is called both by the >>>> GenCollectedHeap based collectors (CMS, Serial) and G1. >>> [...] >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8075210 >>>> >>>> Webrevs: >>>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-1/webrev >>>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-2/webrev >>>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-3/webrev >>>> >>>> Full webrev: >>>> http://cr.openjdk.java.net/~mgerdin/8075210/full/webrev >>> >>> - I think allocation.inline.hpp does not seem to be required in the >>> include list for the hpp file (but in the cpp file). >> >> Fixed. >> >>> >>> - class forward declarations for G1CollectorPolicy, G1RemSet, >>> ReferenceProcessor are not required. Ones (or includes) for the various >>> closures are missing. >> >> Fixed. >> >>> >>> - is it possible to add at least a few lines of documentation to the >>> public methods of G1RootProcessor? To me it is not evidently clear what >>> e.g. the difference between evacuate_roots, and process_strong_roots is. >>> Also, G1CollectedHeap::g1_process_roots() did have at least some >>> documentation. >>> Or what G1RootProcessor actually is supposed to do. >>> Please also mention that the G1RootProcessor is a scoped object that >>> does some serious work in the constructor/destructor. I almost suggested >>> (again :)) to just remove the StrongRootScope :) >> >> I added a few comments in g1RootProcessor.hpp >> >> I also want to get rid of StrongRootsScope, but I'm unsure of what to >> replace it with? >> >>> >>> - g1RootProcessor.?pp copyrights are from 2014. >> >> Fixed. >> >>> >>> - in g1collectedheap.cpp:lines 4489-4492 the parameters for the call to >>> evacuate_roots() are not aligned properly. >> >> Fixed (not visible in webrev, see patch file). >> >>> >>> - the comment in line 5501-5505 in g1CollectedHeap.cpp is outdated, >>> mentioning the StrongRootsScope object that moved to the >>> g1rootprocessor. >> >> Updated the comment. >> >>> >>> - there should imo be a warning in G1CollectedHeap::set_n_termination() >>> why this is an empty method. >> >> I don't think it's needed at all, I removed it. >> >>> >>> - I think Bengt already mentioned this, but g1CollectedHeap.cpp:98 still >>> mentions g1_process_roots(). The entire paragraph seems outdated now. I >>> do not think anything noted there is true any more. >> >> I removed the entire comment. It seemed weird to keep the part about >> ParVerifyTask when no other parallel tasks were being described. >> >>> >>> - comment in g1CollectedHeap.hpp:1007+ is outdated. >> >> Removed. >> >>> >>> - please add braces for every if-statement in >>> GenCollectedHeap::process_roots(). In the G1RootProcessor this has been >>> done. >> >> Done. >> >>> >>> - I think the instantiation of G1RootsProcessor in >>> G1CollectedHeap::verify() should be scoped, i.e. it and the call to >>> process_all_roots() enclosed with braces. >> >> Fixed. >> >>> >>> I will need another round because I am somewhat confused about the >>> changes regarding setting the number of threads in the various >>> locations. >> >> No problem. >> >> Here's an incremental webrev incorporating your suggestions: >> http://cr.openjdk.java.net/~mgerdin/8075210/thomas-comments/webrev/ >> It's based on >> http://cr.openjdk.java.net/~mgerdin/8075210/done_with_threads/webrev/ >> which incorporates Eric's renaming request. >> >> New full webrev at: >> http://cr.openjdk.java.net/~mgerdin/8075210/full2/webrev/ >> >> /Mikael >> >>> >>> Thanks, >>> Thomas >>> >>> >> > From dmitry.fazunenko at oracle.com Wed Mar 18 10:09:18 2015 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 18 Mar 2015 13:09:18 +0300 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <55094901.2030800@oracle.com> References: <5506DC92.7090609@oracle.com> <1426602366.3090.60.camel@oracle.com> <55084FBB.5040605@oracle.com> <5508603C.1010708@oracle.com> <55094901.2030800@oracle.com> Message-ID: <55094ECE.20207@oracle.com> Mikael, Thank you for detailed explanation, my "curiosity" is satisfied now. The level of testing looks good to me. I understand the problem of writing unit tests and I keep hoping that one day we have a mocking framework for GC. And the more we are talking about it the sooner this day will come. Thanks, Dima On 18.03.2015 12:44, Mikael Gerdin wrote: > Hi Dima, > > On 2015-03-17 18:11, Dmitry Fazunenko wrote: >> Hi Mikael, >> >> Sorry for boring question, but how did you test the fix? > > It's not a boring question! > I've been running the phase-1 part of the change when developing a > separate feature. I've also tested the change with JPRT, which found > some bugs in an earlier version of the pathces. > >> This change doesn't look like a trivial one, so how can you guarantee >> that it will not break anything? > > I've tested the G1 change in two parts: > In phase-1 I changed the standard GC pauses to use the new code while > having the verification code call the old variant. Hopefully this > shows that the new code in G1RootProcessor does not break anything. > > In phase-2 I switched the verification code to use the new code as > well, as I was satisfied that it was performing correctly. > > In phase-3 I simply cut-pasted a bunch of code to another class in > order to clean it up. > >> >> I know you guys are monsters and you can verify changes just looking at >> webrev. But what about simple unit tests verifying basic invariants? > > There are no basic invariants. > This code is inherently stateful and touches a lot of global objects. > Without a framework for mocking the entire JVM around G1RootProcessor > I have a hard time figuring out how to test it. > > /Mikael > >> >> Thanks, >> Dima >> >> On 17.03.2015 19:00, Mikael Gerdin wrote: >>> On 2015-03-17 15:26, Thomas Schatzl wrote: >>>> Hi Mikael, >>>> >>>> some comments for the full change: >>>> >>>> On Mon, 2015-03-16 at 14:37 +0100, Mikael Gerdin wrote: >>>>> Hi all! >>>>> >>>>> Currently SharedHeap::process_strong_roots is called both by the >>>>> GenCollectedHeap based collectors (CMS, Serial) and G1. >>>> [...] >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8075210 >>>>> >>>>> Webrevs: >>>>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-1/webrev >>>>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-2/webrev >>>>> http://cr.openjdk.java.net/~mgerdin/8075210/phase-3/webrev >>>>> >>>>> Full webrev: >>>>> http://cr.openjdk.java.net/~mgerdin/8075210/full/webrev >>>> >>>> - I think allocation.inline.hpp does not seem to be required in the >>>> include list for the hpp file (but in the cpp file). >>> >>> Fixed. >>> >>>> >>>> - class forward declarations for G1CollectorPolicy, G1RemSet, >>>> ReferenceProcessor are not required. Ones (or includes) for the >>>> various >>>> closures are missing. >>> >>> Fixed. >>> >>>> >>>> - is it possible to add at least a few lines of documentation to the >>>> public methods of G1RootProcessor? To me it is not evidently clear >>>> what >>>> e.g. the difference between evacuate_roots, and >>>> process_strong_roots is. >>>> Also, G1CollectedHeap::g1_process_roots() did have at least some >>>> documentation. >>>> Or what G1RootProcessor actually is supposed to do. >>>> Please also mention that the G1RootProcessor is a scoped object that >>>> does some serious work in the constructor/destructor. I almost >>>> suggested >>>> (again :)) to just remove the StrongRootScope :) >>> >>> I added a few comments in g1RootProcessor.hpp >>> >>> I also want to get rid of StrongRootsScope, but I'm unsure of what to >>> replace it with? >>> >>>> >>>> - g1RootProcessor.?pp copyrights are from 2014. >>> >>> Fixed. >>> >>>> >>>> - in g1collectedheap.cpp:lines 4489-4492 the parameters for the >>>> call to >>>> evacuate_roots() are not aligned properly. >>> >>> Fixed (not visible in webrev, see patch file). >>> >>>> >>>> - the comment in line 5501-5505 in g1CollectedHeap.cpp is outdated, >>>> mentioning the StrongRootsScope object that moved to the >>>> g1rootprocessor. >>> >>> Updated the comment. >>> >>>> >>>> - there should imo be a warning in >>>> G1CollectedHeap::set_n_termination() >>>> why this is an empty method. >>> >>> I don't think it's needed at all, I removed it. >>> >>>> >>>> - I think Bengt already mentioned this, but g1CollectedHeap.cpp:98 >>>> still >>>> mentions g1_process_roots(). The entire paragraph seems outdated >>>> now. I >>>> do not think anything noted there is true any more. >>> >>> I removed the entire comment. It seemed weird to keep the part about >>> ParVerifyTask when no other parallel tasks were being described. >>> >>>> >>>> - comment in g1CollectedHeap.hpp:1007+ is outdated. >>> >>> Removed. >>> >>>> >>>> - please add braces for every if-statement in >>>> GenCollectedHeap::process_roots(). In the G1RootProcessor this has >>>> been >>>> done. >>> >>> Done. >>> >>>> >>>> - I think the instantiation of G1RootsProcessor in >>>> G1CollectedHeap::verify() should be scoped, i.e. it and the call to >>>> process_all_roots() enclosed with braces. >>> >>> Fixed. >>> >>>> >>>> I will need another round because I am somewhat confused about the >>>> changes regarding setting the number of threads in the various >>>> locations. >>> >>> No problem. >>> >>> Here's an incremental webrev incorporating your suggestions: >>> http://cr.openjdk.java.net/~mgerdin/8075210/thomas-comments/webrev/ >>> It's based on >>> http://cr.openjdk.java.net/~mgerdin/8075210/done_with_threads/webrev/ >>> which incorporates Eric's renaming request. >>> >>> New full webrev at: >>> http://cr.openjdk.java.net/~mgerdin/8075210/full2/webrev/ >>> >>> /Mikael >>> >>>> >>>> Thanks, >>>> Thomas >>>> >>>> >>> >> From thomas.schatzl at oracle.com Wed Mar 18 10:37:35 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 18 Mar 2015 11:37:35 +0100 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <1425898922.3398.35.camel@oracle.com> References: <1425482904.3305.27.camel@oracle.com> <1425567491.3140.42.camel@oracle.com> <54F96CB2.9060107@oracle.com> <1425898922.3398.35.camel@oracle.com> Message-ID: <1426675055.3170.24.camel@oracle.com> Hi Stefan, Kim, could you look at the updated CR again? Also, I need a Reviewer to look at this. Thanks, Thomas On Mon, 2015-03-09 at 12:02 +0100, Thomas Schatzl wrote: > Hi Stefan, > > thanks for the review. > > There is a new webrev at > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.2 (full) > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.1_to_2 (diff) > > Further comments inline: > > On Fri, 2015-03-06 at 10:00 +0100, Stefan Johansson wrote: > > Hi Thomas, > > > > On 2015-03-05 15:58, Thomas Schatzl wrote: > > > Hi all, > > > > > > On Wed, 2015-03-04 at 16:28 +0100, Thomas Schatzl wrote: > > >> Hi all, > > >> > > >> can I have reviews for the following change that does some renamings > > >> in the allocation related class hierarchy, also adding a few lines of > > >> documentation. > > >> > > >> This change is intentionally limited to renames to keep it simple, in a > > >> subsequent patch there will be more cleanup changes, moving methods > > >> around. > > >> Also, if there is demand, I am open to rename the files to something > > >> different (suggestions?) in a follow-up change (to not confuse the > > >> webrev tool too much). > > >> > > >> CR: > > >> https://bugs.openjdk.java.net/browse/JDK-8073052 > > >> Webrev: > > >> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.00/ > > >> Testing: > > > I talked with Stefan Johansson a bit about the change, with the result > > > that we keep the name of G1Allocator, since in the upcoming changes (see > > > below for more) that class is supposed to handle all allocations within > > > the current allocation regions. > > > > > > Webrev: > > > http://cr.openjdk.java.net/~tschatzl/8073052/webrev.01 > > Generally change looks good, but I agree with Kim that PLABAllocator > > could still use the G1 prefix for consistency. Some other comments: > > Done. > > > --- > > g1CollectedHeap.hpp: > > + // Allocates a new heap region instance. > > + virtual HeapRegion* new_heap_region(uint hrs_index, MemRegion mr); > > > > No need to have this one virtual, no one extends G1CollectedHeap. > > Done. > > > --- > > vmStructs_g1.hpp: > > Since _summary_bytes_used have been moved in the native code this needs > > to be reflected in the Java agent as well. You need to move the > > functionality from G1Allocator.java to G1CollectedHeap.java. > > Done. > > Thanks, > Thomas > > From bengt.rutisson at oracle.com Wed Mar 18 11:45:12 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 18 Mar 2015 12:45:12 +0100 Subject: RFR (M): 8027962: Per-phase timing measurements for strong roots processing In-Reply-To: <1424163777.3163.4.camel@oracle.com> References: <1424163777.3163.4.camel@oracle.com> Message-ID: <55096548.5050903@oracle.com> Hi everyone, When this was first sent out for review I suggested a couple of cleanup changes before doing this change. One of the cleanups has been pushed: 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases https://bugs.openjdk.java.net/browse/JDK-8074037 The other one is out for review and is close to being pushed: 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap https://bugs.openjdk.java.net/browse/JDK-8075210 Based on the above patches, here's an updated webrev to fix 8027962: http://cr.openjdk.java.net/~brutisso/8027962/webrev.02 Could I have some reviews for this change? A couple of things to note. - The test TestGCLogMessages.java is the same test that Thomas had in his original patch. The test passes, so the logging output is the same as he suggested in his patch. - The "Filter SATB Roots" filtering phase that Thomas suggested in his patch was actually already recorded as a separate phase called "SATB Filtering". The "SATB Filtering" was printed on the "finer" level and at indentation level 2. Given that we now log all sub phases to the external root scanning it makes more sense to have this logging at the "finest" log level and at indentation level 3. I've made that change in my patch. Also, the "SATB Filtering" was only logged if we were in a marking cycle. That kind of makes sense since there won't be any work to do in that phase otherwise. But it makes parsing of the log files easier if the phase is always printed. Now that we print it a the "finest" level I think it is ok to always print it. Thanks, Bengt On 2015-02-17 10:02, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the following change that adds detailed logging > for the ext root scan phase of the g1 collector? > > If you add -XX:+UnlockExperimentalOptions -XX:G1LogLevel=finest, the > "Ext Root Scan" phase is now split up into several sub-categories, e.g. > instead of > > [Parallel Time: ...] > [GC Worker Start... > Min: ... Avg: ... Max: ... ] > [Ext root scan... > Min: ... Avg: ... Max: ... ] > [Update RS... > Min: ... Avg: ... Max: ... ] > > You get a detailed breakdown like this: > > [Parallel Time: ...] > [GC Worker Start... > Min: ... Avg: ... Max: ... ] > [Ext root scan... > Min: ... Avg: ... Max: ... ] > [Thread Roots: > Min: ... Avg: ... Max: ... ] > [StringTable Roots: > Min: ... Avg: ... Max: ... ] > [same for Universe Roots, JNI Handles Roots, ObjectSynchronizer > Roots, FlatProfiler Roots, Management Roots, SystemDictionary Roots, > CLDG Roots, JVMTI Roots, CodeCache Roots, Filter SATB Roots, CM > RefProcessor Roots, Wait for Strong CLD] > [Weak CLD Roots: > Min: ... Avg: ... Max: ... ] > [Update RS... > Min: ... Avg: ... Max: ... ] > > I intentionally only enabled this with -XX:G1LogLevel=finest because I > think typically this information would just increase the log file > without much additional information. > > Unfortunately there is no log level between finer and finest that could > be used to show this information without the per-thread timing, which > would cut the number of lines in half at least. > There is the option of adding another global option (some diagnostic > option maybe?), but I do think its use is limited (i.e. only after you > notice that "Ext Root Scan" grows over time) so you do not want all > those lines of information using only G1LogLevel=finer/PrintGCDetails. > > It would be trivial to change either way. > > E.g. something like > > [Parallel Time: ...] > [GC Worker Start... Min: ... Avg: ... Max: ... ] > [Ext root scan... Min: ... Avg: ... Max: ... ] > [Thread Roots:... Min: ... Avg: ... Max: ... ] > [StringTable Roots:... Min: ... Avg: ... Max: ... ] > [same for Universe Roots, JNI Handles Roots, ObjectSynchronizer > Roots, FlatProfiler Roots, Management Roots, SystemDictionary Roots, > CLDG Roots, JVMTI Roots, CodeCache Roots, Filter SATB Roots, CM > RefProcessor Roots, Wait for Strong CLD] > [Weak CLD Roots: Min: ... Avg: ... Max: ... ] > [Update RS... Min: ... Avg: ... Max: ... ] > > These messages help a lot in diagnosing the type of root leaks in root > processing. > > JIRA: > https://bugs.openjdk.java.net/browse/JDK-8027962 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8027962/webrev/ > Testing: > jprt, test case > > Thanks, > Thomas > > From erik.helin at oracle.com Wed Mar 18 12:06:00 2015 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 18 Mar 2015 13:06:00 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <55093C58.4050100@oracle.com> References: <5506DC92.7090609@oracle.com> <20150317155656.GA20878@ehelin.jrpg.bea.com> <55093C58.4050100@oracle.com> Message-ID: <20150318120600.GE20878@ehelin.jrpg.bea.com> On 2015-03-18, Mikael Gerdin wrote: > Hi Erik, > > On 2015-03-17 16:56, Erik Helin wrote: > >On 2015-03-16, Mikael Gerdin wrote: > >>Full webrev: > >>http://cr.openjdk.java.net/~mgerdin/8075210/full/webrev > > > >In general, the patch looks good, thanks for refactoring this! > > > >I agree with Thomas' comments and also have one of my own: it looks like > >G1RootProcessor::_trace_metadata only is used by > >G1RootProcessor::evacuate_roots, could trace_metadata become an > >parameter to G1RootProcessor::evacuate_roots instead of being a > >paramater to the constructor? > > Excellent suggestion! > > Incremental webrev at: > http://cr.openjdk.java.net/~mgerdin/8075210/eriks-comments/webrev/ Looks good, the changes you made based on Thomas comments also looks good. Reviewed. Thanks, Erik > > > >Also, since set_n_termination has been removed from SharedHeap, can't we > >just remove it from G1CollectedHeap as well? > > I've removed it in a previous patch (thomas-comments/webrev) > > /Mikael > > > > >Thanks, > >Erik > > From thomas.schatzl at oracle.com Wed Mar 18 12:28:24 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 18 Mar 2015 13:28:24 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <55084FBB.5040605@oracle.com> References: <5506DC92.7090609@oracle.com> <1426602366.3090.60.camel@oracle.com> <55084FBB.5040605@oracle.com> Message-ID: <1426681704.3207.5.camel@oracle.com> Hi Mikael, On Tue, 2015-03-17 at 17:00 +0100, Mikael Gerdin wrote: > On 2015-03-17 15:26, Thomas Schatzl wrote: > > Hi Mikael, [...] > > > > - I think the instantiation of G1RootsProcessor in > > G1CollectedHeap::verify() should be scoped, i.e. it and the call to > > process_all_roots() enclosed with braces. > > Fixed. > Wrong indentation of the &blobsl parameter. I do not need to re-review that. [...] > > Here's an incremental webrev incorporating your suggestions: > http://cr.openjdk.java.net/~mgerdin/8075210/thomas-comments/webrev/ > It's based on > http://cr.openjdk.java.net/~mgerdin/8075210/done_with_threads/webrev/ > which incorporates Eric's renaming request. > > New full webrev at: > http://cr.openjdk.java.net/~mgerdin/8075210/full2/webrev/ Looks good. Thomas From thomas.schatzl at oracle.com Wed Mar 18 12:32:56 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 18 Mar 2015 13:32:56 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <1426681704.3207.5.camel@oracle.com> References: <5506DC92.7090609@oracle.com> <1426602366.3090.60.camel@oracle.com> <55084FBB.5040605@oracle.com> <1426681704.3207.5.camel@oracle.com> Message-ID: <1426681976.3207.8.camel@oracle.com> Hi again, On Wed, 2015-03-18 at 13:28 +0100, Thomas Schatzl wrote: > Hi Mikael, > > On Tue, 2015-03-17 at 17:00 +0100, Mikael Gerdin wrote: > > On 2015-03-17 15:26, Thomas Schatzl wrote: > > > Hi Mikael, > [...] > > > > > > - I think the instantiation of G1RootsProcessor in > > > G1CollectedHeap::verify() should be scoped, i.e. it and the call to > > > process_all_roots() enclosed with braces. > > > > Fixed. > > > > Wrong indentation of the &blobsl parameter. I do not need to re-review > that. > > [...] > > > > Here's an incremental webrev incorporating your suggestions: > > http://cr.openjdk.java.net/~mgerdin/8075210/thomas-comments/webrev/ > > It's based on > > http://cr.openjdk.java.net/~mgerdin/8075210/done_with_threads/webrev/ > > which incorporates Eric's renaming request. > > > > New full webrev at: > > http://cr.openjdk.java.net/~mgerdin/8075210/full2/webrev/ > > Looks good. Some last-minute comment if it is not still too late: - G1CollectedHeap::set_par_threads(uint t) can be removed. It only calls the inherited method anyway. Thanks, Thomas From thomas.schatzl at oracle.com Wed Mar 18 12:39:05 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 18 Mar 2015 13:39:05 +0100 Subject: RFR (M): 8027962: Per-phase timing measurements for strong roots processing In-Reply-To: <55096548.5050903@oracle.com> References: <1424163777.3163.4.camel@oracle.com> <55096548.5050903@oracle.com> Message-ID: <1426682345.3207.13.camel@oracle.com> Hi Bengt, thanks for taking this over... On Wed, 2015-03-18 at 12:45 +0100, Bengt Rutisson wrote: > Hi everyone, > > When this was first sent out for review I suggested a couple of cleanup > changes before doing this change. One of the cleanups has been pushed: > > 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new > phases > https://bugs.openjdk.java.net/browse/JDK-8074037 > > The other one is out for review and is close to being pushed: > > 8075210: Refactor strong root processing in order to allow G1 to evolve > separately from GenCollectedHeap > https://bugs.openjdk.java.net/browse/JDK-8075210 > > Based on the above patches, here's an updated webrev to fix 8027962: > > http://cr.openjdk.java.net/~brutisso/8027962/webrev.02 > > Could I have some reviews for this change? - G1GCPhaseTimes::note_gc_start does not use the mark_in_progress parameter any more and can be removed. - this is more some style issue: since we moved all G1 specific root processing to G1RootProcessor, we actually do not need to pass around the phase_times parameter any more. We already assume that the G1GCPhaseTimes instance is global in the entire G1 code, so code in G1RootProcessor could also just access it via the global. Just store it in a local variable to save typing at the beginning of the method. Actually G1RootProcessor::evacuate_roots() does exactly that unlike process_vm_roots() and process_java_roots(). It is up to you to decide. - I am fine with the move of "SATB filtering" to log level finest and the additional indentation. Thanks, Thomas From mikael.gerdin at oracle.com Wed Mar 18 12:59:51 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 18 Mar 2015 13:59:51 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <1426681976.3207.8.camel@oracle.com> References: <5506DC92.7090609@oracle.com> <1426602366.3090.60.camel@oracle.com> <55084FBB.5040605@oracle.com> <1426681704.3207.5.camel@oracle.com> <1426681976.3207.8.camel@oracle.com> Message-ID: <550976C7.8060207@oracle.com> Hi Thomas, On 2015-03-18 13:32, Thomas Schatzl wrote: > Hi again, > > On Wed, 2015-03-18 at 13:28 +0100, Thomas Schatzl wrote: >> Hi Mikael, >> >> On Tue, 2015-03-17 at 17:00 +0100, Mikael Gerdin wrote: >>> On 2015-03-17 15:26, Thomas Schatzl wrote: >>>> Hi Mikael, >> [...] >>>> >>>> - I think the instantiation of G1RootsProcessor in >>>> G1CollectedHeap::verify() should be scoped, i.e. it and the call to >>>> process_all_roots() enclosed with braces. >>> >>> Fixed. >>> >> >> Wrong indentation of the &blobsl parameter. I do not need to re-review >> that. Yep, fixed already. >> >> [...] >>> >>> Here's an incremental webrev incorporating your suggestions: >>> http://cr.openjdk.java.net/~mgerdin/8075210/thomas-comments/webrev/ >>> It's based on >>> http://cr.openjdk.java.net/~mgerdin/8075210/done_with_threads/webrev/ >>> which incorporates Eric's renaming request. >>> >>> New full webrev at: >>> http://cr.openjdk.java.net/~mgerdin/8075210/full2/webrev/ >> >> Looks good. > > > Some last-minute comment if it is not still too late: > > - G1CollectedHeap::set_par_threads(uint t) can be removed. It only calls > the inherited method anyway. Right, removed it. Final full webrev at http://cr.openjdk.java.net/~mgerdin/8075210/full3/webrev/ I didn't create an incremental for the removal of G1CollectedHeap::set_par_threads(uint t), I hope that's ok. You need to look at the sdiff to see the blobsCl alignment: http://cr.openjdk.java.net/~mgerdin/8075210/full3/webrev/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.sdiff.html /Mikael > > Thanks, > Thomas > > From mikael.gerdin at oracle.com Wed Mar 18 13:05:10 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 18 Mar 2015 14:05:10 +0100 Subject: RFR (M): 8027962: Per-phase timing measurements for strong roots processing In-Reply-To: <1426682345.3207.13.camel@oracle.com> References: <1424163777.3163.4.camel@oracle.com> <55096548.5050903@oracle.com> <1426682345.3207.13.camel@oracle.com> Message-ID: <55097806.9050605@oracle.com> Thomas, On 2015-03-18 13:39, Thomas Schatzl wrote: > Hi Bengt, > > thanks for taking this over... > > On Wed, 2015-03-18 at 12:45 +0100, Bengt Rutisson wrote: >> Hi everyone, >> >> When this was first sent out for review I suggested a couple of cleanup >> changes before doing this change. One of the cleanups has been pushed: >> >> 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new >> phases >> https://bugs.openjdk.java.net/browse/JDK-8074037 >> >> The other one is out for review and is close to being pushed: >> >> 8075210: Refactor strong root processing in order to allow G1 to evolve >> separately from GenCollectedHeap >> https://bugs.openjdk.java.net/browse/JDK-8075210 >> >> Based on the above patches, here's an updated webrev to fix 8027962: >> >> http://cr.openjdk.java.net/~brutisso/8027962/webrev.02 >> >> Could I have some reviews for this change? > > - G1GCPhaseTimes::note_gc_start does not use the mark_in_progress > parameter any more and can be removed. > > - this is more some style issue: since we moved all G1 specific root > processing to G1RootProcessor, we actually do not need to pass around > the phase_times parameter any more. > We already assume that the G1GCPhaseTimes instance is global in the > entire G1 code, so code in G1RootProcessor could also just access it via > the global. > Just store it in a local variable to save typing at the beginning of the > method. Actually G1RootProcessor::evacuate_roots() does exactly that > unlike process_vm_roots() and process_java_roots(). > It is up to you to decide. The problem is that verification (VerifyBefore/AfterGC) also uses G1RootProcessor, but does not want the phase times reported (at least not in the global phase times instance). So in the end we need some way to determine if we should report the time or not for each root step. /Mikael > > - I am fine with the move of "SATB filtering" to log level finest and > the additional indentation. > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Wed Mar 18 13:05:26 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 18 Mar 2015 14:05:26 +0100 Subject: RFR (L): 8058354: SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting with 9-b29 In-Reply-To: <1424446165.3267.13.camel@oracle.com> References: <1422527439.3309.8.camel@oracle.com> <54CC0BCC.2090009@oracle.com> <1422959222.3368.4.camel@oracle.com> <54D11432.5050006@oracle.com> <1424162109.3163.2.camel@oracle.com> <54E75013.9010404@oracle.com> <1424446165.3267.13.camel@oracle.com> Message-ID: <1426683926.5616.6.camel@oracle.com> Hi all, I got a few more internal reviews and suggestions for this change, so I would like to ask for re-reviews. http://cr.openjdk.java.net/~tschatzl/8058354/webrev.3/ (full) http://cr.openjdk.java.net/~tschatzl/8058354/webrev.2_to_3/ (diff) Changes: - changed " SIZE_FORMAT" strings in gclog_or_tty->print_cr() format strings to " SIZE_FORMAT " since this is the correct style. - moved setup of reserved space with the requirements we have to the ReservedSpace constructor. - improve readability: in G1PageBasedVirtualSpace: renamings of "actual_size" -> "used_size" parameter, _commit_size -> _page_size member - G1PageBasedVirtualSpace: changed uintptr_t parameter types to more fitting size_t - some refactorings, extracting a few methods to make control flow more clear Testing: jprt, aurora Thanks, Thomas From thomas.schatzl at oracle.com Wed Mar 18 13:06:51 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 18 Mar 2015 14:06:51 +0100 Subject: RFR (M): 8027962: Per-phase timing measurements for strong roots processing In-Reply-To: <55097806.9050605@oracle.com> References: <1424163777.3163.4.camel@oracle.com> <55096548.5050903@oracle.com> <1426682345.3207.13.camel@oracle.com> <55097806.9050605@oracle.com> Message-ID: <1426684011.5616.7.camel@oracle.com> Hi Mikael, On Wed, 2015-03-18 at 14:05 +0100, Mikael Gerdin wrote: > Thomas, > > On 2015-03-18 13:39, Thomas Schatzl wrote: > > Hi Bengt, > > > > thanks for taking this over... > > > > On Wed, 2015-03-18 at 12:45 +0100, Bengt Rutisson wrote: > >> Hi everyone, > >> > >> When this was first sent out for review I suggested a couple of cleanup > >> changes before doing this change. One of the cleanups has been pushed: > >> > >> 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new > >> phases > >> https://bugs.openjdk.java.net/browse/JDK-8074037 > >> > >> The other one is out for review and is close to being pushed: > >> > >> 8075210: Refactor strong root processing in order to allow G1 to evolve > >> separately from GenCollectedHeap > >> https://bugs.openjdk.java.net/browse/JDK-8075210 > >> > >> Based on the above patches, here's an updated webrev to fix 8027962: > >> > >> http://cr.openjdk.java.net/~brutisso/8027962/webrev.02 > >> > >> Could I have some reviews for this change? > > > > - G1GCPhaseTimes::note_gc_start does not use the mark_in_progress > > parameter any more and can be removed. > > > > - this is more some style issue: since we moved all G1 specific root > > processing to G1RootProcessor, we actually do not need to pass around > > the phase_times parameter any more. > > We already assume that the G1GCPhaseTimes instance is global in the > > entire G1 code, so code in G1RootProcessor could also just access it via > > the global. > > Just store it in a local variable to save typing at the beginning of the > > method. Actually G1RootProcessor::evacuate_roots() does exactly that > > unlike process_vm_roots() and process_java_roots(). > > It is up to you to decide. > > The problem is that verification (VerifyBefore/AfterGC) also uses > G1RootProcessor, but does not want the phase times reported (at least > not in the global phase times instance). > So in the end we need some way to determine if we should report the time > or not for each root step. Okay, I overlooked that. Forget this suggestion then. Thanks, Thomas From thomas.schatzl at oracle.com Wed Mar 18 13:11:57 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 18 Mar 2015 14:11:57 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <550976C7.8060207@oracle.com> References: <5506DC92.7090609@oracle.com> <1426602366.3090.60.camel@oracle.com> <55084FBB.5040605@oracle.com> <1426681704.3207.5.camel@oracle.com> <1426681976.3207.8.camel@oracle.com> <550976C7.8060207@oracle.com> Message-ID: <1426684317.5616.10.camel@oracle.com> Hi, On Wed, 2015-03-18 at 13:59 +0100, Mikael Gerdin wrote: > Hi Thomas, > > On 2015-03-18 13:32, Thomas Schatzl wrote: > > Hi again, > > > > On Wed, 2015-03-18 at 13:28 +0100, Thomas Schatzl wrote: > >> Hi Mikael, > >> > >> On Tue, 2015-03-17 at 17:00 +0100, Mikael Gerdin wrote: > >>> On 2015-03-17 15:26, Thomas Schatzl wrote: > >>>> Hi Mikael, > >> > >> [...] >> > > > > Some last-minute comment if it is not still too late: > > > > - G1CollectedHeap::set_par_threads(uint t) can be removed. It only calls > > the inherited method anyway. > > Right, removed it. > > Final full webrev at > http://cr.openjdk.java.net/~mgerdin/8075210/full3/webrev/ > I didn't create an incremental for the removal of > G1CollectedHeap::set_par_threads(uint t), I hope that's ok. > > You need to look at the sdiff to see the blobsCl alignment: > http://cr.openjdk.java.net/~mgerdin/8075210/full3/webrev/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.sdiff.html It seems that in the call to scan_remembered_set() the parameters are not aligned either. *duck* Looks good. :) Thanks a lot, Thomas From mikael.gerdin at oracle.com Wed Mar 18 13:32:25 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 18 Mar 2015 14:32:25 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <1426684317.5616.10.camel@oracle.com> References: <5506DC92.7090609@oracle.com> <1426602366.3090.60.camel@oracle.com> <55084FBB.5040605@oracle.com> <1426681704.3207.5.camel@oracle.com> <1426681976.3207.8.camel@oracle.com> <550976C7.8060207@oracle.com> <1426684317.5616.10.camel@oracle.com> Message-ID: <55097E69.3040104@oracle.com> On 2015-03-18 14:11, Thomas Schatzl wrote: > Hi, > > On Wed, 2015-03-18 at 13:59 +0100, Mikael Gerdin wrote: >> Hi Thomas, >> >> On 2015-03-18 13:32, Thomas Schatzl wrote: >>> Hi again, >>> >>> On Wed, 2015-03-18 at 13:28 +0100, Thomas Schatzl wrote: >>>> Hi Mikael, >>>> >>>> On Tue, 2015-03-17 at 17:00 +0100, Mikael Gerdin wrote: >>>>> On 2015-03-17 15:26, Thomas Schatzl wrote: >>>>>> Hi Mikael, >>>> >>>> [...] >>> >>> >>> Some last-minute comment if it is not still too late: >>> >>> - G1CollectedHeap::set_par_threads(uint t) can be removed. It only calls >>> the inherited method anyway. >> >> Right, removed it. >> >> Final full webrev at >> http://cr.openjdk.java.net/~mgerdin/8075210/full3/webrev/ >> I didn't create an incremental for the removal of >> G1CollectedHeap::set_par_threads(uint t), I hope that's ok. >> >> You need to look at the sdiff to see the blobsCl alignment: >> http://cr.openjdk.java.net/~mgerdin/8075210/full3/webrev/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.sdiff.html > > It seems that in the call to scan_remembered_set() the parameters are > not aligned either. *duck* I'll fix it before I push. > > Looks good. :) Thanks for the review. /m > > Thanks a lot, > Thomas > > From bengt.rutisson at oracle.com Wed Mar 18 13:28:46 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 18 Mar 2015 14:28:46 +0100 Subject: RFR (M): 8027962: Per-phase timing measurements for strong roots processing In-Reply-To: <1426684011.5616.7.camel@oracle.com> References: <1424163777.3163.4.camel@oracle.com> <55096548.5050903@oracle.com> <1426682345.3207.13.camel@oracle.com> <55097806.9050605@oracle.com> <1426684011.5616.7.camel@oracle.com> Message-ID: <55097D8E.8070905@oracle.com> Hi Thomas and Mikael, Thanks for looking at this! On 2015-03-18 14:06, Thomas Schatzl wrote: > Hi Mikael, > > On Wed, 2015-03-18 at 14:05 +0100, Mikael Gerdin wrote: >> Thomas, >> >> On 2015-03-18 13:39, Thomas Schatzl wrote: >>> Hi Bengt, >>> >>> thanks for taking this over... >>> >>> On Wed, 2015-03-18 at 12:45 +0100, Bengt Rutisson wrote: >>>> Hi everyone, >>>> >>>> When this was first sent out for review I suggested a couple of cleanup >>>> changes before doing this change. One of the cleanups has been pushed: >>>> >>>> 8074037: Refactor the G1GCPhaseTime logging to make it easier to add new >>>> phases >>>> https://bugs.openjdk.java.net/browse/JDK-8074037 >>>> >>>> The other one is out for review and is close to being pushed: >>>> >>>> 8075210: Refactor strong root processing in order to allow G1 to evolve >>>> separately from GenCollectedHeap >>>> https://bugs.openjdk.java.net/browse/JDK-8075210 >>>> >>>> Based on the above patches, here's an updated webrev to fix 8027962: >>>> >>>> http://cr.openjdk.java.net/~brutisso/8027962/webrev.02 >>>> >>>> Could I have some reviews for this change? >>> - G1GCPhaseTimes::note_gc_start does not use the mark_in_progress >>> parameter any more and can be removed. Good catch. I removed the mark_in_progress parameter. Here's an updated webrev: http://cr.openjdk.java.net/~brutisso/8027962/webrev.03/ And an incremetal diff compared to the last one: http://cr.openjdk.java.net/~brutisso/8027962/webrev.02-03.diff/ >>> >>> - this is more some style issue: since we moved all G1 specific root >>> processing to G1RootProcessor, we actually do not need to pass around >>> the phase_times parameter any more. >>> We already assume that the G1GCPhaseTimes instance is global in the >>> entire G1 code, so code in G1RootProcessor could also just access it via >>> the global. >>> Just store it in a local variable to save typing at the beginning of the >>> method. Actually G1RootProcessor::evacuate_roots() does exactly that >>> unlike process_vm_roots() and process_java_roots(). >>> It is up to you to decide. >> The problem is that verification (VerifyBefore/AfterGC) also uses >> G1RootProcessor, but does not want the phase times reported (at least >> not in the global phase times instance). >> So in the end we need some way to determine if we should report the time >> or not for each root step. > Okay, I overlooked that. Forget this suggestion then. Thanks for sorting this out. Bengt > > Thanks, > Thomas > > From bengt.rutisson at oracle.com Wed Mar 18 13:33:35 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 18 Mar 2015 14:33:35 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <55097E69.3040104@oracle.com> References: <5506DC92.7090609@oracle.com> <1426602366.3090.60.camel@oracle.com> <55084FBB.5040605@oracle.com> <1426681704.3207.5.camel@oracle.com> <1426681976.3207.8.camel@oracle.com> <550976C7.8060207@oracle.com> <1426684317.5616.10.camel@oracle.com> <55097E69.3040104@oracle.com> Message-ID: <55097EAF.2050602@oracle.com> On 2015-03-18 14:32, Mikael Gerdin wrote: > > On 2015-03-18 14:11, Thomas Schatzl wrote: >> Hi, >> >> On Wed, 2015-03-18 at 13:59 +0100, Mikael Gerdin wrote: >>> Hi Thomas, >>> >>> On 2015-03-18 13:32, Thomas Schatzl wrote: >>>> Hi again, >>>> >>>> On Wed, 2015-03-18 at 13:28 +0100, Thomas Schatzl wrote: >>>>> Hi Mikael, >>>>> >>>>> On Tue, 2015-03-17 at 17:00 +0100, Mikael Gerdin wrote: >>>>>> On 2015-03-17 15:26, Thomas Schatzl wrote: >>>>>>> Hi Mikael, >>>>> >>>>> [...] >>>> >>>> >>>> Some last-minute comment if it is not still too late: >>>> >>>> - G1CollectedHeap::set_par_threads(uint t) can be removed. It only >>>> calls >>>> the inherited method anyway. >>> >>> Right, removed it. >>> >>> Final full webrev at >>> http://cr.openjdk.java.net/~mgerdin/8075210/full3/webrev/ Looks good to me. Bengt >>> I didn't create an incremental for the removal of >>> G1CollectedHeap::set_par_threads(uint t), I hope that's ok. >>> >>> You need to look at the sdiff to see the blobsCl alignment: >>> http://cr.openjdk.java.net/~mgerdin/8075210/full3/webrev/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.sdiff.html >>> >> >> It seems that in the call to scan_remembered_set() the parameters are >> not aligned either. *duck* > > I'll fix it before I push. > >> >> Looks good. :) > > Thanks for the review. > > /m > >> >> Thanks a lot, >> Thomas >> >> From bengt.rutisson at oracle.com Wed Mar 18 14:02:50 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 18 Mar 2015 15:02:50 +0100 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> <55014F32.3030400@oracle.com> <5501683D.2000905@oracle.com> <58A2D320-A2E7-4304-90CA-CC1C768DA52C@oracle.com> <5502A38F.7000000@oracle.com> Message-ID: <5509858A.5000700@oracle.com> Hi Kim, On 2015-03-17 22:23, Kim Barrett wrote: > On Mar 13, 2015, at 1:51 PM, Kim Barrett wrote: >> On Mar 13, 2015, at 4:45 AM, Bengt Rutisson wrote: >>> Another alternative would be to let initial marking note all humongous objects that were live after initial mark. Then we can just make sure that early reclaim does not reclaim any of those humongous objects while marking is active. That should be a pretty simple fix that can be backported if necessary. >> Bengt and I talked about this some more; I?m going to have a look at the code for this, as it seems likely better. > Here?s a new webrev, following Bengt?s suggestion. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8069367 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8069367/webrev.02/ The change looks good to me. One minor nit. The command line for the @run command in the test is not aligned: 30 * @run main/othervm -XX:+UseG1GC -Xss32m -Xmx128m -XX:G1HeapRegionSize=1m 31 * -XX:+UnlockExperimentalVMOptions 32 * -XX:+G1EagerReclaimHumongousObjects 33 * -XX:+G1EagerReclaimHumongousObjectsWithStaleRefs 34 * TestGreyReclaimedHumongousObjects 1048576 90 Thanks, Bengt > > No incremental webrev, since the approach (and so the changes) are entirely different. > > As a reminder, the scenario we are dealing with is > > (1) A humongous object H is marked and added to the mark stack. > > (2) An evacuation pause determines H is no longer live, and reclaims > it. This occurs before concurrent marking has gotten around to > processing the mark stack entry for H. > > (3) Concurrent marking processes the mark stack entry for H, > attempting to scan the now dead object. > > The new approach is to create a set of candidates at the start of the collection > pause, remove candidates as they are reached from roots or from the young > generation, and release any remaining candidates with empty remsets. (This > is similar to before.) > > The difference is in how we create the set of candidates. Previously, all humongous > objects satisfying certain type restrictions and remset size limits were treated as > candidates. Now, when concurrent marking is in progress, we also exclude from > the initial candidate set any objects that were live at the start of marking, determined > by comparing the object against its region?s TAMS value. Such objects are excluded > because they must be scanned because of SATB. > > Because we now exclude objects that were live at start of marking when marking > is in progress, the scenario we?re trying to deal with simply can?t occur. If H gets > marked and added to the mark stack, it was necessarily live at start of mark; the > marking process filters out objects that were allocated since marking started, e.g. > we allocate black while marking, so such objects aren?t added to the mark stack. > Since the objects that can be added to the mark stack are excluded from the > reclaim candidate set, the problematic situation cannot arise. > > Since I was rewriting the relevant code anyway, I've also changed the type restriction > for candidacy. Previously it was !is_objArray() and has been changed to is_typeArray(). > This addresses https://bugs.openjdk.java.net/browse/JDK-8072598. > > Note that we can?t yet eagerly reclaim humongous objects containing references, > because there are remset entries from such objects that need to be dealt with. > [I think this is (part of?) https://bugs.openjdk.java.net/browse/JDK-8071913.] > > Testing: > JPRT, Aurora ad hoc GC Nightly and other tests with -XX:+UseG1GC > > From kim.barrett at oracle.com Wed Mar 18 14:32:41 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 18 Mar 2015 10:32:41 -0400 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <5509858A.5000700@oracle.com> References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> <55014F32.3030400@oracle.com> <5501683D.2000905@oracle.com> <58A2D320-A2E7-4304-90CA-CC1C768DA52C@oracle.com> <5502A38F.7000000@oracle.com> <5509858A.5000700@oracle.com> Message-ID: <6AA0EB20-219D-4AC2-A0DE-66C8AACBB2C1@oracle.com> On Mar 18, 2015, at 10:02 AM, Bengt Rutisson wrote: > > > Hi Kim, > > On 2015-03-17 22:23, Kim Barrett wrote: >> On Mar 13, 2015, at 1:51 PM, Kim Barrett wrote: >>> On Mar 13, 2015, at 4:45 AM, Bengt Rutisson wrote: >>>> Another alternative would be to let initial marking note all humongous objects that were live after initial mark. Then we can just make sure that early reclaim does not reclaim any of those humongous objects while marking is active. That should be a pretty simple fix that can be backported if necessary. >>> Bengt and I talked about this some more; I?m going to have a look at the code for this, as it seems likely better. >> Here?s a new webrev, following Bengt?s suggestion. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8069367 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8069367/webrev.02/ > > The change looks good to me. One minor nit. The command line for the @run command in the test is not aligned: > > 30 * @run main/othervm -XX:+UseG1GC -Xss32m -Xmx128m -XX:G1HeapRegionSize=1m > 31 * -XX:+UnlockExperimentalVMOptions > 32 * -XX:+G1EagerReclaimHumongousObjects > 33 * -XX:+G1EagerReclaimHumongousObjectsWithStaleRefs > 34 * TestGreyReclaimedHumongousObjects 1048576 90 Thanks for your review, and especially for suggesting a much better solution. That was intentional - extra indentation of the experimental options under the associated unlock. But I don?t feel strongly about it. The experimental options are also not presently required, since they both default to being enabled. But I?m not certain that will remain true all the way through to product, since there is some small overhead for this feature for applications that don?t benefit from it. And since this test is pretty much pointless without that set of features being enabled? From bengt.rutisson at oracle.com Wed Mar 18 14:31:30 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 18 Mar 2015 15:31:30 +0100 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <6AA0EB20-219D-4AC2-A0DE-66C8AACBB2C1@oracle.com> References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> <55014F32.3030400@oracle.com> <5501683D.2000905@oracle.com> <58A2D320-A2E7-4304-90CA-CC1C768DA52C@oracle.com> <5502A38F.7000000@oracle.com> <5509858A.5000700@oracle.com> <6AA0EB20-219D-4AC2-A0DE-66C8AACBB2C1@oracle.com> Message-ID: <55098C42.3080308@oracle.com> On 2015-03-18 15:32, Kim Barrett wrote: > On Mar 18, 2015, at 10:02 AM, Bengt Rutisson wrote: >> >> Hi Kim, >> >> On 2015-03-17 22:23, Kim Barrett wrote: >>> On Mar 13, 2015, at 1:51 PM, Kim Barrett wrote: >>>> On Mar 13, 2015, at 4:45 AM, Bengt Rutisson wrote: >>>>> Another alternative would be to let initial marking note all humongous objects that were live after initial mark. Then we can just make sure that early reclaim does not reclaim any of those humongous objects while marking is active. That should be a pretty simple fix that can be backported if necessary. >>>> Bengt and I talked about this some more; I?m going to have a look at the code for this, as it seems likely better. >>> Here?s a new webrev, following Bengt?s suggestion. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8069367 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8069367/webrev.02/ >> The change looks good to me. One minor nit. The command line for the @run command in the test is not aligned: >> >> 30 * @run main/othervm -XX:+UseG1GC -Xss32m -Xmx128m -XX:G1HeapRegionSize=1m >> 31 * -XX:+UnlockExperimentalVMOptions >> 32 * -XX:+G1EagerReclaimHumongousObjects >> 33 * -XX:+G1EagerReclaimHumongousObjectsWithStaleRefs >> 34 * TestGreyReclaimedHumongousObjects 1048576 90 > Thanks for your review, and especially for suggesting a much better solution. > > That was intentional - extra indentation of the experimental options under the associated unlock. But I don?t feel strongly about it. Ah. Ok. I didn't realize this. In that case I'm fine either way. No strong opinion. > The experimental options are also not presently required, since they both default to being enabled. But I?m not certain that will remain true all the way through to product, since there is some small overhead for this feature for applications that don?t benefit from it. And since this test is pretty much pointless without that set of features being enabled? Agreed. It is probably a good idea to explicitly set these flags. Bengt > > > From bengt.rutisson at oracle.com Wed Mar 18 15:10:57 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 18 Mar 2015 16:10:57 +0100 Subject: RFR: 8075401: Remove DiscoveredListIterator::update_discovered() In-Reply-To: References: Message-ID: <55099581.3080903@oracle.com> Hi Kim, On 2015-03-18 01:20, Kim Barrett wrote: > Please review this change to remove unnecessary calls to > DiscoveredListIterator::update_discovered(), and remove the now unused > function. Details are in the CR. > > I will need a sponsor for this change. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8075401 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8075401/webrev.00/ As far as I can tell this is fine. It is always a bit hairy to follow the state transitions in the reference processing... One question. After your change the only use of _prev_next is in DiscoveredListIterator::remove(). Would it be possible to re-write that method to completely remove the _prev_next field? I didn't really have time to follow up how _prev, _next and _prev_next all work together, but it might be worth investigating. The one who added this comment would probably be happy if we make remove be more transparent with what it does: // First _prev_next ref actually points into DiscoveredList (gross). Thanks, Bengt > > Testing: > JPRT, Aurora ad hoc GC Nightly and other tests, > local JTREG of hotspot/tests/[closed/]{runtime,gc}, > RefWorkload with -XX:+UseG1GC, -XX:+UseParallelOldGC, -XX:+UseConcMarkSweepGC > From kim.barrett at oracle.com Wed Mar 18 17:51:42 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 18 Mar 2015 13:51:42 -0400 Subject: RFR: 8075401: Remove DiscoveredListIterator::update_discovered() In-Reply-To: <55099581.3080903@oracle.com> References: <55099581.3080903@oracle.com> Message-ID: On Mar 18, 2015, at 11:10 AM, Bengt Rutisson wrote: > > > Hi Kim, > > On 2015-03-18 01:20, Kim Barrett wrote: >> Please review this change to remove unnecessary calls to >> DiscoveredListIterator::update_discovered(), and remove the now unused >> function. Details are in the CR. >> >> I will need a sponsor for this change. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8075401 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8075401/webrev.00/ > > As far as I can tell this is fine. Thanks for your review. > t is always a bit hairy to follow the state transitions in the reference processing? No kidding! That's why I ended up separating this change out from the earlier JDK-8066827 - Remove ReferenceProcessor::clean_up_discovered_references(). That one was "relatively" straight-forward except for the removal of update_discovered, and was blocking a possible solution to a different bug I was working on. > One question. After your change the only use of _prev_next is in DiscoveredListIterator::remove(). Would it be possible to re-write that method to completely remove the _prev_next field? I didn't really have time to follow up how _prev, _next and _prev_next all work together, but it might be worth investigating. The one who added this comment would probably be happy if we make remove be more transparent with what it does: > > // First _prev_next ref actually points into DiscoveredList (gross). I don't think so. We have a singly-linked list from which we want to be able to remove the current item. That requires keeping track of the list pointer to the current item, which is what _prev_next is. We could eliminate the "gross" pointer into the DiscoveredList by using NULL as a sentinal for the head of the list, but I'm pretty sure that would end up needing some additional tests for that special case. From eric.caspole at oracle.com Wed Mar 18 22:00:53 2015 From: eric.caspole at oracle.com (Eric Caspole) Date: Wed, 18 Mar 2015 18:00:53 -0400 Subject: RFR: JDK-8060017: Report heap sizing time In-Reply-To: <1B46B485-4F7C-47BC-9B7E-51AE29FD7738@oracle.com> References: <1B46B485-4F7C-47BC-9B7E-51AE29FD7738@oracle.com> Message-ID: <5509F595.2090307@oracle.com> Thanks Kim, I fixed the copyrights and a jchecky thing with trailing spaces I did not notice earlier. New one: http://cr.openjdk.java.net/~ecaspole/JDK-8060017/03/webrev/ Eric On 3/17/2015 5:30 PM, Kim Barrett wrote: > On Mar 16, 2015, at 6:06 PM, Eric Caspole wrote: >> Hi, >> Please review this fix for showing the details of heap expansion time in the PrintGCDetails. >> >> https://bugs.openjdk.java.net/browse/JDK-8060017 >> http://cr.openjdk.java.net/~ecaspole/JDK-8060017/02/webrev/ >> >> The time to expand the heap is shown in the "Other" section at the end of each GC cycle info. >> >> I tested this with a smallish app with a high allocation rate which does a lot of heap expands depending on the command line options used. Also, passes JPRT. The output shows up and graphs correctly in the gc log app. >> Thanks, >> Eric > Looks good. > > A few copyrights need to be updated. > From kim.barrett at oracle.com Wed Mar 18 22:51:11 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 18 Mar 2015 18:51:11 -0400 Subject: RFR: JDK-8060017: Report heap sizing time In-Reply-To: <5509F595.2090307@oracle.com> References: <1B46B485-4F7C-47BC-9B7E-51AE29FD7738@oracle.com> <5509F595.2090307@oracle.com> Message-ID: <8F0362B7-7F1C-40C4-A5C4-9ADC9C90B392@oracle.com> On Mar 18, 2015, at 6:00 PM, Eric Caspole wrote: > > Thanks Kim, > I fixed the copyrights and a jchecky thing with trailing spaces I did not notice earlier. New one: > http://cr.openjdk.java.net/~ecaspole/JDK-8060017/03/webrev/ ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp 3979 size_t expand_bytes = g1_policy()->expansion_amount(); 3980 double expand_time_ms = 0.0; 3981 if (expand_bytes > 0) { 3982 double expand_heap_start_time_sec = os::elapsedTime(); 3983 size_t bytes_before = capacity(); 3984 // No need for an ergo verbose message here, 3985 // expansion_amount() does this when it returns a value > 0. 3986 if (!expand(expand_bytes)) { 3987 // We failed to expand the heap. Cannot do anything about it. 3988 } 3989 double expand_heap_end_time_sec = os::elapsedTime(); 3990 expand_time_ms = (expand_heap_end_time_sec - expand_heap_start_time_sec) * MILLIUNITS; 3991 } 3992 g1_policy()->phase_times()->record_expand_heap_time(expand_time_ms); [I meant to say something about this in the first round, but forgot. Sorry about that.] Seems like a lot more complicated than it really needs to be, in order to avoid measuring and reporting the time for expand_bytes == 0. ------------------------------------------------------------------------------ From mikael.gerdin at oracle.com Thu Mar 19 08:43:12 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 19 Mar 2015 09:43:12 +0100 Subject: RFR (M) 8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap In-Reply-To: <1426681976.3207.8.camel@oracle.com> References: <5506DC92.7090609@oracle.com> <1426602366.3090.60.camel@oracle.com> <55084FBB.5040605@oracle.com> <1426681704.3207.5.camel@oracle.com> <1426681976.3207.8.camel@oracle.com> Message-ID: <550A8C20.6090506@oracle.com> FYI, On 2015-03-18 13:32, Thomas Schatzl wrote: > Hi again, > > On Wed, 2015-03-18 at 13:28 +0100, Thomas Schatzl wrote: >> Hi Mikael, >> >> On Tue, 2015-03-17 at 17:00 +0100, Mikael Gerdin wrote: >>> On 2015-03-17 15:26, Thomas Schatzl wrote: >>>> Hi Mikael, >> [...] >>>> >>>> - I think the instantiation of G1RootsProcessor in >>>> G1CollectedHeap::verify() should be scoped, i.e. it and the call to >>>> process_all_roots() enclosed with braces. >>> >>> Fixed. >>> >> >> Wrong indentation of the &blobsl parameter. I do not need to re-review >> that. >> >> [...] >>> >>> Here's an incremental webrev incorporating your suggestions: >>> http://cr.openjdk.java.net/~mgerdin/8075210/thomas-comments/webrev/ >>> It's based on >>> http://cr.openjdk.java.net/~mgerdin/8075210/done_with_threads/webrev/ >>> which incorporates Eric's renaming request. >>> >>> New full webrev at: >>> http://cr.openjdk.java.net/~mgerdin/8075210/full2/webrev/ >> >> Looks good. > > > Some last-minute comment if it is not still too late: > > - G1CollectedHeap::set_par_threads(uint t) can be removed. It only calls > the inherited method anyway. Actually, just removing the method causes a problem since G1CollectedHeap::set_par_threads() then hides SharedHeap::set_par_threads(uint) "/opt/jprt/T/P1/160530.mgerdin/s/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp", line 1598: Warning: G1CollectedHeap::set_par_threads hides the virtual function SharedHeap::set_par_threads(unsigned). 1 Warning(s) detected. I will add a using SharedHeap::set_par_threads; to G1CollectedHeap to explicitly import it into G1CollectedHeap. I also plan to file a bug to enable this warning for gcc, I didn't hit it until it got to the Solaris build. /Mikael > > Thanks, > Thomas > > From bengt.rutisson at oracle.com Thu Mar 19 09:59:51 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 19 Mar 2015 10:59:51 +0100 Subject: RFR: 8075401: Remove DiscoveredListIterator::update_discovered() In-Reply-To: References: <55099581.3080903@oracle.com> Message-ID: <550A9E17.5040006@oracle.com> Hi Kim, On 2015-03-18 18:51, Kim Barrett wrote: > On Mar 18, 2015, at 11:10 AM, Bengt Rutisson wrote: >> >> Hi Kim, >> >> On 2015-03-18 01:20, Kim Barrett wrote: >>> Please review this change to remove unnecessary calls to >>> DiscoveredListIterator::update_discovered(), and remove the now unused >>> function. Details are in the CR. >>> >>> I will need a sponsor for this change. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8075401 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8075401/webrev.00/ >> As far as I can tell this is fine. > Thanks for your review. > >> t is always a bit hairy to follow the state transitions in the reference processing? > No kidding! > > That's why I ended up separating this change out from the earlier > JDK-8066827 - Remove ReferenceProcessor::clean_up_discovered_references(). > That one was "relatively" straight-forward except for the removal of > update_discovered, and was blocking a possible solution to a different > bug I was working on. > >> One question. After your change the only use of _prev_next is in DiscoveredListIterator::remove(). Would it be possible to re-write that method to completely remove the _prev_next field? I didn't really have time to follow up how _prev, _next and _prev_next all work together, but it might be worth investigating. The one who added this comment would probably be happy if we make remove be more transparent with what it does: >> >> // First _prev_next ref actually points into DiscoveredList (gross). > I don't think so. We have a singly-linked list from which we want to > be able to remove the current item. That requires keeping track of > the list pointer to the current item, which is what _prev_next is. > > We could eliminate the "gross" pointer into the DiscoveredList by > using NULL as a sentinal for the head of the list, but I'm pretty sure > that would end up needing some additional tests for that special case. Ok. That's fine. Let's leave it as it is. Reviewed. Bengt > From jon.masamitsu at oracle.com Thu Mar 19 13:50:41 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 19 Mar 2015 06:50:41 -0700 Subject: Request for review (s) : 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads In-Reply-To: <1426013100.3128.12.camel@oracle.com> References: <54FF1B4A.9020609@oracle.com> <1426013100.3128.12.camel@oracle.com> Message-ID: <550AD431.608@oracle.com> On 3/10/2015 11:45 AM, Thomas Schatzl wrote: > Hi Jon, > > On Tue, 2015-03-10 at 09:26 -0700, Jon Masamitsu wrote: >> 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads >> >> https://bugs.openjdk.java.net/browse/JDK-8017462 >> >> When fewer than the maximum number of threads was being used for >> a parallel section, phase times for the threads that did not execute and >> averages for the phase were misleading. The fix passes the active number of >> GC threads to the G1 phase timers. >> >> http://cr.openjdk.java.net/~jmasa/8017462/webrev.00/ >> >> Tested with gc_test_suite. > - I would somewhat prefer if _active_threads would not be stored in > every WorkerDataArray. This seems a waste of space. G1GCPhaseTimes > already stores it, so it could easily passed to > WorkerDataArray::verify()/print() instead which seems cleaner to me. > > This would also avoid the additional parameter in > note_string_dedup_fixup_start(). > > - WorkerDataArray::reset() is PRODUCT_RETURN. That means that in a > product VM, WorkerDataArray::_active_length is seemingly never assigned > to then as far as I can see. > > - is it possible to create a test for G1 that runs with > G1LogLevel=finest and parses and verifies output of one GC phase that > takes at least some time? I.e. that you have active_workers amount of > durations in that line and the sum matches more or less. I'd like to address this with a separate CR. Would that be satisfactory? Jon > > - Bengt is currently also changing this code significantly (see the > review for 8074037: Refactor the G1GCPhaseTime logging to make it easier > to add new phases). Somebody will have to do a significant amount of > merging :/ > > Thanks, > Thomas > > From bengt.rutisson at oracle.com Thu Mar 19 14:29:28 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 19 Mar 2015 15:29:28 +0100 Subject: RFR (M): 8027962: Per-phase timing measurements for strong roots processing In-Reply-To: <55097D8E.8070905@oracle.com> References: <1424163777.3163.4.camel@oracle.com> <55096548.5050903@oracle.com> <1426682345.3207.13.camel@oracle.com> <55097806.9050605@oracle.com> <1426684011.5616.7.camel@oracle.com> <55097D8E.8070905@oracle.com> Message-ID: <550ADD48.1050602@oracle.com> Hi again, Mikael just pushed his root scanning changes. Here's a rebased version of my changes: http://cr.openjdk.java.net/~brutisso/8027962/webrev.04/ Thanks, Bengt On 2015-03-18 14:28, Bengt Rutisson wrote: > > Hi Thomas and Mikael, > > Thanks for looking at this! > > On 2015-03-18 14:06, Thomas Schatzl wrote: >> Hi Mikael, >> >> On Wed, 2015-03-18 at 14:05 +0100, Mikael Gerdin wrote: >>> Thomas, >>> >>> On 2015-03-18 13:39, Thomas Schatzl wrote: >>>> Hi Bengt, >>>> >>>> thanks for taking this over... >>>> >>>> On Wed, 2015-03-18 at 12:45 +0100, Bengt Rutisson wrote: >>>>> Hi everyone, >>>>> >>>>> When this was first sent out for review I suggested a couple of >>>>> cleanup >>>>> changes before doing this change. One of the cleanups has been >>>>> pushed: >>>>> >>>>> 8074037: Refactor the G1GCPhaseTime logging to make it easier to >>>>> add new >>>>> phases >>>>> https://bugs.openjdk.java.net/browse/JDK-8074037 >>>>> >>>>> The other one is out for review and is close to being pushed: >>>>> >>>>> 8075210: Refactor strong root processing in order to allow G1 to >>>>> evolve >>>>> separately from GenCollectedHeap >>>>> https://bugs.openjdk.java.net/browse/JDK-8075210 >>>>> >>>>> Based on the above patches, here's an updated webrev to fix 8027962: >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/8027962/webrev.02 >>>>> >>>>> Could I have some reviews for this change? >>>> - G1GCPhaseTimes::note_gc_start does not use the mark_in_progress >>>> parameter any more and can be removed. > > Good catch. I removed the mark_in_progress parameter. > > Here's an updated webrev: > http://cr.openjdk.java.net/~brutisso/8027962/webrev.03/ > > And an incremetal diff compared to the last one: > http://cr.openjdk.java.net/~brutisso/8027962/webrev.02-03.diff/ > >>>> >>>> - this is more some style issue: since we moved all G1 specific root >>>> processing to G1RootProcessor, we actually do not need to pass around >>>> the phase_times parameter any more. >>>> We already assume that the G1GCPhaseTimes instance is global in the >>>> entire G1 code, so code in G1RootProcessor could also just access >>>> it via >>>> the global. >>>> Just store it in a local variable to save typing at the beginning >>>> of the >>>> method. Actually G1RootProcessor::evacuate_roots() does exactly that >>>> unlike process_vm_roots() and process_java_roots(). >>>> It is up to you to decide. >>> The problem is that verification (VerifyBefore/AfterGC) also uses >>> G1RootProcessor, but does not want the phase times reported (at least >>> not in the global phase times instance). >>> So in the end we need some way to determine if we should report the >>> time >>> or not for each root step. >> Okay, I overlooked that. Forget this suggestion then. > > Thanks for sorting this out. > > Bengt > >> >> Thanks, >> Thomas >> >> > From eric.caspole at oracle.com Thu Mar 19 15:29:13 2015 From: eric.caspole at oracle.com (Eric Caspole) Date: Thu, 19 Mar 2015 11:29:13 -0400 Subject: RFR (M): 8027962: Per-phase timing measurements for strong roots processing In-Reply-To: <550ADD48.1050602@oracle.com> References: <1424163777.3163.4.camel@oracle.com> <55096548.5050903@oracle.com> <1426682345.3207.13.camel@oracle.com> <55097806.9050605@oracle.com> <1426684011.5616.7.camel@oracle.com> <55097D8E.8070905@oracle.com> <550ADD48.1050602@oracle.com> Message-ID: <550AEB49.3040005@oracle.com> I like this fine grain accounting. Looks good. Eric On 3/19/2015 10:29 AM, Bengt Rutisson wrote: > > Hi again, > > Mikael just pushed his root scanning changes. > > Here's a rebased version of my changes: > > http://cr.openjdk.java.net/~brutisso/8027962/webrev.04/ > > Thanks, > Bengt > > On 2015-03-18 14:28, Bengt Rutisson wrote: >> >> Hi Thomas and Mikael, >> >> Thanks for looking at this! >> >> On 2015-03-18 14:06, Thomas Schatzl wrote: >>> Hi Mikael, >>> >>> On Wed, 2015-03-18 at 14:05 +0100, Mikael Gerdin wrote: >>>> Thomas, >>>> >>>> On 2015-03-18 13:39, Thomas Schatzl wrote: >>>>> Hi Bengt, >>>>> >>>>> thanks for taking this over... >>>>> >>>>> On Wed, 2015-03-18 at 12:45 +0100, Bengt Rutisson wrote: >>>>>> Hi everyone, >>>>>> >>>>>> When this was first sent out for review I suggested a couple of >>>>>> cleanup >>>>>> changes before doing this change. One of the cleanups has been >>>>>> pushed: >>>>>> >>>>>> 8074037: Refactor the G1GCPhaseTime logging to make it easier to >>>>>> add new >>>>>> phases >>>>>> https://bugs.openjdk.java.net/browse/JDK-8074037 >>>>>> >>>>>> The other one is out for review and is close to being pushed: >>>>>> >>>>>> 8075210: Refactor strong root processing in order to allow G1 to >>>>>> evolve >>>>>> separately from GenCollectedHeap >>>>>> https://bugs.openjdk.java.net/browse/JDK-8075210 >>>>>> >>>>>> Based on the above patches, here's an updated webrev to fix 8027962: >>>>>> >>>>>> http://cr.openjdk.java.net/~brutisso/8027962/webrev.02 >>>>>> >>>>>> Could I have some reviews for this change? >>>>> - G1GCPhaseTimes::note_gc_start does not use the mark_in_progress >>>>> parameter any more and can be removed. >> >> Good catch. I removed the mark_in_progress parameter. >> >> Here's an updated webrev: >> http://cr.openjdk.java.net/~brutisso/8027962/webrev.03/ >> >> And an incremetal diff compared to the last one: >> http://cr.openjdk.java.net/~brutisso/8027962/webrev.02-03.diff/ >> >>>>> >>>>> - this is more some style issue: since we moved all G1 specific root >>>>> processing to G1RootProcessor, we actually do not need to pass around >>>>> the phase_times parameter any more. >>>>> We already assume that the G1GCPhaseTimes instance is global in the >>>>> entire G1 code, so code in G1RootProcessor could also just access >>>>> it via >>>>> the global. >>>>> Just store it in a local variable to save typing at the beginning >>>>> of the >>>>> method. Actually G1RootProcessor::evacuate_roots() does exactly that >>>>> unlike process_vm_roots() and process_java_roots(). >>>>> It is up to you to decide. >>>> The problem is that verification (VerifyBefore/AfterGC) also uses >>>> G1RootProcessor, but does not want the phase times reported (at least >>>> not in the global phase times instance). >>>> So in the end we need some way to determine if we should report the >>>> time >>>> or not for each root step. >>> Okay, I overlooked that. Forget this suggestion then. >> >> Thanks for sorting this out. >> >> Bengt >> >>> >>> Thanks, >>> Thomas >>> >>> >> > From bengt.rutisson at oracle.com Thu Mar 19 15:31:39 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 19 Mar 2015 16:31:39 +0100 Subject: RFR (M): 8027962: Per-phase timing measurements for strong roots processing In-Reply-To: <550AEB49.3040005@oracle.com> References: <1424163777.3163.4.camel@oracle.com> <55096548.5050903@oracle.com> <1426682345.3207.13.camel@oracle.com> <55097806.9050605@oracle.com> <1426684011.5616.7.camel@oracle.com> <55097D8E.8070905@oracle.com> <550ADD48.1050602@oracle.com> <550AEB49.3040005@oracle.com> Message-ID: <550AEBDB.2000902@oracle.com> Hi Eric, On 2015-03-19 16:29, Eric Caspole wrote: > I like this fine grain accounting. Looks good. Thanks for the review! Bengt > Eric > > > On 3/19/2015 10:29 AM, Bengt Rutisson wrote: >> >> Hi again, >> >> Mikael just pushed his root scanning changes. >> >> Here's a rebased version of my changes: >> >> http://cr.openjdk.java.net/~brutisso/8027962/webrev.04/ >> >> Thanks, >> Bengt >> >> On 2015-03-18 14:28, Bengt Rutisson wrote: >>> >>> Hi Thomas and Mikael, >>> >>> Thanks for looking at this! >>> >>> On 2015-03-18 14:06, Thomas Schatzl wrote: >>>> Hi Mikael, >>>> >>>> On Wed, 2015-03-18 at 14:05 +0100, Mikael Gerdin wrote: >>>>> Thomas, >>>>> >>>>> On 2015-03-18 13:39, Thomas Schatzl wrote: >>>>>> Hi Bengt, >>>>>> >>>>>> thanks for taking this over... >>>>>> >>>>>> On Wed, 2015-03-18 at 12:45 +0100, Bengt Rutisson wrote: >>>>>>> Hi everyone, >>>>>>> >>>>>>> When this was first sent out for review I suggested a couple of >>>>>>> cleanup >>>>>>> changes before doing this change. One of the cleanups has been >>>>>>> pushed: >>>>>>> >>>>>>> 8074037: Refactor the G1GCPhaseTime logging to make it easier to >>>>>>> add new >>>>>>> phases >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8074037 >>>>>>> >>>>>>> The other one is out for review and is close to being pushed: >>>>>>> >>>>>>> 8075210: Refactor strong root processing in order to allow G1 to >>>>>>> evolve >>>>>>> separately from GenCollectedHeap >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075210 >>>>>>> >>>>>>> Based on the above patches, here's an updated webrev to fix >>>>>>> 8027962: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~brutisso/8027962/webrev.02 >>>>>>> >>>>>>> Could I have some reviews for this change? >>>>>> - G1GCPhaseTimes::note_gc_start does not use the mark_in_progress >>>>>> parameter any more and can be removed. >>> >>> Good catch. I removed the mark_in_progress parameter. >>> >>> Here's an updated webrev: >>> http://cr.openjdk.java.net/~brutisso/8027962/webrev.03/ >>> >>> And an incremetal diff compared to the last one: >>> http://cr.openjdk.java.net/~brutisso/8027962/webrev.02-03.diff/ >>> >>>>>> >>>>>> - this is more some style issue: since we moved all G1 specific root >>>>>> processing to G1RootProcessor, we actually do not need to pass >>>>>> around >>>>>> the phase_times parameter any more. >>>>>> We already assume that the G1GCPhaseTimes instance is global in the >>>>>> entire G1 code, so code in G1RootProcessor could also just access >>>>>> it via >>>>>> the global. >>>>>> Just store it in a local variable to save typing at the beginning >>>>>> of the >>>>>> method. Actually G1RootProcessor::evacuate_roots() does exactly that >>>>>> unlike process_vm_roots() and process_java_roots(). >>>>>> It is up to you to decide. >>>>> The problem is that verification (VerifyBefore/AfterGC) also uses >>>>> G1RootProcessor, but does not want the phase times reported (at least >>>>> not in the global phase times instance). >>>>> So in the end we need some way to determine if we should report >>>>> the time >>>>> or not for each root step. >>>> Okay, I overlooked that. Forget this suggestion then. >>> >>> Thanks for sorting this out. >>> >>> Bengt >>> >>>> >>>> Thanks, >>>> Thomas >>>> >>>> >>> >> > From kim.barrett at oracle.com Thu Mar 19 17:15:50 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 19 Mar 2015 13:15:50 -0400 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <1426675055.3170.24.camel@oracle.com> References: <1425482904.3305.27.camel@oracle.com> <1425567491.3140.42.camel@oracle.com> <54F96CB2.9060107@oracle.com> <1425898922.3398.35.camel@oracle.com> <1426675055.3170.24.camel@oracle.com> Message-ID: <84EC1DB5-4277-4190-8EA1-E0A6F90BE95C@oracle.com> On Mar 18, 2015, at 6:37 AM, Thomas Schatzl wrote: > > Hi Stefan, Kim, > > could you look at the updated CR again? Also, I need a Reviewer to > look at this. > > Thanks, > Thomas > > On Mon, 2015-03-09 at 12:02 +0100, Thomas Schatzl wrote: >> Hi Stefan, >> >> thanks for the review. >> >> There is a new webrev at >> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.2 (full) >> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.1_to_2 (diff) Sorry about losing track of this. New version looks good. From eric.caspole at oracle.com Thu Mar 19 17:15:51 2015 From: eric.caspole at oracle.com (Eric Caspole) Date: Thu, 19 Mar 2015 13:15:51 -0400 Subject: RFR: JDK-8060017: Report heap sizing time In-Reply-To: <8F0362B7-7F1C-40C4-A5C4-9ADC9C90B392@oracle.com> References: <1B46B485-4F7C-47BC-9B7E-51AE29FD7738@oracle.com> <5509F595.2090307@oracle.com> <8F0362B7-7F1C-40C4-A5C4-9ADC9C90B392@oracle.com> Message-ID: <550B0447.60904@oracle.com> Thanks Kim I simplified this part. http://cr.openjdk.java.net/~ecaspole/JDK-8060017/04/webrev/ Eric On 3/18/2015 6:51 PM, Kim Barrett wrote: > On Mar 18, 2015, at 6:00 PM, Eric Caspole wrote: >> Thanks Kim, >> I fixed the copyrights and a jchecky thing with trailing spaces I did not notice earlier. New one: >> http://cr.openjdk.java.net/~ecaspole/JDK-8060017/03/webrev/ > ------------------------------------------------------------------------------ > src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > 3979 size_t expand_bytes = g1_policy()->expansion_amount(); > 3980 double expand_time_ms = 0.0; > 3981 if (expand_bytes > 0) { > 3982 double expand_heap_start_time_sec = os::elapsedTime(); > 3983 size_t bytes_before = capacity(); > 3984 // No need for an ergo verbose message here, > 3985 // expansion_amount() does this when it returns a value > 0. > 3986 if (!expand(expand_bytes)) { > 3987 // We failed to expand the heap. Cannot do anything about it. > 3988 } > 3989 double expand_heap_end_time_sec = os::elapsedTime(); > 3990 expand_time_ms = (expand_heap_end_time_sec - expand_heap_start_time_sec) * MILLIUNITS; > 3991 } > 3992 g1_policy()->phase_times()->record_expand_heap_time(expand_time_ms); > > [I meant to say something about this in the first round, but forgot. > Sorry about that.] > > Seems like a lot more complicated than it really needs to be, in order > to avoid measuring and reporting the time for expand_bytes == 0. > ------------------------------------------------------------------------------ > From stefan.johansson at oracle.com Fri Mar 20 08:54:37 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 20 Mar 2015 09:54:37 +0100 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <1426675055.3170.24.camel@oracle.com> References: <1425482904.3305.27.camel@oracle.com> <1425567491.3140.42.camel@oracle.com> <54F96CB2.9060107@oracle.com> <1425898922.3398.35.camel@oracle.com> <1426675055.3170.24.camel@oracle.com> Message-ID: <550BE04D.3010009@oracle.com> Hi Thomas, The changes looks good. Thanks, Stefan On 2015-03-18 11:37, Thomas Schatzl wrote: > Hi Stefan, Kim, > > could you look at the updated CR again? Also, I need a Reviewer to > look at this. > > Thanks, > Thomas > > On Mon, 2015-03-09 at 12:02 +0100, Thomas Schatzl wrote: >> Hi Stefan, >> >> thanks for the review. >> >> There is a new webrev at >> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.2 (full) >> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.1_to_2 (diff) >> >> Further comments inline: >> >> On Fri, 2015-03-06 at 10:00 +0100, Stefan Johansson wrote: >>> Hi Thomas, >>> >>> On 2015-03-05 15:58, Thomas Schatzl wrote: >>>> Hi all, >>>> >>>> On Wed, 2015-03-04 at 16:28 +0100, Thomas Schatzl wrote: >>>>> Hi all, >>>>> >>>>> can I have reviews for the following change that does some renamings >>>>> in the allocation related class hierarchy, also adding a few lines of >>>>> documentation. >>>>> >>>>> This change is intentionally limited to renames to keep it simple, in a >>>>> subsequent patch there will be more cleanup changes, moving methods >>>>> around. >>>>> Also, if there is demand, I am open to rename the files to something >>>>> different (suggestions?) in a follow-up change (to not confuse the >>>>> webrev tool too much). >>>>> >>>>> CR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8073052 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.00/ >>>>> Testing: >>>> I talked with Stefan Johansson a bit about the change, with the result >>>> that we keep the name of G1Allocator, since in the upcoming changes (see >>>> below for more) that class is supposed to handle all allocations within >>>> the current allocation regions. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.01 >>> Generally change looks good, but I agree with Kim that PLABAllocator >>> could still use the G1 prefix for consistency. Some other comments: >> Done. >> >>> --- >>> g1CollectedHeap.hpp: >>> + // Allocates a new heap region instance. >>> + virtual HeapRegion* new_heap_region(uint hrs_index, MemRegion mr); >>> >>> No need to have this one virtual, no one extends G1CollectedHeap. >> Done. >> >>> --- >>> vmStructs_g1.hpp: >>> Since _summary_bytes_used have been moved in the native code this needs >>> to be reflected in the Java agent as well. You need to move the >>> functionality from G1Allocator.java to G1CollectedHeap.java. >> Done. >> >> Thanks, >> Thomas >> >> > From sangheon.kim at oracle.com Fri Mar 20 16:44:25 2015 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Fri, 20 Mar 2015 09:44:25 -0700 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <1426675055.3170.24.camel@oracle.com> References: <1425482904.3305.27.camel@oracle.com> <1425567491.3140.42.camel@oracle.com> <54F96CB2.9060107@oracle.com> <1425898922.3398.35.camel@oracle.com> <1426675055.3170.24.camel@oracle.com> Message-ID: <550C4E69.4080807@oracle.com> Hi Thomas, New version looks good. Just copyright year of G1CollectedHeap.java needs update. [openjdk id: sangheki] Thanks, Sangheon On 03/18/2015 03:37 AM, Thomas Schatzl wrote: > Hi Stefan, Kim, > > could you look at the updated CR again? Also, I need a Reviewer to > look at this. > > Thanks, > Thomas > > On Mon, 2015-03-09 at 12:02 +0100, Thomas Schatzl wrote: >> Hi Stefan, >> >> thanks for the review. >> >> There is a new webrev at >> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.2 (full) >> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.1_to_2 (diff) >> >> Further comments inline: >> >> On Fri, 2015-03-06 at 10:00 +0100, Stefan Johansson wrote: >>> Hi Thomas, >>> >>> On 2015-03-05 15:58, Thomas Schatzl wrote: >>>> Hi all, >>>> >>>> On Wed, 2015-03-04 at 16:28 +0100, Thomas Schatzl wrote: >>>>> Hi all, >>>>> >>>>> can I have reviews for the following change that does some renamings >>>>> in the allocation related class hierarchy, also adding a few lines of >>>>> documentation. >>>>> >>>>> This change is intentionally limited to renames to keep it simple, in a >>>>> subsequent patch there will be more cleanup changes, moving methods >>>>> around. >>>>> Also, if there is demand, I am open to rename the files to something >>>>> different (suggestions?) in a follow-up change (to not confuse the >>>>> webrev tool too much). >>>>> >>>>> CR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8073052 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.00/ >>>>> Testing: >>>> I talked with Stefan Johansson a bit about the change, with the result >>>> that we keep the name of G1Allocator, since in the upcoming changes (see >>>> below for more) that class is supposed to handle all allocations within >>>> the current allocation regions. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.01 >>> Generally change looks good, but I agree with Kim that PLABAllocator >>> could still use the G1 prefix for consistency. Some other comments: >> Done. >> >>> --- >>> g1CollectedHeap.hpp: >>> + // Allocates a new heap region instance. >>> + virtual HeapRegion* new_heap_region(uint hrs_index, MemRegion mr); >>> >>> No need to have this one virtual, no one extends G1CollectedHeap. >> Done. >> >>> --- >>> vmStructs_g1.hpp: >>> Since _summary_bytes_used have been moved in the native code this needs >>> to be reflected in the Java agent as well. You need to move the >>> functionality from G1Allocator.java to G1CollectedHeap.java. >> Done. >> >> Thanks, >> Thomas >> >> > From thomas.schatzl at oracle.com Fri Mar 20 19:05:19 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 20 Mar 2015 20:05:19 +0100 Subject: Request for review (XXS) : 8067891 Remove vestigal G1SATBCT barrier set kind In-Reply-To: <54FF51D4.5020609@oracle.com> References: <54FF1B4A.9020609@oracle.com> <54FF1F4B.9090609@oracle.com> <54FF42D5.1080005@oracle.com> <54FF51D4.5020609@oracle.com> Message-ID: <1426878319.3117.2.camel@oracle.com> Hi Joe, On Tue, 2015-03-10 at 16:19 -0400, Joseph Provino wrote: > Indeed my repo was out of date. > > New webrev is here: http://cr.openjdk.java.net/~jprovino/8067891/webrev.02/ > > resubmitting to jprt now. looks good. Thomas From thomas.schatzl at oracle.com Fri Mar 20 19:05:52 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 20 Mar 2015 20:05:52 +0100 Subject: Request for review (s) : 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads In-Reply-To: <550AD431.608@oracle.com> References: <54FF1B4A.9020609@oracle.com> <1426013100.3128.12.camel@oracle.com> <550AD431.608@oracle.com> Message-ID: <1426878352.3117.3.camel@oracle.com> Hi Jon, On Thu, 2015-03-19 at 06:50 -0700, Jon Masamitsu wrote: > On 3/10/2015 11:45 AM, Thomas Schatzl wrote: > > Hi Jon, > > > > On Tue, 2015-03-10 at 09:26 -0700, Jon Masamitsu wrote: > >> 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads > >> > >> https://bugs.openjdk.java.net/browse/JDK-8017462 > >> > >> When fewer than the maximum number of threads was being used for > >> a parallel section, phase times for the threads that did not execute and > >> averages for the phase were misleading. The fix passes the active number of > >> GC threads to the G1 phase timers. > >> > >> http://cr.openjdk.java.net/~jmasa/8017462/webrev.00/ > >> > >> Tested with gc_test_suite. > > - I would somewhat prefer if _active_threads would not be stored in > > every WorkerDataArray. This seems a waste of space. G1GCPhaseTimes > > already store [..] > > - is it possible to create a test for G1 that runs with > > G1LogLevel=finest and parses and verifies output of one GC phase that > > takes at least some time? I.e. that you have active_workers amount of > > durations in that line and the sum matches more or less. > > I'd like to address this with a separate CR. Would that be satisfactory? Okay. Thomas From eric.caspole at oracle.com Fri Mar 20 20:16:11 2015 From: eric.caspole at oracle.com (Eric Caspole) Date: Fri, 20 Mar 2015 16:16:11 -0400 Subject: webrev: thread id in G1GCParPhaseTimesTracker Message-ID: <550C800B.9070002@oracle.com> Hi everybody, Yesterday I was chatting with Bengt about trying to encapsulate the GC worker thread id so it does not have to be explicitly passed in in so many GC methods just to record the timing stats. I made a first cut at this here: http://cr.openjdk.java.net/~ecaspole/phase_time_thread/01/webrev/ More could be done here but I wanted to see if everyone thought it was worth continuing with it. Thanks, Eric From rahul.singh at nectechnologies.in Mon Mar 23 07:34:57 2015 From: rahul.singh at nectechnologies.in (Rahul Kumar Singh) Date: Mon, 23 Mar 2015 07:34:57 +0000 Subject: OpenJDK process is consuming 3 times memory . Message-ID: <12500B1E0820DC4193177DEB4F6A430651A1E321@EXCH-MB-U1.nectechnologies.in> Hi OpenJDK support team, While upgrading Tomcat from tomcat 6(6.0.28) to tomcat 7 (7.0.54). the following problem happens. TOMCAT 7 (7.0.54) memory consumption increased about approx. 3 times compare to the existing tomcat 6 (6.0.28) memory consumption. The underline JVM is java version "1.7.0_09-icedtea" OpenJDK Runtime Environment (rhel-2.3.3.el5.1-x86_64) OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) Tomcat 6.0.28 memory consumption MAP. RESIDENT MEMORY:300-400 MB Approx. Tomcat 7.0.54 memory consumption MAP. RESIDENT MEMORY:900-1800 MB Approx. Underline java platform is same(OpenJDK7) in both tomcat 6 and tomcat 7. Now question is that, why the memory consumption increased about 3 times in Tomcat 7. Regards, Rahul Kumar Singh DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NEC or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NEC or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Mon Mar 23 09:18:02 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 23 Mar 2015 10:18:02 +0100 Subject: webrev: thread id in G1GCParPhaseTimesTracker In-Reply-To: <550C800B.9070002@oracle.com> References: <550C800B.9070002@oracle.com> Message-ID: <550FDA4A.3030208@oracle.com> Hi Eric, On 2015-03-20 21:16, Eric Caspole wrote: > Hi everybody, > Yesterday I was chatting with Bengt about trying to encapsulate the GC > worker thread id so it does not have to be explicitly passed in in so > many GC methods just to record the timing stats. I made a first cut at > this here: > > http://cr.openjdk.java.net/~ecaspole/phase_time_thread/01/webrev/ Thread::current() is not a particularly cheap operation. I think it's worth it to keep the worker_id to keep the overhead of timing measurements to a minimum. /Mikael > > More could be done here but I wanted to see if everyone thought it was > worth continuing with it. > Thanks, > Eric > From bengt.rutisson at oracle.com Mon Mar 23 09:18:07 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 23 Mar 2015 10:18:07 +0100 Subject: webrev: thread id in G1GCParPhaseTimesTracker In-Reply-To: <550FDA4A.3030208@oracle.com> References: <550C800B.9070002@oracle.com> <550FDA4A.3030208@oracle.com> Message-ID: <550FDA4F.4090109@oracle.com> On 2015-03-23 10:18, Mikael Gerdin wrote: > Hi Eric, > > On 2015-03-20 21:16, Eric Caspole wrote: >> Hi everybody, >> Yesterday I was chatting with Bengt about trying to encapsulate the GC >> worker thread id so it does not have to be explicitly passed in in so >> many GC methods just to record the timing stats. I made a first cut at >> this here: >> >> http://cr.openjdk.java.net/~ecaspole/phase_time_thread/01/webrev/ > > Thread::current() is not a particularly cheap operation. > I think it's worth it to keep the worker_id to keep the overhead of > timing measurements to a minimum. I agree. The current way of passing worker ids around in the code is a bit annoying, but it is very light weight. If we want to replace it we need something similarly light weight. Bengt > > /Mikael > >> >> More could be done here but I wanted to see if everyone thought it was >> worth continuing with it. >> Thanks, >> Eric >> From charlie.hunt at oracle.com Mon Mar 23 12:33:53 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Mon, 23 Mar 2015 07:33:53 -0500 Subject: OpenJDK process is consuming 3 times memory . In-Reply-To: <12500B1E0820DC4193177DEB4F6A430651A1E321@EXCH-MB-U1.nectechnologies.in> References: <12500B1E0820DC4193177DEB4F6A430651A1E321@EXCH-MB-U1.nectechnologies.in> Message-ID: <55100831.1050006@oracle.com> An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Mon Mar 23 15:02:04 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 23 Mar 2015 16:02:04 +0100 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <84EC1DB5-4277-4190-8EA1-E0A6F90BE95C@oracle.com> References: <1425482904.3305.27.camel@oracle.com> <1425567491.3140.42.camel@oracle.com> <54F96CB2.9060107@oracle.com> <1425898922.3398.35.camel@oracle.com> <1426675055.3170.24.camel@oracle.com> <84EC1DB5-4277-4190-8EA1-E0A6F90BE95C@oracle.com> Message-ID: <1427122924.3194.79.camel@oracle.com> Hi Kim, Sangheon, Stefan, thanks for your reviews. I still need a Reviewer review for this. I will fix Sangheon's comment about the copyright date with the push if you do not object. Thanks, Thomas On Thu, 2015-03-19 at 13:15 -0400, Kim Barrett wrote: > On Mar 18, 2015, at 6:37 AM, Thomas Schatzl wrote: > > > > Hi Stefan, Kim, > > > > could you look at the updated CR again? Also, I need a Reviewer to > > look at this. > > > > Thanks, > > Thomas > > > > On Mon, 2015-03-09 at 12:02 +0100, Thomas Schatzl wrote: > >> Hi Stefan, > >> > >> thanks for the review. > >> > >> There is a new webrev at > >> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.2 (full) > >> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.1_to_2 (diff) > > Sorry about losing track of this. > > New version looks good. > From thomas.schatzl at oracle.com Mon Mar 23 16:15:22 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 23 Mar 2015 17:15:22 +0100 Subject: RFR: JDK-8060017: Report heap sizing time In-Reply-To: <550B0447.60904@oracle.com> References: <1B46B485-4F7C-47BC-9B7E-51AE29FD7738@oracle.com> <5509F595.2090307@oracle.com> <8F0362B7-7F1C-40C4-A5C4-9ADC9C90B392@oracle.com> <550B0447.60904@oracle.com> Message-ID: <1427127322.3194.99.camel@oracle.com> Hi Eric, On Thu, 2015-03-19 at 13:15 -0400, Eric Caspole wrote: > Thanks Kim I simplified this part. > http://cr.openjdk.java.net/~ecaspole/JDK-8060017/04/webrev/ > Eric - I would prefer instead of repeating the code surrounding the expand() call to introduce a new method like expand_and_track_time() or expand_during_young_gc(). - also, I would somewhat prefer to always print the "Expand Heap" message, at least in detail level finest. Keeping current behavior is not really a problem with me, but this would also make a test easier :) (e.g. expand hotspot/test/gc/g1/TestGCLogMessages.java) - _cur_expand_heap_time_ms seems to be never initialized or reset. At least some cursory testing with small benchmarks suspiciously reports heap expansion times without any expansion actually occurring (e.g. heap size staying the same, and the times themselves being always the same). Thanks, Thomas From jesper.wilhelmsson at oracle.com Mon Mar 23 17:10:15 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 23 Mar 2015 18:10:15 +0100 Subject: RFR: 8075635 - Remove GenerationSpec array Message-ID: <551048F7.3070405@oracle.com> Hi, Please review another follow up after the generation array removal. In this change the array of generation specifications is reduced to two variables in the same way as was done for the generations. The reference to the genSpecs that was previously duplicated in GenCollectedHeap is now only available through the collector policy class. Bug: https://bugs.openjdk.java.net/browse/JDK-8075635 Webrev: http://cr.openjdk.java.net/~jwilhelm/8075635/webrev.00 Thanks! /Jesper From kim.barrett at oracle.com Mon Mar 23 21:59:45 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 23 Mar 2015 17:59:45 -0400 Subject: RFR: 8075635 - Remove GenerationSpec array In-Reply-To: <551048F7.3070405@oracle.com> References: <551048F7.3070405@oracle.com> Message-ID: <2E226390-040C-4E5E-A3C3-967AB6567D35@oracle.com> On Mar 23, 2015, at 1:10 PM, Jesper Wilhelmsson wrote: > > Hi, > > Please review another follow up after the generation array removal. In this change the array of generation specifications is reduced to two variables in the same way as was done for the generations. > > The reference to the genSpecs that was previously duplicated in GenCollectedHeap is now only available through the collector policy class. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075635 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8075635/webrev.00 ------------------------------------------------------------------------------ src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp src/share/vm/memory/collectorPolicy.hpp src/share/vm/memory/generationSpec.hpp Needs copyright update. ------------------------------------------------------------------------------ agent/src/share/classes/sun/jvm/hotspot/memory/GenCollectedHeap.java 131 if (level == 0) { 132 return (GenerationSpec) 133 VMObjectFactory.newObject(GenerationSpec.class, 134 youngGenSpecField.getAddress()); 135 } else { 136 return (GenerationSpec) 137 VMObjectFactory.newObject(GenerationSpec.class, 138 oldGenSpecField.getAddress()); 139 } This is effectively assuming that nGens() == 2, but the earlier assertions in this function don't reflect that assumption. I realize there will probably be further cleanup in this area later, but I'd like things to be in a consistent state at each step in these incremental changes. Similar issue here: src/share/vm/memory/generation.cpp 67 return level() == 0 ? gch->gen_policy()->young_gen_spec() : gch->gen_policy()->old_gen_spec(); ------------------------------------------------------------------------------ src/share/vm/memory/genCollectedHeap.cpp 151 size_t total_reserved = young_spec->max_size() + old_spec->max_size(); 152 if (total_reserved < young_spec->max_size() || 153 total_reserved < old_spec->max_size()) { Not that it's all that important, but either of those comparisons alone should be sufficient to test for overflow. It might also be nice to leave a comment about this being a test for overflow. ------------------------------------------------------------------------------ src/share/vm/memory/generationSpec.hpp 42 GenerationSpec(Generation::Name name, size_t init_size, size_t max_size, size_t alignment) { 43 _name = name; 44 _init_size = align_size_up(init_size, alignment); 45 _max_size = align_size_up(max_size, alignment); 46 } I like that you've eliminated the separate post-construction init_size and max_size alignment step and are instead doing that in the constructor. Is there anything that ensures init_size <= max_size? Should there be an assertion to that effect here? Also consider initializing members in ctor-initializer rather than assignments in the constructor body. ------------------------------------------------------------------------------ From thomas.schatzl at oracle.com Mon Mar 23 22:03:57 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 23 Mar 2015 23:03:57 +0100 Subject: [8u60] RFR backport of 8058801: G1TraceReclaimDeadHumongousObjectsAtYoungGC only prints humongous object liveness output when there is at least one candidate humongous object Message-ID: <1427148237.3117.3.camel@oracle.com> Hi all, can I have reviews for the backport of 8058801: G1TraceReclaimDeadHumongousObjectsAtYoungGC only prints humongous object liveness output when there is at least one candidate humongous object to 8u60? It did only apply with minor changes, so I need re-reviews. The problem has been that in jdk9 isHumongous() (and friends) have been renamed to is_humongous(). Full 8u60 changeset: http://cr.openjdk.java.net/~tschatzl/8058801-8u60/webrev.8u60/ Diff changest: http://cr.openjdk.java.net/~tschatzl/8058801-8u60/webrev.8u60.fix/ CR: https://bugs.openjdk.java.net/browse/JDK-8058801 Original change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/744f961b9393 Testing: jprt Thanks, Thomas From kim.barrett at oracle.com Mon Mar 23 23:14:47 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 23 Mar 2015 19:14:47 -0400 Subject: [8u60] RFR backport of 8058801: G1TraceReclaimDeadHumongousObjectsAtYoungGC only prints humongous object liveness output when there is at least one candidate humongous object In-Reply-To: <1427148237.3117.3.camel@oracle.com> References: <1427148237.3117.3.camel@oracle.com> Message-ID: On Mar 23, 2015, at 6:03 PM, Thomas Schatzl wrote: > > Hi all, > > can I have reviews for the backport of 8058801: > G1TraceReclaimDeadHumongousObjectsAtYoungGC only prints humongous object > liveness output when there is at least one candidate humongous object to > 8u60? > > It did only apply with minor changes, so I need re-reviews. The problem > has been that in jdk9 isHumongous() (and friends) have been renamed to > is_humongous(). > > Full 8u60 changeset: > http://cr.openjdk.java.net/~tschatzl/8058801-8u60/webrev.8u60/ > Diff changest: > http://cr.openjdk.java.net/~tschatzl/8058801-8u60/webrev.8u60.fix/ > > CR: > https://bugs.openjdk.java.net/browse/JDK-8058801 > > Original change: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/744f961b9393 > > Testing: jprt Changes look good. Should there be a backport bug for this? Should backports have up to date copyrights? It would be kind of annoying if they do. From marcus.larsson at oracle.com Tue Mar 24 06:34:48 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 23 Mar 2015 23:34:48 -0700 (PDT) Subject: RFR: 8065331: Add JVM trace events for failed allocations Message-ID: <711efabb-7363-4db8-8479-c5ac2518c548@default> Hi, Please review the following patch adding new trace events for allocations requiring GC, and GCs triggered by allocation. See the JEP for a description of these two new events. CR: https://bugs.openjdk.java.net/browse/JDK-8065331 Webrev: http://cr.openjdk.java.net/~mlarsson/8065331/webrev.00/ JEP: https://bugs.openjdk.java.net/browse/JDK-8060092 Tests: jprt, jtreg Thanks, Marcus From thomas.schatzl at oracle.com Tue Mar 24 07:59:35 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 24 Mar 2015 08:59:35 +0100 Subject: [8u60] RFR backport of 8058801: G1TraceReclaimDeadHumongousObjectsAtYoungGC only prints humongous object liveness output when there is at least one candidate humongous object In-Reply-To: References: <1427148237.3117.3.camel@oracle.com> Message-ID: <1427183975.3133.0.camel@oracle.com> Hi, On Mon, 2015-03-23 at 19:14 -0400, Kim Barrett wrote: > On Mar 23, 2015, at 6:03 PM, Thomas Schatzl wrote: > > > > Hi all, > > > > can I have reviews for the backport of 8058801: > > G1TraceReclaimDeadHumongousObjectsAtYoungGC only prints humongous object > > liveness output when there is at least one candidate humongous object to > > 8u60? > > > > It did only apply with minor changes, so I need re-reviews. The problem > > has been that in jdk9 isHumongous() (and friends) have been renamed to > > is_humongous(). > > > > Full 8u60 changeset: > > http://cr.openjdk.java.net/~tschatzl/8058801-8u60/webrev.8u60/ > > Diff changest: > > http://cr.openjdk.java.net/~tschatzl/8058801-8u60/webrev.8u60.fix/ > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8058801 > > > > Original change: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/744f961b9393 > > > > Testing: jprt > > Changes look good. > > Should there be a backport bug for this? They will be automatically created when pushing. > Should backports have up to date copyrights? It would be kind of annoying if they do. Afaik no. Thanks, Thomas From bengt.rutisson at oracle.com Tue Mar 24 09:18:22 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 24 Mar 2015 10:18:22 +0100 Subject: [8u60] RFR backport of 8058801: G1TraceReclaimDeadHumongousObjectsAtYoungGC only prints humongous object liveness output when there is at least one candidate humongous object In-Reply-To: <1427148237.3117.3.camel@oracle.com> References: <1427148237.3117.3.camel@oracle.com> Message-ID: <55112BDE.9070802@oracle.com> On 2015-03-23 23:03, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the backport of 8058801: > G1TraceReclaimDeadHumongousObjectsAtYoungGC only prints humongous object > liveness output when there is at least one candidate humongous object to > 8u60? > > It did only apply with minor changes, so I need re-reviews. The problem > has been that in jdk9 isHumongous() (and friends) have been renamed to > is_humongous(). > > Full 8u60 changeset: > http://cr.openjdk.java.net/~tschatzl/8058801-8u60/webrev.8u60/ > Diff changest: > http://cr.openjdk.java.net/~tschatzl/8058801-8u60/webrev.8u60.fix/ Looks good. Bengt > > CR: > https://bugs.openjdk.java.net/browse/JDK-8058801 > > Original change: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/744f961b9393 > > Testing: jprt > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Tue Mar 24 09:42:41 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 24 Mar 2015 10:42:41 +0100 Subject: [8u60] RFR backport of 8058801: G1TraceReclaimDeadHumongousObjectsAtYoungGC only prints humongous object liveness output when there is at least one candidate humongous object In-Reply-To: <55112BDE.9070802@oracle.com> References: <1427148237.3117.3.camel@oracle.com> <55112BDE.9070802@oracle.com> Message-ID: <1427190161.3133.26.camel@oracle.com> Hi Bengt, On Tue, 2015-03-24 at 10:18 +0100, Bengt Rutisson wrote: > On 2015-03-23 23:03, Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for the backport of 8058801: > > G1TraceReclaimDeadHumongousObjectsAtYoungGC only prints humongous object > > liveness output when there is at least one candidate humongous object to > > 8u60? > > > > It did only apply with minor changes, so I need re-reviews. The problem > > has been that in jdk9 isHumongous() (and friends) have been renamed to > > is_humongous(). > > > > Full 8u60 changeset: > > http://cr.openjdk.java.net/~tschatzl/8058801-8u60/webrev.8u60/ > > Diff changest: > > http://cr.openjdk.java.net/~tschatzl/8058801-8u60/webrev.8u60.fix/ > > Looks good. thanks for the review. Thomas From thomas.schatzl at oracle.com Tue Mar 24 10:56:03 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 24 Mar 2015 11:56:03 +0100 Subject: RFR: JDK-8060017: Report heap sizing time In-Reply-To: <1427127322.3194.99.camel@oracle.com> References: <1B46B485-4F7C-47BC-9B7E-51AE29FD7738@oracle.com> <5509F595.2090307@oracle.com> <8F0362B7-7F1C-40C4-A5C4-9ADC9C90B392@oracle.com> <550B0447.60904@oracle.com> <1427127322.3194.99.camel@oracle.com> Message-ID: <1427194563.3133.34.camel@oracle.com> Hi again, On Mon, 2015-03-23 at 17:15 +0100, Thomas Schatzl wrote: > Hi Eric, > > On Thu, 2015-03-19 at 13:15 -0400, Eric Caspole wrote: > > Thanks Kim I simplified this part. > > http://cr.openjdk.java.net/~ecaspole/JDK-8060017/04/webrev/ > > Eric > > - I would prefer instead of repeating the code surrounding the > expand() call to introduce a new method like expand_and_track_time() or > expand_during_young_gc(). > > - also, I would somewhat prefer to always print the "Expand Heap" > message, at least in detail level finest. Keeping current behavior is > not really a problem with me, but this would also make a test easier :) > (e.g. expand hotspot/test/gc/g1/TestGCLogMessages.java) > > - _cur_expand_heap_time_ms seems to be never initialized or reset. At > least some cursory testing with small benchmarks suspiciously reports > heap expansion times without any expansion actually occurring (e.g. heap > size staying the same, and the times themselves being always the same). thinking about the change a bit more, I think the current way the heap expansion time is presented is confusing: it simply adds together all heap expansion time ever incurred. However, in our printing we assume that indented times are parts of the upper level time. E.g. [Other: 10ms] [Expand Heap: 8ms] means that out of 10ms of Other time, Expand Heap took 8ms outside of the main evacuation task (what is called "Parallel Time" at the moment). This can go as far as the reported "Expand Heap" time being larger than the Other time. I would prefer if the current scheme would be kept, and "Expand Heap" times reported separately for the phases they are incurred. I.e. one "Expand Heap" time for heap expansion after GC, and per-thread timings during the parallel GC phase. An option would be to for now just record the heap expansion time to heap expansion after GC in the VM thread. Thanks, Thomas From michail.chernov at oracle.com Tue Mar 24 11:22:49 2015 From: michail.chernov at oracle.com (Michail Chernov) Date: Tue, 24 Mar 2015 14:22:49 +0300 Subject: [8u60] Request for backport approval: 8055416 Several vm/gc/heap/summary "After GC" events emitted for the same GC ID Message-ID: <55114909.9000409@oracle.com> Dear colleagues, I'd like to get approval to backport changes from JDK9 to 8u. Webrev: http://cr.openjdk.java.net/~eistepan/~mchernov/8055416/webrev.00/ Original issue was fixed and approved at August 2014. Here is the mail thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-August/010549.html JDK9 webrev: http://cr.openjdk.java.net/~stefank/8055416/webrev.00/ Original bug is https://bugs.openjdk.java.net/browse/JDK-8055416 Testing: JDK with changes was built locally. Closed JFR test has passed. Thanks, Michail From stefan.karlsson at oracle.com Tue Mar 24 13:03:42 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 24 Mar 2015 14:03:42 +0100 Subject: RFR: 8075803: Fix GC includes and forward declarations Message-ID: <551160AE.1090705@oracle.com> Hi, Please review this patch to fix some includes and forward declarations of GC specific files and types. These issues were found while working on a patch to restructure parts of the oop_oop_iterate code. http://cr.openjdk.java.net/~stefank/8075803/webrev.01 https://bugs.openjdk.java.net/browse/JDK-8075803 A list of the the changes: http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp.udiff.html - Missing forward declarations http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp.udiff.html - Missing forward declarations - Missing include of cmsOopClosures.hpp - Uses MetadataAwareOopsInGenClosure http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/g1/concurrentMark.hpp.udiff.html - Missing forward declarations http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp.udiff.html - Missing forward declarations http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parNew/parNewGeneration.hpp.udiff.html - Missing include of parNewGeneration.hpp - Uses ParScanClosure http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp.udiff.html - Missing include of genOopClosures.inline.hpp -- Uses OopsInKlassOrGenClosure::do_klass_barrier http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp.udiff.html - Missing include of parallelScavengeHeap.hpp - Using ParallelScavengeHeap http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/oops/cpCache.cpp.udiff.html - Unnecessary include of psPromotionManager.hpp http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp.udiff.html - Unnecessary include of markSweep.inline.hpp http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp.udiff.html - Unnecessary include of markSweep.hpp http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/shared/markSweep.hpp.udiff.html - Unnecessary include of universe.hpp - Missing include of genOopClosure.hpp - Uses OopsInGenClosure - Missing include of iterator.hpp - Uses ExtendedOopClosure - Moved PreservedMark functions from markSweep.hpp into markSweep.cpp - Needed to get rid of warning about adjust_pointer being used but not defined. http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/memory/space.cpp.udiff.html - Unnecessary include of markSweep.hpp http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/memory/defNewGeneration.inline.hpp.udiff.html - Missing include of collectedHeap.hpp - Uses CollectedHeap - Missing include of genOopClosures.inline.hpp - Uses ScanWeakRefClosure::do_oop_nv Thanks, StefanK From stefan.karlsson at oracle.com Tue Mar 24 13:11:29 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 24 Mar 2015 14:11:29 +0100 Subject: RFR: 8075809: Add missing includes of stack.inline.hpp Message-ID: <55116281.9080209@oracle.com> Hi, Please review this patch to add some missing includes of stack.inline.hpp. http://cr.openjdk.java.net/~stefank/8075809/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8075809 Thanks, StefanK From thomas.schatzl at oracle.com Tue Mar 24 14:49:38 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 24 Mar 2015 15:49:38 +0100 Subject: [8u60] RFR backport of 8065358: Refactor G1s usage of save_marks and reduce related races Message-ID: <1427208578.3133.52.camel@oracle.com> Hi all, can I have reviews for the backport of "8065358: Refactor G1s usage of save_marks and reduce related races" to 8u60? It is a change that eases backporting the next change, 8060025. It did only apply with minor changes, so I need re-reviews. The problem has been that in jdk9 isHumongous() (and friends) have been renamed to is_humongous() (in g1Allocator.cpp), and there is a typo fix in a comment (behaviour -> behavior, second hunk in heapRegion.cpp). Full 8u60 changeset: http://cr.openjdk.java.net/~tschatzl/8065358-8u60/webrev.8u60/ Diff changest: http://cr.openjdk.java.net/~tschatzl/8065358-8u60/webrev.8u60.fix/ CR: https://bugs.openjdk.java.net/browse/JDK-8065358 Original change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/760030342f09 Testing: jprt Thanks, Thomas From jesper.wilhelmsson at oracle.com Tue Mar 24 14:59:33 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 24 Mar 2015 15:59:33 +0100 Subject: [8u60] RFR backport of 8065358: Refactor G1s usage of save_marks and reduce related races In-Reply-To: <1427208578.3133.52.camel@oracle.com> References: <1427208578.3133.52.camel@oracle.com> Message-ID: <55117BD5.6050806@oracle.com> Looks good. /Jesper Thomas Schatzl skrev den 24/3/15 15:49: > Hi all, > > can I have reviews for the backport of "8065358: Refactor G1s usage of > save_marks and reduce related races" to 8u60? > > It is a change that eases backporting the next change, 8060025. > > It did only apply with minor changes, so I need re-reviews. The problem > has been that in jdk9 isHumongous() (and friends) have been renamed to > is_humongous() (in g1Allocator.cpp), and there is a typo fix in a > comment (behaviour -> behavior, second hunk in heapRegion.cpp). > > Full 8u60 changeset: > http://cr.openjdk.java.net/~tschatzl/8065358-8u60/webrev.8u60/ > Diff changest: > http://cr.openjdk.java.net/~tschatzl/8065358-8u60/webrev.8u60.fix/ > > CR: > https://bugs.openjdk.java.net/browse/JDK-8065358 > > Original change: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/760030342f09 > > Testing: jprt > > Thanks, > Thomas > > From per.liden at oracle.com Tue Mar 24 15:30:48 2015 From: per.liden at oracle.com (Per Liden) Date: Tue, 24 Mar 2015 16:30:48 +0100 Subject: RFR: 8075803: Fix GC includes and forward declarations In-Reply-To: <551160AE.1090705@oracle.com> References: <551160AE.1090705@oracle.com> Message-ID: <55118328.5090002@oracle.com> Looks good! /Per On 2015-03-24 14:03, Stefan Karlsson wrote: > Hi, > > Please review this patch to fix some includes and forward declarations > of GC specific files and types. These issues were found while working on > a patch to restructure parts of the oop_oop_iterate code. > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01 > https://bugs.openjdk.java.net/browse/JDK-8075803 > > A list of the the changes: > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp.udiff.html > > > - Missing forward declarations > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp.udiff.html > > > - Missing forward declarations > - Missing include of cmsOopClosures.hpp > - Uses MetadataAwareOopsInGenClosure > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/g1/concurrentMark.hpp.udiff.html > > > - Missing forward declarations > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp.udiff.html > > > - Missing forward declarations > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parNew/parNewGeneration.hpp.udiff.html > > > - Missing include of parNewGeneration.hpp > - Uses ParScanClosure > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp.udiff.html > > > - Missing include of genOopClosures.inline.hpp > -- Uses OopsInKlassOrGenClosure::do_klass_barrier > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp.udiff.html > > > - Missing include of parallelScavengeHeap.hpp > - Using ParallelScavengeHeap > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/oops/cpCache.cpp.udiff.html > > > - Unnecessary include of psPromotionManager.hpp > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp.udiff.html > > > - Unnecessary include of markSweep.inline.hpp > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp.udiff.html > > > - Unnecessary include of markSweep.hpp > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/shared/markSweep.hpp.udiff.html > > > - Unnecessary include of universe.hpp > > - Missing include of genOopClosure.hpp > - Uses OopsInGenClosure > > - Missing include of iterator.hpp > - Uses ExtendedOopClosure > > - Moved PreservedMark functions from markSweep.hpp into markSweep.cpp > - Needed to get rid of warning about adjust_pointer being used but not > defined. > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/memory/space.cpp.udiff.html > > > - Unnecessary include of markSweep.hpp > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/memory/defNewGeneration.inline.hpp.udiff.html > > > - Missing include of collectedHeap.hpp > - Uses CollectedHeap > > - Missing include of genOopClosures.inline.hpp > - Uses ScanWeakRefClosure::do_oop_nv > > Thanks, > StefanK From per.liden at oracle.com Tue Mar 24 15:31:50 2015 From: per.liden at oracle.com (Per Liden) Date: Tue, 24 Mar 2015 16:31:50 +0100 Subject: RFR: 8075809: Add missing includes of stack.inline.hpp In-Reply-To: <55116281.9080209@oracle.com> References: <55116281.9080209@oracle.com> Message-ID: <55118366.7060002@oracle.com> Looks good! /Per On 2015-03-24 14:11, Stefan Karlsson wrote: > Hi, > > Please review this patch to add some missing includes of stack.inline.hpp. > > http://cr.openjdk.java.net/~stefank/8075809/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8075809 > > Thanks, > StefanK From stefan.karlsson at oracle.com Tue Mar 24 15:34:28 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 24 Mar 2015 16:34:28 +0100 Subject: RFR: 8075803: Fix GC includes and forward declarations In-Reply-To: <55118328.5090002@oracle.com> References: <551160AE.1090705@oracle.com> <55118328.5090002@oracle.com> Message-ID: <55118404.30605@oracle.com> On 2015-03-24 16:30, Per Liden wrote: > Looks good! Thanks, Per! StefanK > > /Per > > On 2015-03-24 14:03, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to fix some includes and forward declarations >> of GC specific files and types. These issues were found while working on >> a patch to restructure parts of the oop_oop_iterate code. >> >> http://cr.openjdk.java.net/~stefank/8075803/webrev.01 >> https://bugs.openjdk.java.net/browse/JDK-8075803 >> >> A list of the the changes: >> >> http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp.udiff.html >> >> >> >> - Missing forward declarations >> >> >> http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp.udiff.html >> >> >> >> - Missing forward declarations >> - Missing include of cmsOopClosures.hpp >> - Uses MetadataAwareOopsInGenClosure >> >> >> http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/g1/concurrentMark.hpp.udiff.html >> >> >> >> - Missing forward declarations >> >> >> http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp.udiff.html >> >> >> >> - Missing forward declarations >> >> >> http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parNew/parNewGeneration.hpp.udiff.html >> >> >> >> - Missing include of parNewGeneration.hpp >> - Uses ParScanClosure >> >> >> http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp.udiff.html >> >> >> >> - Missing include of genOopClosures.inline.hpp >> -- Uses OopsInKlassOrGenClosure::do_klass_barrier >> >> >> http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp.udiff.html >> >> >> >> - Missing include of parallelScavengeHeap.hpp >> - Using ParallelScavengeHeap >> >> >> http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/oops/cpCache.cpp.udiff.html >> >> >> >> - Unnecessary include of psPromotionManager.hpp >> >> >> http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp.udiff.html >> >> >> >> - Unnecessary include of markSweep.inline.hpp >> >> >> http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp.udiff.html >> >> >> >> - Unnecessary include of markSweep.hpp >> >> >> http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/shared/markSweep.hpp.udiff.html >> >> >> >> - Unnecessary include of universe.hpp >> >> - Missing include of genOopClosure.hpp >> - Uses OopsInGenClosure >> >> - Missing include of iterator.hpp >> - Uses ExtendedOopClosure >> >> - Moved PreservedMark functions from markSweep.hpp into markSweep.cpp >> - Needed to get rid of warning about adjust_pointer being used but not >> defined. >> >> >> http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/memory/space.cpp.udiff.html >> >> >> >> - Unnecessary include of markSweep.hpp >> >> >> http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/memory/defNewGeneration.inline.hpp.udiff.html >> >> >> >> - Missing include of collectedHeap.hpp >> - Uses CollectedHeap >> >> - Missing include of genOopClosures.inline.hpp >> - Uses ScanWeakRefClosure::do_oop_nv >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Tue Mar 24 15:34:42 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 24 Mar 2015 16:34:42 +0100 Subject: RFR: 8075809: Add missing includes of stack.inline.hpp In-Reply-To: <55118366.7060002@oracle.com> References: <55116281.9080209@oracle.com> <55118366.7060002@oracle.com> Message-ID: <55118412.6010801@oracle.com> On 2015-03-24 16:31, Per Liden wrote: > Looks good! Thanks, Per! StefanK > > /Per > > On 2015-03-24 14:11, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to add some missing includes of >> stack.inline.hpp. >> >> http://cr.openjdk.java.net/~stefank/8075809/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8075809 >> >> Thanks, >> StefanK From jesper.wilhelmsson at oracle.com Tue Mar 24 16:27:18 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 24 Mar 2015 17:27:18 +0100 Subject: RFR: 8075635 - Remove GenerationSpec array In-Reply-To: <2E226390-040C-4E5E-A3C3-967AB6567D35@oracle.com> References: <551048F7.3070405@oracle.com> <2E226390-040C-4E5E-A3C3-967AB6567D35@oracle.com> Message-ID: <55119066.3070802@oracle.com> Hi Kim, Thanks for reviewing! A new webrev is available here: http://cr.openjdk.java.net/~jwilhelm/8075635/webrev.01/hotspot/ Latest increment: http://cr.openjdk.java.net/~jwilhelm/8075635/webrev.01/hotspot_incremental/ Comments inline. Kim Barrett skrev den 23/3/15 22:59: > On Mar 23, 2015, at 1:10 PM, Jesper Wilhelmsson wrote: >> >> Hi, >> >> Please review another follow up after the generation array removal. In this change the array of generation specifications is reduced to two variables in the same way as was done for the generations. >> >> The reference to the genSpecs that was previously duplicated in GenCollectedHeap is now only available through the collector policy class. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075635 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8075635/webrev.00 > > ------------------------------------------------------------------------------ > src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp > src/share/vm/memory/collectorPolicy.hpp > src/share/vm/memory/generationSpec.hpp > > Needs copyright update. Fixed. > ------------------------------------------------------------------------------ > agent/src/share/classes/sun/jvm/hotspot/memory/GenCollectedHeap.java > 131 if (level == 0) { > 132 return (GenerationSpec) > 133 VMObjectFactory.newObject(GenerationSpec.class, > 134 youngGenSpecField.getAddress()); > 135 } else { > 136 return (GenerationSpec) > 137 VMObjectFactory.newObject(GenerationSpec.class, > 138 oldGenSpecField.getAddress()); > 139 } > > This is effectively assuming that nGens() == 2, but the earlier > assertions in this function don't reflect that assumption. I realize > there will probably be further cleanup in this area later, but I'd > like things to be in a consistent state at each step in these > incremental changes. I changed the existing assert to look for 0 or 1 rather than using nGens(). This is the same approach as we used in the last change that changed the assert in a method a few lines above this one. > > Similar issue here: > src/share/vm/memory/generation.cpp > 67 return level() == 0 ? gch->gen_policy()->young_gen_spec() : gch->gen_policy()->old_gen_spec(); Same change here. > > ------------------------------------------------------------------------------ > src/share/vm/memory/genCollectedHeap.cpp > 151 size_t total_reserved = young_spec->max_size() + old_spec->max_size(); > 152 if (total_reserved < young_spec->max_size() || > 153 total_reserved < old_spec->max_size()) { > > Not that it's all that important, but either of those comparisons > alone should be sufficient to test for overflow. It might also be > nice to leave a comment about this being a test for overflow. Yes, you are right. You are most likely the first one to give this code enough thought to realize this. Good catch! I cleaned up this code a bit in the new version. > ------------------------------------------------------------------------------ > src/share/vm/memory/generationSpec.hpp > 42 GenerationSpec(Generation::Name name, size_t init_size, size_t max_size, size_t alignment) { > 43 _name = name; > 44 _init_size = align_size_up(init_size, alignment); > 45 _max_size = align_size_up(max_size, alignment); > 46 } > > I like that you've eliminated the separate post-construction init_size > and max_size alignment step and are instead doing that in the > constructor. > > Is there anything that ensures init_size <= max_size? Should there be > an assertion to that effect here? This is verified in the collector policy code where initial and max sizes are set up. I wouldn't object to having an assert here if you feel strongly about it. On the other hand we have a quite extensive set off asserts in GenCollectorPolicy::assert_flags() and GenCollectorPolicy::assert_size_info() to make sure this stuff is correct already. > > Also consider initializing members in ctor-initializer rather than > assignments in the constructor body. Fixed. Thanks! /Jesper From stefan.karlsson at oracle.com Tue Mar 24 16:33:16 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 24 Mar 2015 17:33:16 +0100 Subject: RFR: 8075829: Move CSpaceCounters implementation to cSpaceCounters.cpp Message-ID: <551191CC.6060604@oracle.com> Hi, Please review this patch to reduce the dependency against space.inline.hpp in cSpaceCounters.hpp. - The update_* functions are not called frequently and doesn't have to be inlined. - The take_sample() function is called as a virtual call, and doesn't need to be inlined. - The change in cSpaceCounters.hpp to include space.hpp instead of space.inline.hpp, causes some files to no longer include space.inline.hpp. If one of these files use the Space class but doesn't include space.inline.hpp we get a compile error stating that block_start is used but never defined, even when the block_start function isn't used from that file. To solve that, the 'inline' keyword is removed from the declaration, but kept at the definition. The compiler will not complain about missing definition of block_start if space.inline.hpp isn't included, but the linker will. The compiler will still be able to inline the function. http://cr.openjdk.java.net/~stefank/8075829/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8075829 Thanks, StefanK From mikael.gerdin at oracle.com Tue Mar 24 16:40:14 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 24 Mar 2015 17:40:14 +0100 Subject: [8u60] RFR backport of 8065358: Refactor G1s usage of save_marks and reduce related races In-Reply-To: <1427208578.3133.52.camel@oracle.com> References: <1427208578.3133.52.camel@oracle.com> Message-ID: <5511936E.2090205@oracle.com> Hi Thomas, On 2015-03-24 15:49, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the backport of "8065358: Refactor G1s usage of > save_marks and reduce related races" to 8u60? > > It is a change that eases backporting the next change, 8060025. > > It did only apply with minor changes, so I need re-reviews. The problem > has been that in jdk9 isHumongous() (and friends) have been renamed to > is_humongous() (in g1Allocator.cpp), and there is a typo fix in a > comment (behaviour -> behavior, second hunk in heapRegion.cpp). > > Full 8u60 changeset: > http://cr.openjdk.java.net/~tschatzl/8065358-8u60/webrev.8u60/ > Diff changest: > http://cr.openjdk.java.net/~tschatzl/8065358-8u60/webrev.8u60.fix/ Looks good to me. /Mikael > > CR: > https://bugs.openjdk.java.net/browse/JDK-8065358 > > Original change: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/760030342f09 > > Testing: jprt > > Thanks, > Thomas > > From jesper.wilhelmsson at oracle.com Tue Mar 24 16:42:27 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 24 Mar 2015 17:42:27 +0100 Subject: RFR: 8075829: Move CSpaceCounters implementation to cSpaceCounters.cpp In-Reply-To: <551191CC.6060604@oracle.com> References: <551191CC.6060604@oracle.com> Message-ID: <551193F3.60603@oracle.com> Looks good. /Jesper Stefan Karlsson skrev den 24/3/15 17:33: > Hi, > > Please review this patch to reduce the dependency against space.inline.hpp in > cSpaceCounters.hpp. > > - The update_* functions are not called frequently and doesn't have to be inlined. > > - The take_sample() function is called as a virtual call, and doesn't need to be > inlined. > > - The change in cSpaceCounters.hpp to include space.hpp instead of > space.inline.hpp, causes some files to no longer include space.inline.hpp. If > one of these files use the Space class but doesn't include space.inline.hpp we > get a compile error stating that block_start is used but never defined, even > when the block_start function isn't used from that file. To solve that, the > 'inline' keyword is removed from the declaration, but kept at the definition. > The compiler will not complain about missing definition of block_start if > space.inline.hpp isn't included, but the linker will. The compiler will still be > able to inline the function. > > http://cr.openjdk.java.net/~stefank/8075829/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8075829 > > Thanks, > StefanK From jon.masamitsu at oracle.com Tue Mar 24 18:01:43 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 24 Mar 2015 11:01:43 -0700 Subject: RFR: 8075809: Add missing includes of stack.inline.hpp In-Reply-To: <55116281.9080209@oracle.com> References: <55116281.9080209@oracle.com> Message-ID: <5511A687.20702@oracle.com> Update copyright on http://cr.openjdk.java.net/~stefank/8075809/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp.frames.html Otherwise, looks good. Reviewed. I don't need a re-review. Jon On 3/24/2015 6:11 AM, Stefan Karlsson wrote: > Hi, > > Please review this patch to add some missing includes of > stack.inline.hpp. > > http://cr.openjdk.java.net/~stefank/8075809/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8075809 > > Thanks, > StefanK From kim.barrett at oracle.com Tue Mar 24 20:10:53 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 24 Mar 2015 16:10:53 -0400 Subject: RFR: 8075635 - Remove GenerationSpec array In-Reply-To: <55119066.3070802@oracle.com> References: <551048F7.3070405@oracle.com> <2E226390-040C-4E5E-A3C3-967AB6567D35@oracle.com> <55119066.3070802@oracle.com> Message-ID: <8F7EAC00-D8E3-4705-A1AA-6DCEF0FAF330@oracle.com> On Mar 24, 2015, at 12:27 PM, Jesper Wilhelmsson wrote: > > Hi Kim, > > Thanks for reviewing! > > A new webrev is available here: > http://cr.openjdk.java.net/~jwilhelm/8075635/webrev.01/hotspot/ > > Latest increment: > http://cr.openjdk.java.net/~jwilhelm/8075635/webrev.01/hotspot_incremental/ Looks good. > > Comments inline. > > Kim Barrett skrev den 23/3/15 22:59: >> ------------------------------------------------------------------------------ >> src/share/vm/memory/generationSpec.hpp >> 42 GenerationSpec(Generation::Name name, size_t init_size, size_t max_size, size_t alignment) { >> 43 _name = name; >> 44 _init_size = align_size_up(init_size, alignment); >> 45 _max_size = align_size_up(max_size, alignment); >> 46 } >> >> I like that you've eliminated the separate post-construction init_size >> and max_size alignment step and are instead doing that in the >> constructor. >> >> Is there anything that ensures init_size <= max_size? Should there be >> an assertion to that effect here? > > This is verified in the collector policy code where initial and max sizes are set up. I wouldn't object to having an assert here if you feel strongly about it. On the other hand we have a quite extensive set off asserts in GenCollectorPolicy::assert_flags() and GenCollectorPolicy::assert_size_info() to make sure this stuff is correct already. Existing checks seem sufficient. From jesper.wilhelmsson at oracle.com Tue Mar 24 20:23:07 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 24 Mar 2015 21:23:07 +0100 Subject: RFR: 8075635 - Remove GenerationSpec array In-Reply-To: <8F7EAC00-D8E3-4705-A1AA-6DCEF0FAF330@oracle.com> References: <551048F7.3070405@oracle.com> <2E226390-040C-4E5E-A3C3-967AB6567D35@oracle.com> <55119066.3070802@oracle.com> <8F7EAC00-D8E3-4705-A1AA-6DCEF0FAF330@oracle.com> Message-ID: <5511C7AB.3020201@oracle.com> Thanks! /Jesper Kim Barrett skrev den 24/3/15 21:10: > On Mar 24, 2015, at 12:27 PM, Jesper Wilhelmsson wrote: >> >> Hi Kim, >> >> Thanks for reviewing! >> >> A new webrev is available here: >> http://cr.openjdk.java.net/~jwilhelm/8075635/webrev.01/hotspot/ >> >> Latest increment: >> http://cr.openjdk.java.net/~jwilhelm/8075635/webrev.01/hotspot_incremental/ > > Looks good. > >> >> Comments inline. >> >> Kim Barrett skrev den 23/3/15 22:59: >>> ------------------------------------------------------------------------------ >>> src/share/vm/memory/generationSpec.hpp >>> 42 GenerationSpec(Generation::Name name, size_t init_size, size_t max_size, size_t alignment) { >>> 43 _name = name; >>> 44 _init_size = align_size_up(init_size, alignment); >>> 45 _max_size = align_size_up(max_size, alignment); >>> 46 } >>> >>> I like that you've eliminated the separate post-construction init_size >>> and max_size alignment step and are instead doing that in the >>> constructor. >>> >>> Is there anything that ensures init_size <= max_size? Should there be >>> an assertion to that effect here? >> >> This is verified in the collector policy code where initial and max sizes are set up. I wouldn't object to having an assert here if you feel strongly about it. On the other hand we have a quite extensive set off asserts in GenCollectorPolicy::assert_flags() and GenCollectorPolicy::assert_size_info() to make sure this stuff is correct already. > > Existing checks seem sufficient. > > From bengt.rutisson at oracle.com Wed Mar 25 08:19:44 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 25 Mar 2015 09:19:44 +0100 Subject: RFR: 8075829: Move CSpaceCounters implementation to cSpaceCounters.cpp In-Reply-To: <551191CC.6060604@oracle.com> References: <551191CC.6060604@oracle.com> Message-ID: <55126FA0.1000109@oracle.com> Hi Stefan, On 2015-03-24 17:33, Stefan Karlsson wrote: > Hi, > > Please review this patch to reduce the dependency against > space.inline.hpp in cSpaceCounters.hpp. > > - The update_* functions are not called frequently and doesn't have to > be inlined. It looks to me like the update_* functions don't need to be virtual. Can we make them non-virtual? Otherwise looks good. Bengt > > - The take_sample() function is called as a virtual call, and doesn't > need to be inlined. > > - The change in cSpaceCounters.hpp to include space.hpp instead of > space.inline.hpp, causes some files to no longer include > space.inline.hpp. If one of these files use the Space class but > doesn't include space.inline.hpp we get a compile error stating that > block_start is used but never defined, even when the block_start > function isn't used from that file. To solve that, the 'inline' > keyword is removed from the declaration, but kept at the definition. > The compiler will not complain about missing definition of block_start > if space.inline.hpp isn't included, but the linker will. The compiler > will still be able to inline the function. > > http://cr.openjdk.java.net/~stefank/8075829/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8075829 > > Thanks, > StefanK From stefan.karlsson at oracle.com Wed Mar 25 08:36:00 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 25 Mar 2015 09:36:00 +0100 Subject: RFR: 8075829: Move CSpaceCounters implementation to cSpaceCounters.cpp In-Reply-To: <551193F3.60603@oracle.com> References: <551191CC.6060604@oracle.com> <551193F3.60603@oracle.com> Message-ID: <55127370.80704@oracle.com> On 2015-03-24 17:42, Jesper Wilhelmsson wrote: > Looks good. Thanks, Jesper. StefanK > /Jesper > > > Stefan Karlsson skrev den 24/3/15 17:33: >> Hi, >> >> Please review this patch to reduce the dependency against >> space.inline.hpp in >> cSpaceCounters.hpp. >> >> - The update_* functions are not called frequently and doesn't have >> to be inlined. >> >> - The take_sample() function is called as a virtual call, and doesn't >> need to be >> inlined. >> >> - The change in cSpaceCounters.hpp to include space.hpp instead of >> space.inline.hpp, causes some files to no longer include >> space.inline.hpp. If >> one of these files use the Space class but doesn't include >> space.inline.hpp we >> get a compile error stating that block_start is used but never >> defined, even >> when the block_start function isn't used from that file. To solve >> that, the >> 'inline' keyword is removed from the declaration, but kept at the >> definition. >> The compiler will not complain about missing definition of >> block_start if >> space.inline.hpp isn't included, but the linker will. The compiler >> will still be >> able to inline the function. >> >> http://cr.openjdk.java.net/~stefank/8075829/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8075829 >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Wed Mar 25 08:43:31 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 25 Mar 2015 09:43:31 +0100 Subject: RFR: 8075829: Move CSpaceCounters implementation to cSpaceCounters.cpp In-Reply-To: <55126FA0.1000109@oracle.com> References: <551191CC.6060604@oracle.com> <55126FA0.1000109@oracle.com> Message-ID: <55127533.6030908@oracle.com> Hi Bengt, On 2015-03-25 09:19, Bengt Rutisson wrote: > > Hi Stefan, > > On 2015-03-24 17:33, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to reduce the dependency against >> space.inline.hpp in cSpaceCounters.hpp. >> >> - The update_* functions are not called frequently and doesn't have >> to be inlined. > > It looks to me like the update_* functions don't need to be virtual. > Can we make them non-virtual? Good point, although not really related to my change. I took a look at CSpaceCounter and you're right, the update functions are never overridden. However, there's a similar class named GenerationCounters, which has a virtual update_all function that is overridden by subclasses. Let's change this in a separate RFE, if we think it's worth changing. > Otherwise looks good. Thanks. StefanK > > Bengt > >> >> - The take_sample() function is called as a virtual call, and doesn't >> need to be inlined. >> >> - The change in cSpaceCounters.hpp to include space.hpp instead of >> space.inline.hpp, causes some files to no longer include >> space.inline.hpp. If one of these files use the Space class but >> doesn't include space.inline.hpp we get a compile error stating that >> block_start is used but never defined, even when the block_start >> function isn't used from that file. To solve that, the 'inline' >> keyword is removed from the declaration, but kept at the definition. >> The compiler will not complain about missing definition of >> block_start if space.inline.hpp isn't included, but the linker will. >> The compiler will still be able to inline the function. >> >> http://cr.openjdk.java.net/~stefank/8075829/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8075829 >> >> Thanks, >> StefanK > From bengt.rutisson at oracle.com Wed Mar 25 08:43:25 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 25 Mar 2015 09:43:25 +0100 Subject: RFR: 8075829: Move CSpaceCounters implementation to cSpaceCounters.cpp In-Reply-To: <55127533.6030908@oracle.com> References: <551191CC.6060604@oracle.com> <55126FA0.1000109@oracle.com> <55127533.6030908@oracle.com> Message-ID: <5512752D.7080503@oracle.com> On 2015-03-25 09:43, Stefan Karlsson wrote: > Hi Bengt, > > On 2015-03-25 09:19, Bengt Rutisson wrote: >> >> Hi Stefan, >> >> On 2015-03-24 17:33, Stefan Karlsson wrote: >>> Hi, >>> >>> Please review this patch to reduce the dependency against >>> space.inline.hpp in cSpaceCounters.hpp. >>> >>> - The update_* functions are not called frequently and doesn't have >>> to be inlined. >> >> It looks to me like the update_* functions don't need to be virtual. >> Can we make them non-virtual? > > Good point, although not really related to my change. I took a look at > CSpaceCounter and you're right, the update functions are never > overridden. However, there's a similar class named GenerationCounters, > which has a virtual update_all function that is overridden by > subclasses. Let's change this in a separate RFE, if we think it's > worth changing. OK. Sounds good. Reviewed. Bengt > >> Otherwise looks good. > > Thanks. > > StefanK > >> >> Bengt >> >>> >>> - The take_sample() function is called as a virtual call, and >>> doesn't need to be inlined. >>> >>> - The change in cSpaceCounters.hpp to include space.hpp instead of >>> space.inline.hpp, causes some files to no longer include >>> space.inline.hpp. If one of these files use the Space class but >>> doesn't include space.inline.hpp we get a compile error stating that >>> block_start is used but never defined, even when the block_start >>> function isn't used from that file. To solve that, the 'inline' >>> keyword is removed from the declaration, but kept at the definition. >>> The compiler will not complain about missing definition of >>> block_start if space.inline.hpp isn't included, but the linker will. >>> The compiler will still be able to inline the function. >>> >>> http://cr.openjdk.java.net/~stefank/8075829/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8075829 >>> >>> Thanks, >>> StefanK >> > From stefan.karlsson at oracle.com Wed Mar 25 08:52:02 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 25 Mar 2015 09:52:02 +0100 Subject: RFR: 8075809: Add missing includes of stack.inline.hpp In-Reply-To: <5511A687.20702@oracle.com> References: <55116281.9080209@oracle.com> <5511A687.20702@oracle.com> Message-ID: <55127732.1050701@oracle.com> On 2015-03-24 19:01, Jon Masamitsu wrote: > Update copyright on > http://cr.openjdk.java.net/~stefank/8075809/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp.frames.html > Will do. > > Otherwise, looks good. > > Reviewed. > > I don't need a re-review. Thanks, Jon. StefanK > > Jon > > On 3/24/2015 6:11 AM, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to add some missing includes of >> stack.inline.hpp. >> >> http://cr.openjdk.java.net/~stefank/8075809/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8075809 >> >> Thanks, >> StefanK > From mikael.gerdin at oracle.com Wed Mar 25 09:00:10 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 25 Mar 2015 10:00:10 +0100 Subject: RFR: 8075803: Fix GC includes and forward declarations In-Reply-To: <551160AE.1090705@oracle.com> References: <551160AE.1090705@oracle.com> Message-ID: <5512791A.8010707@oracle.com> Hi Stefan, On 2015-03-24 14:03, Stefan Karlsson wrote: > Hi, > > Please review this patch to fix some includes and forward declarations > of GC specific files and types. These issues were found while working on > a patch to restructure parts of the oop_oop_iterate code. > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01 Looks good, thanks for cleaning this up! /Mikael > https://bugs.openjdk.java.net/browse/JDK-8075803 > > A list of the the changes: > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp.udiff.html > > > - Missing forward declarations > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp.udiff.html > > > - Missing forward declarations > - Missing include of cmsOopClosures.hpp > - Uses MetadataAwareOopsInGenClosure > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/g1/concurrentMark.hpp.udiff.html > > > - Missing forward declarations > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp.udiff.html > > > - Missing forward declarations > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parNew/parNewGeneration.hpp.udiff.html > > > - Missing include of parNewGeneration.hpp > - Uses ParScanClosure > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp.udiff.html > > > - Missing include of genOopClosures.inline.hpp > -- Uses OopsInKlassOrGenClosure::do_klass_barrier > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp.udiff.html > > > - Missing include of parallelScavengeHeap.hpp > - Using ParallelScavengeHeap > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/oops/cpCache.cpp.udiff.html > > > - Unnecessary include of psPromotionManager.hpp > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp.udiff.html > > > - Unnecessary include of markSweep.inline.hpp > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp.udiff.html > > > - Unnecessary include of markSweep.hpp > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/gc_implementation/shared/markSweep.hpp.udiff.html > > > - Unnecessary include of universe.hpp > > - Missing include of genOopClosure.hpp > - Uses OopsInGenClosure > > - Missing include of iterator.hpp > - Uses ExtendedOopClosure > > - Moved PreservedMark functions from markSweep.hpp into markSweep.cpp > - Needed to get rid of warning about adjust_pointer being used but not > defined. > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/memory/space.cpp.udiff.html > > > - Unnecessary include of markSweep.hpp > > > http://cr.openjdk.java.net/~stefank/8075803/webrev.01/src/share/vm/memory/defNewGeneration.inline.hpp.udiff.html > > > - Missing include of collectedHeap.hpp > - Uses CollectedHeap > > - Missing include of genOopClosures.inline.hpp > - Uses ScanWeakRefClosure::do_oop_nv > > Thanks, > StefanK From thomas.schatzl at oracle.com Wed Mar 25 10:40:33 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 25 Mar 2015 11:40:33 +0100 Subject: [8u60] RFR backport of 8065358: Refactor G1s usage of save_marks and reduce related races In-Reply-To: <5511936E.2090205@oracle.com> References: <1427208578.3133.52.camel@oracle.com> <5511936E.2090205@oracle.com> Message-ID: <1427280033.3163.7.camel@oracle.com> Hi Mikael, On Tue, 2015-03-24 at 17:40 +0100, Mikael Gerdin wrote: > Hi Thomas, > > On 2015-03-24 15:49, Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for the backport of "8065358: Refactor G1s usage of > > save_marks and reduce related races" to 8u60? > > > > It is a change that eases backporting the next change, 8060025. > > > > It did only apply with minor changes, so I need re-reviews. The problem > > has been that in jdk9 isHumongous() (and friends) have been renamed to > > is_humongous() (in g1Allocator.cpp), and there is a typo fix in a > > comment (behaviour -> behavior, second hunk in heapRegion.cpp). > > > > Full 8u60 changeset: > > http://cr.openjdk.java.net/~tschatzl/8065358-8u60/webrev.8u60/ > > Diff changest: > > http://cr.openjdk.java.net/~tschatzl/8065358-8u60/webrev.8u60.fix/ > > Looks good to me. thanks, Thomas From thomas.schatzl at oracle.com Wed Mar 25 10:40:48 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 25 Mar 2015 11:40:48 +0100 Subject: [8u60] RFR backport of 8065358: Refactor G1s usage of save_marks and reduce related races In-Reply-To: <55117BD5.6050806@oracle.com> References: <1427208578.3133.52.camel@oracle.com> <55117BD5.6050806@oracle.com> Message-ID: <1427280048.3163.8.camel@oracle.com> Hi Jesper, On Tue, 2015-03-24 at 15:59 +0100, Jesper Wilhelmsson wrote: > Looks good. > /Jesper > thanks for the review. Thomas From bengt.rutisson at oracle.com Wed Mar 25 12:45:07 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 25 Mar 2015 13:45:07 +0100 Subject: RFR: Backport JDK-8074037, JDK-8075210, JDK-8027962 and also JDK-8061630, JDK-8051837 to 8u Message-ID: <5512ADD3.7010107@oracle.com> Hi all, I would like to backport this fix to the 8 update repo: JDK-8027962: Per-phase timing measurements for strong roots processing https://bugs.openjdk.java.net/browse/JDK-8027962 This fix was originally intended for the 8u branch. During the review process it was decided to take on a couple of broader cleanup fixes to make it easier to address JDK-8027962. So, the work was split up into three separate changes. This means that to backport JDK-8027962 I also need to backport these two changes: JDK-8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases https://bugs.openjdk.java.net/browse/JDK-8074037 JDK-8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap https://bugs.openjdk.java.net/browse/JDK-8075210 The 8u branch has deviated a bit from the JDK 9 branch so the above changesets do not apply cleanly. Two small fixes cause conflicts, so I would like to backport those changes as well: JDK-8061630: G1 iterates over JNIHandles two time https://bugs.openjdk.java.net/browse/JDK-8061630 JDK-8051837: Remove temporary G1UseParallelRSetUpdating and G1UseParallelRSetScanning flags https://bugs.openjdk.java.net/browse/JDK-8051837 These two changes both apply cleanly to the 8u repo. There are also conflicts due to other changes that have not been backported. I prefer *not* to backport these since I think they are too intrusive: JDK-6979279: remove special-case code for ParallelGCThreads==0 JDK-8039244: Don't use UINT32_FORMAT and INT32_FORMAT when printing uints and ints in the GC code JDK-8060074: os::free() takes MemoryTrackingLevel but doesn't need it JDK-8044775: Improve usage of umbrella header atomic.inline.hpp JDK-8062206: Remove unusable G1RSLogCheckCardTable command line argument Instead I manually fixed the conflicts in two ways. I prepared the 8u repo with the following fix: http://cr.openjdk.java.net/~brutisso/backport-8027962/preparation/ And then I patched the export files for the changesets to apply cleanly. Here are webreves for the patches to the exports: http://cr.openjdk.java.net/~brutisso/backport-8027962/exports/ And here are the resulting webrevs for the three changes: http://cr.openjdk.java.net/~brutisso/backport-8027962/8027962/ http://cr.openjdk.java.net/~brutisso/backport-8027962/8075210/ http://cr.openjdk.java.net/~brutisso/backport-8027962/8074037/ I realize that this is difficult to review. Let me know if there is more I can do to ease up the review. Thanks, Bengt From michail.chernov at oracle.com Wed Mar 25 13:33:03 2015 From: michail.chernov at oracle.com (Michail Chernov) Date: Wed, 25 Mar 2015 16:33:03 +0300 Subject: [8u60] Request for backport approval: 8055416 Several vm/gc/heap/summary "After GC" events emitted for the same GC ID In-Reply-To: <55114909.9000409@oracle.com> References: <55114909.9000409@oracle.com> Message-ID: <5512B90F.50806@oracle.com> Hi all, Could someone please have a look at this backport? Thanks, Michail On 24.03.2015 14:22, Michail Chernov wrote: > Dear colleagues, > > I'd like to get approval to backport changes from JDK9 to 8u. > > Webrev: http://cr.openjdk.java.net/~eistepan/~mchernov/8055416/webrev.00/ > > > Original issue was fixed and approved at August 2014. Here is the mail > thread: > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-August/010549.html > > JDK9 webrev: http://cr.openjdk.java.net/~stefank/8055416/webrev.00/ > > Original bug is https://bugs.openjdk.java.net/browse/JDK-8055416 > > Testing: JDK with changes was built locally. Closed JFR test has passed. > > Thanks, > Michail From mikael.gerdin at oracle.com Wed Mar 25 13:46:51 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 25 Mar 2015 14:46:51 +0100 Subject: RFR: 8075635 - Remove GenerationSpec array In-Reply-To: <55119066.3070802@oracle.com> References: <551048F7.3070405@oracle.com> <2E226390-040C-4E5E-A3C3-967AB6567D35@oracle.com> <55119066.3070802@oracle.com> Message-ID: <5512BC4B.9030200@oracle.com> Hi Jesper, On 2015-03-24 17:27, Jesper Wilhelmsson wrote: > Hi Kim, > > Thanks for reviewing! > > A new webrev is available here: > http://cr.openjdk.java.net/~jwilhelm/8075635/webrev.01/hotspot/ Why are young_gen_spec() and old_gen_spec() virtual in GenCollectorPolicy? As a possible follow up Generation::spec() only has a few callers, all of which are interested in the initial_size of the Generation, if that value could be cached in the Generation then the not particularly pretty Generation::spec() can go away. Or perhaps your end game is the end of GenerationSpec alltogether? /Mikael > > Latest increment: > http://cr.openjdk.java.net/~jwilhelm/8075635/webrev.01/hotspot_incremental/ > > Comments inline. > > Kim Barrett skrev den 23/3/15 22:59: >> On Mar 23, 2015, at 1:10 PM, Jesper Wilhelmsson >> wrote: >>> >>> Hi, >>> >>> Please review another follow up after the generation array removal. >>> In this change the array of generation specifications is reduced to >>> two variables in the same way as was done for the generations. >>> >>> The reference to the genSpecs that was previously duplicated in >>> GenCollectedHeap is now only available through the collector policy >>> class. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075635 >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8075635/webrev.00 >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp >> src/share/vm/memory/collectorPolicy.hpp >> src/share/vm/memory/generationSpec.hpp >> >> Needs copyright update. > > Fixed. > >> ------------------------------------------------------------------------------ >> >> agent/src/share/classes/sun/jvm/hotspot/memory/GenCollectedHeap.java >> 131 if (level == 0) { >> 132 return (GenerationSpec) >> 133 VMObjectFactory.newObject(GenerationSpec.class, >> 134 youngGenSpecField.getAddress()); >> 135 } else { >> 136 return (GenerationSpec) >> 137 VMObjectFactory.newObject(GenerationSpec.class, >> 138 oldGenSpecField.getAddress()); >> 139 } >> >> This is effectively assuming that nGens() == 2, but the earlier >> assertions in this function don't reflect that assumption. I realize >> there will probably be further cleanup in this area later, but I'd >> like things to be in a consistent state at each step in these >> incremental changes. > > I changed the existing assert to look for 0 or 1 rather than using > nGens(). This is the same approach as we used in the last change that > changed the assert in a method a few lines above this one. > >> >> Similar issue here: >> src/share/vm/memory/generation.cpp >> 67 return level() == 0 ? gch->gen_policy()->young_gen_spec() : >> gch->gen_policy()->old_gen_spec(); > > Same change here. > >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/memory/genCollectedHeap.cpp >> 151 size_t total_reserved = young_spec->max_size() + >> old_spec->max_size(); >> 152 if (total_reserved < young_spec->max_size() || >> 153 total_reserved < old_spec->max_size()) { >> >> Not that it's all that important, but either of those comparisons >> alone should be sufficient to test for overflow. It might also be >> nice to leave a comment about this being a test for overflow. > > Yes, you are right. You are most likely the first one to give this code > enough thought to realize this. Good catch! I cleaned up this code a bit > in the new version. > >> ------------------------------------------------------------------------------ >> >> src/share/vm/memory/generationSpec.hpp >> 42 GenerationSpec(Generation::Name name, size_t init_size, size_t >> max_size, size_t alignment) { >> 43 _name = name; >> 44 _init_size = align_size_up(init_size, alignment); >> 45 _max_size = align_size_up(max_size, alignment); >> 46 } >> >> I like that you've eliminated the separate post-construction init_size >> and max_size alignment step and are instead doing that in the >> constructor. >> >> Is there anything that ensures init_size <= max_size? Should there be >> an assertion to that effect here? > > This is verified in the collector policy code where initial and max > sizes are set up. I wouldn't object to having an assert here if you feel > strongly about it. On the other hand we have a quite extensive set off > asserts in GenCollectorPolicy::assert_flags() and > GenCollectorPolicy::assert_size_info() to make sure this stuff is > correct already. > >> >> Also consider initializing members in ctor-initializer rather than >> assignments in the constructor body. > > Fixed. > > Thanks! > /Jesper From eric.caspole at oracle.com Wed Mar 25 14:07:43 2015 From: eric.caspole at oracle.com (Eric Caspole) Date: Wed, 25 Mar 2015 10:07:43 -0400 Subject: RFR: Backport JDK-8074037, JDK-8075210, JDK-8027962 and also JDK-8061630, JDK-8051837 to 8u In-Reply-To: <5512ADD3.7010107@oracle.com> References: <5512ADD3.7010107@oracle.com> Message-ID: <5512C12F.5040406@oracle.com> Looks good to me, although I have never tried a backport before. It is worthwhile to get this better stats system collection in use. I did not follow why the #include "runtime/atomic.inline.hpp" got added into this middle step merge: http://cr.openjdk.java.net/~brutisso/backport-8027962/preparation/src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp.frames.html but I saw it was removed in the final merge: http://cr.openjdk.java.net/~brutisso/backport-8027962/8074037/src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp.frames.html Regards, Eric On 3/25/2015 8:45 AM, Bengt Rutisson wrote: > > Hi all, > > I would like to backport this fix to the 8 update repo: > > JDK-8027962: Per-phase timing measurements for strong roots processing > https://bugs.openjdk.java.net/browse/JDK-8027962 > > This fix was originally intended for the 8u branch. During the review > process it was decided to take on a couple of broader cleanup fixes to > make it easier to address JDK-8027962. So, the work was split up into > three separate changes. This means that to backport JDK-8027962 I also > need to backport these two changes: > > JDK-8074037: Refactor the G1GCPhaseTime logging to make it easier to > add new phases > https://bugs.openjdk.java.net/browse/JDK-8074037 > > JDK-8075210: Refactor strong root processing in order to allow G1 to > evolve separately from GenCollectedHeap > https://bugs.openjdk.java.net/browse/JDK-8075210 > > > The 8u branch has deviated a bit from the JDK 9 branch so the above > changesets do not apply cleanly. Two small fixes cause conflicts, so I > would like to backport those changes as well: > > JDK-8061630: G1 iterates over JNIHandles two time > https://bugs.openjdk.java.net/browse/JDK-8061630 > > JDK-8051837: Remove temporary G1UseParallelRSetUpdating and > G1UseParallelRSetScanning flags > https://bugs.openjdk.java.net/browse/JDK-8051837 > > These two changes both apply cleanly to the 8u repo. > > There are also conflicts due to other changes that have not been > backported. I prefer *not* to backport these since I think they are > too intrusive: > > JDK-6979279: remove special-case code for ParallelGCThreads==0 > JDK-8039244: Don't use UINT32_FORMAT and INT32_FORMAT when printing > uints and ints in the GC code > JDK-8060074: os::free() takes MemoryTrackingLevel but doesn't need it > JDK-8044775: Improve usage of umbrella header atomic.inline.hpp > JDK-8062206: Remove unusable G1RSLogCheckCardTable command line argument > > Instead I manually fixed the conflicts in two ways. I prepared the 8u > repo with the following fix: > > http://cr.openjdk.java.net/~brutisso/backport-8027962/preparation/ > > And then I patched the export files for the changesets to apply > cleanly. Here are webreves for the patches to the exports: > > http://cr.openjdk.java.net/~brutisso/backport-8027962/exports/ > > And here are the resulting webrevs for the three changes: > > http://cr.openjdk.java.net/~brutisso/backport-8027962/8027962/ > http://cr.openjdk.java.net/~brutisso/backport-8027962/8075210/ > http://cr.openjdk.java.net/~brutisso/backport-8027962/8074037/ > > I realize that this is difficult to review. Let me know if there is > more I can do to ease up the review. > > Thanks, > Bengt > > From jesper.wilhelmsson at oracle.com Wed Mar 25 14:18:28 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 25 Mar 2015 15:18:28 +0100 Subject: [8u60] Request for backport approval: 8055416 Several vm/gc/heap/summary "After GC" events emitted for the same GC ID In-Reply-To: <5512B90F.50806@oracle.com> References: <55114909.9000409@oracle.com> <5512B90F.50806@oracle.com> Message-ID: <5512C3B4.8020907@oracle.com> Looks to me as the patch applied clean to 8u. You don't need a new review for a backport change that applies clean, but since I looked at it: Ship it! /Jesper Michail Chernov skrev den 25/3/15 14:33: > Hi all, > > Could someone please have a look at this backport? > > Thanks, > Michail > > On 24.03.2015 14:22, Michail Chernov wrote: >> Dear colleagues, >> >> I'd like to get approval to backport changes from JDK9 to 8u. >> >> Webrev: http://cr.openjdk.java.net/~eistepan/~mchernov/8055416/webrev.00/ >> >> >> Original issue was fixed and approved at August 2014. Here is the mail thread: >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-August/010549.html >> JDK9 webrev: http://cr.openjdk.java.net/~stefank/8055416/webrev.00/ >> >> Original bug is https://bugs.openjdk.java.net/browse/JDK-8055416 >> >> Testing: JDK with changes was built locally. Closed JFR test has passed. >> >> Thanks, >> Michail > From thomas.schatzl at oracle.com Wed Mar 25 14:40:30 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 25 Mar 2015 15:40:30 +0100 Subject: [8u60] RFR backport of 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 Message-ID: <1427294430.3163.37.camel@oracle.com> Hi all, can I have reviews for the backport of "8060025: Object copy time regressions after JDK-8031323 and JDK-8057536" for 8u60? It did only apply with minor changes, so I need re-reviews. The problem has been that in jdk9 isHumongous() (and friends) have been renamed to is_humongous() in g1CollectedHeap.cpp. Full 8u60 changeset: http://cr.openjdk.java.net/~tschatzl/8060025-8u60/webrev.8u60/ Diff changest: http://cr.openjdk.java.net/~tschatzl/8060025-8u60/webrev.8u60-fix/ CR: https://bugs.openjdk.java.net/browse/JDK-8060025 Original change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5cdbde3a9a57 Testing: jprt Thanks, Thomas From jesper.wilhelmsson at oracle.com Wed Mar 25 14:44:47 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 25 Mar 2015 15:44:47 +0100 Subject: [8u60] RFR backport of 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <1427294430.3163.37.camel@oracle.com> References: <1427294430.3163.37.camel@oracle.com> Message-ID: <5512C9DF.5010508@oracle.com> Looks good. /Jesper Thomas Schatzl skrev den 25/3/15 15:40: > Hi all, > > can I have reviews for the backport of "8060025: Object copy time > regressions after JDK-8031323 and JDK-8057536" for 8u60? > > It did only apply with minor changes, so I need re-reviews. The problem > has been that in jdk9 isHumongous() (and friends) have been renamed to > is_humongous() in g1CollectedHeap.cpp. > > Full 8u60 changeset: > http://cr.openjdk.java.net/~tschatzl/8060025-8u60/webrev.8u60/ > Diff changest: > http://cr.openjdk.java.net/~tschatzl/8060025-8u60/webrev.8u60-fix/ > > CR: > https://bugs.openjdk.java.net/browse/JDK-8060025 > > Original change: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5cdbde3a9a57 > > Testing: jprt > > Thanks, > Thomas > > From michail.chernov at oracle.com Wed Mar 25 14:49:04 2015 From: michail.chernov at oracle.com (Michail Chernov) Date: Wed, 25 Mar 2015 17:49:04 +0300 Subject: [8u60] Request for backport approval: 8055416 Several vm/gc/heap/summary "After GC" events emitted for the same GC ID In-Reply-To: <5512C3B4.8020907@oracle.com> References: <55114909.9000409@oracle.com> <5512B90F.50806@oracle.com> <5512C3B4.8020907@oracle.com> Message-ID: <5512CAE0.4050208@oracle.com> Thanks! On 25.03.2015 17:18, Jesper Wilhelmsson wrote: > Looks to me as the patch applied clean to 8u. You don't need a new > review for a backport change that applies clean, but since I looked at > it: Ship it! > /Jesper > > > Michail Chernov skrev den 25/3/15 14:33: >> Hi all, >> >> Could someone please have a look at this backport? >> >> Thanks, >> Michail >> >> On 24.03.2015 14:22, Michail Chernov wrote: >>> Dear colleagues, >>> >>> I'd like to get approval to backport changes from JDK9 to 8u. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~eistepan/~mchernov/8055416/webrev.00/ >>> >>> >>> Original issue was fixed and approved at August 2014. Here is the >>> mail thread: >>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-August/010549.html >>> >>> JDK9 webrev: http://cr.openjdk.java.net/~stefank/8055416/webrev.00/ >>> >>> Original bug is https://bugs.openjdk.java.net/browse/JDK-8055416 >>> >>> Testing: JDK with changes was built locally. Closed JFR test has >>> passed. >>> >>> Thanks, >>> Michail >> From mikael.gerdin at oracle.com Wed Mar 25 14:53:54 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 25 Mar 2015 15:53:54 +0100 Subject: [8u60] RFR backport of 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <1427294430.3163.37.camel@oracle.com> References: <1427294430.3163.37.camel@oracle.com> Message-ID: <5512CC02.9020605@oracle.com> Hi Thomas, On 2015-03-25 15:40, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the backport of "8060025: Object copy time > regressions after JDK-8031323 and JDK-8057536" for 8u60? > > It did only apply with minor changes, so I need re-reviews. The problem > has been that in jdk9 isHumongous() (and friends) have been renamed to > is_humongous() in g1CollectedHeap.cpp. > > Full 8u60 changeset: > http://cr.openjdk.java.net/~tschatzl/8060025-8u60/webrev.8u60/ This is not the correct webrev :) /Mikael > Diff changest: > http://cr.openjdk.java.net/~tschatzl/8060025-8u60/webrev.8u60-fix/ > > CR: > https://bugs.openjdk.java.net/browse/JDK-8060025 > > Original change: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5cdbde3a9a57 > > Testing: jprt > > Thanks, > Thomas > > From stefan.karlsson at oracle.com Wed Mar 25 15:02:40 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 25 Mar 2015 16:02:40 +0100 Subject: RFR: 8075957: Reduce calls to the GC specific object visitors in oopDesc Message-ID: <5512CE10.7030805@oracle.com> Hi, Please review this refactoring patch: http://cr.openjdk.java.net/~stefank/8075957/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8075957 Some of our GCs have GC specific entry points and code placed in the oopDesc and Klass files. They are used to implement marking, scavenging and adjusting of oops in the the objects. See the following functions: Mark Sweep: void follow_contents(void); int adjust_pointers(); Parallel Scavenge void push_contents(PSPromotionManager* pm); Parallel Old void update_contents(ParCompactionManager* cm); void follow_contents(ParCompactionManager* cm); With JDK-8075955 we'll start to use parts of the oop_oop_iterate framework to implement these functions, and as a preparation patch I'd like to minimize the number of places where these functions are directly called from Mark Sweep, Parallel Scavenge and Parallel Old. The proposal is to add thin wrapper functions to the three GCs, and let these wrappers be the only callers of the functions above. Detailed description of the patch: http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html - Include of oop.pcgc.inline.hpp not needed http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1MarkSweep.cpp.udiff.html - Call to GC wrapper function http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1ParScanThreadState.cpp.udiff.html - Include of oop.pcgc.inline.hpp not needed http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp.udiff.html - Include of oop.pcgc.inline.hpp not needed http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp.udiff.html - Include of oop.pcgc.inline.hpp not needed - Call to GC wrapper function http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp.udiff.html - Include of oop.pcgc.inline.hpp not needed - Call to GC wrapper function http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp.udiff.html - Include of oop.pcgc.inline.hpp not needed - Call to GC wrapper function http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp.udiff.html - Wrapper declarations http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.inline.hpp.udiff.html - Wrapper definitions http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp.udiff.html - Call to GC wrapper function http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp.udiff.html - Include of oop.pcgc.inline.hpp not needed - Call to GC wrapper function - Moved definition of do_addr since it was only used in the .cpp, placed in the .hpp file, and used other .inline.hpp files. http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp.udiff.html - Moved definition of do_addr since it was only used in the .cpp, placed in the .hpp file, and used other .inline.hpp files. - Removed dead code (follow_root) that referred to one of the object visitors. http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp.udiff.html - Include of oop.pcgc.inline.hpp not needed - Call to GC wrapper function http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp.udiff.html - Wrapper declaration http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp.udiff.html - Wrapper declarations - Call to GC wrapper function http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp.udiff.html - Include of oop.pcgc.inline.hpp not needed http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp.udiff.html - Include of oop.pcgc.inline.hpp not needed http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.cpp.udiff.html - Wrapper definition - Call to GC wrapper function http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.hpp.udiff.html - Wrapper declarations http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.inline.hpp.udiff.html - Wrapper definitions http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/memory/space.inline.hpp.udiff.html - Call to GC wrapper function http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.cpp.udiff.html - Include of oop.pcgc.inline.hpp not needed http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html - Include of oop.pcgc.inline.hpp not needed http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceMirrorKlass.cpp.udiff.html - Include of oop.pcgc.inline.hpp not needed http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceRefKlass.cpp.udiff.html - Include of oop.pcgc.inline.hpp not needed http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/objArrayKlass.cpp.udiff.html - Include of oop.pcgc.inline.hpp not needed No copyright years have been updated. Thanks, StefanK From thomas.schatzl at oracle.com Wed Mar 25 15:09:29 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 25 Mar 2015 16:09:29 +0100 Subject: [8u60] RFR backport of 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <5512CC02.9020605@oracle.com> References: <1427294430.3163.37.camel@oracle.com> <5512CC02.9020605@oracle.com> Message-ID: <1427296169.3163.44.camel@oracle.com> Hi, On Wed, 2015-03-25 at 15:53 +0100, Mikael Gerdin wrote: > Hi Thomas, > > On 2015-03-25 15:40, Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for the backport of "8060025: Object copy time > > regressions after JDK-8031323 and JDK-8057536" for 8u60? > > > > It did only apply with minor changes, so I need re-reviews. The problem > > has been that in jdk9 isHumongous() (and friends) have been renamed to > > is_humongous() in g1CollectedHeap.cpp. > > > > Full 8u60 changeset: > > http://cr.openjdk.java.net/~tschatzl/8060025-8u60/webrev.8u60/ > > This is not the correct webrev :) It is now :) Sorry - I forgot to properly rename the webrev directory and did not check thoroughly enough. Thanks, Thomas From thomas.schatzl at oracle.com Wed Mar 25 15:22:08 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 25 Mar 2015 16:22:08 +0100 Subject: [8u60] RFR backport of 8053998: Hot card cache flush chunk size too coarse grained Message-ID: <1427296928.3163.48.camel@oracle.com> Hi all, can I have reviews for the backport of "8053998: Hot card cache flush chunk size too coarse grained" for 8u60? It did only apply with minor changes, so I need re-reviews. The problem is that some non-ported change (removing ParallelGCThreads == 0) requires an additional cast of the ParallelGCThreads variable (which is uintx) to be comparable to an integer zero constant. Note that this change is based on "8060025: Object copy time regressions after JDK-8031323 and JDK-8057536" which is also out for review Full 8u60 changeset: http://cr.openjdk.java.net/~tschatzl/8053998-8u60/webrev.8u60/ Diff changest: http://cr.openjdk.java.net/~tschatzl/8053998-8u60/webrev.8u60-fix/ CR: https://bugs.openjdk.java.net/browse/JDK-8053998 Original change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7894458add89 Testing: jprt Thanks, Thomas From thomas.schatzl at oracle.com Wed Mar 25 15:22:18 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 25 Mar 2015 16:22:18 +0100 Subject: [8u60] RFR backport of 8069273: Decrease Hot Card Cache Lock contention Message-ID: <1427296938.3163.49.camel@oracle.com> Hi all, can I have reviews for the backport of "8069273: Decrease Hot Card Cache Lock contention" for 8u60? It did only apply with minor changes, so I need re-reviews. The problems are: - some previous, non-ported changed the copyright date - 8u60 does not have size_t versions of the Atomic instructions, fixed by casting to intptr_t (as done elsewhere in this case) - removing the HotCardCache_lock needed to be done manually, as somewhere the declaration order of locks changed in mutexLocker.cpp. Note that this change is based on "JDK-8053998: Hot card cache flush chunk size too coarse grained", which is also out for review. Full 8u60 changeset: http://cr.openjdk.java.net/~tschatzl/8069273-8u60/webrev.8u60/ Diff changest: http://cr.openjdk.java.net/~tschatzl/8069273-8u60/webrev.8u60-fix/ CR: https://bugs.openjdk.java.net/browse/JDK-8069273 Original change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1c8ba2d0d2f0 Testing: jprt Thanks, Thomas From thomas.schatzl at oracle.com Wed Mar 25 15:42:57 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 25 Mar 2015 16:42:57 +0100 Subject: [8u60] RFR backport of 8067655: Clean up G1 remembered set oop iteration Message-ID: <1427298177.3163.57.camel@oracle.com> Hi all, can I have reviews for the backport of "8067655: Clean up G1 remembered set oop iteration" for 8u60? It did only apply with minor changes, so I need re-reviews. The problems are - some guarantee that is still in jdk8u in G1RemSet::G1RemSet(), but has been removed in jdk9 - in jdk9, FREE_C_HEAP_ARRAY does not need the type specifier ("mtGC") any more - CountNonCleanMemRegionClosure moved in jdk9 Note that this change is based on "8069273: Decrease Hot Card Cache Lock contention" which is also out for review, and "8069760: When iterating over a card, G1 often iterates over much more..." which applied cleanly (hence no RFR for that one). Full 8u60 changeset: http://cr.openjdk.java.net/~tschatzl/8067655-8u60/webrev.8u60/ Diff changest: http://cr.openjdk.java.net/~tschatzl/8067655-8u60/webrev.8u60-fix/ CR: https://bugs.openjdk.java.net/browse/JDK-8067655 Original change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6aa9ea790814 Testing: jprt Thanks, Thomas From thomas.schatzl at oracle.com Wed Mar 25 21:31:01 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 25 Mar 2015 22:31:01 +0100 Subject: [8u60] RFR of backport for 8067469: G1 ignores AlwaysPreTouch Message-ID: <1427319061.3220.5.camel@oracle.com> Hi all, can I have reviews for the backport of "8067469: G1 ignores AlwaysPreTouch" for 8u60? It did only apply with minor changes, so I need re-reviews. The problem is that JDK-8062063 that has been pushed later has already been backported to 8u. Note that this change is based on "8067655: Clean up G1 remembered set oop iteration" which is also out for review, and "8049536: os::commit_memory on Solaris uses alignment_hint as page size" which applied cleanly (hence no RFR for that one). Full 8u60 changeset: http://cr.openjdk.java.net/~tschatzl/8067469-8u60/webrev.8u60/ Diff changest: http://cr.openjdk.java.net/~tschatzl/8067469-8u60/webrev.8u60-fix/ CR: https://bugs.openjdk.java.net/browse/JDK-8067469 Original change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d87c2d9c1eb4 Testing: jprt Thanks, Thomas From jesper.wilhelmsson at oracle.com Wed Mar 25 22:37:47 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 25 Mar 2015 23:37:47 +0100 Subject: RFR: 8075635 - Remove GenerationSpec array In-Reply-To: <5512BC4B.9030200@oracle.com> References: <551048F7.3070405@oracle.com> <2E226390-040C-4E5E-A3C3-967AB6567D35@oracle.com> <55119066.3070802@oracle.com> <5512BC4B.9030200@oracle.com> Message-ID: <551338BB.30401@oracle.com> Hi Mikael, I guess the simple answer is that young/old_gen_spec() was virtual because their predecessor "generations()" was. There is no reason for them to be virtual. I have removed that now. Latest webrev: http://cr.openjdk.java.net/~jwilhelm/8075635/webrev.02 (Only change was to remove virtual from these two methods.) I have added your comments about Generation::spec() to my list of future work. Thanks, /Jesper Mikael Gerdin skrev den 25/3/15 14:46: > Hi Jesper, > > On 2015-03-24 17:27, Jesper Wilhelmsson wrote: >> Hi Kim, >> >> Thanks for reviewing! >> >> A new webrev is available here: >> http://cr.openjdk.java.net/~jwilhelm/8075635/webrev.01/hotspot/ > > Why are young_gen_spec() and old_gen_spec() virtual in GenCollectorPolicy? > > As a possible follow up Generation::spec() only has a few callers, all of which > are interested in the initial_size of the Generation, if that value could be > cached in the Generation then the not particularly pretty Generation::spec() can > go away. Or perhaps your end game is the end of GenerationSpec alltogether? > > /Mikael > >> >> Latest increment: >> http://cr.openjdk.java.net/~jwilhelm/8075635/webrev.01/hotspot_incremental/ >> >> Comments inline. >> >> Kim Barrett skrev den 23/3/15 22:59: >>> On Mar 23, 2015, at 1:10 PM, Jesper Wilhelmsson >>> wrote: >>>> >>>> Hi, >>>> >>>> Please review another follow up after the generation array removal. >>>> In this change the array of generation specifications is reduced to >>>> two variables in the same way as was done for the generations. >>>> >>>> The reference to the genSpecs that was previously duplicated in >>>> GenCollectedHeap is now only available through the collector policy >>>> class. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075635 >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8075635/webrev.00 >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp >>> src/share/vm/memory/collectorPolicy.hpp >>> src/share/vm/memory/generationSpec.hpp >>> >>> Needs copyright update. >> >> Fixed. >> >>> ------------------------------------------------------------------------------ >>> >>> agent/src/share/classes/sun/jvm/hotspot/memory/GenCollectedHeap.java >>> 131 if (level == 0) { >>> 132 return (GenerationSpec) >>> 133 VMObjectFactory.newObject(GenerationSpec.class, >>> 134 youngGenSpecField.getAddress()); >>> 135 } else { >>> 136 return (GenerationSpec) >>> 137 VMObjectFactory.newObject(GenerationSpec.class, >>> 138 oldGenSpecField.getAddress()); >>> 139 } >>> >>> This is effectively assuming that nGens() == 2, but the earlier >>> assertions in this function don't reflect that assumption. I realize >>> there will probably be further cleanup in this area later, but I'd >>> like things to be in a consistent state at each step in these >>> incremental changes. >> >> I changed the existing assert to look for 0 or 1 rather than using >> nGens(). This is the same approach as we used in the last change that >> changed the assert in a method a few lines above this one. >> >>> >>> Similar issue here: >>> src/share/vm/memory/generation.cpp >>> 67 return level() == 0 ? gch->gen_policy()->young_gen_spec() : >>> gch->gen_policy()->old_gen_spec(); >> >> Same change here. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/memory/genCollectedHeap.cpp >>> 151 size_t total_reserved = young_spec->max_size() + >>> old_spec->max_size(); >>> 152 if (total_reserved < young_spec->max_size() || >>> 153 total_reserved < old_spec->max_size()) { >>> >>> Not that it's all that important, but either of those comparisons >>> alone should be sufficient to test for overflow. It might also be >>> nice to leave a comment about this being a test for overflow. >> >> Yes, you are right. You are most likely the first one to give this code >> enough thought to realize this. Good catch! I cleaned up this code a bit >> in the new version. >> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/memory/generationSpec.hpp >>> 42 GenerationSpec(Generation::Name name, size_t init_size, size_t >>> max_size, size_t alignment) { >>> 43 _name = name; >>> 44 _init_size = align_size_up(init_size, alignment); >>> 45 _max_size = align_size_up(max_size, alignment); >>> 46 } >>> >>> I like that you've eliminated the separate post-construction init_size >>> and max_size alignment step and are instead doing that in the >>> constructor. >>> >>> Is there anything that ensures init_size <= max_size? Should there be >>> an assertion to that effect here? >> >> This is verified in the collector policy code where initial and max >> sizes are set up. I wouldn't object to having an assert here if you feel >> strongly about it. On the other hand we have a quite extensive set off >> asserts in GenCollectorPolicy::assert_flags() and >> GenCollectorPolicy::assert_size_info() to make sure this stuff is >> correct already. >> >>> >>> Also consider initializing members in ctor-initializer rather than >>> assignments in the constructor body. >> >> Fixed. >> >> Thanks! >> /Jesper From psockali at gmail.com Wed Mar 25 22:39:24 2015 From: psockali at gmail.com (Pressenna) Date: Wed, 25 Mar 2015 23:39:24 +0100 Subject: CMM GC Message-ID: Hello together, I am working on a GC dubbed CMM. I have discussed the client API details with a few colleagues / friends and they think that it might be a worthwhile effort. CMM attempts to give the mutators better control over their memory utilization. This is achieved by means of scoped heaps. The mutators are now able to create, activate / deactivate, collect and dispose of scoped heaps via an API. I have now written up some of the details on a web site and was wondering if I could obtain some feedback from the experts who know the subject matter best. See http://sockali.net/openjdk/cmm/ for a bit more detail and some use cases. I also checked in the CMM Java API into a repository. The code will certainty not survive any reviews at this stage, but the CMM interfaces are there to illustrate the basic idea. See https://bitbucket.org/cmmgc/cmm-api All feedback is most welcome, maybe something similar like this already exists and I could learn from it for this implementation. Thanks and regards, Pressenna -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Thu Mar 26 03:47:16 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 25 Mar 2015 20:47:16 -0700 Subject: RFR (L): 8058354: SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting with 9-b29 In-Reply-To: <1426683926.5616.6.camel@oracle.com> References: <1422527439.3309.8.camel@oracle.com> <54CC0BCC.2090009@oracle.com> <1422959222.3368.4.camel@oracle.com> <54D11432.5050006@oracle.com> <1424162109.3163.2.camel@oracle.com> <54E75013.9010404@oracle.com> <1424446165.3267.13.camel@oracle.com> <1426683926.5616.6.camel@oracle.com> Message-ID: <55138144.6000406@oracle.com> Thomas, Haven't gotten very far but let me send you one question. http://cr.openjdk.java.net/~tschatzl/8058354/webrev.2_to_3/src/share/vm/gc_implementation/g1/g1PageBasedVirtualSpace.cpp.frames.html > 157 void G1PageBasedVirtualSpace::commit_tail() { > 158 char* const aligned_end_address = (char*)align_ptr_down(_high_boundary, _page_size); > 159 size_t const tail_size = pointer_delta(_high_boundary, aligned_end_address, sizeof(char)); Should there be a check that tail_size is not 0 before attempting to commit it? Jon On 3/18/2015 6:05 AM, Thomas Schatzl wrote: > Hi all, > > I got a few more internal reviews and suggestions for this change, so > I would like to ask for re-reviews. > > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.3/ (full) > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.2_to_3/ (diff) > > Changes: > > - changed " SIZE_FORMAT" strings in gclog_or_tty->print_cr() format > strings to " SIZE_FORMAT " since this is the correct style. > > - moved setup of reserved space with the requirements we have to the > ReservedSpace constructor. > > - improve readability: in G1PageBasedVirtualSpace: renamings of > "actual_size" -> "used_size" parameter, _commit_size -> _page_size > member > > - G1PageBasedVirtualSpace: changed uintptr_t parameter types to more > fitting size_t > > - some refactorings, extracting a few methods to make control flow more > clear > > Testing: > jprt, aurora > > Thanks, > Thomas > > From bengt.rutisson at oracle.com Thu Mar 26 04:49:53 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 26 Mar 2015 05:49:53 +0100 Subject: RFR: Backport JDK-8074037, JDK-8075210, JDK-8027962 and also JDK-8061630, JDK-8051837 to 8u In-Reply-To: <5512C12F.5040406@oracle.com> References: <5512ADD3.7010107@oracle.com> <5512C12F.5040406@oracle.com> Message-ID: Hi Eric, Thanks for looking at this! > 25 mar 2015 kl. 15:07 skrev Eric Caspole : > > Looks good to me, although I have never tried a backport before. > It is worthwhile to get this better stats system collection in use. > > I did not follow why the > > #include "runtime/atomic.inline.hpp" > > got added into this middle step merge: > > http://cr.openjdk.java.net/~brutisso/backport-8027962/preparation/src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp.frames.html > It was added because I did not backport "JDK-8044775: Improve usage of umbrella header atomic.inline.hpp" that added that include to JDK 9. I could have done that as s patch to the export file instead but this was the first chsnge I did before I started changing the export files. Thanks, Bengt > but I saw it was removed in the final merge: > > http://cr.openjdk.java.net/~brutisso/backport-8027962/8074037/src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp.frames.html > > Regards, > Eric > > >> On 3/25/2015 8:45 AM, Bengt Rutisson wrote: >> >> Hi all, >> >> I would like to backport this fix to the 8 update repo: >> >> JDK-8027962: Per-phase timing measurements for strong roots processing >> https://bugs.openjdk.java.net/browse/JDK-8027962 >> >> This fix was originally intended for the 8u branch. During the review process it was decided to take on a couple of broader cleanup fixes to make it easier to address JDK-8027962. So, the work was split up into three separate changes. This means that to backport JDK-8027962 I also need to backport these two changes: >> >> JDK-8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases >> https://bugs.openjdk.java.net/browse/JDK-8074037 >> >> JDK-8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap >> https://bugs.openjdk.java.net/browse/JDK-8075210 >> >> >> The 8u branch has deviated a bit from the JDK 9 branch so the above changesets do not apply cleanly. Two small fixes cause conflicts, so I would like to backport those changes as well: >> >> JDK-8061630: G1 iterates over JNIHandles two time >> https://bugs.openjdk.java.net/browse/JDK-8061630 >> >> JDK-8051837: Remove temporary G1UseParallelRSetUpdating and G1UseParallelRSetScanning flags >> https://bugs.openjdk.java.net/browse/JDK-8051837 >> >> These two changes both apply cleanly to the 8u repo. >> >> There are also conflicts due to other changes that have not been backported. I prefer *not* to backport these since I think they are too intrusive: >> >> JDK-6979279: remove special-case code for ParallelGCThreads==0 >> JDK-8039244: Don't use UINT32_FORMAT and INT32_FORMAT when printing uints and ints in the GC code >> JDK-8060074: os::free() takes MemoryTrackingLevel but doesn't need it >> JDK-8044775: Improve usage of umbrella header atomic.inline.hpp >> JDK-8062206: Remove unusable G1RSLogCheckCardTable command line argument >> >> Instead I manually fixed the conflicts in two ways. I prepared the 8u repo with the following fix: >> >> http://cr.openjdk.java.net/~brutisso/backport-8027962/preparation/ >> >> And then I patched the export files for the changesets to apply cleanly. Here are webreves for the patches to the exports: >> >> http://cr.openjdk.java.net/~brutisso/backport-8027962/exports/ >> >> And here are the resulting webrevs for the three changes: >> >> http://cr.openjdk.java.net/~brutisso/backport-8027962/8027962/ >> http://cr.openjdk.java.net/~brutisso/backport-8027962/8075210/ >> http://cr.openjdk.java.net/~brutisso/backport-8027962/8074037/ >> >> I realize that this is difficult to review. Let me know if there is more I can do to ease up the review. >> >> Thanks, >> Bengt > From mikael.gerdin at oracle.com Thu Mar 26 08:20:01 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 26 Mar 2015 09:20:01 +0100 Subject: [8u60] RFR backport of 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <1427296169.3163.44.camel@oracle.com> References: <1427294430.3163.37.camel@oracle.com> <5512CC02.9020605@oracle.com> <1427296169.3163.44.camel@oracle.com> Message-ID: <5513C131.1040802@oracle.com> Hi Thomas, On 2015-03-25 16:09, Thomas Schatzl wrote: > Hi, > > On Wed, 2015-03-25 at 15:53 +0100, Mikael Gerdin wrote: >> Hi Thomas, >> >> On 2015-03-25 15:40, Thomas Schatzl wrote: >>> Hi all, >>> >>> can I have reviews for the backport of "8060025: Object copy time >>> regressions after JDK-8031323 and JDK-8057536" for 8u60? >>> >>> It did only apply with minor changes, so I need re-reviews. The problem >>> has been that in jdk9 isHumongous() (and friends) have been renamed to >>> is_humongous() in g1CollectedHeap.cpp. >>> >>> Full 8u60 changeset: >>> http://cr.openjdk.java.net/~tschatzl/8060025-8u60/webrev.8u60/ >> >> This is not the correct webrev :) > > It is now :) Sorry - I forgot to properly rename the webrev directory > and did not check thoroughly enough. Looks good now. /Mikael > > Thanks, > Thomas > > From mikael.gerdin at oracle.com Thu Mar 26 08:21:01 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 26 Mar 2015 09:21:01 +0100 Subject: [8u60] RFR backport of 8053998: Hot card cache flush chunk size too coarse grained In-Reply-To: <1427296928.3163.48.camel@oracle.com> References: <1427296928.3163.48.camel@oracle.com> Message-ID: <5513C16D.4080405@oracle.com> Hi Thomas, On 2015-03-25 16:22, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the backport of "8053998: Hot card cache flush > chunk size too coarse grained" for 8u60? > > It did only apply with minor changes, so I need re-reviews. The problem > is that some non-ported change (removing ParallelGCThreads == 0) > requires an additional cast of the ParallelGCThreads variable (which is > uintx) to be comparable to an integer zero constant. > > Note that this change is based on "8060025: Object copy time regressions > after JDK-8031323 and JDK-8057536" which is also out for review > > Full 8u60 changeset: > http://cr.openjdk.java.net/~tschatzl/8053998-8u60/webrev.8u60/ > Diff changest: > http://cr.openjdk.java.net/~tschatzl/8053998-8u60/webrev.8u60-fix/ Looks good. /Mikael > > CR: > https://bugs.openjdk.java.net/browse/JDK-8053998 > > Original change: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7894458add89 > > Testing: jprt > > Thanks, > Thomas > > From mikael.gerdin at oracle.com Thu Mar 26 08:28:18 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 26 Mar 2015 09:28:18 +0100 Subject: [8u60] RFR backport of 8069273: Decrease Hot Card Cache Lock contention In-Reply-To: <1427296938.3163.49.camel@oracle.com> References: <1427296938.3163.49.camel@oracle.com> Message-ID: <5513C322.2000509@oracle.com> Hi Thomas, On 2015-03-25 16:22, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the backport of "8069273: Decrease Hot Card > Cache Lock contention" for 8u60? > > It did only apply with minor changes, so I need re-reviews. The problems > are: > - some previous, non-ported changed the copyright date > - 8u60 does not have size_t versions of the Atomic instructions, fixed > by casting to intptr_t (as done elsewhere in this case) > - removing the HotCardCache_lock needed to be done manually, as > somewhere the declaration order of locks changed in mutexLocker.cpp. > > Note that this change is based on "JDK-8053998: Hot card cache flush > chunk size too coarse grained", which is also out for review. > > Full 8u60 changeset: > http://cr.openjdk.java.net/~tschatzl/8069273-8u60/webrev.8u60/ > Diff changest: > http://cr.openjdk.java.net/~tschatzl/8069273-8u60/webrev.8u60-fix/ Looks good. /Mikael > > CR: > https://bugs.openjdk.java.net/browse/JDK-8069273 > > Original change: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1c8ba2d0d2f0 > > Testing: jprt > > Thanks, > Thomas > > From mikael.gerdin at oracle.com Thu Mar 26 08:32:17 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 26 Mar 2015 09:32:17 +0100 Subject: [8u60] RFR backport of 8067655: Clean up G1 remembered set oop iteration In-Reply-To: <1427298177.3163.57.camel@oracle.com> References: <1427298177.3163.57.camel@oracle.com> Message-ID: <5513C411.30504@oracle.com> Hi Thomas, On 2015-03-25 16:42, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the backport of "8067655: Clean up G1 > remembered set oop iteration" for 8u60? > > It did only apply with minor changes, so I need re-reviews. The problems > are > - some guarantee that is still in jdk8u in G1RemSet::G1RemSet(), but has > been removed in jdk9 > - in jdk9, FREE_C_HEAP_ARRAY does not need the type specifier ("mtGC") > any more > - CountNonCleanMemRegionClosure moved in jdk9 > > Note that this change is based on "8069273: Decrease Hot Card Cache Lock > contention" which is also out for review, and "8069760: When iterating > over a card, G1 often iterates over much more..." which applied cleanly > (hence no RFR for that one). > > Full 8u60 changeset: > http://cr.openjdk.java.net/~tschatzl/8067655-8u60/webrev.8u60/ > Diff changest: > http://cr.openjdk.java.net/~tschatzl/8067655-8u60/webrev.8u60-fix/ Looks good. /Mikael > > CR: > https://bugs.openjdk.java.net/browse/JDK-8067655 > > Original change: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6aa9ea790814 > > Testing: jprt > > Thanks, > Thomas > > From mikael.gerdin at oracle.com Thu Mar 26 08:35:47 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 26 Mar 2015 09:35:47 +0100 Subject: [8u60] RFR of backport for 8067469: G1 ignores AlwaysPreTouch In-Reply-To: <1427319061.3220.5.camel@oracle.com> References: <1427319061.3220.5.camel@oracle.com> Message-ID: <5513C4E3.4080700@oracle.com> On 2015-03-25 22:31, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the backport of "8067469: G1 ignores > AlwaysPreTouch" for 8u60? > > It did only apply with minor changes, so I need re-reviews. The problem > is that JDK-8062063 that has been pushed later has already been > backported to 8u. > > Note that this change is based on "8067655: Clean up G1 remembered set > oop iteration" which is also out for review, and "8049536: > os::commit_memory on Solaris uses alignment_hint as page size" which > applied cleanly (hence no RFR for that one). I have some sort of recollection that 8049536 causes some regression with large pages, but I may be misremembering. Erik, do you remember? > > Full 8u60 changeset: > http://cr.openjdk.java.net/~tschatzl/8067469-8u60/webrev.8u60/ > Diff changest: > http://cr.openjdk.java.net/~tschatzl/8067469-8u60/webrev.8u60-fix/ The backport looks good. /Mikael > > CR: > https://bugs.openjdk.java.net/browse/JDK-8067469 > Original change: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d87c2d9c1eb4 > > Testing: jprt > > Thanks, > Thomas > > > > From thomas.schatzl at oracle.com Thu Mar 26 08:47:40 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 26 Mar 2015 09:47:40 +0100 Subject: RFR (L): 8058354: SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting with 9-b29 In-Reply-To: <55138144.6000406@oracle.com> References: <1422527439.3309.8.camel@oracle.com> <54CC0BCC.2090009@oracle.com> <1422959222.3368.4.camel@oracle.com> <54D11432.5050006@oracle.com> <1424162109.3163.2.camel@oracle.com> <54E75013.9010404@oracle.com> <1424446165.3267.13.camel@oracle.com> <1426683926.5616.6.camel@oracle.com> <55138144.6000406@oracle.com> Message-ID: <1427359660.3149.6.camel@oracle.com> Hi Jon, On Wed, 2015-03-25 at 20:47 -0700, Jon Masamitsu wrote: > Thomas, > > Haven't gotten very far but let me send you one question. > > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.2_to_3/src/share/vm/gc_implementation/g1/g1PageBasedVirtualSpace.cpp.frames.html > > > 157 void G1PageBasedVirtualSpace::commit_tail() { > > 158 char* const aligned_end_address = (char*)align_ptr_down(_high_boundary, _page_size); > > 159 size_t const tail_size = pointer_delta(_high_boundary, aligned_end_address, sizeof(char)); > > Should there be a check that tail_size is not 0 before attempting to > commit it? commit_tail() can only be called if is_last_page_partial() is true, i.e. tail_size > 0. I can add an assert for that. Thanks, Thomas From thomas.schatzl at oracle.com Thu Mar 26 09:13:01 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 26 Mar 2015 10:13:01 +0100 Subject: [8u60] RFR of backport for 8067469: G1 ignores AlwaysPreTouch In-Reply-To: <5513C4E3.4080700@oracle.com> References: <1427319061.3220.5.camel@oracle.com> <5513C4E3.4080700@oracle.com> Message-ID: <1427361181.3149.7.camel@oracle.com> Hi, On Thu, 2015-03-26 at 09:35 +0100, Mikael Gerdin wrote: > On 2015-03-25 22:31, Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for the backport of "8067469: G1 ignores > > AlwaysPreTouch" for 8u60? > > > > It did only apply with minor changes, so I need re-reviews. The problem > > is that JDK-8062063 that has been pushed later has already been > > backported to 8u. > > > > Note that this change is based on "8067655: Clean up G1 remembered set > > oop iteration" which is also out for review, and "8049536: > > os::commit_memory on Solaris uses alignment_hint as page size" which > > applied cleanly (hence no RFR for that one). > > I have some sort of recollection that 8049536 causes some regression > with large pages, but I may be misremembering. > Erik, do you remember? Backporting "JDK-8049864 TestParallelHeapSizeFlags fails with unexpected heap size" is next on my list. Then there is 8053995, 8066875, and finally, as soon as it has completed some jdk9 nightlies, 8058354 :) Thanks for this and the many other reviews, Thomas From bengt.rutisson at oracle.com Thu Mar 26 09:10:42 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 26 Mar 2015 10:10:42 +0100 Subject: RFR: 8075957: Reduce calls to the GC specific object visitors in oopDesc In-Reply-To: <5512CE10.7030805@oracle.com> References: <5512CE10.7030805@oracle.com> Message-ID: <5513CD12.5010200@oracle.com> Hi Stefan, On 2015-03-25 16:02, Stefan Karlsson wrote: > Hi, > > Please review this refactoring patch: > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/ Looks good. Bengt > https://bugs.openjdk.java.net/browse/JDK-8075957 > > Some of our GCs have GC specific entry points and code placed in the > oopDesc and Klass files. They are used to implement marking, > scavenging and adjusting of oops in the the objects. See the following > functions: > > Mark Sweep: > void follow_contents(void); > int adjust_pointers(); > > Parallel Scavenge > void push_contents(PSPromotionManager* pm); > > Parallel Old > void update_contents(ParCompactionManager* cm); > void follow_contents(ParCompactionManager* cm); > > With JDK-8075955 we'll start to use parts of the oop_oop_iterate > framework to implement these functions, and as a preparation patch I'd > like to minimize the number of places where these functions are > directly called from Mark Sweep, Parallel Scavenge and Parallel Old. > > The proposal is to add thin wrapper functions to the three GCs, and > let these wrappers be the only callers of the functions above. > > > Detailed description of the patch: > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1MarkSweep.cpp.udiff.html > > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1ParScanThreadState.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp.udiff.html > > - Wrapper declarations > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.inline.hpp.udiff.html > > - Wrapper definitions > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp.udiff.html > > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > - Call to GC wrapper function > - Moved definition of do_addr since it was only used in the .cpp, > placed in the .hpp file, and used other .inline.hpp files. > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp.udiff.html > > - Moved definition of do_addr since it was only used in the .cpp, > placed in the .hpp file, and used other .inline.hpp files. > - Removed dead code (follow_root) that referred to one of the object > visitors. > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp.udiff.html > > - Wrapper declaration > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp.udiff.html > > - Wrapper declarations > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.cpp.udiff.html > > - Wrapper definition > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.hpp.udiff.html > > - Wrapper declarations > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.inline.hpp.udiff.html > > - Wrapper definitions > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/memory/space.inline.hpp.udiff.html > > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceMirrorKlass.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceRefKlass.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/objArrayKlass.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > No copyright years have been updated. > > Thanks, > StefanK > From mikael.gerdin at oracle.com Thu Mar 26 09:34:23 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 26 Mar 2015 10:34:23 +0100 Subject: RFR: 8075957: Reduce calls to the GC specific object visitors in oopDesc In-Reply-To: <5512CE10.7030805@oracle.com> References: <5512CE10.7030805@oracle.com> Message-ID: <5513D29F.2090301@oracle.com> Hi Stefan, On 2015-03-25 16:02, Stefan Karlsson wrote: > Hi, > > Please review this refactoring patch: > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8075957 > > Some of our GCs have GC specific entry points and code placed in the > oopDesc and Klass files. They are used to implement marking, scavenging > and adjusting of oops in the the objects. See the following functions: > > Mark Sweep: > void follow_contents(void); > int adjust_pointers(); > > Parallel Scavenge > void push_contents(PSPromotionManager* pm); > > Parallel Old > void update_contents(ParCompactionManager* cm); > void follow_contents(ParCompactionManager* cm); > > With JDK-8075955 we'll start to use parts of the oop_oop_iterate > framework to implement these functions, and as a preparation patch I'd > like to minimize the number of places where these functions are directly > called from Mark Sweep, Parallel Scavenge and Parallel Old. > > The proposal is to add thin wrapper functions to the three GCs, and let > these wrappers be the only callers of the functions above. > > > Detailed description of the patch: > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1MarkSweep.cpp.udiff.html > > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1ParScanThreadState.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp.udiff.html > > - Wrapper declarations > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.inline.hpp.udiff.html 55 inline void ParCompactionManager::follow_contents(objArrayOop obj, int index) { 56 ObjArrayKlass* k = (ObjArrayKlass*)obj->klass(); 57 k->oop_follow_contents(obj, index); 58 } That should be k->oop_follow_contents(this, obj, index) Otherwise you end up in the MarkSweep code instead of ParCompact. The rest of the change looks good. Again, excellent cleanups! /Mikael > > - Wrapper definitions > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp.udiff.html > > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > - Call to GC wrapper function > - Moved definition of do_addr since it was only used in the .cpp, placed > in the .hpp file, and used other .inline.hpp files. > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp.udiff.html > > - Moved definition of do_addr since it was only used in the .cpp, placed > in the .hpp file, and used other .inline.hpp files. > - Removed dead code (follow_root) that referred to one of the object > visitors. > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp.udiff.html > > - Wrapper declaration > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp.udiff.html > > - Wrapper declarations > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.cpp.udiff.html > > - Wrapper definition > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.hpp.udiff.html > > - Wrapper declarations > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.inline.hpp.udiff.html > > - Wrapper definitions > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/memory/space.inline.hpp.udiff.html > > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceMirrorKlass.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceRefKlass.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/objArrayKlass.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > No copyright years have been updated. > > Thanks, > StefanK > From david.lindholm at oracle.com Thu Mar 26 09:47:21 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Thu, 26 Mar 2015 10:47:21 +0100 Subject: RFR: 8076054 - g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files Message-ID: <5513D5A9.2090703@oracle.com> Hi, Please review this fix that removes the macro PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc warnings for the format strings. Some files had this macro even though there were no warnings in them. This patch deals with all the G1 source files that had this macro. There will be separate patches for the other collectors. Webrev: http://cr.openjdk.java.net/~ehelin/david/8076054/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8076054 Testing done: Passed JPRT Thanks, David From thomas.schatzl at oracle.com Thu Mar 26 09:51:00 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 26 Mar 2015 10:51:00 +0100 Subject: [8u60] RFR of backport for 8049864: TestParallelHeapSizeFlags fails with unexpected heap size Message-ID: <1427363460.3149.13.camel@oracle.com> Hi all, can I have reviews for the backport of "8049864: TestParallelHeapSizeFlags fails with unexpected heap size" for 8u60? It did only apply with minor changes, so I need re-reviews. The problem is that the test TestParallelHeapSizeFlags.java, during a few intermediate steps (where an initial patch had been pushed, then reverted) got an @ignore tag added, changed and later removed. The problem is that in the original revision, this code removed the final @ignore, however since I did not backport all these 5 or 6 additional changes (which also touch other files sometimes), there is a conflict in removing the @ignore flag. I.e this hunk --- a/test/gc/arguments/TestParallelHeapSizeFlags.java Mon Sep 15 13:32:30 2014 +0000 +++ b/test/gc/arguments/TestParallelHeapSizeFlags.java Tue Jun 24 15:50:50 2014 +0200 @@ -22,7 +22,6 @@ */ /* - * @ignore 8049864 * @test TestParallelHeapSizeFlags * @key gc * @bug 8006088 Is not required for the backport. Note that this change is based on "8067469: G1 ignores AlwaysPreTouch" which is also out for review. It fixes "8049536: os::commit_memory on Solaris uses alignment_hint as page size". Full 8u60 changeset: http://cr.openjdk.java.net/~tschatzl/8049864-8u60/webrev.8u60/ CR: https://bugs.openjdk.java.net/browse/JDK-8049864 Original change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b326a3e8dcab Testing: jprt Thanks, Thomas From per.liden at oracle.com Thu Mar 26 10:05:12 2015 From: per.liden at oracle.com (Per Liden) Date: Thu, 26 Mar 2015 11:05:12 +0100 Subject: RFR: 8075957: Reduce calls to the GC specific object visitors in oopDesc In-Reply-To: <5512CE10.7030805@oracle.com> References: <5512CE10.7030805@oracle.com> Message-ID: <5513D9D8.4000503@oracle.com> Hi, Inline On 2015-03-25 16:02, Stefan Karlsson wrote: > Hi, > > Please review this refactoring patch: > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8075957 > > Some of our GCs have GC specific entry points and code placed in the > oopDesc and Klass files. They are used to implement marking, scavenging > and adjusting of oops in the the objects. See the following functions: > > Mark Sweep: > void follow_contents(void); > int adjust_pointers(); > > Parallel Scavenge > void push_contents(PSPromotionManager* pm); > > Parallel Old > void update_contents(ParCompactionManager* cm); > void follow_contents(ParCompactionManager* cm); > > With JDK-8075955 we'll start to use parts of the oop_oop_iterate > framework to implement these functions, and as a preparation patch I'd > like to minimize the number of places where these functions are directly > called from Mark Sweep, Parallel Scavenge and Parallel Old. > > The proposal is to add thin wrapper functions to the three GCs, and let > these wrappers be the only callers of the functions above. > > > Detailed description of the patch: > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1MarkSweep.cpp.udiff.html > > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1ParScanThreadState.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp.udiff.html > > - Wrapper declarations > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.inline.hpp.udiff.html > > - Wrapper definitions > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp.udiff.html > > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > - Call to GC wrapper function > - Moved definition of do_addr since it was only used in the .cpp, placed > in the .hpp file, and used other .inline.hpp files. > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp.udiff.html > > - Moved definition of do_addr since it was only used in the .cpp, placed > in the .hpp file, and used other .inline.hpp files. > - Removed dead code (follow_root) that referred to one of the object > visitors. > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp.udiff.html > > - Wrapper declaration > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp.udiff.html > > - Wrapper declarations > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.cpp.udiff.html > > - Wrapper definition > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.hpp.udiff.html > > - Wrapper declarations > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.inline.hpp.udiff.html > > - Wrapper definitions 61 inline void MarkSweep::follow_object(oop obj) { 62 obj->follow_contents(); 63 } 64 65 template inline void MarkSweep::follow_root(T* p) { 66 assert(!Universe::heap()->is_in_reserved(p), 67 "roots shouldn't be things within the heap"); 68 T heap_oop = oopDesc::load_heap_oop(p); 69 if (!oopDesc::is_null(heap_oop)) { 70 oop obj = oopDesc::decode_heap_oop_not_null(heap_oop); 71 if (!obj->mark()->is_marked()) { 72 mark_object(obj); 73 obj->follow_contents(); 74 } 75 } 76 follow_stack(); 77 } Line 73 should be a call to follow_object(obj) Other than that the change looks good! /Per > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/memory/space.inline.hpp.udiff.html > > - Call to GC wrapper function > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceMirrorKlass.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceRefKlass.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/objArrayKlass.cpp.udiff.html > > - Include of oop.pcgc.inline.hpp not needed > > No copyright years have been updated. > > Thanks, > StefanK > From stefan.karlsson at oracle.com Thu Mar 26 10:15:46 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 26 Mar 2015 11:15:46 +0100 Subject: RFR: 8075957: Reduce calls to the GC specific object visitors in oopDesc In-Reply-To: <5513D29F.2090301@oracle.com> References: <5512CE10.7030805@oracle.com> <5513D29F.2090301@oracle.com> Message-ID: <5513DC52.2020909@oracle.com> On 2015-03-26 10:34, Mikael Gerdin wrote: > Hi Stefan, > > On 2015-03-25 16:02, Stefan Karlsson wrote: >> Hi, >> >> Please review this refactoring patch: >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8075957 >> >> Some of our GCs have GC specific entry points and code placed in the >> oopDesc and Klass files. They are used to implement marking, scavenging >> and adjusting of oops in the the objects. See the following functions: >> >> Mark Sweep: >> void follow_contents(void); >> int adjust_pointers(); >> >> Parallel Scavenge >> void push_contents(PSPromotionManager* pm); >> >> Parallel Old >> void update_contents(ParCompactionManager* cm); >> void follow_contents(ParCompactionManager* cm); >> >> With JDK-8075955 we'll start to use parts of the oop_oop_iterate >> framework to implement these functions, and as a preparation patch I'd >> like to minimize the number of places where these functions are directly >> called from Mark Sweep, Parallel Scavenge and Parallel Old. >> >> The proposal is to add thin wrapper functions to the three GCs, and let >> these wrappers be the only callers of the functions above. >> >> >> Detailed description of the patch: >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1MarkSweep.cpp.udiff.html >> >> >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1ParScanThreadState.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp.udiff.html >> >> >> - Wrapper declarations >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.inline.hpp.udiff.html >> > > 55 inline void ParCompactionManager::follow_contents(objArrayOop > obj, int index) { > 56 ObjArrayKlass* k = (ObjArrayKlass*)obj->klass(); > 57 k->oop_follow_contents(obj, index); > 58 } > > That should be k->oop_follow_contents(this, obj, index) > Otherwise you end up in the MarkSweep code instead of ParCompact. Yes, you're right. This was introduced when I extracted this patch out from the JDK-8075955 patch. This fails immediately when I start SPECjbb2005. > > The rest of the change looks good. > > Again, excellent cleanups! Thanks, Mikael! StefanK > > /Mikael > > >> >> - Wrapper definitions >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp.udiff.html >> >> >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> - Call to GC wrapper function >> - Moved definition of do_addr since it was only used in the .cpp, placed >> in the .hpp file, and used other .inline.hpp files. >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp.udiff.html >> >> >> - Moved definition of do_addr since it was only used in the .cpp, placed >> in the .hpp file, and used other .inline.hpp files. >> - Removed dead code (follow_root) that referred to one of the object >> visitors. >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp.udiff.html >> >> >> - Wrapper declaration >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp.udiff.html >> >> >> - Wrapper declarations >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.cpp.udiff.html >> >> >> - Wrapper definition >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.hpp.udiff.html >> >> >> - Wrapper declarations >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.inline.hpp.udiff.html >> >> >> - Wrapper definitions >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/memory/space.inline.hpp.udiff.html >> >> >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceMirrorKlass.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceRefKlass.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/objArrayKlass.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> No copyright years have been updated. >> >> Thanks, >> StefanK >> > From stefan.karlsson at oracle.com Thu Mar 26 10:16:34 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 26 Mar 2015 11:16:34 +0100 Subject: RFR: 8075957: Reduce calls to the GC specific object visitors in oopDesc In-Reply-To: <5513D9D8.4000503@oracle.com> References: <5512CE10.7030805@oracle.com> <5513D9D8.4000503@oracle.com> Message-ID: <5513DC82.7060705@oracle.com> On 2015-03-26 11:05, Per Liden wrote: > Hi, > > Inline > > On 2015-03-25 16:02, Stefan Karlsson wrote: >> Hi, >> >> Please review this refactoring patch: >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8075957 >> >> Some of our GCs have GC specific entry points and code placed in the >> oopDesc and Klass files. They are used to implement marking, scavenging >> and adjusting of oops in the the objects. See the following functions: >> >> Mark Sweep: >> void follow_contents(void); >> int adjust_pointers(); >> >> Parallel Scavenge >> void push_contents(PSPromotionManager* pm); >> >> Parallel Old >> void update_contents(ParCompactionManager* cm); >> void follow_contents(ParCompactionManager* cm); >> >> With JDK-8075955 we'll start to use parts of the oop_oop_iterate >> framework to implement these functions, and as a preparation patch I'd >> like to minimize the number of places where these functions are directly >> called from Mark Sweep, Parallel Scavenge and Parallel Old. >> >> The proposal is to add thin wrapper functions to the three GCs, and let >> these wrappers be the only callers of the functions above. >> >> >> Detailed description of the patch: >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1MarkSweep.cpp.udiff.html >> >> >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/g1/g1ParScanThreadState.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp.udiff.html >> >> >> - Wrapper declarations >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.inline.hpp.udiff.html >> >> >> - Wrapper definitions >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp.udiff.html >> >> >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> - Call to GC wrapper function >> - Moved definition of do_addr since it was only used in the .cpp, placed >> in the .hpp file, and used other .inline.hpp files. >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp.udiff.html >> >> >> - Moved definition of do_addr since it was only used in the .cpp, placed >> in the .hpp file, and used other .inline.hpp files. >> - Removed dead code (follow_root) that referred to one of the object >> visitors. >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp.udiff.html >> >> >> - Wrapper declaration >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp.udiff.html >> >> >> - Wrapper declarations >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.cpp.udiff.html >> >> >> - Wrapper definition >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.hpp.udiff.html >> >> >> - Wrapper declarations >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/gc_implementation/shared/markSweep.inline.hpp.udiff.html >> >> >> - Wrapper definitions > > 61 inline void MarkSweep::follow_object(oop obj) { > 62 obj->follow_contents(); > 63 } > 64 > 65 template inline void MarkSweep::follow_root(T* p) { > 66 assert(!Universe::heap()->is_in_reserved(p), > 67 "roots shouldn't be things within the heap"); > 68 T heap_oop = oopDesc::load_heap_oop(p); > 69 if (!oopDesc::is_null(heap_oop)) { > 70 oop obj = oopDesc::decode_heap_oop_not_null(heap_oop); > 71 if (!obj->mark()->is_marked()) { > 72 mark_object(obj); > 73 obj->follow_contents(); > 74 } > 75 } > 76 follow_stack(); > 77 } > > Line 73 should be a call to follow_object(obj) Yes, I missed to bring that over from the original patch. > > Other than that the change looks good! Thanks, Per! StefanK > > /Per > >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/memory/space.inline.hpp.udiff.html >> >> >> - Call to GC wrapper function >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceClassLoaderKlass.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceKlass.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceMirrorKlass.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/instanceRefKlass.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> http://cr.openjdk.java.net/~stefank/8075957/webrev.01/src/share/vm/oops/objArrayKlass.cpp.udiff.html >> >> >> - Include of oop.pcgc.inline.hpp not needed >> >> No copyright years have been updated. >> >> Thanks, >> StefanK >> From bengt.rutisson at oracle.com Thu Mar 26 11:57:26 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 26 Mar 2015 12:57:26 +0100 Subject: RFR: Backport JDK-8074037, JDK-8075210, JDK-8027962 and also JDK-8061630, JDK-8051837 to 8u In-Reply-To: <5512ADD3.7010107@oracle.com> References: <5512ADD3.7010107@oracle.com> Message-ID: <5513F426.4030606@oracle.com> Hi again, Thomas just pushed a backport for "JDK-8067655: Clean up G1 remembered set oop iteration". This simplifies my changes a bit. Here's an updated webrev of the export files: http://cr.openjdk.java.net/~brutisso/backport-8027962/exports.01/ and here's the diff compared to the last version: http://cr.openjdk.java.net/~brutisso/backport-8027962/exports.00-01.diff/ Thanks, Bengt On 2015-03-25 13:45, Bengt Rutisson wrote: > > Hi all, > > I would like to backport this fix to the 8 update repo: > > JDK-8027962: Per-phase timing measurements for strong roots processing > https://bugs.openjdk.java.net/browse/JDK-8027962 > > This fix was originally intended for the 8u branch. During the review > process it was decided to take on a couple of broader cleanup fixes to > make it easier to address JDK-8027962. So, the work was split up into > three separate changes. This means that to backport JDK-8027962 I also > need to backport these two changes: > > JDK-8074037: Refactor the G1GCPhaseTime logging to make it easier to > add new phases > https://bugs.openjdk.java.net/browse/JDK-8074037 > > JDK-8075210: Refactor strong root processing in order to allow G1 to > evolve separately from GenCollectedHeap > https://bugs.openjdk.java.net/browse/JDK-8075210 > > > The 8u branch has deviated a bit from the JDK 9 branch so the above > changesets do not apply cleanly. Two small fixes cause conflicts, so I > would like to backport those changes as well: > > JDK-8061630: G1 iterates over JNIHandles two time > https://bugs.openjdk.java.net/browse/JDK-8061630 > > JDK-8051837: Remove temporary G1UseParallelRSetUpdating and > G1UseParallelRSetScanning flags > https://bugs.openjdk.java.net/browse/JDK-8051837 > > These two changes both apply cleanly to the 8u repo. > > There are also conflicts due to other changes that have not been > backported. I prefer *not* to backport these since I think they are > too intrusive: > > JDK-6979279: remove special-case code for ParallelGCThreads==0 > JDK-8039244: Don't use UINT32_FORMAT and INT32_FORMAT when printing > uints and ints in the GC code > JDK-8060074: os::free() takes MemoryTrackingLevel but doesn't need it > JDK-8044775: Improve usage of umbrella header atomic.inline.hpp > JDK-8062206: Remove unusable G1RSLogCheckCardTable command line argument > > Instead I manually fixed the conflicts in two ways. I prepared the 8u > repo with the following fix: > > http://cr.openjdk.java.net/~brutisso/backport-8027962/preparation/ > > And then I patched the export files for the changesets to apply > cleanly. Here are webreves for the patches to the exports: > > http://cr.openjdk.java.net/~brutisso/backport-8027962/exports/ > > And here are the resulting webrevs for the three changes: > > http://cr.openjdk.java.net/~brutisso/backport-8027962/8027962/ > http://cr.openjdk.java.net/~brutisso/backport-8027962/8075210/ > http://cr.openjdk.java.net/~brutisso/backport-8027962/8074037/ > > I realize that this is difficult to review. Let me know if there is > more I can do to ease up the review. > > Thanks, > Bengt > > From bengt.rutisson at oracle.com Thu Mar 26 12:06:08 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 26 Mar 2015 13:06:08 +0100 Subject: RFR: 8076054 - g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <5513D5A9.2090703@oracle.com> References: <5513D5A9.2090703@oracle.com> Message-ID: <5513F630.9070707@oracle.com> Hi David, On 2015-03-26 10:47, David Lindholm wrote: > Hi, > > Please review this fix that removes the macro > PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc > warnings for the format strings. Some files had this macro even though > there were no warnings in them. > > This patch deals with all the G1 source files that had this macro. > There will be separate patches for the other collectors. > > Webrev: http://cr.openjdk.java.net/~ehelin/david/8076054/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8076054 Looks good to me. Thanks for doing this cleanup! I can sponsor the fix. Bengt > > Testing done: Passed JPRT > > > Thanks, > David From mikael.gerdin at oracle.com Thu Mar 26 12:16:21 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 26 Mar 2015 13:16:21 +0100 Subject: RFR: Backport JDK-8074037, JDK-8075210, JDK-8027962 and also JDK-8061630, JDK-8051837 to 8u In-Reply-To: <5513F426.4030606@oracle.com> References: <5512ADD3.7010107@oracle.com> <5513F426.4030606@oracle.com> Message-ID: <5513F895.70206@oracle.com> Hi Bengt, On 2015-03-26 12:57, Bengt Rutisson wrote: > > Hi again, > > Thomas just pushed a backport for "JDK-8067655: Clean up G1 remembered > set oop iteration". This simplifies my changes a bit. Here's an updated > webrev of the export files: > > http://cr.openjdk.java.net/~brutisso/backport-8027962/exports.01/ The backports look good to me. /Mikael > > and here's the diff compared to the last version: > > http://cr.openjdk.java.net/~brutisso/backport-8027962/exports.00-01.diff/ > > Thanks, > Bengt > > On 2015-03-25 13:45, Bengt Rutisson wrote: >> >> Hi all, >> >> I would like to backport this fix to the 8 update repo: >> >> JDK-8027962: Per-phase timing measurements for strong roots processing >> https://bugs.openjdk.java.net/browse/JDK-8027962 >> >> This fix was originally intended for the 8u branch. During the review >> process it was decided to take on a couple of broader cleanup fixes to >> make it easier to address JDK-8027962. So, the work was split up into >> three separate changes. This means that to backport JDK-8027962 I also >> need to backport these two changes: >> >> JDK-8074037: Refactor the G1GCPhaseTime logging to make it easier to >> add new phases >> https://bugs.openjdk.java.net/browse/JDK-8074037 >> >> JDK-8075210: Refactor strong root processing in order to allow G1 to >> evolve separately from GenCollectedHeap >> https://bugs.openjdk.java.net/browse/JDK-8075210 >> >> >> The 8u branch has deviated a bit from the JDK 9 branch so the above >> changesets do not apply cleanly. Two small fixes cause conflicts, so I >> would like to backport those changes as well: >> >> JDK-8061630: G1 iterates over JNIHandles two time >> https://bugs.openjdk.java.net/browse/JDK-8061630 >> >> JDK-8051837: Remove temporary G1UseParallelRSetUpdating and >> G1UseParallelRSetScanning flags >> https://bugs.openjdk.java.net/browse/JDK-8051837 >> >> These two changes both apply cleanly to the 8u repo. >> >> There are also conflicts due to other changes that have not been >> backported. I prefer *not* to backport these since I think they are >> too intrusive: >> >> JDK-6979279: remove special-case code for ParallelGCThreads==0 >> JDK-8039244: Don't use UINT32_FORMAT and INT32_FORMAT when printing >> uints and ints in the GC code >> JDK-8060074: os::free() takes MemoryTrackingLevel but doesn't need it >> JDK-8044775: Improve usage of umbrella header atomic.inline.hpp >> JDK-8062206: Remove unusable G1RSLogCheckCardTable command line argument >> >> Instead I manually fixed the conflicts in two ways. I prepared the 8u >> repo with the following fix: >> >> http://cr.openjdk.java.net/~brutisso/backport-8027962/preparation/ >> >> And then I patched the export files for the changesets to apply >> cleanly. Here are webreves for the patches to the exports: >> >> http://cr.openjdk.java.net/~brutisso/backport-8027962/exports/ >> >> And here are the resulting webrevs for the three changes: >> >> http://cr.openjdk.java.net/~brutisso/backport-8027962/8027962/ >> http://cr.openjdk.java.net/~brutisso/backport-8027962/8075210/ >> http://cr.openjdk.java.net/~brutisso/backport-8027962/8074037/ >> >> I realize that this is difficult to review. Let me know if there is >> more I can do to ease up the review. >> >> Thanks, >> Bengt >> >> > From bengt.rutisson at oracle.com Thu Mar 26 12:14:40 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 26 Mar 2015 13:14:40 +0100 Subject: RFR: Backport JDK-8074037, JDK-8075210, JDK-8027962 and also JDK-8061630, JDK-8051837 to 8u In-Reply-To: <5513F895.70206@oracle.com> References: <5512ADD3.7010107@oracle.com> <5513F426.4030606@oracle.com> <5513F895.70206@oracle.com> Message-ID: <5513F830.6060605@oracle.com> On 2015-03-26 13:16, Mikael Gerdin wrote: > Hi Bengt, > > On 2015-03-26 12:57, Bengt Rutisson wrote: >> >> Hi again, >> >> Thomas just pushed a backport for "JDK-8067655: Clean up G1 remembered >> set oop iteration". This simplifies my changes a bit. Here's an updated >> webrev of the export files: >> >> http://cr.openjdk.java.net/~brutisso/backport-8027962/exports.01/ > > The backports look good to me. Thanks Mikael! Bengt > > /Mikael > >> >> and here's the diff compared to the last version: >> >> http://cr.openjdk.java.net/~brutisso/backport-8027962/exports.00-01.diff/ >> >> >> Thanks, >> Bengt >> >> On 2015-03-25 13:45, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> I would like to backport this fix to the 8 update repo: >>> >>> JDK-8027962: Per-phase timing measurements for strong roots processing >>> https://bugs.openjdk.java.net/browse/JDK-8027962 >>> >>> This fix was originally intended for the 8u branch. During the review >>> process it was decided to take on a couple of broader cleanup fixes to >>> make it easier to address JDK-8027962. So, the work was split up into >>> three separate changes. This means that to backport JDK-8027962 I also >>> need to backport these two changes: >>> >>> JDK-8074037: Refactor the G1GCPhaseTime logging to make it easier to >>> add new phases >>> https://bugs.openjdk.java.net/browse/JDK-8074037 >>> >>> JDK-8075210: Refactor strong root processing in order to allow G1 to >>> evolve separately from GenCollectedHeap >>> https://bugs.openjdk.java.net/browse/JDK-8075210 >>> >>> >>> The 8u branch has deviated a bit from the JDK 9 branch so the above >>> changesets do not apply cleanly. Two small fixes cause conflicts, so I >>> would like to backport those changes as well: >>> >>> JDK-8061630: G1 iterates over JNIHandles two time >>> https://bugs.openjdk.java.net/browse/JDK-8061630 >>> >>> JDK-8051837: Remove temporary G1UseParallelRSetUpdating and >>> G1UseParallelRSetScanning flags >>> https://bugs.openjdk.java.net/browse/JDK-8051837 >>> >>> These two changes both apply cleanly to the 8u repo. >>> >>> There are also conflicts due to other changes that have not been >>> backported. I prefer *not* to backport these since I think they are >>> too intrusive: >>> >>> JDK-6979279: remove special-case code for ParallelGCThreads==0 >>> JDK-8039244: Don't use UINT32_FORMAT and INT32_FORMAT when printing >>> uints and ints in the GC code >>> JDK-8060074: os::free() takes MemoryTrackingLevel but doesn't need it >>> JDK-8044775: Improve usage of umbrella header atomic.inline.hpp >>> JDK-8062206: Remove unusable G1RSLogCheckCardTable command line >>> argument >>> >>> Instead I manually fixed the conflicts in two ways. I prepared the 8u >>> repo with the following fix: >>> >>> http://cr.openjdk.java.net/~brutisso/backport-8027962/preparation/ >>> >>> And then I patched the export files for the changesets to apply >>> cleanly. Here are webreves for the patches to the exports: >>> >>> http://cr.openjdk.java.net/~brutisso/backport-8027962/exports/ >>> >>> And here are the resulting webrevs for the three changes: >>> >>> http://cr.openjdk.java.net/~brutisso/backport-8027962/8027962/ >>> http://cr.openjdk.java.net/~brutisso/backport-8027962/8075210/ >>> http://cr.openjdk.java.net/~brutisso/backport-8027962/8074037/ >>> >>> I realize that this is difficult to review. Let me know if there is >>> more I can do to ease up the review. >>> >>> Thanks, >>> Bengt >>> >>> >> > From stefan.karlsson at oracle.com Thu Mar 26 12:21:19 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 26 Mar 2015 13:21:19 +0100 Subject: RFR: 8076054 - g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <5513D5A9.2090703@oracle.com> References: <5513D5A9.2090703@oracle.com> Message-ID: <5513F9BF.7050707@oracle.com> On 2015-03-26 10:47, David Lindholm wrote: > Hi, > > Please review this fix that removes the macro > PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc > warnings for the format strings. Some files had this macro even though > there were no warnings in them. > > This patch deals with all the G1 source files that had this macro. > There will be separate patches for the other collectors. > > Webrev: http://cr.openjdk.java.net/~ehelin/david/8076054/webrev.00/ Looks good. Thanks for fixing this! StefanK > Bug: https://bugs.openjdk.java.net/browse/JDK-8076054 > > Testing done: Passed JPRT > > > Thanks, > David From david.lindholm at oracle.com Thu Mar 26 12:23:03 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Thu, 26 Mar 2015 13:23:03 +0100 Subject: RFR: 8076054 - g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <5513F630.9070707@oracle.com> References: <5513D5A9.2090703@oracle.com> <5513F630.9070707@oracle.com> Message-ID: <5513FA27.6040504@oracle.com> Hi Bengt, Thanks for the review. /David On 2015-03-26 13:06, Bengt Rutisson wrote: > > Hi David, > > On 2015-03-26 10:47, David Lindholm wrote: >> Hi, >> >> Please review this fix that removes the macro >> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >> warnings for the format strings. Some files had this macro even >> though there were no warnings in them. >> >> This patch deals with all the G1 source files that had this macro. >> There will be separate patches for the other collectors. >> >> Webrev: http://cr.openjdk.java.net/~ehelin/david/8076054/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076054 > > Looks good to me. > > Thanks for doing this cleanup! I can sponsor the fix. > > Bengt > >> >> Testing done: Passed JPRT >> >> >> Thanks, >> David > From david.lindholm at oracle.com Thu Mar 26 12:23:29 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Thu, 26 Mar 2015 13:23:29 +0100 Subject: RFR: 8076054 - g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <5513F9BF.7050707@oracle.com> References: <5513D5A9.2090703@oracle.com> <5513F9BF.7050707@oracle.com> Message-ID: <5513FA41.50300@oracle.com> Hi Stefan, Thanks for the review! /David On 2015-03-26 13:21, Stefan Karlsson wrote: > > On 2015-03-26 10:47, David Lindholm wrote: >> Hi, >> >> Please review this fix that removes the macro >> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >> warnings for the format strings. Some files had this macro even >> though there were no warnings in them. >> >> This patch deals with all the G1 source files that had this macro. >> There will be separate patches for the other collectors. >> >> Webrev: http://cr.openjdk.java.net/~ehelin/david/8076054/webrev.00/ > > Looks good. Thanks for fixing this! > > StefanK > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076054 >> >> Testing done: Passed JPRT >> >> >> Thanks, >> David > From david.lindholm at oracle.com Thu Mar 26 12:40:34 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Thu, 26 Mar 2015 13:40:34 +0100 Subject: RFR_ 8076055 - cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files Message-ID: <5513FE42.3000407@oracle.com> Hi, Please review this fix that removes the macro PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc warnings for the format strings. Some files had this macro even though there were no warnings in them. This patch deals with all the cms source files that had this macro. There will be separate patches for the other collectors. Webrev: http://cr.openjdk.java.net/~brutisso/8076055/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8076055 Testing done: Passed JPRT Thanks, David From bengt.rutisson at oracle.com Thu Mar 26 12:37:38 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 26 Mar 2015 13:37:38 +0100 Subject: RFR_ 8076055 - cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <5513FE42.3000407@oracle.com> References: <5513FE42.3000407@oracle.com> Message-ID: <5513FD92.7090201@oracle.com> Hi David, On 2015-03-26 13:40, David Lindholm wrote: > Hi, > > Please review this fix that removes the macro > PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc > warnings for the format strings. Some files had this macro even though > there were no warnings in them. > > This patch deals with all the cms source files that had this macro. > There will be separate patches for the other collectors. > > Webrev: http://cr.openjdk.java.net/~brutisso/8076055/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8076055 Looks good. Bengt > > > Testing done: Passed JPRT > > > Thanks, > David From thomas.schatzl at oracle.com Thu Mar 26 12:54:59 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 26 Mar 2015 13:54:59 +0100 Subject: RFR_ 8076055 - cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <5513FE42.3000407@oracle.com> References: <5513FE42.3000407@oracle.com> Message-ID: <1427374499.3149.36.camel@oracle.com> Hi, On Thu, 2015-03-26 at 13:40 +0100, David Lindholm wrote: > Hi, > > Please review this fix that removes the macro > PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc > warnings for the format strings. Some files had this macro even though > there were no warnings in them. > > This patch deals with all the cms source files that had this macro. > There will be separate patches for the other collectors. > > Webrev: http://cr.openjdk.java.net/~brutisso/8076055/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8076055 > > Testing done: Passed JPRT looks good. Thomas From thomas.schatzl at oracle.com Thu Mar 26 12:55:16 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 26 Mar 2015 13:55:16 +0100 Subject: [8u60] RFR of backport for 8066875: VirtualSpace does not use large pages Message-ID: <1427374516.3149.37.camel@oracle.com> Hi all, can I have reviews for the backport of "8066875: VirtualSpace does not use large pages" for 8u60? I also would like to have one review from the compiler team (cc'ed) since the change touches some compiler files. It did only apply with minor changes, so I need re-reviews. The problem is that in jdk9 the code cache sizing has been changed. In particular: - dropped the hunk in code/codeCache.cpp because the code to determine memory sizes in 8u60 is much simpler i.e. . E.g. this change: --- a/src/share/vm/code/codeCache.cpp Thu Jan 15 16:05:20 2015 +0100 +++ b/src/share/vm/code/codeCache.cpp Fri Jan 16 10:29:12 2015 +0100 @@ -233,8 +233,8 @@ ReservedCodeSpace CodeCache::reserve_heap_memory(size_t size) { // Determine alignment const size_t page_size = os::can_execute_large_page_memory() ? - MIN2(os::page_size_for_region(InitialCodeCacheSize, 8), - os::page_size_for_region(size, 8)) : + MIN2(os::page_size_for_region_aligned(InitialCodeCacheSize, 8), + os::page_size_for_region_aligned(size, 8)) : os::vm_page_size(); const size_t granularity = os::vm_allocation_granularity(); const size_t r_align = MAX2(page_size, granularity); - fixed the code in heap.cpp because of the same change (JDK-8015774: Add support for multiple code heaps) is not in 8u60. Note that this change is based on "8049864: TestParallelHeapSizeFlags fails with unexpected heap size" which is also out for review (on hotspot-gc-dev), and "8053995: Add method to WhiteBox to get vm_pagesize" which applies cleanly. Full 8u60 changeset: http://cr.openjdk.java.net/~tschatzl/8066875-8u60/webrev.8u60/ Fix changeset: http://cr.openjdk.java.net/~tschatzl/8066875-8u60/webrev.8u60-fix/ CR: https://bugs.openjdk.java.net/browse/JDK-8066875 Original change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4321214d5dbc Testing: jprt With that changeset in place, JDK-8058354 can be merged relatively easily, which is the goal of most of the recent backports. Thanks, Thomas From david.lindholm at oracle.com Thu Mar 26 12:56:24 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Thu, 26 Mar 2015 13:56:24 +0100 Subject: RFR_ 8076055 - cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <5513FD92.7090201@oracle.com> References: <5513FE42.3000407@oracle.com> <5513FD92.7090201@oracle.com> Message-ID: <551401F8.6080404@oracle.com> Hi Bengt, Thanks for the review. /David On 2015-03-26 13:37, Bengt Rutisson wrote: > > Hi David, > > On 2015-03-26 13:40, David Lindholm wrote: >> Hi, >> >> Please review this fix that removes the macro >> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >> warnings for the format strings. Some files had this macro even >> though there were no warnings in them. >> >> This patch deals with all the cms source files that had this macro. >> There will be separate patches for the other collectors. >> >> Webrev: http://cr.openjdk.java.net/~brutisso/8076055/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076055 > > Looks good. > > Bengt > >> >> >> Testing done: Passed JPRT >> >> >> Thanks, >> David > From david.lindholm at oracle.com Thu Mar 26 12:57:10 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Thu, 26 Mar 2015 13:57:10 +0100 Subject: RFR_ 8076055 - cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <1427374499.3149.36.camel@oracle.com> References: <5513FE42.3000407@oracle.com> <1427374499.3149.36.camel@oracle.com> Message-ID: <55140226.40207@oracle.com> Hi Thomas, Thanks for the review. /David On 2015-03-26 13:54, Thomas Schatzl wrote: > Hi, > > On Thu, 2015-03-26 at 13:40 +0100, David Lindholm wrote: >> Hi, >> >> Please review this fix that removes the macro >> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >> warnings for the format strings. Some files had this macro even though >> there were no warnings in them. >> >> This patch deals with all the cms source files that had this macro. >> There will be separate patches for the other collectors. >> >> Webrev: http://cr.openjdk.java.net/~brutisso/8076055/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076055 >> >> Testing done: Passed JPRT > looks good. > > Thomas > > From bengt.rutisson at oracle.com Thu Mar 26 13:30:42 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 26 Mar 2015 14:30:42 +0100 Subject: RFR (S): JDK-8076076: Move SharedHeap::print_size_transition() into G1 code Message-ID: <55140A02.7050202@oracle.com> Hi everyone, One more step towards eventually getting rid of SharedHeap. Could I have a couple of reviews for this small change: http://cr.openjdk.java.net/~brutisso/8076076/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8076076 The method SharedHeap::print_size_transition() is only used by G1 but was placed in SharedHeap. It was called from the G1CollectorPolicy class, so I moved it to be next to the other related methods (G1CollectorPolicy::print_heap_transition() and G1CollectorPolicy::print_detailed_heap_transition()). I also renamed it to print_heap_transition() to be more consistent with the other two methods. Some simplifications to the parameter list could be made now that it is an internal G1 method. Thanks, Bengt From mikael.gerdin at oracle.com Thu Mar 26 14:37:44 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 26 Mar 2015 15:37:44 +0100 Subject: RFR (S): JDK-8076076: Move SharedHeap::print_size_transition() into G1 code In-Reply-To: <55140A02.7050202@oracle.com> References: <55140A02.7050202@oracle.com> Message-ID: <551419B8.1030005@oracle.com> Hi Bengt, On 2015-03-26 14:30, Bengt Rutisson wrote: > > Hi everyone, > > One more step towards eventually getting rid of SharedHeap. > > Could I have a couple of reviews for this small change: > > http://cr.openjdk.java.net/~brutisso/8076076/webrev.00/ Looks good to me. /Mikael > > https://bugs.openjdk.java.net/browse/JDK-8076076 > > The method SharedHeap::print_size_transition() is only used by G1 but > was placed in SharedHeap. It was called from the G1CollectorPolicy > class, so I moved it to be next to the other related methods > (G1CollectorPolicy::print_heap_transition() and > G1CollectorPolicy::print_detailed_heap_transition()). I also renamed it > to print_heap_transition() to be more consistent with the other two > methods. Some simplifications to the parameter list could be made now > that it is an internal G1 method. > > Thanks, > Bengt > From thomas.schatzl at oracle.com Thu Mar 26 14:43:01 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 26 Mar 2015 15:43:01 +0100 Subject: RFR (S): JDK-8076076: Move SharedHeap::print_size_transition() into G1 code In-Reply-To: <55140A02.7050202@oracle.com> References: <55140A02.7050202@oracle.com> Message-ID: <1427380981.3149.46.camel@oracle.com> Hi, On Thu, 2015-03-26 at 14:30 +0100, Bengt Rutisson wrote: > Hi everyone, > > One more step towards eventually getting rid of SharedHeap. > > Could I have a couple of reviews for this small change: > > http://cr.openjdk.java.net/~brutisso/8076076/webrev.00/ > > https://bugs.openjdk.java.net/browse/JDK-8076076 > > The method SharedHeap::print_size_transition() is only used by G1 but > was placed in SharedHeap. It was called from the G1CollectorPolicy > class, so I moved it to be next to the other related methods > (G1CollectorPolicy::print_heap_transition() and > G1CollectorPolicy::print_detailed_heap_transition()). I also renamed it > to print_heap_transition() to be more consistent with the other two > methods. Some simplifications to the parameter list could be made now > that it is an internal G1 method. looks good. Could you align the parameters of the gclog_or_tty->print_cr() in print_heap_transition()? I do not need another review for that. Thanks, Thomas From thomas.schatzl at oracle.com Thu Mar 26 15:11:28 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 26 Mar 2015 16:11:28 +0100 Subject: RFR (L): 8058354: SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting with 9-b29 In-Reply-To: <1427359660.3149.6.camel@oracle.com> References: <1422527439.3309.8.camel@oracle.com> <54CC0BCC.2090009@oracle.com> <1422959222.3368.4.camel@oracle.com> <54D11432.5050006@oracle.com> <1424162109.3163.2.camel@oracle.com> <54E75013.9010404@oracle.com> <1424446165.3267.13.camel@oracle.com> <1426683926.5616.6.camel@oracle.com> <55138144.6000406@oracle.com> <1427359660.3149.6.camel@oracle.com> Message-ID: <1427382688.3149.47.camel@oracle.com> Hi again, On Thu, 2015-03-26 at 09:47 +0100, Thomas Schatzl wrote: > Hi Jon, > > On Wed, 2015-03-25 at 20:47 -0700, Jon Masamitsu wrote: > > Thomas, > > > > Haven't gotten very far but let me send you one question. > > > > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.2_to_3/src/share/vm/gc_implementation/g1/g1PageBasedVirtualSpace.cpp.frames.html > > > > > 157 void G1PageBasedVirtualSpace::commit_tail() { > > > 158 char* const aligned_end_address = (char*)align_ptr_down(_high_boundary, _page_size); > > > 159 size_t const tail_size = pointer_delta(_high_boundary, aligned_end_address, sizeof(char)); > > > > Should there be a check that tail_size is not 0 before attempting to > > commit it? > > commit_tail() can only be called if is_last_page_partial() is true, > i.e. tail_size > 0. I can add an assert for that. Here's a change with that assert added. Full webrev: http://cr.openjdk.java.net/~tschatzl/8058354/webrev.4/ Diff: http://cr.openjdk.java.net/~tschatzl/8058354/webrev.3_to_4/ top-level changes: http://cr.openjdk.java.net/~tschatzl/8058354/webrev.hs-gc.1/ (there were no changes in it for months, just for completeness) Testing: another jprt round Thanks a lot, Thomas From jon.masamitsu at oracle.com Thu Mar 26 17:26:40 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 26 Mar 2015 10:26:40 -0700 Subject: RFR (L): 8058354: SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting with 9-b29 In-Reply-To: <1426683926.5616.6.camel@oracle.com> References: <1422527439.3309.8.camel@oracle.com> <54CC0BCC.2090009@oracle.com> <1422959222.3368.4.camel@oracle.com> <54D11432.5050006@oracle.com> <1424162109.3163.2.camel@oracle.com> <54E75013.9010404@oracle.com> <1424446165.3267.13.camel@oracle.com> <1426683926.5616.6.camel@oracle.com> Message-ID: <55144150.80106@oracle.com> Thomas, http://cr.openjdk.java.net/~tschatzl/8058354/webrev.2_to_3/src/share/vm/gc_implementation/g1/g1PageBasedVirtualSpace.cpp.frames.html Is rs.size() guaranteed to be "page_size" aligned? Or might you need 1 more page in "size_in_pages". 76 vmassert(_committed.size() == 0, "virtual space initialized more than once"); 77 BitMap::idx_t size_in_pages = rs.size() / page_size; 78 _committed.resize(size_in_pages, /* in_resource_area */ false); I would find these easier to read if "start" was "start_page". 122 bool G1PageBasedVirtualSpace::is_area_committed(size_t start, size_t size_in_pages) const { 123 size_t end = start + size_in_pages; 124 return _committed.get_next_zero_offset(start, end) >= end; 125 } 126 127 bool G1PageBasedVirtualSpace::is_area_uncommitted(size_t start, size_t size_in_pages) const { 128 size_t end = start + size_in_pages; 129 return _committed.get_next_one_offset(start, end) >= end; 130 } http://cr.openjdk.java.net/~tschatzl/8058354/webrev.2_to_3/src/share/vm/gc_implementation/g1/g1PageBasedVirtualSpace.hpp.frames.html I would prefer "commit_preferred_pages()" to "commit_full_pages()". The "full" in the name lead me to look for something about "full" page in the code. This is a throw away comment if "full" makes sense to you. Drop the "full" in the comment. 75 // Commit num_pages full pages of _page_size size starting from start. All argument 76 // checking has been performed. 77 void commit_full_pages(size_t start_page, size_t end_page); In the comments is the sentence with "start address" needed? Since these are page indexes. I'd suggest adding a comment // Helper function for committing memory. Because this code is about committing in different ranges (the whole _page_size range and the tail range), when I read "internal" in the name, I thought it had to do with committing "internal" pages. After reading the code and the surrounding code I understood the "internal" implied a helper function. 71 // Commit the given memory range by using _page_size pages as much as possible 72 // and the remainder with small sized pages. The start address must be _page_size 73 // aligned. 74 void commit_internal(size_t start_page, size_t end_page); For 78 // Commit the tail area. 79 void commit_tail(); would this be a correct description? // Commit space at the high end of the VirtualSpace // that is smaller than the preferred page size. Please replace with that description if you like it. tail_size is calculated and used in commit_tail() 158 char* const aligned_end_address = (char*)align_ptr_down(_high_boundary, _page_size); 159 size_t const tail_size = pointer_delta(_high_boundary, aligned_end_address, sizeof(char)); A similar calculation is done in committed_size() 104 char* aligned_high_boundary = (char*)align_ptr_up(_high_boundary, _page_size); 105 result -= pointer_delta(aligned_high_boundary, _high_boundary, sizeof(char)); Maybe calculate the tail size once and save it for later uses. Or have a method to calculate tail_size. Parameter "start" to "start_page" seems consistent with other parameter naming. 114 void uncommit(size_t start, size_t size_in_pages); Rest looks good. Jon On 03/18/2015 06:05 AM, Thomas Schatzl wrote: > Hi all, > > I got a few more internal reviews and suggestions for this change, so > I would like to ask for re-reviews. > > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.3/ (full) > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.2_to_3/ (diff) > > Changes: > > - changed " SIZE_FORMAT" strings in gclog_or_tty->print_cr() format > strings to " SIZE_FORMAT " since this is the correct style. > > - moved setup of reserved space with the requirements we have to the > ReservedSpace constructor. > > - improve readability: in G1PageBasedVirtualSpace: renamings of > "actual_size" -> "used_size" parameter, _commit_size -> _page_size > member > > - G1PageBasedVirtualSpace: changed uintptr_t parameter types to more > fitting size_t > > - some refactorings, extracting a few methods to make control flow more > clear > > Testing: > jprt, aurora > > Thanks, > Thomas > > From bengt.rutisson at oracle.com Thu Mar 26 19:56:53 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 26 Mar 2015 20:56:53 +0100 Subject: RFR (S): JDK-8076076: Move SharedHeap::print_size_transition() into G1 code In-Reply-To: <551419B8.1030005@oracle.com> References: <55140A02.7050202@oracle.com> <551419B8.1030005@oracle.com> Message-ID: <55146485.9040600@oracle.com> On 26/03/15 15:37, Mikael Gerdin wrote: > Hi Bengt, > > On 2015-03-26 14:30, Bengt Rutisson wrote: >> >> Hi everyone, >> >> One more step towards eventually getting rid of SharedHeap. >> >> Could I have a couple of reviews for this small change: >> >> http://cr.openjdk.java.net/~brutisso/8076076/webrev.00/ > > Looks good to me. Thanks, Mikael! Bengt > /Mikael > >> >> https://bugs.openjdk.java.net/browse/JDK-8076076 >> >> The method SharedHeap::print_size_transition() is only used by G1 but >> was placed in SharedHeap. It was called from the G1CollectorPolicy >> class, so I moved it to be next to the other related methods >> (G1CollectorPolicy::print_heap_transition() and >> G1CollectorPolicy::print_detailed_heap_transition()). I also renamed it >> to print_heap_transition() to be more consistent with the other two >> methods. Some simplifications to the parameter list could be made now >> that it is an internal G1 method. >> >> Thanks, >> Bengt >> > From bengt.rutisson at oracle.com Thu Mar 26 19:57:41 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 26 Mar 2015 20:57:41 +0100 Subject: RFR (S): JDK-8076076: Move SharedHeap::print_size_transition() into G1 code In-Reply-To: <1427380981.3149.46.camel@oracle.com> References: <55140A02.7050202@oracle.com> <1427380981.3149.46.camel@oracle.com> Message-ID: <551464B5.6080700@oracle.com> On 26/03/15 15:43, Thomas Schatzl wrote: > Hi, > > On Thu, 2015-03-26 at 14:30 +0100, Bengt Rutisson wrote: >> Hi everyone, >> >> One more step towards eventually getting rid of SharedHeap. >> >> Could I have a couple of reviews for this small change: >> >> http://cr.openjdk.java.net/~brutisso/8076076/webrev.00/ >> >> https://bugs.openjdk.java.net/browse/JDK-8076076 >> >> The method SharedHeap::print_size_transition() is only used by G1 but >> was placed in SharedHeap. It was called from the G1CollectorPolicy >> class, so I moved it to be next to the other related methods >> (G1CollectorPolicy::print_heap_transition() and >> G1CollectorPolicy::print_detailed_heap_transition()). I also renamed it >> to print_heap_transition() to be more consistent with the other two >> methods. Some simplifications to the parameter list could be made now >> that it is an internal G1 method. > looks good. Thanks for the review, Thomas! > Could you align the parameters of the > gclog_or_tty->print_cr() in print_heap_transition()? > > I do not need another review for that. Good point. I'll fix that before I push. Bengt > > Thanks, > Thomas > > From jon.masamitsu at oracle.com Thu Mar 26 20:43:24 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 26 Mar 2015 13:43:24 -0700 Subject: RFR (L): 8058354: SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting with 9-b29 In-Reply-To: <1427359660.3149.6.camel@oracle.com> References: <1422527439.3309.8.camel@oracle.com> <54CC0BCC.2090009@oracle.com> <1422959222.3368.4.camel@oracle.com> <54D11432.5050006@oracle.com> <1424162109.3163.2.camel@oracle.com> <54E75013.9010404@oracle.com> <1424446165.3267.13.camel@oracle.com> <1426683926.5616.6.camel@oracle.com> <55138144.6000406@oracle.com> <1427359660.3149.6.camel@oracle.com> Message-ID: <55146F6C.5010406@oracle.com> On 03/26/2015 01:47 AM, Thomas Schatzl wrote: > Hi Jon, > > On Wed, 2015-03-25 at 20:47 -0700, Jon Masamitsu wrote: >> Thomas, >> >> Haven't gotten very far but let me send you one question. >> >> http://cr.openjdk.java.net/~tschatzl/8058354/webrev.2_to_3/src/share/vm/gc_implementation/g1/g1PageBasedVirtualSpace.cpp.frames.html >> >>> 157 void G1PageBasedVirtualSpace::commit_tail() { >>> 158 char* const aligned_end_address = (char*)align_ptr_down(_high_boundary, _page_size); >>> 159 size_t const tail_size = pointer_delta(_high_boundary, aligned_end_address, sizeof(char)); >> Should there be a check that tail_size is not 0 before attempting to >> commit it? > commit_tail() can only be called if is_last_page_partial() is true, > i.e. tail_size > 0. I can add an assert for that. Please do add the assert. commit_tail() is currently only called if is_last_page_partial() is true, right? But could be called in a different context where that is not true. Jon > > Thanks, > Thomas > > From jon.masamitsu at oracle.com Thu Mar 26 20:44:16 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 26 Mar 2015 13:44:16 -0700 Subject: RFR (L): 8058354: SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting with 9-b29 In-Reply-To: <1427382688.3149.47.camel@oracle.com> References: <1422527439.3309.8.camel@oracle.com> <54CC0BCC.2090009@oracle.com> <1422959222.3368.4.camel@oracle.com> <54D11432.5050006@oracle.com> <1424162109.3163.2.camel@oracle.com> <54E75013.9010404@oracle.com> <1424446165.3267.13.camel@oracle.com> <1426683926.5616.6.camel@oracle.com> <55138144.6000406@oracle.com> <1427359660.3149.6.camel@oracle.com> <1427382688.3149.47.camel@oracle.com> Message-ID: <55146FA0.40304@oracle.com> On 03/26/2015 08:11 AM, Thomas Schatzl wrote: > Hi again, > > On Thu, 2015-03-26 at 09:47 +0100, Thomas Schatzl wrote: >> Hi Jon, >> >> On Wed, 2015-03-25 at 20:47 -0700, Jon Masamitsu wrote: >>> Thomas, >>> >>> Haven't gotten very far but let me send you one question. >>> >>> http://cr.openjdk.java.net/~tschatzl/8058354/webrev.2_to_3/src/share/vm/gc_implementation/g1/g1PageBasedVirtualSpace.cpp.frames.html >>> >>>> 157 void G1PageBasedVirtualSpace::commit_tail() { >>>> 158 char* const aligned_end_address = (char*)align_ptr_down(_high_boundary, _page_size); >>>> 159 size_t const tail_size = pointer_delta(_high_boundary, aligned_end_address, sizeof(char)); >>> Should there be a check that tail_size is not 0 before attempting to >>> commit it? >> commit_tail() can only be called if is_last_page_partial() is true, >> i.e. tail_size > 0. I can add an assert for that. > Here's a change with that assert added. > > Full webrev: > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.4/ > Diff: > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.3_to_4/ > top-level changes: > http://cr.openjdk.java.net/~tschatzl/8058354/webrev.hs-gc.1/ (there were > no changes in it for months, just for completeness) Thanks. Jon > > Testing: another jprt round > > Thanks a lot, > Thomas > > From jon.masamitsu at oracle.com Fri Mar 27 04:33:15 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 26 Mar 2015 21:33:15 -0700 Subject: Request for review (s) : 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads In-Reply-To: <54FF1B4A.9020609@oracle.com> References: <54FF1B4A.9020609@oracle.com> Message-ID: <5514DD8B.2070700@oracle.com> The fix for 8017462 has been changed to adopt the suggestion from Bengt (thanks, Bengt). The patch from Bengt has been enhanced to include some of the changes in this first version that did not make it into Bengt's original patch. The test remains the same. A CR has been created to add another test to check the consistency of one of the per thread statistics with the sum of the statistics over all the threads (e.g., per thread object copy time and total object copy time) https://bugs.openjdk.java.net/browse/JDK-8076140 http://cr.openjdk.java.net/~jmasa/8017462/webrev.01/ On 3/10/2015 9:26 AM, Jon Masamitsu wrote: > 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads > > https://bugs.openjdk.java.net/browse/JDK-8017462 > > When fewer than the maximum number of threads was being used for > a parallel section, phase times for the threads that did not execute and > averages for the phase were misleading. The fix passes the active > number of > GC threads to the G1 phase timers. > > http://cr.openjdk.java.net/~jmasa/8017462/webrev.00/ > > Tested with gc_test_suite. From david.lindholm at oracle.com Fri Mar 27 08:52:08 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 27 Mar 2015 09:52:08 +0100 Subject: RFR: JDK-8076071 - parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files Message-ID: <55151A38.7000903@oracle.com> Hi, Please review this fix that removes the macro PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc warnings for the format strings. Some files had this macro even though there were no warnings in them. This patch deals with all the parallelScavenge source files that had this macro. There will be separate patches for the other collectors. Webrev: http://cr.openjdk.java.net/~david/JDK-8076071/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8076071 Testing done: Passed JPRT Thanks, David From david.lindholm at oracle.com Fri Mar 27 09:04:57 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 27 Mar 2015 10:04:57 +0100 Subject: RFR: JDK-8076072 - parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files Message-ID: <55151D39.6020401@oracle.com> Hi, Please review this fix that removes the macro PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc warnings for the format strings. Some files had this macro even though there were no warnings in them. This patch deals with all the parNew source files that had this macro. Webrev: http://cr.openjdk.java.net/~david/JDK-8076072/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8076072 Testing done: Passed JPRT Thanks, David From bengt.rutisson at oracle.com Fri Mar 27 09:03:38 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 27 Mar 2015 10:03:38 +0100 Subject: RFR: JDK-8076071 - parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <55151A38.7000903@oracle.com> References: <55151A38.7000903@oracle.com> Message-ID: <55151CEA.8060603@oracle.com> Hi David, On 2015-03-27 09:52, David Lindholm wrote: > Hi, > > Please review this fix that removes the macro > PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc > warnings for the format strings. Some files had this macro even though > there were no warnings in them. > > This patch deals with all the parallelScavenge source files that had > this macro. There will be separate patches for the other collectors. > > Webrev: http://cr.openjdk.java.net/~david/JDK-8076071/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8076071 Looks good! Bengt > > Testing done: Passed JPRT > > > Thanks, > David From mikael.gerdin at oracle.com Fri Mar 27 09:18:26 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 27 Mar 2015 10:18:26 +0100 Subject: RFR: JDK-8076071 - parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <55151A38.7000903@oracle.com> References: <55151A38.7000903@oracle.com> Message-ID: <55152062.5060701@oracle.com> Hi David, On 2015-03-27 09:52, David Lindholm wrote: > Hi, > > Please review this fix that removes the macro > PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc > warnings for the format strings. Some files had this macro even though > there were no warnings in them. > > This patch deals with all the parallelScavenge source files that had > this macro. There will be separate patches for the other collectors. > > Webrev: http://cr.openjdk.java.net/~david/JDK-8076071/webrev.00/ Looks good. /Mikael > Bug: https://bugs.openjdk.java.net/browse/JDK-8076071 > > Testing done: Passed JPRT > > > Thanks, > David From stefan.karlsson at oracle.com Fri Mar 27 09:24:31 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 27 Mar 2015 10:24:31 +0100 Subject: RFR: JDK-8076071 - parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <55151A38.7000903@oracle.com> References: <55151A38.7000903@oracle.com> Message-ID: <551521CF.8060702@oracle.com> Hi David, On 27/03/15 09:52, David Lindholm wrote: > Hi, > > Please review this fix that removes the macro > PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc > warnings for the format strings. Some files had this macro even though > there were no warnings in them. > > This patch deals with all the parallelScavenge source files that had > this macro. There will be separate patches for the other collectors. > > Webrev: http://cr.openjdk.java.net/~david/JDK-8076071/webrev.00/ http://cr.openjdk.java.net/~david/JDK-8076071/webrev.00/src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp.udiff.html 418 gclog_or_tty->print_cr("Current region: [" PTR_FORMAT ", " PTR_FORMAT ") " 419 "New region: [" PTR_FORMAT ", " PTR_FORMAT ")", 420 p2i(s1->bottom()), p2i(s1->end()), 421 p2i(s1MR.start()), p2i(s1MR.end())); If you have to line break, could you align the parameters? Like: 418 gclog_or_tty->print_cr("Current region: [" PTR_FORMAT ", " PTR_FORMAT ") " 419 "New region: [" PTR_FORMAT ", " PTR_FORMAT ")", 420 p2i(s1->bottom()), p2i(s1->end()), 421 p2i(s1MR.start()), p2i(s1MR.end())); Thanks for fixing this! StefanK > Bug: https://bugs.openjdk.java.net/browse/JDK-8076071 > > Testing done: Passed JPRT > > > Thanks, > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lindholm at oracle.com Fri Mar 27 09:23:34 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 27 Mar 2015 10:23:34 +0100 Subject: RFR: JDK-8076073 - shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files Message-ID: <55152196.2020102@oracle.com> Hi, Please review this fix that removes the macro PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc warnings for the format strings. Some files had this macro even though there were no warnings in them. This patch deals with all the source files in vm/gc_implementation/shared/ and vm/memory/ that had this macro. Webrev: http://cr.openjdk.java.net/~david/JDK-8076073/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8076073 Testing done: Passed JPRT Thanks, David From stefan.karlsson at oracle.com Fri Mar 27 09:28:12 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 27 Mar 2015 10:28:12 +0100 Subject: RFR: JDK-8076072 - parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <55151D39.6020401@oracle.com> References: <55151D39.6020401@oracle.com> Message-ID: <551522AC.9010402@oracle.com> On 27/03/15 10:04, David Lindholm wrote: > Hi, > > Please review this fix that removes the macro > PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc > warnings for the format strings. Some files had this macro even though > there were no warnings in them. > > This patch deals with all the parNew source files that had this macro. > > Webrev: http://cr.openjdk.java.net/~david/JDK-8076072/webrev.00/ http://cr.openjdk.java.net/~david/JDK-8076072/webrev.00/src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp.frames.html The alignment needs to be fixed: 380 assert(sp->used_region().end() > used.end(), 381 err_msg("Expansion did not happen: " 382 "[" PTR_FORMAT "," PTR_FORMAT ") -> [" PTR_FORMAT "," PTR_FORMAT ")", 383 p2i(sp->used_region().start()), p2i(sp->used_region().end()), 384 p2i(used.start()), p2i(used.end()))); Thanks, StefanK > Bug: https://bugs.openjdk.java.net/browse/JDK-8076072 > > Testing done: Passed JPRT > > > Thanks, > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lindholm at oracle.com Fri Mar 27 09:50:35 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 27 Mar 2015 10:50:35 +0100 Subject: RFR: JDK-8076071 - parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <551521CF.8060702@oracle.com> References: <55151A38.7000903@oracle.com> <551521CF.8060702@oracle.com> Message-ID: <551527EB.80600@oracle.com> Hi Stefan, I have fixed this. Do you need a new webrev? Thanks, David On 2015-03-27 10:24, Stefan Karlsson wrote: > Hi David, > > On 27/03/15 09:52, David Lindholm wrote: >> Hi, >> >> Please review this fix that removes the macro >> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >> warnings for the format strings. Some files had this macro even >> though there were no warnings in them. >> >> This patch deals with all the parallelScavenge source files that had >> this macro. There will be separate patches for the other collectors. >> >> Webrev: http://cr.openjdk.java.net/~david/JDK-8076071/webrev.00/ > > http://cr.openjdk.java.net/~david/JDK-8076071/webrev.00/src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp.udiff.html > 418 gclog_or_tty->print_cr("Current region: [" PTR_FORMAT ", " PTR_FORMAT ") " > 419 "New region: [" PTR_FORMAT ", " PTR_FORMAT ")", > 420 p2i(s1->bottom()), p2i(s1->end()), > 421 p2i(s1MR.start()), p2i(s1MR.end())); > > > If you have to line break, could you align the parameters? Like: > > 418 gclog_or_tty->print_cr("Current region: [" PTR_FORMAT ", " PTR_FORMAT ") " > 419 "New region: [" PTR_FORMAT ", " PTR_FORMAT ")", > 420 p2i(s1->bottom()), p2i(s1->end()), > 421 p2i(s1MR.start()), p2i(s1MR.end())); > > Thanks for fixing this! > > StefanK > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076071 >> >> Testing done: Passed JPRT >> >> >> Thanks, >> David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lindholm at oracle.com Fri Mar 27 09:50:54 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 27 Mar 2015 10:50:54 +0100 Subject: RFR: JDK-8076072 - parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <551522AC.9010402@oracle.com> References: <55151D39.6020401@oracle.com> <551522AC.9010402@oracle.com> Message-ID: <551527FE.5040603@oracle.com> Hi Stefan, I have fixed this. Do you need a new webrev? Thanks, David On 2015-03-27 10:28, Stefan Karlsson wrote: > On 27/03/15 10:04, David Lindholm wrote: >> Hi, >> >> Please review this fix that removes the macro >> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >> warnings for the format strings. Some files had this macro even >> though there were no warnings in them. >> >> This patch deals with all the parNew source files that had this macro. >> >> Webrev: http://cr.openjdk.java.net/~david/JDK-8076072/webrev.00/ > > http://cr.openjdk.java.net/~david/JDK-8076072/webrev.00/src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp.frames.html > > The alignment needs to be fixed: > 380 assert(sp->used_region().end() > used.end(), > 381 err_msg("Expansion did not happen: " > 382 "[" PTR_FORMAT "," PTR_FORMAT ") -> [" PTR_FORMAT "," PTR_FORMAT ")", > 383 p2i(sp->used_region().start()), p2i(sp->used_region().end()), > 384 p2i(used.start()), p2i(used.end()))); > > > Thanks, > StefanK > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076072 >> >> Testing done: Passed JPRT >> >> >> Thanks, >> David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Fri Mar 27 09:48:06 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 27 Mar 2015 10:48:06 +0100 Subject: Request for review (s) : 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads In-Reply-To: <5514DD8B.2070700@oracle.com> References: <54FF1B4A.9020609@oracle.com> <5514DD8B.2070700@oracle.com> Message-ID: <55152756.8090307@oracle.com> On 2015-03-27 05:33, Jon Masamitsu wrote: > The fix for 8017462 has been changed to adopt the suggestion from > Bengt (thanks, Bengt). The patch from Bengt has been enhanced to > include some of the changes in this first version that did not make > it into Bengt's original patch. The test remains the same. A CR has > been > created to add another test to check the consistency of one of > the per thread statistics with the sum of the statistics over all the > threads (e.g., per thread object copy time and total object copy time) > https://bugs.openjdk.java.net/browse/JDK-8076140 > > http://cr.openjdk.java.net/~jmasa/8017462/webrev.01/ Thanks for adopting this patch. I think it looks good now. :) A couple of questions about the test case. The proposed test will run with any GC configuration since it just discards the JTreg configuration and selects its own GC. You have specified @requires vm.gc=="null", which makes sense since we don't have to run this test in every configuration. The test will anyway always run with the GCs that it specifies itself. However, the @requires tag will mean that the test is only run if no GC is specified. Currently there is a "noopt" baseline in our nightly testing that runs without explicitly setting a GC, so this test will be run there. But if we change the nightly baselines to always specify a GC we will never run this test. I guess this is a more general question. Should we use @requires to avoid running the same test many times or should we only use it when the test actually requires a specific GC configuration? Also, the test use a lot of flags: "-XX:+UnlockExperimentalVMOptions", "-XX:G1LogLevel=finest", "-XX:+" + gcFlag, "-Xmx10M", "-showversion", "-XX:+PrintGCDetails", "-XX:+UseDynamicNumberOfGCThreads", "-XX:+TraceDynamicGCThreads" I think this should be enough: "-XX:+" + gcFlag, "-Xmx10M", "-XX:+UseDynamicNumberOfGCThreads", "-XX:+TraceDynamicGCThreads" Is there a particular reason to have the other flags? Thanks, Bengt > > On 3/10/2015 9:26 AM, Jon Masamitsu wrote: >> 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads >> >> https://bugs.openjdk.java.net/browse/JDK-8017462 >> >> When fewer than the maximum number of threads was being used for >> a parallel section, phase times for the threads that did not execute and >> averages for the phase were misleading. The fix passes the active >> number of >> GC threads to the G1 phase timers. >> >> http://cr.openjdk.java.net/~jmasa/8017462/webrev.00/ >> >> Tested with gc_test_suite. > From stefan.karlsson at oracle.com Fri Mar 27 10:00:57 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 27 Mar 2015 11:00:57 +0100 Subject: RFR: JDK-8076071 - parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <551527EB.80600@oracle.com> References: <55151A38.7000903@oracle.com> <551521CF.8060702@oracle.com> <551527EB.80600@oracle.com> Message-ID: <55152A59.6050208@oracle.com> On 27/03/15 10:50, David Lindholm wrote: > Hi Stefan, > > I have fixed this. Do you need a new webrev? No. I'm happy with the patch if you fixed the alignment issues. Thanks, StefanK > > > Thanks, > David > > On 2015-03-27 10:24, Stefan Karlsson wrote: >> Hi David, >> >> On 27/03/15 09:52, David Lindholm wrote: >>> Hi, >>> >>> Please review this fix that removes the macro >>> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >>> warnings for the format strings. Some files had this macro even >>> though there were no warnings in them. >>> >>> This patch deals with all the parallelScavenge source files that had >>> this macro. There will be separate patches for the other collectors. >>> >>> Webrev: http://cr.openjdk.java.net/~david/JDK-8076071/webrev.00/ >> >> http://cr.openjdk.java.net/~david/JDK-8076071/webrev.00/src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp.udiff.html >> 418 gclog_or_tty->print_cr("Current region: [" PTR_FORMAT ", " PTR_FORMAT ") " >> 419 "New region: [" PTR_FORMAT ", " PTR_FORMAT ")", >> 420 p2i(s1->bottom()), p2i(s1->end()), >> 421 p2i(s1MR.start()), p2i(s1MR.end())); >> >> >> If you have to line break, could you align the parameters? Like: >> >> 418 gclog_or_tty->print_cr("Current region: [" PTR_FORMAT ", " PTR_FORMAT ") " >> 419 "New region: [" PTR_FORMAT ", " PTR_FORMAT ")", >> 420 p2i(s1->bottom()), p2i(s1->end()), >> 421 p2i(s1MR.start()), p2i(s1MR.end())); >> >> Thanks for fixing this! >> >> StefanK >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076071 >>> >>> Testing done: Passed JPRT >>> >>> >>> Thanks, >>> David >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Fri Mar 27 10:01:40 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 27 Mar 2015 11:01:40 +0100 Subject: RFR: JDK-8076072 - parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <551527FE.5040603@oracle.com> References: <55151D39.6020401@oracle.com> <551522AC.9010402@oracle.com> <551527FE.5040603@oracle.com> Message-ID: <55152A84.6080704@oracle.com> On 27/03/15 10:50, David Lindholm wrote: > Hi Stefan, > > I have fixed this. Do you need a new webrev? No. I'm OK with the patch if you fix the alignment. Thanks, StefanK > > > Thanks, > David > > On 2015-03-27 10:28, Stefan Karlsson wrote: >> On 27/03/15 10:04, David Lindholm wrote: >>> Hi, >>> >>> Please review this fix that removes the macro >>> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >>> warnings for the format strings. Some files had this macro even >>> though there were no warnings in them. >>> >>> This patch deals with all the parNew source files that had this macro. >>> >>> Webrev: http://cr.openjdk.java.net/~david/JDK-8076072/webrev.00/ >> >> http://cr.openjdk.java.net/~david/JDK-8076072/webrev.00/src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp.frames.html >> >> The alignment needs to be fixed: >> 380 assert(sp->used_region().end() > used.end(), >> 381 err_msg("Expansion did not happen: " >> 382 "[" PTR_FORMAT "," PTR_FORMAT ") -> [" PTR_FORMAT "," PTR_FORMAT ")", >> 383 p2i(sp->used_region().start()), p2i(sp->used_region().end()), >> 384 p2i(used.start()), p2i(used.end()))); >> >> >> Thanks, >> StefanK >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076072 >>> >>> Testing done: Passed JPRT >>> >>> >>> Thanks, >>> David >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Fri Mar 27 11:40:59 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 27 Mar 2015 12:40:59 +0100 Subject: RFR: JDK-8076072 - parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <55152A84.6080704@oracle.com> References: <55151D39.6020401@oracle.com> <551522AC.9010402@oracle.com> <551527FE.5040603@oracle.com> <55152A84.6080704@oracle.com> Message-ID: <551541CB.9020200@oracle.com> On 2015-03-27 11:01, Stefan Karlsson wrote: > On 27/03/15 10:50, David Lindholm wrote: >> Hi Stefan, >> >> I have fixed this. Do you need a new webrev? > > No. I'm OK with the patch if you fix the alignment. With the alignment fix this looks good to me too. Bengt > > Thanks, > StefanK >> >> >> Thanks, >> David >> >> On 2015-03-27 10:28, Stefan Karlsson wrote: >>> On 27/03/15 10:04, David Lindholm wrote: >>>> Hi, >>>> >>>> Please review this fix that removes the macro >>>> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >>>> warnings for the format strings. Some files had this macro even >>>> though there were no warnings in them. >>>> >>>> This patch deals with all the parNew source files that had this macro. >>>> >>>> Webrev: http://cr.openjdk.java.net/~david/JDK-8076072/webrev.00/ >>> >>> http://cr.openjdk.java.net/~david/JDK-8076072/webrev.00/src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp.frames.html >>> >>> The alignment needs to be fixed: >>> 380 assert(sp->used_region().end() > used.end(), >>> 381 err_msg("Expansion did not happen: " >>> 382 "[" PTR_FORMAT "," PTR_FORMAT ") -> [" PTR_FORMAT "," PTR_FORMAT ")", >>> 383 p2i(sp->used_region().start()), p2i(sp->used_region().end()), >>> 384 p2i(used.start()), p2i(used.end()))); >>> >>> >>> Thanks, >>> StefanK >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076072 >>>> >>>> Testing done: Passed JPRT >>>> >>>> >>>> Thanks, >>>> David >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lindholm at oracle.com Fri Mar 27 13:00:01 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 27 Mar 2015 14:00:01 +0100 Subject: RFR: JDK-8076071 - parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <55151CEA.8060603@oracle.com> References: <55151A38.7000903@oracle.com> <55151CEA.8060603@oracle.com> Message-ID: <55155451.9010606@oracle.com> Hi Bengt, Thanks for the review! /David On 2015-03-27 10:03, Bengt Rutisson wrote: > > Hi David, > > On 2015-03-27 09:52, David Lindholm wrote: >> Hi, >> >> Please review this fix that removes the macro >> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >> warnings for the format strings. Some files had this macro even >> though there were no warnings in them. >> >> This patch deals with all the parallelScavenge source files that had >> this macro. There will be separate patches for the other collectors. >> >> Webrev: http://cr.openjdk.java.net/~david/JDK-8076071/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076071 > > Looks good! > > Bengt > >> >> Testing done: Passed JPRT >> >> >> Thanks, >> David > From david.lindholm at oracle.com Fri Mar 27 13:00:27 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 27 Mar 2015 14:00:27 +0100 Subject: RFR: JDK-8076071 - parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <55152062.5060701@oracle.com> References: <55151A38.7000903@oracle.com> <55152062.5060701@oracle.com> Message-ID: <5515546B.6070303@oracle.com> Hi Mikael, Thanks for the review. /David On 2015-03-27 10:18, Mikael Gerdin wrote: > Hi David, > > On 2015-03-27 09:52, David Lindholm wrote: >> Hi, >> >> Please review this fix that removes the macro >> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >> warnings for the format strings. Some files had this macro even though >> there were no warnings in them. >> >> This patch deals with all the parallelScavenge source files that had >> this macro. There will be separate patches for the other collectors. >> >> Webrev: http://cr.openjdk.java.net/~david/JDK-8076071/webrev.00/ > > Looks good. > > /Mikael > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076071 >> >> Testing done: Passed JPRT >> >> >> Thanks, >> David From david.lindholm at oracle.com Fri Mar 27 13:01:02 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 27 Mar 2015 14:01:02 +0100 Subject: RFR: JDK-8076071 - parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <55152A59.6050208@oracle.com> References: <55151A38.7000903@oracle.com> <551521CF.8060702@oracle.com> <551527EB.80600@oracle.com> <55152A59.6050208@oracle.com> Message-ID: <5515548E.9060209@oracle.com> Stefan, Thanks for the review. /David On 2015-03-27 11:00, Stefan Karlsson wrote: > On 27/03/15 10:50, David Lindholm wrote: >> Hi Stefan, >> >> I have fixed this. Do you need a new webrev? > > No. I'm happy with the patch if you fixed the alignment issues. > > Thanks, > StefanK >> >> >> Thanks, >> David >> >> On 2015-03-27 10:24, Stefan Karlsson wrote: >>> Hi David, >>> >>> On 27/03/15 09:52, David Lindholm wrote: >>>> Hi, >>>> >>>> Please review this fix that removes the macro >>>> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >>>> warnings for the format strings. Some files had this macro even >>>> though there were no warnings in them. >>>> >>>> This patch deals with all the parallelScavenge source files that >>>> had this macro. There will be separate patches for the other >>>> collectors. >>>> >>>> Webrev: http://cr.openjdk.java.net/~david/JDK-8076071/webrev.00/ >>> >>> http://cr.openjdk.java.net/~david/JDK-8076071/webrev.00/src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp.udiff.html >>> 418 gclog_or_tty->print_cr("Current region: [" PTR_FORMAT ", " PTR_FORMAT ") " >>> 419 "New region: [" PTR_FORMAT ", " PTR_FORMAT ")", >>> 420 p2i(s1->bottom()), p2i(s1->end()), >>> 421 p2i(s1MR.start()), p2i(s1MR.end())); >>> >>> >>> If you have to line break, could you align the parameters? Like: >>> >>> 418 gclog_or_tty->print_cr("Current region: [" PTR_FORMAT ", " PTR_FORMAT ") " >>> 419 "New region: [" PTR_FORMAT ", " PTR_FORMAT ")", >>> 420 p2i(s1->bottom()), p2i(s1->end()), >>> 421 p2i(s1MR.start()), p2i(s1MR.end())); >>> >>> Thanks for fixing this! >>> >>> StefanK >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076071 >>>> >>>> Testing done: Passed JPRT >>>> >>>> >>>> Thanks, >>>> David >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lindholm at oracle.com Fri Mar 27 13:02:14 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 27 Mar 2015 14:02:14 +0100 Subject: RFR: JDK-8076072 - parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <55152A84.6080704@oracle.com> References: <55151D39.6020401@oracle.com> <551522AC.9010402@oracle.com> <551527FE.5040603@oracle.com> <55152A84.6080704@oracle.com> Message-ID: <551554D6.9060706@oracle.com> Hi Stefan, Thanks for the review. /David On 2015-03-27 11:01, Stefan Karlsson wrote: > On 27/03/15 10:50, David Lindholm wrote: >> Hi Stefan, >> >> I have fixed this. Do you need a new webrev? > > No. I'm OK with the patch if you fix the alignment. > > Thanks, > StefanK >> >> >> Thanks, >> David >> >> On 2015-03-27 10:28, Stefan Karlsson wrote: >>> On 27/03/15 10:04, David Lindholm wrote: >>>> Hi, >>>> >>>> Please review this fix that removes the macro >>>> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >>>> warnings for the format strings. Some files had this macro even >>>> though there were no warnings in them. >>>> >>>> This patch deals with all the parNew source files that had this macro. >>>> >>>> Webrev: http://cr.openjdk.java.net/~david/JDK-8076072/webrev.00/ >>> >>> http://cr.openjdk.java.net/~david/JDK-8076072/webrev.00/src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp.frames.html >>> >>> The alignment needs to be fixed: >>> 380 assert(sp->used_region().end() > used.end(), >>> 381 err_msg("Expansion did not happen: " >>> 382 "[" PTR_FORMAT "," PTR_FORMAT ") -> [" PTR_FORMAT "," PTR_FORMAT ")", >>> 383 p2i(sp->used_region().start()), p2i(sp->used_region().end()), >>> 384 p2i(used.start()), p2i(used.end()))); >>> >>> >>> Thanks, >>> StefanK >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076072 >>>> >>>> Testing done: Passed JPRT >>>> >>>> >>>> Thanks, >>>> David >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lindholm at oracle.com Fri Mar 27 13:02:43 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 27 Mar 2015 14:02:43 +0100 Subject: RFR: JDK-8076072 - parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <551541CB.9020200@oracle.com> References: <55151D39.6020401@oracle.com> <551522AC.9010402@oracle.com> <551527FE.5040603@oracle.com> <55152A84.6080704@oracle.com> <551541CB.9020200@oracle.com> Message-ID: <551554F3.6050607@oracle.com> Hi Bengt, Thanks for the review. /David On 2015-03-27 12:40, Bengt Rutisson wrote: > > On 2015-03-27 11:01, Stefan Karlsson wrote: >> On 27/03/15 10:50, David Lindholm wrote: >>> Hi Stefan, >>> >>> I have fixed this. Do you need a new webrev? >> >> No. I'm OK with the patch if you fix the alignment. > > With the alignment fix this looks good to me too. > > Bengt > >> >> Thanks, >> StefanK >>> >>> >>> Thanks, >>> David >>> >>> On 2015-03-27 10:28, Stefan Karlsson wrote: >>>> On 27/03/15 10:04, David Lindholm wrote: >>>>> Hi, >>>>> >>>>> Please review this fix that removes the macro >>>>> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >>>>> warnings for the format strings. Some files had this macro even >>>>> though there were no warnings in them. >>>>> >>>>> This patch deals with all the parNew source files that had this >>>>> macro. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~david/JDK-8076072/webrev.00/ >>>> >>>> http://cr.openjdk.java.net/~david/JDK-8076072/webrev.00/src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp.frames.html >>>> >>>> The alignment needs to be fixed: >>>> 380 assert(sp->used_region().end() > used.end(), >>>> 381 err_msg("Expansion did not happen: " >>>> 382 "[" PTR_FORMAT "," PTR_FORMAT ") -> [" PTR_FORMAT "," PTR_FORMAT ")", >>>> 383 p2i(sp->used_region().start()), p2i(sp->used_region().end()), >>>> 384 p2i(used.start()), p2i(used.end()))); >>>> >>>> >>>> Thanks, >>>> StefanK >>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076072 >>>>> >>>>> Testing done: Passed JPRT >>>>> >>>>> >>>>> Thanks, >>>>> David >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lindholm at oracle.com Fri Mar 27 13:29:47 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 27 Mar 2015 14:29:47 +0100 Subject: RFR: JDK-8076073 - shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <55152196.2020102@oracle.com> References: <55152196.2020102@oracle.com> Message-ID: <55155B4B.9000407@oracle.com> Hi, After some discussions with StefanK I have updated this webrev. I have reverted the changes to files not "owned" by us, and I have made some minor changes to heapInspection.cpp New webrev: http://cr.openjdk.java.net/~david/JDK-8076073/webrev.01/ Thanks, David On 2015-03-27 10:23, David Lindholm wrote: > Hi, > > Please review this fix that removes the macro > PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc > warnings for the format strings. Some files had this macro even though > there were no warnings in them. > > This patch deals with all the source files in > vm/gc_implementation/shared/ and vm/memory/ that had this macro. > > Webrev: http://cr.openjdk.java.net/~david/JDK-8076073/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8076073 > > Testing done: Passed JPRT > > > Thanks, > David From stefan.karlsson at oracle.com Fri Mar 27 13:39:34 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 27 Mar 2015 14:39:34 +0100 Subject: RFR: JDK-8076073 - shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <55155B4B.9000407@oracle.com> References: <55152196.2020102@oracle.com> <55155B4B.9000407@oracle.com> Message-ID: <55155D96.9060104@oracle.com> On 27/03/15 14:29, David Lindholm wrote: > Hi, > > After some discussions with StefanK I have updated this webrev. I have > reverted the changes to files not "owned" by us, and I have made some > minor changes to heapInspection.cpp > > New webrev: http://cr.openjdk.java.net/~david/JDK-8076073/webrev.01/ Looks good. StefanK > > > Thanks, > David > > On 2015-03-27 10:23, David Lindholm wrote: >> Hi, >> >> Please review this fix that removes the macro >> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >> warnings for the format strings. Some files had this macro even >> though there were no warnings in them. >> >> This patch deals with all the source files in >> vm/gc_implementation/shared/ and vm/memory/ that had this macro. >> >> Webrev: http://cr.openjdk.java.net/~david/JDK-8076073/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076073 >> >> Testing done: Passed JPRT >> >> >> Thanks, >> David > From david.lindholm at oracle.com Fri Mar 27 13:43:29 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 27 Mar 2015 14:43:29 +0100 Subject: RFR: JDK-8076073 - shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <55155D96.9060104@oracle.com> References: <55152196.2020102@oracle.com> <55155B4B.9000407@oracle.com> <55155D96.9060104@oracle.com> Message-ID: <55155E81.1050905@oracle.com> Stefan, Thanks for the review. /David On 2015-03-27 14:39, Stefan Karlsson wrote: > On 27/03/15 14:29, David Lindholm wrote: >> Hi, >> >> After some discussions with StefanK I have updated this webrev. I >> have reverted the changes to files not "owned" by us, and I have made >> some minor changes to heapInspection.cpp >> >> New webrev: http://cr.openjdk.java.net/~david/JDK-8076073/webrev.01/ > > Looks good. > > StefanK > >> >> >> Thanks, >> David >> >> On 2015-03-27 10:23, David Lindholm wrote: >>> Hi, >>> >>> Please review this fix that removes the macro >>> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >>> warnings for the format strings. Some files had this macro even >>> though there were no warnings in them. >>> >>> This patch deals with all the source files in >>> vm/gc_implementation/shared/ and vm/memory/ that had this macro. >>> >>> Webrev: http://cr.openjdk.java.net/~david/JDK-8076073/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076073 >>> >>> Testing done: Passed JPRT >>> >>> >>> Thanks, >>> David >> > From bengt.rutisson at oracle.com Fri Mar 27 13:49:12 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 27 Mar 2015 14:49:12 +0100 Subject: RFR: JDK-8076073 - shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <55155D96.9060104@oracle.com> References: <55152196.2020102@oracle.com> <55155B4B.9000407@oracle.com> <55155D96.9060104@oracle.com> Message-ID: <55155FD8.4050409@oracle.com> On 2015-03-27 14:39, Stefan Karlsson wrote: > On 27/03/15 14:29, David Lindholm wrote: >> Hi, >> >> After some discussions with StefanK I have updated this webrev. I >> have reverted the changes to files not "owned" by us, and I have made >> some minor changes to heapInspection.cpp >> >> New webrev: http://cr.openjdk.java.net/~david/JDK-8076073/webrev.01/ > > Looks good. Looks good to me too. Bengt > > StefanK > >> >> >> Thanks, >> David >> >> On 2015-03-27 10:23, David Lindholm wrote: >>> Hi, >>> >>> Please review this fix that removes the macro >>> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >>> warnings for the format strings. Some files had this macro even >>> though there were no warnings in them. >>> >>> This patch deals with all the source files in >>> vm/gc_implementation/shared/ and vm/memory/ that had this macro. >>> >>> Webrev: http://cr.openjdk.java.net/~david/JDK-8076073/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076073 >>> >>> Testing done: Passed JPRT >>> >>> >>> Thanks, >>> David >> > From david.lindholm at oracle.com Fri Mar 27 13:56:03 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 27 Mar 2015 14:56:03 +0100 Subject: RFR: JDK-8076073 - shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <55155FD8.4050409@oracle.com> References: <55152196.2020102@oracle.com> <55155B4B.9000407@oracle.com> <55155D96.9060104@oracle.com> <55155FD8.4050409@oracle.com> Message-ID: <55156173.4060200@oracle.com> Hi Bengt, Thanks for the review. /David On 2015-03-27 14:49, Bengt Rutisson wrote: > > On 2015-03-27 14:39, Stefan Karlsson wrote: >> On 27/03/15 14:29, David Lindholm wrote: >>> Hi, >>> >>> After some discussions with StefanK I have updated this webrev. I >>> have reverted the changes to files not "owned" by us, and I have >>> made some minor changes to heapInspection.cpp >>> >>> New webrev: http://cr.openjdk.java.net/~david/JDK-8076073/webrev.01/ >> >> Looks good. > > Looks good to me too. > > Bengt > >> >> StefanK >> >>> >>> >>> Thanks, >>> David >>> >>> On 2015-03-27 10:23, David Lindholm wrote: >>>> Hi, >>>> >>>> Please review this fix that removes the macro >>>> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC in gc files and fixes the gcc >>>> warnings for the format strings. Some files had this macro even >>>> though there were no warnings in them. >>>> >>>> This patch deals with all the source files in >>>> vm/gc_implementation/shared/ and vm/memory/ that had this macro. >>>> >>>> Webrev: http://cr.openjdk.java.net/~david/JDK-8076073/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076073 >>>> >>>> Testing done: Passed JPRT >>>> >>>> >>>> Thanks, >>>> David >>> >> > From jon.masamitsu at oracle.com Fri Mar 27 14:37:37 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 27 Mar 2015 07:37:37 -0700 Subject: Request for review (s) : 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads In-Reply-To: <55152756.8090307@oracle.com> References: <54FF1B4A.9020609@oracle.com> <5514DD8B.2070700@oracle.com> <55152756.8090307@oracle.com> Message-ID: <55156B31.3080906@oracle.com> Bengt, Thanks for looking at this. On 3/27/2015 2:48 AM, Bengt Rutisson wrote: > > On 2015-03-27 05:33, Jon Masamitsu wrote: >> The fix for 8017462 has been changed to adopt the suggestion from >> Bengt (thanks, Bengt). The patch from Bengt has been enhanced to >> include some of the changes in this first version that did not make >> it into Bengt's original patch. The test remains the same. A CR has >> been >> created to add another test to check the consistency of one of >> the per thread statistics with the sum of the statistics over all the >> threads (e.g., per thread object copy time and total object copy time) >> https://bugs.openjdk.java.net/browse/JDK-8076140 >> >> http://cr.openjdk.java.net/~jmasa/8017462/webrev.01/ > > Thanks for adopting this patch. I think it looks good now. :) > > A couple of questions about the test case. > > The proposed test will run with any GC configuration since it just > discards the JTreg configuration and selects its own GC. You have > specified @requires vm.gc=="null", which makes sense since we don't > have to run this test in every configuration. The test will anyway > always run with the GCs that it specifies itself. However, the > @requires tag will mean that the test is only run if no GC is > specified. Currently there is a "noopt" baseline in our nightly > testing that runs without explicitly setting a GC, so this test will > be run there. But if we change the nightly baselines to always specify > a GC we will never run this test. I would not expect that the nightly testing to always specify a specific GC because we do have a default GC and test should be run when we do the selection of the GC. Is this going to changes such that every nightly test specifies a specific GC? Are you suggesting that the command line be changed to not include a specific GC and that the the @requires be removed? So the test is run with whatever GC is being tested? > > I guess this is a more general question. Should we use @requires to > avoid running the same test many times or should we only use it when > the test actually requires a specific GC configuration? I'll happily take guidance on this point. Only using it when tests actually requires a specific GC sounds OK. > > Also, the test use a lot of flags: > > "-XX:+UnlockExperimentalVMOptions", "-XX:G1LogLevel=finest", "-XX:+" + > gcFlag, "-Xmx10M", "-showversion", "-XX:+PrintGCDetails", > "-XX:+UseDynamicNumberOfGCThreads", "-XX:+TraceDynamicGCThreads" > > > I think this should be enough: > > "-XX:+" + gcFlag, "-Xmx10M", "-XX:+UseDynamicNumberOfGCThreads", > "-XX:+TraceDynamicGCThreads" > > Is there a particular reason to have the other flags? In some of my testing there was a failure when I ran with log level set to finest that I did not see when I used the default logging level. I cannot recall if it was actually this test but I decided to add finest to this test as a result of seeing that failure. Wow. I have not known that G1 logging is printed when PrintGCDetails is off. Is that really the intent? Jon > > Thanks, > Bengt > >> >> On 3/10/2015 9:26 AM, Jon Masamitsu wrote: >>> 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads >>> >>> https://bugs.openjdk.java.net/browse/JDK-8017462 >>> >>> When fewer than the maximum number of threads was being used for >>> a parallel section, phase times for the threads that did not execute >>> and >>> averages for the phase were misleading. The fix passes the active >>> number of >>> GC threads to the G1 phase timers. >>> >>> http://cr.openjdk.java.net/~jmasa/8017462/webrev.00/ >>> >>> Tested with gc_test_suite. >> > From jon.masamitsu at oracle.com Fri Mar 27 20:22:46 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 27 Mar 2015 13:22:46 -0700 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> <55014F32.3030400@oracle.com> <5501683D.2000905@oracle.com> <58A2D320-A2E7-4304-90CA-CC1C768DA52C@oracle.com> <5502A38F.7000000@oracle.com> Message-ID: <5515BC16.3090405@oracle.com> Kim, http://cr.openjdk.java.net/~kbarrett/8069367/webrev.02/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html Can you explain this to me 3498 HeapRegionRemSet* const rset = region->rem_set(); 3499 if (G1EagerReclaimHumongousObjectsWithStaleRefs) { 3500 return rset->occupancy_less_or_equal_than(G1RSetSparseRegionEntries); 3501 } else { I understand that if there remembered set is empty, then no problem. I don't understand why the test on the occupancy is allowing early reclaiming. That's my only question and it is for my education so you can consider this a complete 2nd review. Jon On 3/17/2015 2:23 PM, Kim Barrett wrote: > On Mar 13, 2015, at 1:51 PM, Kim Barrett wrote: >> On Mar 13, 2015, at 4:45 AM, Bengt Rutisson wrote: >>> Another alternative would be to let initial marking note all humongous objects that were live after initial mark. Then we can just make sure that early reclaim does not reclaim any of those humongous objects while marking is active. That should be a pretty simple fix that can be backported if necessary. >> Bengt and I talked about this some more; I?m going to have a look at the code for this, as it seems likely better. > Here?s a new webrev, following Bengt?s suggestion. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8069367 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8069367/webrev.02/ > > No incremental webrev, since the approach (and so the changes) are entirely different. > > As a reminder, the scenario we are dealing with is > > (1) A humongous object H is marked and added to the mark stack. > > (2) An evacuation pause determines H is no longer live, and reclaims > it. This occurs before concurrent marking has gotten around to > processing the mark stack entry for H. > > (3) Concurrent marking processes the mark stack entry for H, > attempting to scan the now dead object. > > The new approach is to create a set of candidates at the start of the collection > pause, remove candidates as they are reached from roots or from the young > generation, and release any remaining candidates with empty remsets. (This > is similar to before.) > > The difference is in how we create the set of candidates. Previously, all humongous > objects satisfying certain type restrictions and remset size limits were treated as > candidates. Now, when concurrent marking is in progress, we also exclude from > the initial candidate set any objects that were live at the start of marking, determined > by comparing the object against its region?s TAMS value. Such objects are excluded > because they must be scanned because of SATB. > > Because we now exclude objects that were live at start of marking when marking > is in progress, the scenario we?re trying to deal with simply can?t occur. If H gets > marked and added to the mark stack, it was necessarily live at start of mark; the > marking process filters out objects that were allocated since marking started, e.g. > we allocate black while marking, so such objects aren?t added to the mark stack. > Since the objects that can be added to the mark stack are excluded from the > reclaim candidate set, the problematic situation cannot arise. > > Since I was rewriting the relevant code anyway, I've also changed the type restriction > for candidacy. Previously it was !is_objArray() and has been changed to is_typeArray(). > This addresses https://bugs.openjdk.java.net/browse/JDK-8072598. > > Note that we can?t yet eagerly reclaim humongous objects containing references, > because there are remset entries from such objects that need to be dealt with. > [I think this is (part of?) https://bugs.openjdk.java.net/browse/JDK-8071913.] > > Testing: > JPRT, Aurora ad hoc GC Nightly and other tests with -XX:+UseG1GC > > From kim.barrett at oracle.com Sat Mar 28 04:31:53 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 28 Mar 2015 00:31:53 -0400 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <5515BC16.3090405@oracle.com> References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> <55014F32.3030400@oracle.com> <5501683D.2000905@oracle.com> <58A2D320-A2E7-4304-90CA-CC1C768DA52C@oracle.com> <5502A38F.7000000@oracle.com> <5515BC16.3090405@oracle.com> Message-ID: On Mar 27, 2015, at 4:22 PM, Jon Masamitsu wrote: > > Kim, > > http://cr.openjdk.java.net/~kbarrett/8069367/webrev.02/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html > > Can you explain this to me > > 3498 HeapRegionRemSet* const rset = region->rem_set(); > 3499 if (G1EagerReclaimHumongousObjectsWithStaleRefs) { > 3500 return rset->occupancy_less_or_equal_than(G1RSetSparseRegionEntries); > 3501 } else { > > I understand that if there remembered set is empty, then no problem. I don't > understand why the test on the occupancy is allowing early reclaiming. The contents of the remembered set might be stale, due to concurrent mutator action. The heuristic being used here is that if the size of the remembered set is small then it is worth re-evaluating it, with the possibility that the result will be empty. Empirically, for some real applications, this heuristic provides good results. This is from https://bugs.openjdk.java.net/browse/JDK-8048179 > That's my only question and it is for my education so you can > consider this a complete 2nd review. Well, there may be further changes. Thomas and Bengt wondered if excluding typeArrays allocated before the start of the in-progress concurrent mark might matter. I?ve been looking at a way to still allow that. Though maybe the version that has been reviewed is good enough, and the possible further improvement can be done as followup work? Bengt and Thomas? From jon.masamitsu at oracle.com Sun Mar 29 19:35:33 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Sun, 29 Mar 2015 12:35:33 -0700 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <1427122924.3194.79.camel@oracle.com> References: <1425482904.3305.27.camel@oracle.com> <1425567491.3140.42.camel@oracle.com> <54F96CB2.9060107@oracle.com> <1425898922.3398.35.camel@oracle.com> <1426675055.3170.24.camel@oracle.com> <84EC1DB5-4277-4190-8EA1-E0A6F90BE95C@oracle.com> <1427122924.3194.79.camel@oracle.com> Message-ID: <55185405.8040803@oracle.com> Thomas, It's not clear to me that the name change G1ParGCAllocBuffer to G1PLAB is a change for the better. From the base class name ParGCAllocBuffer, I could guess the G1 version is G1ParGCAllocBuffer but I would not guess G1PLAB. Can you motivate that name (G1PLAB) for me? Jon On 3/23/2015 8:02 AM, Thomas Schatzl wrote: > Hi Kim, Sangheon, Stefan, > > thanks for your reviews. > > I still need a Reviewer review for this. I will fix Sangheon's comment > about the copyright date with the push if you do not object. > > Thanks, > Thomas > > On Thu, 2015-03-19 at 13:15 -0400, Kim Barrett wrote: >> On Mar 18, 2015, at 6:37 AM, Thomas Schatzl wrote: >>> Hi Stefan, Kim, >>> >>> could you look at the updated CR again? Also, I need a Reviewer to >>> look at this. >>> >>> Thanks, >>> Thomas >>> >>> On Mon, 2015-03-09 at 12:02 +0100, Thomas Schatzl wrote: >>>> Hi Stefan, >>>> >>>> thanks for the review. >>>> >>>> There is a new webrev at >>>> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.2 (full) >>>> http://cr.openjdk.java.net/~tschatzl/8073052/webrev.1_to_2 (diff) >> Sorry about losing track of this. >> >> New version looks good. >> > From kim.barrett at oracle.com Mon Mar 30 01:28:01 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 29 Mar 2015 21:28:01 -0400 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> <55014F32.3030400@oracle.com> <5501683D.2000905@oracle.com> <58A2D320-A2E7-4304-90CA-CC1C768DA52C@oracle.com> <5502A38F.7000000@oracle.com> <5515BC16.3090405@oracle.com> Message-ID: <8B99B9A3-7298-4119-88D2-BEFA3D16E078@oracle.com> On Mar 28, 2015, at 12:31 AM, Kim Barrett wrote: > > On Mar 27, 2015, at 4:22 PM, Jon Masamitsu wrote: >> That's my only question and it is for my education so you can >> consider this a complete 2nd review. > > Well, there may be further changes. Thomas and Bengt wondered if excluding typeArrays > allocated before the start of the in-progress concurrent mark might matter. I?ve been looking > at a way to still allow that. > > Though maybe the version that has been reviewed is good enough, and the possible further > improvement can be done as followup work? Bengt and Thomas? Another round on this. In the previous version we disallowed eager reclaim of any humongous objects that were allocated prior to the current snapshot when concurrent marking was in progress. As noted, there was some concern (private email with Thomas and Bengt) that this would result in more headroom being needed because some humongous objects that were previously reclaimed now would not be. This time we allow pre-snapshot humongous typeArrays to be candidates for reclaiming. However, we now ensure that such objects won't ever be added to the mark stack. We accomplish this by filtering out all typeArrays from the mark stack; rather than pushing them we immediately perform the "scan", which for typeArray objects amounts to just doing some bookkeeping and checking task limits. The addition of typeArray filtering in front of the mark stack is rather far away from the place that is requiring it. I'm not entirely happy with this coupling, and would be OK with not going this extra step. The cost of the pre-filtering of the mark stack is small, and some of it may be recovered by avoiding the cost of moving the filtered objects through the mark stack, and by doing less work on the filtered objects than would otherwise be needed. Aurora GC performance tests show mostly insignificant differences, with a few small improvements compared to the baseline that has bug 8069367. [While I was at it, I simplified the conditionalization of deal_with_references for _CHECK_BOTH_FINGERS_, eliminating some code duplication.] CR: https://bugs.openjdk.java.net/browse/JDK-8069367 Webrev: http://cr.openjdk.java.net/~kbarrett/8069367/webrev.03/ Incremental webrev: http://cr.openjdk.java.net/~kbarrett/8069367/webrev.03.incr/ Testing: Hand testing JPRT Aurora Ad-hoc GC Nightly using G1 Aurora GC perf test using G1. From kim.barrett at oracle.com Mon Mar 30 04:04:36 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 30 Mar 2015 00:04:36 -0400 Subject: RFR: 8075401: Remove DiscoveredListIterator::update_discovered() In-Reply-To: <550A9E17.5040006@oracle.com> References: <55099581.3080903@oracle.com> <550A9E17.5040006@oracle.com> Message-ID: <45B6B9F7-1066-4B81-8DEC-3802D684F6D9@oracle.com> On Mar 19, 2015, at 5:59 AM, Bengt Rutisson wrote: > >>> On 2015-03-18 01:20, Kim Barrett wrote: >>>> Please review this change to remove unnecessary calls to >>>> DiscoveredListIterator::update_discovered(), and remove the now unused >>>> function. Details are in the CR. >>>> >>>> I will need a sponsor for this change. >>>> >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8075401 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~kbarrett/8075401/webrev.00/ >>> As far as I can tell this is fine. > Ok. That's fine. Let's leave it as it is. > > Reviewed. > > Bengt Looking for a second reviewer. Also a sponsor. From bengt.rutisson at oracle.com Mon Mar 30 09:15:06 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 30 Mar 2015 11:15:06 +0200 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <8B99B9A3-7298-4119-88D2-BEFA3D16E078@oracle.com> References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> <55014F32.3030400@oracle.com> <5501683D.2000905@oracle.com> <58A2D320-A2E7-4304-90CA-CC1C768DA52C@oracle.com> <5502A38F.7000000@oracle.com> <5515BC16.3090405@oracle.com> <8B99B9A3-7298-4119-88D2-BEFA3D16E078@oracle.com> Message-ID: <5519141A.2090705@oracle.com> On 2015-03-30 03:28, Kim Barrett wrote: > On Mar 28, 2015, at 12:31 AM, Kim Barrett wrote: >> On Mar 27, 2015, at 4:22 PM, Jon Masamitsu wrote: >>> That's my only question and it is for my education so you can >>> consider this a complete 2nd review. >> Well, there may be further changes. Thomas and Bengt wondered if excluding typeArrays >> allocated before the start of the in-progress concurrent mark might matter. I?ve been looking >> at a way to still allow that. >> >> Though maybe the version that has been reviewed is good enough, and the possible further >> improvement can be done as followup work? Bengt and Thomas? > Another round on this. > > In the previous version we disallowed eager reclaim of any humongous > objects that were allocated prior to the current snapshot when > concurrent marking was in progress. As noted, there was some concern > (private email with Thomas and Bengt) that this would result in more > headroom being needed because some humongous objects that were > previously reclaimed now would not be. > > This time we allow pre-snapshot humongous typeArrays to be candidates > for reclaiming. However, we now ensure that such objects won't ever > be added to the mark stack. We accomplish this by filtering out all > typeArrays from the mark stack; rather than pushing them we > immediately perform the "scan", which for typeArray objects amounts to > just doing some bookkeeping and checking task limits. > > The addition of typeArray filtering in front of the mark stack is > rather far away from the place that is requiring it. I'm not entirely > happy with this coupling, and would be OK with not going this extra > step. > > The cost of the pre-filtering of the mark stack is small, and some of > it may be recovered by avoiding the cost of moving the filtered > objects through the mark stack, and by doing less work on the filtered > objects than would otherwise be needed. Aurora GC performance tests > show mostly insignificant differences, with a few small improvements > compared to the baseline that has bug 8069367. I like this approach. I think it makes sense even without the humongous reclamation issues to handle type arrays specially. > [While I was at it, I simplified the conditionalization of > deal_with_references for _CHECK_BOTH_FINGERS_, eliminating some code > duplication.] Personally I would prefer to do a small cleanup fix before your change to simply remove _CHECK_BOTH_FINGERS_. It has been in the code since 2011 (JDK-7046558: G1: concurrent marking optimizations) and as I understand it it was mostly added because there was not time to do enough performance testing at the time. I doubt that anyone will pick up the performance work here, so I'd rather remove the code. > CR: > https://bugs.openjdk.java.net/browse/JDK-8069367 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8069367/webrev.03/ A couple of questions about this code in concurrentMark.inline.hpp: 300 if (_CHECK_BOTH_FINGERS_ && _finger != NULL && objAddr < _finger) { 301 if (obj->is_typeArray()) { 302 // Immediately process arrays of binary data, rather 303 // than pushing on the mark stack. This keeps us from 304 // adding humongous objects to the mark stack that might 305 // be reclaimed before the entry is processed - see 306 // G1EagerReclaimHumongousPreSnapshotTypeArrays. The 307 // cost of the additional type test is mitigated by 308 // avoiding a trip through the mark stack, and by only 309 // doing bookkeeping update and avoiding the actual scan 310 // of the object - a typeArray contains no references, 311 // and the metadata is built-in. 312 process_grey_object(obj); 313 } else { 314 if (_cm->verbose_high()) { 315 gclog_or_tty->print_cr( 316 "[%u] below the local finger (" PTR_FORMAT "), pushing " PTR_FORMAT, 317 _worker_id, p2i(_finger), p2i(objAddr)); 318 } 319 push(obj); 320 } It looks to me like the logging (lines 314-318) is relevant for type arrays too. Can we move it up before line 301? Possibly changing the wording from "pushing" to something more generic - maybe simply "obj". I think the comment (lines 302-311) is good but it takes up a lot of space inside the deal_with_reference() method. How about breaking lines 301-320 out into its own method? (Keeping the logging that I mentioned in the previous paragraph inside deal_with_reference().) I'm not sure I understand the changes in the g1CollectedHeap.* files. In particular the changes to RegisterHumongousWithInCSetFastTestClosure: http://cr.openjdk.java.net/~kbarrett/8069367/webrev.03/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html It looks like the G1EagerReclaimHumongousPreSnapshotTypeArrays flag controls if you want to use the previous version (don't reclaim objects that may be part of the SATB snapshot) and the new version (don't push type arrays on the mark stack). Is this debugging code that was left or is your intention that we should have both versions in the code? Thanks, Bengt > > Incremental webrev: > http://cr.openjdk.java.net/~kbarrett/8069367/webrev.03.incr/ > > Testing: > Hand testing > JPRT > Aurora Ad-hoc GC Nightly using G1 > Aurora GC perf test using G1. > From bengt.rutisson at oracle.com Mon Mar 30 11:03:03 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 30 Mar 2015 13:03:03 +0200 Subject: Request for review (s) : 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads In-Reply-To: <55156B31.3080906@oracle.com> References: <54FF1B4A.9020609@oracle.com> <5514DD8B.2070700@oracle.com> <55152756.8090307@oracle.com> <55156B31.3080906@oracle.com> Message-ID: <55192D67.7020205@oracle.com> Hi Jon, On 2015-03-27 15:37, Jon Masamitsu wrote: > Bengt, > > Thanks for looking at this. > > On 3/27/2015 2:48 AM, Bengt Rutisson wrote: >> >> On 2015-03-27 05:33, Jon Masamitsu wrote: >>> The fix for 8017462 has been changed to adopt the suggestion from >>> Bengt (thanks, Bengt). The patch from Bengt has been enhanced to >>> include some of the changes in this first version that did not make >>> it into Bengt's original patch. The test remains the same. A CR >>> has been >>> created to add another test to check the consistency of one of >>> the per thread statistics with the sum of the statistics over all the >>> threads (e.g., per thread object copy time and total object copy time) >>> https://bugs.openjdk.java.net/browse/JDK-8076140 >>> >>> http://cr.openjdk.java.net/~jmasa/8017462/webrev.01/ >> >> Thanks for adopting this patch. I think it looks good now. :) >> >> A couple of questions about the test case. >> >> The proposed test will run with any GC configuration since it just >> discards the JTreg configuration and selects its own GC. You have >> specified @requires vm.gc=="null", which makes sense since we don't >> have to run this test in every configuration. The test will anyway >> always run with the GCs that it specifies itself. However, the >> @requires tag will mean that the test is only run if no GC is >> specified. Currently there is a "noopt" baseline in our nightly >> testing that runs without explicitly setting a GC, so this test will >> be run there. But if we change the nightly baselines to always >> specify a GC we will never run this test. > > I would not expect that the nightly testing to always specify a > specific GC because > we do have a default GC and test should be run when we do the > selection of the > GC. Is this going to changes such that every nightly test specifies a > specific GC? > > Are you suggesting that the command line be changed to not include a > specific GC and that the the @requires be removed? So the test is run > with whatever GC is being tested? I think I prefer that the test specifies the GCs that it needs to test rather than relying on the framework to pass the relevant GC flags. So, I prefer the way the test is written now. My question was really if we want to use @requires for controlling when a test is run. More below... > >> >> I guess this is a more general question. Should we use @requires to >> avoid running the same test many times or should we only use it when >> the test actually requires a specific GC configuration? > > I'll happily take guidance on this point. Only using it when tests > actually requires a specific > GC sounds OK. I'm also not sure, so my question was really a question. Is this how we want to make sure that a generic test is only run once? There are other ways...test groups, nightly batch configuration etc... > >> >> Also, the test use a lot of flags: >> >> "-XX:+UnlockExperimentalVMOptions", "-XX:G1LogLevel=finest", "-XX:+" >> + gcFlag, "-Xmx10M", "-showversion", "-XX:+PrintGCDetails", >> "-XX:+UseDynamicNumberOfGCThreads", "-XX:+TraceDynamicGCThreads" >> >> >> I think this should be enough: >> >> "-XX:+" + gcFlag, "-Xmx10M", "-XX:+UseDynamicNumberOfGCThreads", >> "-XX:+TraceDynamicGCThreads" >> >> Is there a particular reason to have the other flags? > > In some of my testing there was a failure when I ran with log level > set to finest > that I did not see when I used the default logging level. I cannot > recall if it was > actually this test but I decided to add finest to this test as a > result of seeing > that failure. I don't see why the G1 log level would affect this test. Can you try to reproduce the issue? If not I would prefer to remove those flags. > > Wow. I have not known that G1 logging is printed when PrintGCDetails is > off. Is that really the intent? Yes, that was intentional when G1LogLevel was introduced. I'm not saying it is the right choice, but it was intentional. All of this will be replaced with the unified logging for JDK 9, so I doubt that it is worth digging too deep into it now. Thanks, Bengt > > Jon > > >> >> Thanks, >> Bengt >> >>> >>> On 3/10/2015 9:26 AM, Jon Masamitsu wrote: >>>> 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8017462 >>>> >>>> When fewer than the maximum number of threads was being used for >>>> a parallel section, phase times for the threads that did not >>>> execute and >>>> averages for the phase were misleading. The fix passes the active >>>> number of >>>> GC threads to the G1 phase timers. >>>> >>>> http://cr.openjdk.java.net/~jmasa/8017462/webrev.00/ >>>> >>>> Tested with gc_test_suite. >>> >> > From bengt.rutisson at oracle.com Mon Mar 30 11:27:57 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 30 Mar 2015 13:27:57 +0200 Subject: RFR (S): JDK-8076225: Move the thread claim parity from SharedHeap to Thread Message-ID: <5519333D.5040606@oracle.com> Hi everyone, This patch was contributed by Mikael Gerdin, I'm mostly just shepherding this patch in to the repo. http://cr.openjdk.java.net/~brutisso/8076225/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8076225 From the bug report: The thread claim parity is used to parallelize the scanning of root in the JavaThreads. This was placed in SharedHeap, but used by the Thread class (Threads::possibly_parallel_oops_do()). Moving this claiming state into the Thread class will collect the state information and the usage in one place. It will also anther step towards eventually being able to remove SharedHeap. Apart from just moving the claiming state, Mikael also added an assert that verifies that all Java threads have the correct parity after a GC. This is to quickly find out if anybody forgets to handle the Java threads during root processing at some point. Thanks, Bengt From kim.barrett at oracle.com Mon Mar 30 12:42:40 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 30 Mar 2015 08:42:40 -0400 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: <5519141A.2090705@oracle.com> References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> <55014F32.3030400@oracle.com> <5501683D.2000905@oracle.com> <58A2D320-A2E7-4304-90CA-CC1C768DA52C@oracle.com> <5502A38F.7000000@oracle.com> <5515BC16.3090405@oracle.com> <8B99B9A3-7298-4119-88D2-BEFA3D16E078@oracle.com> <5519141A.2090705@oracle.com> Message-ID: On Mar 30, 2015, at 5:15 AM, Bengt Rutisson wrote: > On 2015-03-30 03:28, Kim Barrett wrote: >> The cost of the pre-filtering of the mark stack is small, and some of >> it may be recovered by avoiding the cost of moving the filtered >> objects through the mark stack, and by doing less work on the filtered >> objects than would otherwise be needed. Aurora GC performance tests >> show mostly insignificant differences, with a few small improvements >> compared to the baseline that has bug 8069367. > > I like this approach. I think it makes sense even without the > humongous reclamation issues to handle type arrays specially. I've been waffling over this. I would guess it would be a rare application that had a sufficiently low typeArray / object ratio that this would negatively impact performance (by a small amount?), and common for it to be a net benefit. But I don't have any data to back up that guess. And the effect is dynamic, since it doesn't apply in the non-push case - I don't think we should add such a check in scan_object. >> [While I was at it, I simplified the conditionalization of >> deal_with_references for _CHECK_BOTH_FINGERS_, eliminating some code >> duplication.] > > Personally I would prefer to do a small cleanup fix before your change > to simply remove _CHECK_BOTH_FINGERS_. It has been in the code since > 2011 (JDK-7046558: G1: concurrent marking optimizations) and as I > understand it it was mostly added because there was not time to do > enough performance testing at the time. I doubt that anyone will pick > up the performance work here, so I'd rather remove the code. I would be fine with killing off _CHECK_BOTH_FINGERS_. And looking at that code again, it seems like it would be worth trying to eliminate one or both of the _finger or _curr_region NULL checks. I'll take a look at that. > A couple of questions about this code in concurrentMark.inline.hpp: > > 300 if (_CHECK_BOTH_FINGERS_ && _finger != NULL && objAddr < _finger) { > 301 if (obj->is_typeArray()) { > 302 // Immediately process arrays of binary data, rather > 303 // than pushing on the mark stack. This keeps us from > 304 // adding humongous objects to the mark stack that might > 305 // be reclaimed before the entry is processed - see > 306 // G1EagerReclaimHumongousPreSnapshotTypeArrays. The > 307 // cost of the additional type test is mitigated by > 308 // avoiding a trip through the mark stack, and by only > 309 // doing bookkeeping update and avoiding the actual scan > 310 // of the object - a typeArray contains no references, > 311 // and the metadata is built-in. > 312 process_grey_object(obj); > 313 } else { > 314 if (_cm->verbose_high()) { > 315 gclog_or_tty->print_cr( > 316 "[%u] below the local finger (" PTR_FORMAT "), pushing " PTR_FORMAT, > 317 _worker_id, p2i(_finger), p2i(objAddr)); > 318 } > 319 push(obj); > 320 } > > It looks to me like the logging (lines 314-318) is relevant for type > arrays too. Can we move it up before line 301? Possibly changing the > wording from "pushing" to something more generic - maybe simply "obj". I limited the logging to the "push" branch intentionally. process_grey_objects similarly logs, and to me it didn't seem useful to have both in the non-push case and to lose the "pushing" distinction in that case. I would be more inclined to add an explicit immediate processing vs pushing distinction in the log output than to merge away that distinction. (That distinction is presently implicit from deal_with_reference logging each object that needs marking, followed by the process_grey_objects message, the pushing message, or silence because par_mark lost the race with some other task.) > I think the comment (lines 302-311) is good but it takes up a lot of > space inside the deal_with_reference() method. How about breaking > lines 301-320 out into its own method? (Keeping the logging that I > mentioned in the previous paragraph inside deal_with_reference().) I thought about that, but put it aside when I failed to come up with a decent name for that helper function, and didn't got back to it. I'll think about it some more. > I'm not sure I understand the changes in the g1CollectedHeap.* > files. In particular the changes to > RegisterHumongousWithInCSetFastTestClosure: > > http://cr.openjdk.java.net/~kbarrett/8069367/webrev.03/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html > > It looks like the G1EagerReclaimHumongousPreSnapshotTypeArrays flag > controls if you want to use the previous version (don't reclaim > objects that may be part of the SATB snapshot) and the new version > (don't push type arrays on the mark stack). Is this debugging code > that was left or is your intention that we should have both versions > in the code? We've encountered a number of bugs related to the eager reclaim of humongous objects feature, some of which might end up requiring the previous behavior. (When I say "might", I mean I have little confidence either way right now.) And there might be more we haven't run into yet. This new flag is intended as a partial mitigation strategy for those, being weaker than simply turning off one or both of the other related flags. It also provides a searchable name to for the coupling between the this code and the is_typeArray check in deal_with_reference. But maybe the comment in the latter is sufficient now? From jesper.wilhelmsson at oracle.com Mon Mar 30 13:21:12 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 30 Mar 2015 15:21:12 +0200 Subject: RFR: 8075401: Remove DiscoveredListIterator::update_discovered() In-Reply-To: <45B6B9F7-1066-4B81-8DEC-3802D684F6D9@oracle.com> References: <55099581.3080903@oracle.com> <550A9E17.5040006@oracle.com> <45B6B9F7-1066-4B81-8DEC-3802D684F6D9@oracle.com> Message-ID: <55194DC8.8060706@oracle.com> Looks good. I can sponsor. /Jesper Kim Barrett skrev den 30/3/15 06:04: > On Mar 19, 2015, at 5:59 AM, Bengt Rutisson wrote: >> >>>> On 2015-03-18 01:20, Kim Barrett wrote: >>>>> Please review this change to remove unnecessary calls to >>>>> DiscoveredListIterator::update_discovered(), and remove the now unused >>>>> function. Details are in the CR. >>>>> >>>>> I will need a sponsor for this change. >>>>> >>>>> CR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8075401 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~kbarrett/8075401/webrev.00/ >>>> As far as I can tell this is fine. >> Ok. That's fine. Let's leave it as it is. >> >> Reviewed. >> >> Bengt > > Looking for a second reviewer. Also a sponsor. > From eric.caspole at oracle.com Mon Mar 30 13:29:01 2015 From: eric.caspole at oracle.com (Eric Caspole) Date: Mon, 30 Mar 2015 09:29:01 -0400 Subject: RFR: 8075401: Remove DiscoveredListIterator::update_discovered() In-Reply-To: <45B6B9F7-1066-4B81-8DEC-3802D684F6D9@oracle.com> References: <55099581.3080903@oracle.com> <550A9E17.5040006@oracle.com> <45B6B9F7-1066-4B81-8DEC-3802D684F6D9@oracle.com> Message-ID: <55194F9D.2060102@oracle.com> Looks good. Eric On 3/30/2015 12:04 AM, Kim Barrett wrote: > On Mar 19, 2015, at 5:59 AM, Bengt Rutisson wrote: >>>> On 2015-03-18 01:20, Kim Barrett wrote: >>>>> Please review this change to remove unnecessary calls to >>>>> DiscoveredListIterator::update_discovered(), and remove the now unused >>>>> function. Details are in the CR. >>>>> >>>>> I will need a sponsor for this change. >>>>> >>>>> CR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8075401 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~kbarrett/8075401/webrev.00/ >>>> As far as I can tell this is fine. >> Ok. That's fine. Let's leave it as it is. >> >> Reviewed. >> >> Bengt > Looking for a second reviewer. Also a sponsor. > From jesper.wilhelmsson at oracle.com Mon Mar 30 13:40:49 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 30 Mar 2015 15:40:49 +0200 Subject: RFR (S): JDK-8076225: Move the thread claim parity from SharedHeap to Thread In-Reply-To: <5519333D.5040606@oracle.com> References: <5519333D.5040606@oracle.com> Message-ID: <55195261.3010903@oracle.com> Looks good. I assume you count yourself as a Reviewer(?) /Jesper Bengt Rutisson skrev den 30/3/15 13:27: > > Hi everyone, > > This patch was contributed by Mikael Gerdin, I'm mostly just shepherding this > patch in to the repo. > > http://cr.openjdk.java.net/~brutisso/8076225/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8076225 > > From the bug report: > > The thread claim parity is used to parallelize the scanning of root in the > JavaThreads. This was placed in SharedHeap, but used by the Thread class > (Threads::possibly_parallel_oops_do()). Moving this claiming state into the > Thread class will collect the state information and the usage in one place. It > will also anther step towards eventually being able to remove SharedHeap. > > > Apart from just moving the claiming state, Mikael also added an assert that > verifies that all Java threads have the correct parity after a GC. This is to > quickly find out if anybody forgets to handle the Java threads during root > processing at some point. > > Thanks, > Bengt > From bengt.rutisson at oracle.com Mon Mar 30 13:44:37 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 30 Mar 2015 15:44:37 +0200 Subject: RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed In-Reply-To: References: <1425894736.3398.22.camel@oracle.com> <066FA826-04CC-4289-82E9-27ACD0D9EAFA@oracle.com> <1426067448.3171.8.camel@oracle.com> <65C4908D-F583-45DF-8170-CBFBDD14A46B@oracle.com> <55014F32.3030400@oracle.com> <5501683D.2000905@oracle.com> <58A2D320-A2E7-4304-90CA-CC1C768DA52C@oracle.com> <5502A38F.7000000@oracle.com> <5515BC16.3090405@oracle.com> <8B99B9A3-7298-4119-88D2-BEFA3D16E078@oracle.com> <5519141A.2090705@oracle.com> Message-ID: <55195345.70305@oracle.com> On 2015-03-30 14:42, Kim Barrett wrote: > On Mar 30, 2015, at 5:15 AM, Bengt Rutisson wrote: >> On 2015-03-30 03:28, Kim Barrett wrote: >>> The cost of the pre-filtering of the mark stack is small, and some of >>> it may be recovered by avoiding the cost of moving the filtered >>> objects through the mark stack, and by doing less work on the filtered >>> objects than would otherwise be needed. Aurora GC performance tests >>> show mostly insignificant differences, with a few small improvements >>> compared to the baseline that has bug 8069367. >> I like this approach. I think it makes sense even without the >> humongous reclamation issues to handle type arrays specially. > I've been waffling over this. I would guess it would be a rare > application that had a sufficiently low typeArray / object ratio that > this would negatively impact performance (by a small amount?), and > common for it to be a net benefit. But I don't have any data to back > up that guess. And the effect is dynamic, since it doesn't apply in > the non-push case - I don't think we should add such a check in > scan_object. Right. Agreed. > >>> [While I was at it, I simplified the conditionalization of >>> deal_with_references for _CHECK_BOTH_FINGERS_, eliminating some code >>> duplication.] >> Personally I would prefer to do a small cleanup fix before your change >> to simply remove _CHECK_BOTH_FINGERS_. It has been in the code since >> 2011 (JDK-7046558: G1: concurrent marking optimizations) and as I >> understand it it was mostly added because there was not time to do >> enough performance testing at the time. I doubt that anyone will pick >> up the performance work here, so I'd rather remove the code. > I would be fine with killing off _CHECK_BOTH_FINGERS_. And looking at > that code again, it seems like it would be worth trying to eliminate > one or both of the _finger or _curr_region NULL checks. > > I'll take a look at that. Great! Thanks! > >> A couple of questions about this code in concurrentMark.inline.hpp: >> >> 300 if (_CHECK_BOTH_FINGERS_ && _finger != NULL && objAddr < _finger) { >> 301 if (obj->is_typeArray()) { >> 302 // Immediately process arrays of binary data, rather >> 303 // than pushing on the mark stack. This keeps us from >> 304 // adding humongous objects to the mark stack that might >> 305 // be reclaimed before the entry is processed - see >> 306 // G1EagerReclaimHumongousPreSnapshotTypeArrays. The >> 307 // cost of the additional type test is mitigated by >> 308 // avoiding a trip through the mark stack, and by only >> 309 // doing bookkeeping update and avoiding the actual scan >> 310 // of the object - a typeArray contains no references, >> 311 // and the metadata is built-in. >> 312 process_grey_object(obj); >> 313 } else { >> 314 if (_cm->verbose_high()) { >> 315 gclog_or_tty->print_cr( >> 316 "[%u] below the local finger (" PTR_FORMAT "), pushing " PTR_FORMAT, >> 317 _worker_id, p2i(_finger), p2i(objAddr)); >> 318 } >> 319 push(obj); >> 320 } >> >> It looks to me like the logging (lines 314-318) is relevant for type >> arrays too. Can we move it up before line 301? Possibly changing the >> wording from "pushing" to something more generic - maybe simply "obj". > I limited the logging to the "push" branch intentionally. > process_grey_objects similarly logs, and to me it didn't seem useful > to have both in the non-push case and to lose the "pushing" > distinction in that case. I would be more inclined to add an explicit > immediate processing vs pushing distinction in the log output than to > merge away that distinction. (That distinction is presently implicit > from deal_with_reference logging each object that needs marking, > followed by the process_grey_objects message, the pushing message, or > silence because par_mark lost the race with some other task.) Ok. Thanks for explaining this. I'm fine with the logging as you suggested it. > >> I think the comment (lines 302-311) is good but it takes up a lot of >> space inside the deal_with_reference() method. How about breaking >> lines 301-320 out into its own method? (Keeping the logging that I >> mentioned in the previous paragraph inside deal_with_reference().) > I thought about that, but put it aside when I failed to come up with a > decent name for that helper function, and didn't got back to it. I'll > think about it some more. Good. Thanks! > >> I'm not sure I understand the changes in the g1CollectedHeap.* >> files. In particular the changes to >> RegisterHumongousWithInCSetFastTestClosure: >> >> http://cr.openjdk.java.net/~kbarrett/8069367/webrev.03/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html >> >> It looks like the G1EagerReclaimHumongousPreSnapshotTypeArrays flag >> controls if you want to use the previous version (don't reclaim >> objects that may be part of the SATB snapshot) and the new version >> (don't push type arrays on the mark stack). Is this debugging code >> that was left or is your intention that we should have both versions >> in the code? > We've encountered a number of bugs related to the eager reclaim of > humongous objects feature, some of which might end up requiring the > previous behavior. (When I say "might", I mean I have little > confidence either way right now.) And there might be more we haven't > run into yet. This new flag is intended as a partial mitigation > strategy for those, being weaker than simply turning off one or both > of the other related flags. > > It also provides a searchable name to for the coupling between the > this code and the is_typeArray check in deal_with_reference. But > maybe the comment in the latter is sufficient now? I'm not too happy about adding code just in case we need it. I'm afraid that the code for the -XX:-G1EagerReclaimHumongousPreSnapshotTypeArrays case will be tested very rarely and when we suddenly need it it will contain some subtle bugs and just cause more problems for us. Bengt > From bengt.rutisson at oracle.com Mon Mar 30 13:45:47 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 30 Mar 2015 15:45:47 +0200 Subject: RFR (S): JDK-8076225: Move the thread claim parity from SharedHeap to Thread In-Reply-To: <55195261.3010903@oracle.com> References: <5519333D.5040606@oracle.com> <55195261.3010903@oracle.com> Message-ID: <5519538B.80600@oracle.com> On 2015-03-30 15:40, Jesper Wilhelmsson wrote: > Looks good. Thanks, Jesper! > > I assume you count yourself as a Reviewer(?) Yes, so unless anyone else looks at this and complains I'll push it tomorrow :) Thanks, Bengt > /Jesper > > > Bengt Rutisson skrev den 30/3/15 13:27: >> >> Hi everyone, >> >> This patch was contributed by Mikael Gerdin, I'm mostly just >> shepherding this >> patch in to the repo. >> >> http://cr.openjdk.java.net/~brutisso/8076225/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8076225 >> >> From the bug report: >> >> The thread claim parity is used to parallelize the scanning of root >> in the >> JavaThreads. This was placed in SharedHeap, but used by the Thread class >> (Threads::possibly_parallel_oops_do()). Moving this claiming state >> into the >> Thread class will collect the state information and the usage in one >> place. It >> will also anther step towards eventually being able to remove >> SharedHeap. >> >> >> Apart from just moving the claiming state, Mikael also added an >> assert that >> verifies that all Java threads have the correct parity after a GC. >> This is to >> quickly find out if anybody forgets to handle the Java threads during >> root >> processing at some point. >> >> Thanks, >> Bengt >> From bengt.rutisson at oracle.com Mon Mar 30 13:53:20 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 30 Mar 2015 15:53:20 +0200 Subject: RFR (XS): JDK-8076237: Remove unused _collector_policy field in SharedHeap Message-ID: <55195550.1050408@oracle.com> Hi all, Can I have a couple of reviews for this small patch? http://cr.openjdk.java.net/~brutisso/8076237/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8076237 The _collector_policy field in SharedHeap is no longer used. Thanks, Bengt From per.liden at oracle.com Mon Mar 30 14:00:00 2015 From: per.liden at oracle.com (Per Liden) Date: Mon, 30 Mar 2015 16:00:00 +0200 Subject: RFR(s): 8076231: Remove unused is_in_partial_collection() Message-ID: <551956E0.4080503@oracle.com> Hi, Please review this small cleanup. All collectors provide an implementation for is_in_partial_collection(), but it's actually only ever used by GenCollectedHeap. This patch removes the unused versions and removes the function from the CollectedHeap interface. Webrev: http://cr.openjdk.java.net/~pliden/8076231/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8076231 Testing: jprt /Per From jesper.wilhelmsson at oracle.com Mon Mar 30 14:04:13 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 30 Mar 2015 16:04:13 +0200 Subject: RFR (XS): JDK-8076237: Remove unused _collector_policy field in SharedHeap In-Reply-To: <55195550.1050408@oracle.com> References: <55195550.1050408@oracle.com> Message-ID: <551957DD.4030405@oracle.com> Looks good! /Jesper Bengt Rutisson skrev den 30/3/15 15:53: > > Hi all, > > Can I have a couple of reviews for this small patch? > > http://cr.openjdk.java.net/~brutisso/8076237/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8076237 > > The _collector_policy field in SharedHeap is no longer used. > > Thanks, > Bengt From bengt.rutisson at oracle.com Mon Mar 30 14:00:51 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 30 Mar 2015 16:00:51 +0200 Subject: RFR(s): 8076231: Remove unused is_in_partial_collection() In-Reply-To: <551956E0.4080503@oracle.com> References: <551956E0.4080503@oracle.com> Message-ID: <55195713.8070708@oracle.com> Hi Per, On 2015-03-30 16:00, Per Liden wrote: > Hi, > > Please review this small cleanup. > > All collectors provide an implementation for > is_in_partial_collection(), but it's actually only ever used by > GenCollectedHeap. This patch removes the unused versions and removes > the function from the CollectedHeap interface. > > Webrev: http://cr.openjdk.java.net/~pliden/8076231/webrev.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076231 > > Testing: jprt Looks good. Bengt > > /Per From bengt.rutisson at oracle.com Mon Mar 30 14:01:10 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 30 Mar 2015 16:01:10 +0200 Subject: RFR (XS): JDK-8076237: Remove unused _collector_policy field in SharedHeap In-Reply-To: <551957DD.4030405@oracle.com> References: <55195550.1050408@oracle.com> <551957DD.4030405@oracle.com> Message-ID: <55195726.2030208@oracle.com> On 2015-03-30 16:04, Jesper Wilhelmsson wrote: > Looks good! Thanks, Jesper! Bengt > /Jesper > > Bengt Rutisson skrev den 30/3/15 15:53: >> >> Hi all, >> >> Can I have a couple of reviews for this small patch? >> >> http://cr.openjdk.java.net/~brutisso/8076237/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8076237 >> >> The _collector_policy field in SharedHeap is no longer used. >> >> Thanks, >> Bengt From per.liden at oracle.com Mon Mar 30 14:23:18 2015 From: per.liden at oracle.com (Per Liden) Date: Mon, 30 Mar 2015 16:23:18 +0200 Subject: RFR(s): 8076231: Remove unused is_in_partial_collection() In-Reply-To: <55195713.8070708@oracle.com> References: <551956E0.4080503@oracle.com> <55195713.8070708@oracle.com> Message-ID: <55195C56.1080707@oracle.com> Thanks Bengt! /Per On 2015-03-30 16:00, Bengt Rutisson wrote: > > Hi Per, > > On 2015-03-30 16:00, Per Liden wrote: >> Hi, >> >> Please review this small cleanup. >> >> All collectors provide an implementation for >> is_in_partial_collection(), but it's actually only ever used by >> GenCollectedHeap. This patch removes the unused versions and removes >> the function from the CollectedHeap interface. >> >> Webrev: http://cr.openjdk.java.net/~pliden/8076231/webrev.0/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076231 >> >> Testing: jprt > > Looks good. > > Bengt > >> >> /Per > From bengt.rutisson at oracle.com Mon Mar 30 14:18:57 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 30 Mar 2015 16:18:57 +0200 Subject: RFR (S): JDK-8076241: Remove unused methods mod_card_iterate() and non_clean_card_iterate_serial() Message-ID: <55195B51.3030403@oracle.com> Hi all, Could I have a couple of reviews for this small change? http://cr.openjdk.java.net/~brutisso/8076241/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8076241 The methods mod_card_iterate() and non_clean_card_iterate_serial() in CardTableModRefBS are not being used. Thanks, Bengt From kim.barrett at oracle.com Mon Mar 30 14:28:59 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 30 Mar 2015 10:28:59 -0400 Subject: RFR: 8075401: Remove DiscoveredListIterator::update_discovered() In-Reply-To: <55194DC8.8060706@oracle.com> References: <55099581.3080903@oracle.com> <550A9E17.5040006@oracle.com> <45B6B9F7-1066-4B81-8DEC-3802D684F6D9@oracle.com> <55194DC8.8060706@oracle.com> Message-ID: On Mar 30, 2015, at 9:21 AM, Jesper Wilhelmsson wrote: > > Looks good. > I can sponsor. Thanks for your review. I?ll send you an hg export later today. From kim.barrett at oracle.com Mon Mar 30 14:29:14 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 30 Mar 2015 10:29:14 -0400 Subject: RFR: 8075401: Remove DiscoveredListIterator::update_discovered() In-Reply-To: <55194F9D.2060102@oracle.com> References: <55099581.3080903@oracle.com> <550A9E17.5040006@oracle.com> <45B6B9F7-1066-4B81-8DEC-3802D684F6D9@oracle.com> <55194F9D.2060102@oracle.com> Message-ID: On Mar 30, 2015, at 9:29 AM, Eric Caspole wrote: > > Looks good. > Eric Thanks for your review. From kim.barrett at oracle.com Mon Mar 30 16:00:52 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 30 Mar 2015 12:00:52 -0400 Subject: RFR (S): JDK-8076225: Move the thread claim parity from SharedHeap to Thread In-Reply-To: <5519538B.80600@oracle.com> References: <5519333D.5040606@oracle.com> <55195261.3010903@oracle.com> <5519538B.80600@oracle.com> Message-ID: <145AA3D7-7DC5-4EC3-99F0-D6B4264CF9E0@oracle.com> On Mar 30, 2015, at 9:45 AM, Bengt Rutisson wrote: > > > On 2015-03-30 15:40, Jesper Wilhelmsson wrote: >> Looks good. > > Thanks, Jesper! > >> >> I assume you count yourself as a Reviewer(?) > > Yes, so unless anyone else looks at this and complains I'll push it tomorrow :) There?s a big comment in src/share/vm/memory/sharedHeap.hpp, preceding the location of the now removed strong_roots_parity(), which talks about the parity handling. It seems kind of misplaced now (though it is related to the StrongRootsScope). It also refers to the strong_roots_parity() function, which is being removed. The code changes look ok. From derek.white at oracle.com Mon Mar 30 16:54:41 2015 From: derek.white at oracle.com (Derek White) Date: Mon, 30 Mar 2015 12:54:41 -0400 Subject: RFR (S): JDK-8069004: Kitchensink hanged with 16Gb heap and GC pause >30 min Message-ID: <55197FD1.8090006@oracle.com> This is a P1 bug in JDK 9 - a conflict when freeing continues_humongous regions. The scenario is a region was continues_humongous is then freed by one worker when the whole H-object is freed. The continues_humongous region needs to be claimed by the first worker, otherwise other workers may run into the free region. It turns out the fix was to revert a change made a few months ago. It didn't help out that an assert actually did the right thing, so it never failed in debug code :-) BUG: JDK-8069004 Kitchensink hanged with 16Gb heap and GC pause >30 min Webrev: http://cr.openjdk.java.net/~drwhite/8069004/webrev.00/ Ran jprt. Thanks! - Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Mon Mar 30 17:36:59 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 30 Mar 2015 13:36:59 -0400 Subject: RFR (S): JDK-8069004: Kitchensink hanged with 16Gb heap and GC pause >30 min In-Reply-To: <55197FD1.8090006@oracle.com> References: <55197FD1.8090006@oracle.com> Message-ID: On Mar 30, 2015, at 12:54 PM, Derek White wrote: > > This is a P1 bug in JDK 9 - a conflict when freeing continues_humongous regions. > > The scenario is a region was continues_humongous is then freed by one worker when the whole H-object is freed. The continues_humongous region needs to be claimed by the first worker, otherwise other workers may run into the free region. It turns out the fix was to revert a change made a few months ago. > > It didn't help out that an assert actually did the right thing, so it never failed in debug code :-) > > BUG: JDK-8069004 Kitchensink hanged with 16Gb heap and GC pause >30 min > Webrev: http://cr.openjdk.java.net/~drwhite/8069004/webrev.00/ Looks good. From bengt.rutisson at oracle.com Mon Mar 30 19:21:47 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 30 Mar 2015 21:21:47 +0200 Subject: RFR (S): JDK-8076225: Move the thread claim parity from SharedHeap to Thread In-Reply-To: <145AA3D7-7DC5-4EC3-99F0-D6B4264CF9E0@oracle.com> References: <5519333D.5040606@oracle.com> <55195261.3010903@oracle.com> <5519538B.80600@oracle.com> <145AA3D7-7DC5-4EC3-99F0-D6B4264CF9E0@oracle.com> Message-ID: <5519A24B.5060002@oracle.com> Hi Kim, Thanks for looking at this! On 30/03/15 18:00, Kim Barrett wrote: > On Mar 30, 2015, at 9:45 AM, Bengt Rutisson wrote: >> >> On 2015-03-30 15:40, Jesper Wilhelmsson wrote: >>> Looks good. >> Thanks, Jesper! >> >>> I assume you count yourself as a Reviewer(?) >> Yes, so unless anyone else looks at this and complains I'll push it tomorrow :) > There?s a big comment in src/share/vm/memory/sharedHeap.hpp, preceding the location > of the now removed strong_roots_parity(), which talks about the parity handling. It seems > kind of misplaced now (though it is related to the StrongRootsScope). It also refers to the > strong_roots_parity() function, which is being removed. I absolutely agree. The comment needs to be placed (and probably re-written a bit) closer to where this code now exist. The proposed patch is a step towards removing SharedHeap all together. The next step I am planning on is to move the StrongRootsScope handling out of SharedHeap. Would you be ok with me leaving the comment as it is now and postpone updating the comment to the StrongRootsScope patch? I'm convinced that I will need to work on the comments for that patch but I don't yet know exactly how it will end up. > The code changes look ok. Great! Thanks! Bengt > From derek.white at oracle.com Mon Mar 30 19:35:01 2015 From: derek.white at oracle.com (Derek White) Date: Mon, 30 Mar 2015 15:35:01 -0400 Subject: RFR (XS): JDK-8076237: Remove unused _collector_policy field in SharedHeap In-Reply-To: <55195550.1050408@oracle.com> References: <55195550.1050408@oracle.com> Message-ID: <5519A565.6020504@oracle.com> On 3/30/15 9:53 AM, Bengt Rutisson wrote: > > Hi all, > > Can I have a couple of reviews for this small patch? > > http://cr.openjdk.java.net/~brutisso/8076237/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8076237 > > The _collector_policy field in SharedHeap is no longer used. > > Thanks, > Bengt Hi Bengt, Obligatory copyright notice update for src/share/vm/memory/sharedHeap.hpp, otherwise looks great! - Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek.white at oracle.com Mon Mar 30 19:40:08 2015 From: derek.white at oracle.com (Derek White) Date: Mon, 30 Mar 2015 15:40:08 -0400 Subject: RFR(s): 8076231: Remove unused is_in_partial_collection() In-Reply-To: <551956E0.4080503@oracle.com> References: <551956E0.4080503@oracle.com> Message-ID: <5519A698.2080603@oracle.com> On 3/30/15 10:00 AM, Per Liden wrote: > Hi, > > Please review this small cleanup. > > All collectors provide an implementation for > is_in_partial_collection(), but it's actually only ever used by > GenCollectedHeap. This patch removes the unused versions and removes > the function from the CollectedHeap interface. > > Webrev: http://cr.openjdk.java.net/~pliden/8076231/webrev.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076231 > > Testing: jprt > > /Per Looks good to me Per. - Derek From kim.barrett at oracle.com Mon Mar 30 20:33:15 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 30 Mar 2015 16:33:15 -0400 Subject: RFR (S): JDK-8076225: Move the thread claim parity from SharedHeap to Thread In-Reply-To: <5519A24B.5060002@oracle.com> References: <5519333D.5040606@oracle.com> <55195261.3010903@oracle.com> <5519538B.80600@oracle.com> <145AA3D7-7DC5-4EC3-99F0-D6B4264CF9E0@oracle.com> <5519A24B.5060002@oracle.com> Message-ID: On Mar 30, 2015, at 3:21 PM, Bengt Rutisson wrote: > > > Hi Kim, > > Thanks for looking at this! > > On 30/03/15 18:00, Kim Barrett wrote: >> On Mar 30, 2015, at 9:45 AM, Bengt Rutisson wrote: >>> >>> On 2015-03-30 15:40, Jesper Wilhelmsson wrote: >>>> Looks good. >>> Thanks, Jesper! >>> >>>> I assume you count yourself as a Reviewer(?) >>> Yes, so unless anyone else looks at this and complains I'll push it tomorrow :) >> There?s a big comment in src/share/vm/memory/sharedHeap.hpp, preceding the location >> of the now removed strong_roots_parity(), which talks about the parity handling. It seems >> kind of misplaced now (though it is related to the StrongRootsScope). It also refers to the >> strong_roots_parity() function, which is being removed. > > I absolutely agree. The comment needs to be placed (and probably re-written a bit) closer to where this code now exist. > > The proposed patch is a step towards removing SharedHeap all together. The next step I am planning on is to move the StrongRootsScope handling out of SharedHeap. Would you be ok with me leaving the comment as it is now and postpone updating the comment to the StrongRootsScope patch? I'm convinced that I will need to work on the comments for that patch but I don't yet know exactly how it will end up. That?s mostly ok with me. But I?d like some kind of TBD comment added to the current change, in case of delays or distractions on that further cleanup. I don?t need another webrev to see such a comment though. From bengt.rutisson at oracle.com Mon Mar 30 20:47:58 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 30 Mar 2015 22:47:58 +0200 Subject: RFR (S): JDK-8076225: Move the thread claim parity from SharedHeap to Thread In-Reply-To: References: <5519333D.5040606@oracle.com> <55195261.3010903@oracle.com> <5519538B.80600@oracle.com> <145AA3D7-7DC5-4EC3-99F0-D6B4264CF9E0@oracle.com> <5519A24B.5060002@oracle.com> Message-ID: <5519B67E.4080007@oracle.com> On 30/03/15 22:33, Kim Barrett wrote: > On Mar 30, 2015, at 3:21 PM, Bengt Rutisson wrote: >> >> Hi Kim, >> >> Thanks for looking at this! >> >> On 30/03/15 18:00, Kim Barrett wrote: >>> On Mar 30, 2015, at 9:45 AM, Bengt Rutisson wrote: >>>> On 2015-03-30 15:40, Jesper Wilhelmsson wrote: >>>>> Looks good. >>>> Thanks, Jesper! >>>> >>>>> I assume you count yourself as a Reviewer(?) >>>> Yes, so unless anyone else looks at this and complains I'll push it tomorrow :) >>> There?s a big comment in src/share/vm/memory/sharedHeap.hpp, preceding the location >>> of the now removed strong_roots_parity(), which talks about the parity handling. It seems >>> kind of misplaced now (though it is related to the StrongRootsScope). It also refers to the >>> strong_roots_parity() function, which is being removed. >> I absolutely agree. The comment needs to be placed (and probably re-written a bit) closer to where this code now exist. >> >> The proposed patch is a step towards removing SharedHeap all together. The next step I am planning on is to move the StrongRootsScope handling out of SharedHeap. Would you be ok with me leaving the comment as it is now and postpone updating the comment to the StrongRootsScope patch? I'm convinced that I will need to work on the comments for that patch but I don't yet know exactly how it will end up. > That?s mostly ok with me. But I?d like some kind of TBD comment added to the current change, in case of delays or distractions on that further cleanup. I don?t need another webrev to see such a comment though. Great! Thanks! I'll add a TBD comment before I push. Bengt > > From bengt.rutisson at oracle.com Mon Mar 30 20:49:00 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 30 Mar 2015 22:49:00 +0200 Subject: RFR (XS): JDK-8076237: Remove unused _collector_policy field in SharedHeap In-Reply-To: <5519A565.6020504@oracle.com> References: <55195550.1050408@oracle.com> <5519A565.6020504@oracle.com> Message-ID: <5519B6BC.9040107@oracle.com> Hi Derek, Thanks for looking at this! On 30/03/15 21:35, Derek White wrote: > On 3/30/15 9:53 AM, Bengt Rutisson wrote: >> >> Hi all, >> >> Can I have a couple of reviews for this small patch? >> >> http://cr.openjdk.java.net/~brutisso/8076237/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8076237 >> >> The _collector_policy field in SharedHeap is no longer used. >> >> Thanks, >> Bengt > Hi Bengt, > > Obligatory copyright notice update for > src/share/vm/memory/sharedHeap.hpp, otherwise looks great! Thanks! I'll update the copyright before I push. Bengt > > - Derek > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Mon Mar 30 21:19:38 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 30 Mar 2015 17:19:38 -0400 Subject: [8u60] RFR of backport for 8049864: TestParallelHeapSizeFlags fails with unexpected heap size In-Reply-To: <1427363460.3149.13.camel@oracle.com> References: <1427363460.3149.13.camel@oracle.com> Message-ID: On Mar 26, 2015, at 5:51 AM, Thomas Schatzl wrote: > > Hi all, > > can I have reviews for the backport of "8049864: > TestParallelHeapSizeFlags fails with unexpected heap size" for 8u60? > > It did only apply with minor changes, so I need re-reviews. The problem > is that the test TestParallelHeapSizeFlags.java, during a few > intermediate steps (where an initial patch had been pushed, then > reverted) got an @ignore tag added, changed and later removed. > > The problem is that in the original revision, this code removed the > final @ignore, however since I did not backport all these 5 or 6 > additional changes (which also touch other files sometimes), there is a > conflict in removing the @ignore flag. > > I.e this hunk > --- a/test/gc/arguments/TestParallelHeapSizeFlags.java Mon Sep 15 > 13:32:30 2014 +0000 > +++ b/test/gc/arguments/TestParallelHeapSizeFlags.java Tue Jun 24 15:50:50 2014 +0200 > @@ -22,7 +22,6 @@ > */ > > /* > - * @ignore 8049864 > * @test TestParallelHeapSizeFlags > * @key gc > * @bug 8006088 > > Is not required for the backport. > > Note that this change is based on "8067469: G1 ignores AlwaysPreTouch" > which is also out for review. It fixes "8049536: > os::commit_memory on Solaris uses alignment_hint as page size". > > Full 8u60 changeset: > http://cr.openjdk.java.net/~tschatzl/8049864-8u60/webrev.8u60/ > > CR: > https://bugs.openjdk.java.net/browse/JDK-8049864 > Original change: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b326a3e8dcab Looks good. From kim.barrett at oracle.com Mon Mar 30 22:16:09 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 30 Mar 2015 18:16:09 -0400 Subject: RFR (S): JDK-8076241: Remove unused methods mod_card_iterate() and non_clean_card_iterate_serial() In-Reply-To: <55195B51.3030403@oracle.com> References: <55195B51.3030403@oracle.com> Message-ID: <15B61388-9257-466F-8355-867F30F49004@oracle.com> On Mar 30, 2015, at 10:18 AM, Bengt Rutisson wrote: > > > Hi all, > > Could I have a couple of reviews for this small change? > > http://cr.openjdk.java.net/~brutisso/8076241/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8076241 > > The methods mod_card_iterate() and non_clean_card_iterate_serial() in CardTableModRefBS are not being used. > > Thanks, > Bengt Aww. I was going to do that. Actually, I was supposed to file a RFE for this as a followup to 8062206 (Remove unusable G1RSLogCheckCardTable command line argument), but that seems to have not gotten out of my notes file. ------------------------------------------------------------------------------ src/share/vm/memory/cardTableModRefBS.hpp 181 // XXX ??? MemRegionClosure above vs OopsInGenClosure below XXX 182 // XXX some new_dcto_cl's take OopClosure's, plus as above there are 183 // some MemRegionClosures. Clean this up everywhere. XXX This untouched comment is referring to the removed non_clean_card_iterate_serial function ("above"), so needs to be updated. It may be that the comment can be removed entirely now, possibly being moved to the technical debt wiki. ------------------------------------------------------------------------------ src/share/vm/memory/cardTableModRefBS.hpp 382 // Invoke "cl.do_MemRegion" on a set of MemRegions that collectively 383 // includes all the modified cards (expressing each card as a 384 // MemRegion). Thus, several modified cards may be lumped into one 385 // region. The regions are non-overlapping, and are visited in 386 // *decreasing* address order. (This order aids with imprecise card 387 // marking, where a dirty card may cause scanning, and summarization 388 // marking, of objects that extend onto subsequent cards.) This comment was the reason I'd deferred removing mod_card_iterate. So far as I can tell, this comment is the *only* place where there is any discussion whatsoever of why some card iterators scan backward. I wanted to find a new and better home for that information before deleting the comment. ------------------------------------------------------------------------------ The code changes look good. From jon.masamitsu at oracle.com Mon Mar 30 22:40:33 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 30 Mar 2015 15:40:33 -0700 Subject: Request for review (s) : 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads In-Reply-To: <55192D67.7020205@oracle.com> References: <54FF1B4A.9020609@oracle.com> <5514DD8B.2070700@oracle.com> <55152756.8090307@oracle.com> <55156B31.3080906@oracle.com> <55192D67.7020205@oracle.com> Message-ID: <5519D0E1.8030601@oracle.com> I'm moving Bengt's question about using @requires into its own thread because it deserves it. On 03/30/2015 04:03 AM, Bengt Rutisson wrote: > > > >> >>> >>> I guess this is a more general question. Should we use @requires to >>> avoid running the same test many times or should we only use it when >>> the test actually requires a specific GC configuration? >> >> I'll happily take guidance on this point. Only using it when tests >> actually requires a specific >> GC sounds OK. > > I'm also not sure, so my question was really a question. Is this how > we want to make sure that a generic test is only run once? There are > other ways...test groups, nightly batch configuration etc... I like that @requires is local to the test so easy to change. Also that it works for JPRT when JPRT runs the jtreg tests. Jon From marcus.larsson at oracle.com Mon Mar 30 22:54:51 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 30 Mar 2015 15:54:51 -0700 (PDT) Subject: RFR: 8065331: Add JVM trace events for failed allocations Message-ID: <79f28401-1d7d-4217-ada6-81f124344803@default> Ping! ----- Original Message ----- From: marcus.larsson at oracle.com To: hotspot-gc-dev at openjdk.java.net Sent: Tuesday, 24 March, 2015 7:35:08 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: RFR: 8065331: Add JVM trace events for failed allocations Hi, Please review the following patch adding new trace events for allocations requiring GC, and GCs triggered by allocation. See the JEP for a description of these two new events. CR: https://bugs.openjdk.java.net/browse/JDK-8065331 Webrev: http://cr.openjdk.java.net/~mlarsson/8065331/webrev.00/ JEP: https://bugs.openjdk.java.net/browse/JDK-8060092 Tests: jprt, jtreg Thanks, Marcus From bengt.rutisson at oracle.com Tue Mar 31 05:28:19 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 31 Mar 2015 07:28:19 +0200 Subject: Request for review (s) : 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads In-Reply-To: <5519D0E1.8030601@oracle.com> References: <54FF1B4A.9020609@oracle.com> <5514DD8B.2070700@oracle.com> <55152756.8090307@oracle.com> <55156B31.3080906@oracle.com> <55192D67.7020205@oracle.com> <5519D0E1.8030601@oracle.com> Message-ID: <551A3073.9020304@oracle.com> On 31/03/15 00:40, Jon Masamitsu wrote: > I'm moving Bengt's question about using @requires into > its own thread because it deserves it. Good idea, Jon! And for now I think your changes are good to push. If the @requires discussion comes to any conclusion we can always update the test later on. Thanks, Bengt > > On 03/30/2015 04:03 AM, Bengt Rutisson wrote: >> >> >> >>> >>>> >>>> I guess this is a more general question. Should we use @requires to >>>> avoid running the same test many times or should we only use it >>>> when the test actually requires a specific GC configuration? >>> >>> I'll happily take guidance on this point. Only using it when tests >>> actually requires a specific >>> GC sounds OK. >> >> I'm also not sure, so my question was really a question. Is this how >> we want to make sure that a generic test is only run once? There are >> other ways...test groups, nightly batch configuration etc... > > I like that @requires is local to the test so easy to change. Also > that it > works for JPRT when JPRT runs the jtreg tests. > > Jon > From bengt.rutisson at oracle.com Tue Mar 31 05:57:07 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 31 Mar 2015 07:57:07 +0200 Subject: RFR (S): JDK-8076225: Move the thread claim parity from SharedHeap to Thread In-Reply-To: <5519B67E.4080007@oracle.com> References: <5519333D.5040606@oracle.com> <55195261.3010903@oracle.com> <5519538B.80600@oracle.com> <145AA3D7-7DC5-4EC3-99F0-D6B4264CF9E0@oracle.com> <5519A24B.5060002@oracle.com> <5519B67E.4080007@oracle.com> Message-ID: <551A3733.3040804@oracle.com> On 2015-03-30 22:47, Bengt Rutisson wrote: > On 30/03/15 22:33, Kim Barrett wrote: >> On Mar 30, 2015, at 3:21 PM, Bengt Rutisson >> wrote: >>> >>> Hi Kim, >>> >>> Thanks for looking at this! >>> >>> On 30/03/15 18:00, Kim Barrett wrote: >>>> On Mar 30, 2015, at 9:45 AM, Bengt Rutisson >>>> wrote: >>>>> On 2015-03-30 15:40, Jesper Wilhelmsson wrote: >>>>>> Looks good. >>>>> Thanks, Jesper! >>>>> >>>>>> I assume you count yourself as a Reviewer(?) >>>>> Yes, so unless anyone else looks at this and complains I'll push >>>>> it tomorrow :) >>>> There?s a big comment in src/share/vm/memory/sharedHeap.hpp, >>>> preceding the location >>>> of the now removed strong_roots_parity(), which talks about the >>>> parity handling. It seems >>>> kind of misplaced now (though it is related to the >>>> StrongRootsScope). It also refers to the >>>> strong_roots_parity() function, which is being removed. >>> I absolutely agree. The comment needs to be placed (and probably >>> re-written a bit) closer to where this code now exist. >>> >>> The proposed patch is a step towards removing SharedHeap all >>> together. The next step I am planning on is to move the >>> StrongRootsScope handling out of SharedHeap. Would you be ok with me >>> leaving the comment as it is now and postpone updating the comment >>> to the StrongRootsScope patch? I'm convinced that I will need to >>> work on the comments for that patch but I don't yet know exactly how >>> it will end up. >> That?s mostly ok with me. But I?d like some kind of TBD comment >> added to the current change, in case of delays or distractions on >> that further cleanup. I don?t need another webrev to see such a >> comment though. > > Great! Thanks! I'll add a TBD comment before I push. I filed this bug to track the StrongRootsScope work: Move the StrongRootsScope out of SharedHeap https://bugs.openjdk.java.net/browse/JDK-8076289 And I added this note to sharedHeap.hpp before I pushed: // Note, the below comment needs to be updated to reflect the changes // introduced by JDK-8076225. This should be done as part of JDK-8076289. Thanks, Bengt > > Bengt > >> >> > From per.liden at oracle.com Tue Mar 31 06:25:23 2015 From: per.liden at oracle.com (Per Liden) Date: Tue, 31 Mar 2015 08:25:23 +0200 Subject: RFR(s): 8076231: Remove unused is_in_partial_collection() In-Reply-To: <5519A698.2080603@oracle.com> References: <551956E0.4080503@oracle.com> <5519A698.2080603@oracle.com> Message-ID: <551A3DD3.5010308@oracle.com> Thanks Derek! /Per On 2015-03-30 21:40, Derek White wrote: > On 3/30/15 10:00 AM, Per Liden wrote: >> Hi, >> >> Please review this small cleanup. >> >> All collectors provide an implementation for >> is_in_partial_collection(), but it's actually only ever used by >> GenCollectedHeap. This patch removes the unused versions and removes >> the function from the CollectedHeap interface. >> >> Webrev: http://cr.openjdk.java.net/~pliden/8076231/webrev.0/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076231 >> >> Testing: jprt >> >> /Per > > Looks good to me Per. > - Derek From bengt.rutisson at oracle.com Tue Mar 31 06:59:46 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 31 Mar 2015 08:59:46 +0200 Subject: RFR (S): JDK-8076241: Remove unused methods mod_card_iterate() and non_clean_card_iterate_serial() In-Reply-To: <15B61388-9257-466F-8355-867F30F49004@oracle.com> References: <55195B51.3030403@oracle.com> <15B61388-9257-466F-8355-867F30F49004@oracle.com> Message-ID: <551A45E2.4000502@oracle.com> Hi Kim, Thanks, for looking at this! On 2015-03-31 00:16, Kim Barrett wrote: > On Mar 30, 2015, at 10:18 AM, Bengt Rutisson wrote: >> >> Hi all, >> >> Could I have a couple of reviews for this small change? >> >> http://cr.openjdk.java.net/~brutisso/8076241/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8076241 >> >> The methods mod_card_iterate() and non_clean_card_iterate_serial() in CardTableModRefBS are not being used. >> >> Thanks, >> Bengt > Aww. I was going to do that. Actually, I was supposed to file a RFE > for this as a followup to 8062206 (Remove unusable > G1RSLogCheckCardTable command line argument), but that seems to have > not gotten out of my notes file. I see. No problem. I just ran in to this since non_clean_card_iterate_serial() makes use of SharedHeap. Rather than trying to updated it when I remove SharedHeap I'd like to remove the dead code. > > ------------------------------------------------------------------------------ > src/share/vm/memory/cardTableModRefBS.hpp > 181 // XXX ??? MemRegionClosure above vs OopsInGenClosure below XXX > 182 // XXX some new_dcto_cl's take OopClosure's, plus as above there are > 183 // some MemRegionClosures. Clean this up everywhere. XXX > > This untouched comment is referring to the removed > non_clean_card_iterate_serial function ("above"), so needs to be > updated. It may be that the comment can be removed entirely now, > possibly being moved to the technical debt wiki. Ah. Good point. I removed the comment and added this to the technical debt wiki: "CardTableModRefBS::dirty_card_iterate() works with a MemRegion and a MemRegionClosure. Other similar methods, such as CardTableModRefBS::non_clean_card_iterate_possibly_parallel() and CardTableModRefBS::process_stride() use OopsInGenClosure instead. Can we use a consistent API?" > > ------------------------------------------------------------------------------ > src/share/vm/memory/cardTableModRefBS.hpp > 382 // Invoke "cl.do_MemRegion" on a set of MemRegions that collectively > 383 // includes all the modified cards (expressing each card as a > 384 // MemRegion). Thus, several modified cards may be lumped into one > 385 // region. The regions are non-overlapping, and are visited in > 386 // *decreasing* address order. (This order aids with imprecise card > 387 // marking, where a dirty card may cause scanning, and summarization > 388 // marking, of objects that extend onto subsequent cards.) > > This comment was the reason I'd deferred removing mod_card_iterate. So > far as I can tell, this comment is the *only* place where there is any > discussion whatsoever of why some card iterators scan backward. I > wanted to find a new and better home for that information before > deleting the comment. I see. I couldn't find a card iterator that scans backwards now. Do you have a pointer to one that still scans backwards? I'll push the change with the comment removed. I'm happy to find a new place for the comment if we have an iterators that scan backwards. > > ------------------------------------------------------------------------------ > > The code changes look good. Good. Thanks! Bengt > From thomas.schatzl at oracle.com Tue Mar 31 07:32:34 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 31 Mar 2015 09:32:34 +0200 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <55185405.8040803@oracle.com> References: <1425482904.3305.27.camel@oracle.com> <1425567491.3140.42.camel@oracle.com> <54F96CB2.9060107@oracle.com> <1425898922.3398.35.camel@oracle.com> <1426675055.3170.24.camel@oracle.com> <84EC1DB5-4277-4190-8EA1-E0A6F90BE95C@oracle.com> <1427122924.3194.79.camel@oracle.com> <55185405.8040803@oracle.com> Message-ID: <1427787154.3432.9.camel@oracle.com> Hi Jon, On Sun, 2015-03-29 at 12:35 -0700, Jon Masamitsu wrote: > Thomas, > > It's not clear to me that the name change > G1ParGCAllocBuffer to G1PLAB is a change for the better. > From the base class name ParGCAllocBuffer, I could guess > the G1 version is G1ParGCAllocBuffer but I would not guess > G1PLAB. Can you motivate that name (G1PLAB) for me? "PLAB" is a commonly used and more concise abbreviation for this kind of data structure. We ourselves use "Promotion Local Allocation Buffer" (sometimes also "Parallel Local...") e.g. in the description of the *PLAB* switches. Also in literature (see some GC papers) that name is used for this kind of data structure (note that they apparently use our naming). ParGCAllocBuffer misses the information about it being about "promotion"/"parallel" and "local" too, and is longer to type. I think it is prudent to follow existing naming for stuff like that instead of re-inventing it within the same code. Thanks, Thomas From david.lindholm at oracle.com Tue Mar 31 08:20:02 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Tue, 31 Mar 2015 10:20:02 +0200 Subject: RFR(xs): JDK-8076173: VirtualSpaceNode container_count() and container_count_slow() have different return types Message-ID: <551A58B2.1050806@oracle.com> Hi, Please review this small patch that makes container_count_slow() use the same return type as container_count(). Webrev: http://cr.openjdk.java.net/~david/JDK-8076173/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8076173 Testing: JPRT. Thanks, David From per.liden at oracle.com Tue Mar 31 08:21:46 2015 From: per.liden at oracle.com (Per Liden) Date: Tue, 31 Mar 2015 10:21:46 +0200 Subject: RFR(s): 8076294: Cleanup of CollectedHeap::kind() Message-ID: <551A591A.6020900@oracle.com> Hi, Another small cleanup. CollectedHeap::kind() currently returns CollectedHeap::Abstract, which makes little sense. Changing it to be a pure virtual member function instead. The Abstract and SharedHeap members of CollectedHeap::Name can then be removed as they are never used. Webrev: http://cr.openjdk.java.net/~pliden/8076294/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8076294 Testing: jprt cheers, /Per From per.liden at oracle.com Tue Mar 31 08:31:08 2015 From: per.liden at oracle.com (Per Liden) Date: Tue, 31 Mar 2015 10:31:08 +0200 Subject: RFR(xs): JDK-8076173: VirtualSpaceNode container_count() and container_count_slow() have different return types In-Reply-To: <551A58B2.1050806@oracle.com> References: <551A58B2.1050806@oracle.com> Message-ID: <551A5B4C.6060406@oracle.com> On 2015-03-31 10:20, David Lindholm wrote: > Hi, > > Please review this small patch that makes container_count_slow() use the > same return type as container_count(). > > > Webrev: http://cr.openjdk.java.net/~david/JDK-8076173/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8076173 Change looks good. But while you're at it, could you please also change so that we're using UINTX_FORMAT instead of SIZE_FORMAT when we're printing those? /Per From per.liden at oracle.com Tue Mar 31 08:45:15 2015 From: per.liden at oracle.com (Per Liden) Date: Tue, 31 Mar 2015 10:45:15 +0200 Subject: RFR (S): JDK-8076241: Remove unused methods mod_card_iterate() and non_clean_card_iterate_serial() In-Reply-To: <55195B51.3030403@oracle.com> References: <55195B51.3030403@oracle.com> Message-ID: <551A5E9B.6010702@oracle.com> On 2015-03-30 16:18, Bengt Rutisson wrote: > > Hi all, > > Could I have a couple of reviews for this small change? > > http://cr.openjdk.java.net/~brutisso/8076241/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8076241 > > The methods mod_card_iterate() and non_clean_card_iterate_serial() in > CardTableModRefBS are not being used. Change looks good, Bengt! /Per From david.lindholm at oracle.com Tue Mar 31 08:50:59 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Tue, 31 Mar 2015 10:50:59 +0200 Subject: RFR(xs): JDK-8076173: VirtualSpaceNode container_count() and container_count_slow() have different return types In-Reply-To: <551A5B4C.6060406@oracle.com> References: <551A58B2.1050806@oracle.com> <551A5B4C.6060406@oracle.com> Message-ID: <551A5FF3.80804@oracle.com> Hi, Ok. New webrev at http://cr.openjdk.java.net/~david/JDK-8076173/webrev.01/ /David On 2015-03-31 10:31, Per Liden wrote: > On 2015-03-31 10:20, David Lindholm wrote: >> Hi, >> >> Please review this small patch that makes container_count_slow() use the >> same return type as container_count(). >> >> >> Webrev: http://cr.openjdk.java.net/~david/JDK-8076173/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076173 > > Change looks good. But while you're at it, could you please also > change so that we're using UINTX_FORMAT instead of SIZE_FORMAT when > we're printing those? > > /Per From per.liden at oracle.com Tue Mar 31 08:55:00 2015 From: per.liden at oracle.com (Per Liden) Date: Tue, 31 Mar 2015 10:55:00 +0200 Subject: RFR(xs): JDK-8076173: VirtualSpaceNode container_count() and container_count_slow() have different return types In-Reply-To: <551A5FF3.80804@oracle.com> References: <551A58B2.1050806@oracle.com> <551A5B4C.6060406@oracle.com> <551A5FF3.80804@oracle.com> Message-ID: <551A60E4.9050300@oracle.com> Thanks for fixing that, change looks good! /Per On 2015-03-31 10:50, David Lindholm wrote: > Hi, > > Ok. New webrev at http://cr.openjdk.java.net/~david/JDK-8076173/webrev.01/ > > > /David > > On 2015-03-31 10:31, Per Liden wrote: >> On 2015-03-31 10:20, David Lindholm wrote: >>> Hi, >>> >>> Please review this small patch that makes container_count_slow() use the >>> same return type as container_count(). >>> >>> >>> Webrev: http://cr.openjdk.java.net/~david/JDK-8076173/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076173 >> >> Change looks good. But while you're at it, could you please also >> change so that we're using UINTX_FORMAT instead of SIZE_FORMAT when >> we're printing those? >> >> /Per > From stefan.karlsson at oracle.com Tue Mar 31 09:17:02 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 31 Mar 2015 11:17:02 +0200 Subject: RFR(xs): JDK-8076173: VirtualSpaceNode container_count() and container_count_slow() have different return types In-Reply-To: <551A5FF3.80804@oracle.com> References: <551A58B2.1050806@oracle.com> <551A5B4C.6060406@oracle.com> <551A5FF3.80804@oracle.com> Message-ID: <551A660E.6080702@oracle.com> On 2015-03-31 10:50, David Lindholm wrote: > Hi, > > Ok. New webrev at > http://cr.openjdk.java.net/~david/JDK-8076173/webrev.01/ Looks good. StefanK > > > /David > > On 2015-03-31 10:31, Per Liden wrote: >> On 2015-03-31 10:20, David Lindholm wrote: >>> Hi, >>> >>> Please review this small patch that makes container_count_slow() use >>> the >>> same return type as container_count(). >>> >>> >>> Webrev: http://cr.openjdk.java.net/~david/JDK-8076173/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076173 >> >> Change looks good. But while you're at it, could you please also >> change so that we're using UINTX_FORMAT instead of SIZE_FORMAT when >> we're printing those? >> >> /Per > From stefan.karlsson at oracle.com Tue Mar 31 09:22:11 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 31 Mar 2015 11:22:11 +0200 Subject: RFR (XS): JDK-8076237: Remove unused _collector_policy field in SharedHeap In-Reply-To: <55195550.1050408@oracle.com> References: <55195550.1050408@oracle.com> Message-ID: <551A6743.50900@oracle.com> On 2015-03-30 15:53, Bengt Rutisson wrote: > > Hi all, > > Can I have a couple of reviews for this small patch? > > http://cr.openjdk.java.net/~brutisso/8076237/webrev.00/ Looks good. StefanK > https://bugs.openjdk.java.net/browse/JDK-8076237 > > The _collector_policy field in SharedHeap is no longer used. > > Thanks, > Bengt From bengt.rutisson at oracle.com Tue Mar 31 09:18:25 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 31 Mar 2015 11:18:25 +0200 Subject: RFR (S): JDK-8076241: Remove unused methods mod_card_iterate() and non_clean_card_iterate_serial() In-Reply-To: <551A5E9B.6010702@oracle.com> References: <55195B51.3030403@oracle.com> <551A5E9B.6010702@oracle.com> Message-ID: <551A6661.8010102@oracle.com> On 2015-03-31 10:45, Per Liden wrote: > On 2015-03-30 16:18, Bengt Rutisson wrote: >> >> Hi all, >> >> Could I have a couple of reviews for this small change? >> >> http://cr.openjdk.java.net/~brutisso/8076241/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8076241 >> >> The methods mod_card_iterate() and non_clean_card_iterate_serial() in >> CardTableModRefBS are not being used. > > Change looks good, Bengt! Thanks Per! I did an offline review with StefanK and we made some minor update to the comments. Here's the final webrev: http://cr.openjdk.java.net/~brutisso/8076241/webrev.01/ Thanks, Bengt > > /Per From david.lindholm at oracle.com Tue Mar 31 09:26:55 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Tue, 31 Mar 2015 11:26:55 +0200 Subject: RFR(xs): JDK-8076173: VirtualSpaceNode container_count() and container_count_slow() have different return types In-Reply-To: <551A660E.6080702@oracle.com> References: <551A58B2.1050806@oracle.com> <551A5B4C.6060406@oracle.com> <551A5FF3.80804@oracle.com> <551A660E.6080702@oracle.com> Message-ID: <551A685F.3010306@oracle.com> Thanks, I did a little further cleanup by letting inc_container_count() call verify_container_count() instead of having its own copy of the same assert. http://cr.openjdk.java.net/~david/JDK-8076173/webrev.02/ /David On 2015-03-31 11:17, Stefan Karlsson wrote: > On 2015-03-31 10:50, David Lindholm wrote: >> Hi, >> >> Ok. New webrev at >> http://cr.openjdk.java.net/~david/JDK-8076173/webrev.01/ > > Looks good. > > StefanK > >> >> >> /David >> >> On 2015-03-31 10:31, Per Liden wrote: >>> On 2015-03-31 10:20, David Lindholm wrote: >>>> Hi, >>>> >>>> Please review this small patch that makes container_count_slow() >>>> use the >>>> same return type as container_count(). >>>> >>>> >>>> Webrev: http://cr.openjdk.java.net/~david/JDK-8076173/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076173 >>> >>> Change looks good. But while you're at it, could you please also >>> change so that we're using UINTX_FORMAT instead of SIZE_FORMAT when >>> we're printing those? >>> >>> /Per >> > From stefan.karlsson at oracle.com Tue Mar 31 09:28:17 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 31 Mar 2015 11:28:17 +0200 Subject: RFR(xs): JDK-8076173: VirtualSpaceNode container_count() and container_count_slow() have different return types In-Reply-To: <551A685F.3010306@oracle.com> References: <551A58B2.1050806@oracle.com> <551A5B4C.6060406@oracle.com> <551A5FF3.80804@oracle.com> <551A660E.6080702@oracle.com> <551A685F.3010306@oracle.com> Message-ID: <551A68B1.7030301@oracle.com> On 2015-03-31 11:26, David Lindholm wrote: > Thanks, > > I did a little further cleanup by letting inc_container_count() call > verify_container_count() instead of having its own copy of the same > assert. > > http://cr.openjdk.java.net/~david/JDK-8076173/webrev.02/ Looks good. StefanK > > > /David > > On 2015-03-31 11:17, Stefan Karlsson wrote: >> On 2015-03-31 10:50, David Lindholm wrote: >>> Hi, >>> >>> Ok. New webrev at >>> http://cr.openjdk.java.net/~david/JDK-8076173/webrev.01/ >> >> Looks good. >> >> StefanK >> >>> >>> >>> /David >>> >>> On 2015-03-31 10:31, Per Liden wrote: >>>> On 2015-03-31 10:20, David Lindholm wrote: >>>>> Hi, >>>>> >>>>> Please review this small patch that makes container_count_slow() >>>>> use the >>>>> same return type as container_count(). >>>>> >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~david/JDK-8076173/webrev.00/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076173 >>>> >>>> Change looks good. But while you're at it, could you please also >>>> change so that we're using UINTX_FORMAT instead of SIZE_FORMAT when >>>> we're printing those? >>>> >>>> /Per >>> >> > From stefan.karlsson at oracle.com Tue Mar 31 09:31:37 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 31 Mar 2015 11:31:37 +0200 Subject: RFR (S): JDK-8076241: Remove unused methods mod_card_iterate() and non_clean_card_iterate_serial() In-Reply-To: <551A6661.8010102@oracle.com> References: <55195B51.3030403@oracle.com> <551A5E9B.6010702@oracle.com> <551A6661.8010102@oracle.com> Message-ID: <551A6979.6050204@oracle.com> On 2015-03-31 11:18, Bengt Rutisson wrote: > > On 2015-03-31 10:45, Per Liden wrote: >> On 2015-03-30 16:18, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> Could I have a couple of reviews for this small change? >>> >>> http://cr.openjdk.java.net/~brutisso/8076241/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8076241 >>> >>> The methods mod_card_iterate() and non_clean_card_iterate_serial() in >>> CardTableModRefBS are not being used. >> >> Change looks good, Bengt! > > Thanks Per! > > I did an offline review with StefanK and we made some minor update to > the comments. > > Here's the final webrev: > http://cr.openjdk.java.net/~brutisso/8076241/webrev.01/ Looks good. StefanK > > Thanks, > Bengt > >> >> /Per > From bengt.rutisson at oracle.com Tue Mar 31 09:35:34 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 31 Mar 2015 11:35:34 +0200 Subject: RFR (S): JDK-8076241: Remove unused methods mod_card_iterate() and non_clean_card_iterate_serial() In-Reply-To: <551A6979.6050204@oracle.com> References: <55195B51.3030403@oracle.com> <551A5E9B.6010702@oracle.com> <551A6661.8010102@oracle.com> <551A6979.6050204@oracle.com> Message-ID: <551A6A66.7030505@oracle.com> On 2015-03-31 11:31, Stefan Karlsson wrote: > > > On 2015-03-31 11:18, Bengt Rutisson wrote: >> >> On 2015-03-31 10:45, Per Liden wrote: >>> On 2015-03-30 16:18, Bengt Rutisson wrote: >>>> >>>> Hi all, >>>> >>>> Could I have a couple of reviews for this small change? >>>> >>>> http://cr.openjdk.java.net/~brutisso/8076241/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8076241 >>>> >>>> The methods mod_card_iterate() and non_clean_card_iterate_serial() in >>>> CardTableModRefBS are not being used. >>> >>> Change looks good, Bengt! >> >> Thanks Per! >> >> I did an offline review with StefanK and we made some minor update to >> the comments. >> >> Here's the final webrev: >> http://cr.openjdk.java.net/~brutisso/8076241/webrev.01/ > > Looks good. Thanks, StefanK! Bengt > > StefanK > >> >> Thanks, >> Bengt >> >>> >>> /Per >> > From bengt.rutisson at oracle.com Tue Mar 31 09:36:04 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 31 Mar 2015 11:36:04 +0200 Subject: RFR (XS): JDK-8076237: Remove unused _collector_policy field in SharedHeap In-Reply-To: <551A6743.50900@oracle.com> References: <55195550.1050408@oracle.com> <551A6743.50900@oracle.com> Message-ID: <551A6A84.4020107@oracle.com> On 2015-03-31 11:22, Stefan Karlsson wrote: > On 2015-03-30 15:53, Bengt Rutisson wrote: >> >> Hi all, >> >> Can I have a couple of reviews for this small patch? >> >> http://cr.openjdk.java.net/~brutisso/8076237/webrev.00/ > > Looks good. Thanks, StefanK! Bengt > > StefanK > >> https://bugs.openjdk.java.net/browse/JDK-8076237 >> >> The _collector_policy field in SharedHeap is no longer used. >> >> Thanks, >> Bengt > From thomas.schatzl at oracle.com Tue Mar 31 10:04:58 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 31 Mar 2015 12:04:58 +0200 Subject: [8u60] RFR of backport for 8068036: assert(is_available(index)) failed in G1 cset Message-ID: <1427796298.3432.43.camel@oracle.com> Hi all, can I have reviews for the backport of "8068036: assert(is_available(index)) failed in G1 cset" for 8u60? It did only apply with minor changes, so I need re-reviews. The problem is that there are some merge failures with HeapRegion::isHumongous and friends. I missed that when backporting 8060025, and so the error occurred in 8u60 testing :( Full 8u60 changeset: http://cr.openjdk.java.net/~tschatzl/8068036-8u60/webrev.8u60/ CR: https://bugs.openjdk.java.net/browse/JDK-8068036 Original change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3f138457d7e6 Testing: jprt Thanks, Thomas From bengt.rutisson at oracle.com Tue Mar 31 10:09:31 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 31 Mar 2015 12:09:31 +0200 Subject: RFR (S): JDK-8069004: Kitchensink hanged with 16Gb heap and GC pause >30 min In-Reply-To: <55197FD1.8090006@oracle.com> References: <55197FD1.8090006@oracle.com> Message-ID: <551A725B.1050602@oracle.com> Hi Derek, On 2015-03-30 18:54, Derek White wrote: > This is a P1 bug in JDK 9 - a conflict when freeing > continues_humongous regions. > > The scenario is a region was continues_humongous is then freed by one > worker when the whole H-object is freed. The continues_humongous > region needs to be claimed by the first worker, otherwise other > workers may run into the free region. It turns out the fix was to > revert a change made a few months ago. Nice catch! > > It didn't help out that an assert actually did the right thing, so it > never failed in debug code :-) Yes, that must have been very confusing! > > BUG: JDK-8069004 Kitchensink hanged with 16Gb heap and GC pause >30 > min > Webrev: http://cr.openjdk.java.net/~drwhite/8069004/webrev.00/ > Change looks good. Thanks, Bengt > Ran jprt. > > Thanks! > > - Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Tue Mar 31 10:28:00 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 31 Mar 2015 12:28:00 +0200 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <1427787154.3432.9.camel@oracle.com> References: <1425482904.3305.27.camel@oracle.com> <1425567491.3140.42.camel@oracle.com> <54F96CB2.9060107@oracle.com> <1425898922.3398.35.camel@oracle.com> <1426675055.3170.24.camel@oracle.com> <84EC1DB5-4277-4190-8EA1-E0A6F90BE95C@oracle.com> <1427122924.3194.79.camel@oracle.com> <55185405.8040803@oracle.com> <1427787154.3432.9.camel@oracle.com> Message-ID: <1427797680.3432.51.camel@oracle.com> Hi again, On Tue, 2015-03-31 at 09:32 +0200, Thomas Schatzl wrote: > Hi Jon, > > On Sun, 2015-03-29 at 12:35 -0700, Jon Masamitsu wrote: > > Thomas, > > > > It's not clear to me that the name change > > G1ParGCAllocBuffer to G1PLAB is a change for the better. > > From the base class name ParGCAllocBuffer, I could guess > > the G1 version is G1ParGCAllocBuffer but I would not guess > > G1PLAB. Can you motivate that name (G1PLAB) for me? > > "PLAB" is a commonly used and more concise abbreviation for this kind of > data structure. We ourselves use "Promotion Local Allocation > Buffer" (sometimes also "Parallel Local...") e.g. in the description of > the *PLAB* switches. Also in literature (see some GC papers) that name > is used for this kind of data structure (note that they apparently use > our naming). > > ParGCAllocBuffer misses the information about it being about > "promotion"/"parallel" and "local" too, and is longer to type. > > I think it is prudent to follow existing naming for stuff like that > instead of re-inventing it within the same code. talked to StefanK a bit about this, and we think that it would be good to do this renaming in JDK-8074546 before this change goes in. This would avoid having the subclass renamed temporarily, but not the parent. I will provide a new webrev then. Thanks for looking at this. Thanks, Thomas From thomas.schatzl at oracle.com Tue Mar 31 11:37:14 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 31 Mar 2015 13:37:14 +0200 Subject: [8u60] RFR of backport for 8049864: TestParallelHeapSizeFlags fails with unexpected heap size In-Reply-To: References: <1427363460.3149.13.camel@oracle.com> Message-ID: <1427801834.3432.83.camel@oracle.com> Hi Kim, On Mon, 2015-03-30 at 17:19 -0400, Kim Barrett wrote: > On Mar 26, 2015, at 5:51 AM, Thomas Schatzl wrote: > > > > Hi all, > > > > can I have reviews for the backport of "8049864: > > TestParallelHeapSizeFlags fails with unexpected heap size" for 8u60? [...] > > Note that this change is based on "8067469: G1 ignores AlwaysPreTouch" > > which is also out for review. It fixes "8049536: > > os::commit_memory on Solaris uses alignment_hint as page size". > > > > Full 8u60 changeset: > > http://cr.openjdk.java.net/~tschatzl/8049864-8u60/webrev.8u60/ > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8049864 > > Original change: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b326a3e8dcab > > Looks good. > Thanks for the review. Thomas From bengt.rutisson at oracle.com Tue Mar 31 11:50:31 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 31 Mar 2015 13:50:31 +0200 Subject: [8u60] RFR of backport for 8068036: assert(is_available(index)) failed in G1 cset In-Reply-To: <1427796298.3432.43.camel@oracle.com> References: <1427796298.3432.43.camel@oracle.com> Message-ID: <551A8A07.2090307@oracle.com> Hi Thomas, On 2015-03-31 12:04, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the backport of "8068036: > assert(is_available(index)) failed in G1 cset" for 8u60? > > It did only apply with minor changes, so I need re-reviews. The problem > is that there are some merge failures with HeapRegion::isHumongous and > friends. > > I missed that when backporting 8060025, and so the error occurred in > 8u60 testing :( > > Full 8u60 changeset: > http://cr.openjdk.java.net/~tschatzl/8068036-8u60/webrev.8u60/ > > CR: > https://bugs.openjdk.java.net/browse/JDK-8068036 > Original change: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3f138457d7e6 Looks good. Thanks, Bengt > > Testing: jprt > > Thanks, > Thomas > > > > > > From thomas.schatzl at oracle.com Tue Mar 31 12:00:56 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 31 Mar 2015 14:00:56 +0200 Subject: [8u60] RFR of backport for 8068036: assert(is_available(index)) failed in G1 cset In-Reply-To: <551A8A07.2090307@oracle.com> References: <1427796298.3432.43.camel@oracle.com> <551A8A07.2090307@oracle.com> Message-ID: <1427803256.3432.89.camel@oracle.com> Hi, On Tue, 2015-03-31 at 13:50 +0200, Bengt Rutisson wrote: > Hi Thomas, > > On 2015-03-31 12:04, Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for the backport of "8068036: > > assert(is_available(index)) failed in G1 cset" for 8u60? > > > > It did only apply with minor changes, so I need re-reviews. The problem > > is that there are some merge failures with HeapRegion::isHumongous and > > friends. > > > > I missed that when backporting 8060025, and so the error occurred in > > 8u60 testing :( > > > > Full 8u60 changeset: > > http://cr.openjdk.java.net/~tschatzl/8068036-8u60/webrev.8u60/ > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8068036 > > Original change: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3f138457d7e6 > > Looks good. thanks for the review. Thomas From jesper.wilhelmsson at oracle.com Tue Mar 31 13:14:09 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 31 Mar 2015 15:14:09 +0200 Subject: RFR: JDK-8076267 - Remove n_gens() Message-ID: <551A9DA1.8080804@oracle.com> Hi, Please review this next cleanup in the backwaters of the generation array removal. This change removes the n_gens() method and the max_gens variable from GenCollectedHeap. Next in line in the cleanup queue is a change to remove the levels concept. Mostly all places where we today pass a "level" in the GC code can be removed, or be made more explicit by introducing two constants, YOUNG and OLD. Removing n_gens() and the levels touches upon the same code in many places and we could skip one, in some places somewhat ugly, intermediate version by doing both changes at the same time. The levels removal is a much larger and trickier change though, so to make it easier to review I choose to split these into two changes. Please keep this in mind when reviewing the current change. Bug: https://bugs.openjdk.java.net/browse/JDK-8076267 Webrev: http://cr.openjdk.java.net/~jwilhelm/8076267/webrev.00/ Thanks, /Jesper From bengt.rutisson at oracle.com Tue Mar 31 13:14:39 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 31 Mar 2015 15:14:39 +0200 Subject: RFR (M): JDK-8076314: Remove the static instance variable SharedHeap:: _sh Message-ID: <551A9DBF.5070006@oracle.com> Hi all, Could I have a couple of reviews for this change? http://cr.openjdk.java.net/~brutisso/8076314/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8076314 This is another step towards getting rid of SharedHeap. There used to be an instance variable in SharedHeap to keep track of the actual instance being used (which would be of type GenCollectedHeap or G1CollectedHeap). The SharedHeap::heap() would return this value and was mostly used in asserts. I've changed so that we use the specific instance in most cases. That is either GenCollectedHeap::heap() or G1CollectedHeap::heap(). A couple of other changes were needed to avoid the use of SharedHeap::heap(): - The field _thread_holds_heap_lock_for_gc was only used by G1 and was thus moved to G1CollectedHeap. It brought with it the method heap_lock_held_for_gc() and I introduced set_heap_lock_held_for_gc() to set the value. All of these are only used in asserts so I put them in an #ifndef PRODUCT section. This also meant that I had to implement doit_prologue() and doit_epilogue() for VM_G1OperationWithAllocRequest to make sure that the state of _thread_holds_heap_lock_for_gc got set correctly. - The ageTable::compute_tenuring_threshold() method used the SharedHeap::heap() only to look up the perf counters for GC. Instead of having compute_tenuring_threshold() look that up I now pass in the correct counters from the callers. - The Threads::possibly_parallel_oops_do() method used the SharedHeap::heap() only to check if we were to execute in parallel. I moved the lookup of this to the callers and now just pass in an is_par paramter. - I simplified the VM_CGC_Operation::doit() a bit since even before my change the heap returned could never be NULL. Thanks, Bengt From joseph.provino at oracle.com Tue Mar 31 13:38:39 2015 From: joseph.provino at oracle.com (Joseph Provino) Date: Tue, 31 Mar 2015 09:38:39 -0400 Subject: RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp In-Reply-To: <1427797680.3432.51.camel@oracle.com> References: <1425482904.3305.27.camel@oracle.com> <1425567491.3140.42.camel@oracle.com> <54F96CB2.9060107@oracle.com> <1425898922.3398.35.camel@oracle.com> <1426675055.3170.24.camel@oracle.com> <84EC1DB5-4277-4190-8EA1-E0A6F90BE95C@oracle.com> <1427122924.3194.79.camel@oracle.com> <55185405.8040803@oracle.com> <1427787154.3432.9.camel@oracle.com> <1427797680.3432.51.camel@oracle.com> Message-ID: <551AA35F.3090603@oracle.com> I assigned https://bugs.openjdk.java.net/browse/JDK-8074546 to myself yesterday and made the changes in my local repo. If someone else is working on this, I'll reassign it to them. BTW, should parGCAllocBuffer.cpp, parGCAllocBuffer.hpp,, parGCAllocBuffer.inline.hpp be renamed to plab.cpp, plab.hpp, plab.inline.hpp Or should "plab" be capitalized differently? joe On 3/31/2015 6:28 AM, Thomas Schatzl wrote: > Hi again, > > On Tue, 2015-03-31 at 09:32 +0200, Thomas Schatzl wrote: >> Hi Jon, >> >> On Sun, 2015-03-29 at 12:35 -0700, Jon Masamitsu wrote: >>> Thomas, >>> >>> It's not clear to me that the name change >>> G1ParGCAllocBuffer to G1PLAB is a change for the better. >>> From the base class name ParGCAllocBuffer, I could guess >>> the G1 version is G1ParGCAllocBuffer but I would not guess >>> G1PLAB. Can you motivate that name (G1PLAB) for me? >> "PLAB" is a commonly used and more concise abbreviation for this kind of >> data structure. We ourselves use "Promotion Local Allocation >> Buffer" (sometimes also "Parallel Local...") e.g. in the description of >> the *PLAB* switches. Also in literature (see some GC papers) that name >> is used for this kind of data structure (note that they apparently use >> our naming). >> >> ParGCAllocBuffer misses the information about it being about >> "promotion"/"parallel" and "local" too, and is longer to type. >> >> I think it is prudent to follow existing naming for stuff like that >> instead of re-inventing it within the same code. > talked to StefanK a bit about this, and we think that it would be good > to do this renaming in JDK-8074546 before this change goes in. > > This would avoid having the subclass renamed temporarily, but not the > parent. > > I will provide a new webrev then. > > Thanks for looking at this. > > Thanks, > Thomas > > From joseph.provino at oracle.com Tue Mar 31 14:03:54 2015 From: joseph.provino at oracle.com (Joseph Provino) Date: Tue, 31 Mar 2015 10:03:54 -0400 Subject: RFR: JDK-8076267 - Remove n_gens() In-Reply-To: <551A9DA1.8080804@oracle.com> References: <551A9DA1.8080804@oracle.com> Message-ID: <551AA94A.1010809@oracle.com> Looks good to me. joe On 3/31/2015 9:14 AM, Jesper Wilhelmsson wrote: > Hi, > > Please review this next cleanup in the backwaters of the generation > array removal. This change removes the n_gens() method and the > max_gens variable from GenCollectedHeap. > > Next in line in the cleanup queue is a change to remove the levels > concept. Mostly all places where we today pass a "level" in the GC > code can be removed, or be made more explicit by introducing two > constants, YOUNG and OLD. Removing n_gens() and the levels touches > upon the same code in many places and we could skip one, in some > places somewhat ugly, intermediate version by doing both changes at > the same time. The levels removal is a much larger and trickier change > though, so to make it easier to review I choose to split these into > two changes. Please keep this in mind when reviewing the current change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076267 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8076267/webrev.00/ > > Thanks, > /Jesper From jesper.wilhelmsson at oracle.com Tue Mar 31 14:10:26 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 31 Mar 2015 16:10:26 +0200 Subject: RFR: JDK-8076267 - Remove n_gens() In-Reply-To: <551AA94A.1010809@oracle.com> References: <551A9DA1.8080804@oracle.com> <551AA94A.1010809@oracle.com> Message-ID: <551AAAD2.5040400@oracle.com> Thanks for reviewing! /Jesper Joseph Provino skrev den 31/3/15 16:03: > Looks good to me. > > joe > > On 3/31/2015 9:14 AM, Jesper Wilhelmsson wrote: >> Hi, >> >> Please review this next cleanup in the backwaters of the generation array >> removal. This change removes the n_gens() method and the max_gens variable >> from GenCollectedHeap. >> >> Next in line in the cleanup queue is a change to remove the levels concept. >> Mostly all places where we today pass a "level" in the GC code can be removed, >> or be made more explicit by introducing two constants, YOUNG and OLD. Removing >> n_gens() and the levels touches upon the same code in many places and we could >> skip one, in some places somewhat ugly, intermediate version by doing both >> changes at the same time. The levels removal is a much larger and trickier >> change though, so to make it easier to review I choose to split these into two >> changes. Please keep this in mind when reviewing the current change. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076267 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8076267/webrev.00/ >> >> Thanks, >> /Jesper > From evgeniya.stepanova at oracle.com Tue Mar 31 14:10:25 2015 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Tue, 31 Mar 2015 17:10:25 +0300 Subject: RFR: 8026043: Add regression test for JDK-8000831 Message-ID: <551AAAD1.90301@oracle.com> Hi all, Could you please review fix for 8026043? It is a regression test for 8000831: Heap verification output incorrect/incomplete. Test check that gc log contains expected information Originally patch was performed by Filipp Zhinkin in [1] , but review process was never finished. Test adapted to use current testlibrary functionality. bug: https://bugs.openjdk.java.net/browse/JDK-8026043 webrev: http://cr.openjdk.java.net/~eistepan/8026043/webrev.00/ [1] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-October/008772.html Thanks, Jane // -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.caspole at oracle.com Tue Mar 31 15:37:14 2015 From: eric.caspole at oracle.com (Eric Caspole) Date: Tue, 31 Mar 2015 11:37:14 -0400 Subject: RFR(s): 8076294: Cleanup of CollectedHeap::kind() In-Reply-To: <551A591A.6020900@oracle.com> References: <551A591A.6020900@oracle.com> Message-ID: <551ABF2A.9020308@oracle.com> Looks good. Eric On 3/31/2015 4:21 AM, Per Liden wrote: > Hi, > > Another small cleanup. > > CollectedHeap::kind() currently returns CollectedHeap::Abstract, which > makes little sense. Changing it to be a pure virtual member function > instead. The Abstract and SharedHeap members of CollectedHeap::Name > can then be removed as they are never used. > > Webrev: http://cr.openjdk.java.net/~pliden/8076294/webrev.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076294 > > Testing: jprt > > cheers, > /Per From mandy.chung at oracle.com Tue Mar 31 16:25:34 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Mar 2015 09:25:34 -0700 Subject: RFR: 8026043: Add regression test for JDK-8000831 In-Reply-To: <551AAAD1.90301@oracle.com> References: <551AAAD1.90301@oracle.com> Message-ID: <551ACA7E.8010502@oracle.com> Does this need any @modules tag? Mandy On 3/31/15 7:10 AM, Evgeniya Stepanova wrote: > Hi all, > > Could you please review fix for 8026043? It is a regression test for > 8000831: Heap verification output incorrect/incomplete. Test check > that gc log contains expected information > Originally patch was performed by Filipp Zhinkin in [1] , but review > process was never finished. > Test adapted to use current testlibrary functionality. > > bug: https://bugs.openjdk.java.net/browse/JDK-8026043 > webrev: http://cr.openjdk.java.net/~eistepan/8026043/webrev.00/ > [1] > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-October/008772.html > > Thanks, > Jane > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Tue Mar 31 16:49:40 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 31 Mar 2015 09:49:40 -0700 Subject: Request for review (s) : 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads In-Reply-To: <55192D67.7020205@oracle.com> References: <54FF1B4A.9020609@oracle.com> <5514DD8B.2070700@oracle.com> <55152756.8090307@oracle.com> <55156B31.3080906@oracle.com> <55192D67.7020205@oracle.com> Message-ID: <551AD024.1060300@oracle.com> On 3/30/2015 4:03 AM, Bengt Rutisson wrote: > > Hi Jon, > > On 2015-03-27 15:37, Jon Masamitsu wrote: >> Bengt, >> >> Thanks for looking at this. >> >> On 3/27/2015 2:48 AM, Bengt Rutisson wrote: >>> >>> On 2015-03-27 05:33, Jon Masamitsu wrote: >>>> The fix for 8017462 has been changed to adopt the suggestion from >>>> Bengt (thanks, Bengt). The patch from Bengt has been enhanced to >>>> include some of the changes in this first version that did not make >>>> it into Bengt's original patch. The test remains the same. A CR >>>> has been >>>> created to add another test to check the consistency of one of >>>> the per thread statistics with the sum of the statistics over all the >>>> threads (e.g., per thread object copy time and total object copy time) >>>> https://bugs.openjdk.java.net/browse/JDK-8076140 >>>> >>>> http://cr.openjdk.java.net/~jmasa/8017462/webrev.01/ >>> >>> Thanks for adopting this patch. I think it looks good now. :) >>> >>> A couple of questions about the test case. >>> >>> The proposed test will run with any GC configuration since it just >>> discards the JTreg configuration and selects its own GC. You have >>> specified @requires vm.gc=="null", which makes sense since we don't >>> have to run this test in every configuration. The test will anyway >>> always run with the GCs that it specifies itself. However, the >>> @requires tag will mean that the test is only run if no GC is >>> specified. Currently there is a "noopt" baseline in our nightly >>> testing that runs without explicitly setting a GC, so this test will >>> be run there. But if we change the nightly baselines to always >>> specify a GC we will never run this test. >> >> I would not expect that the nightly testing to always specify a >> specific GC because >> we do have a default GC and test should be run when we do the >> selection of the >> GC. Is this going to changes such that every nightly test specifies >> a specific GC? >> >> Are you suggesting that the command line be changed to not include a >> specific GC and that the the @requires be removed? So the test is run >> with whatever GC is being tested? > > I think I prefer that the test specifies the GCs that it needs to test > rather than relying on the framework to pass the relevant GC flags. > So, I prefer the way the test is written now. My question was really > if we want to use @requires for controlling when a test is run. More > below... OK. > >> >>> >>> I guess this is a more general question. Should we use @requires to >>> avoid running the same test many times or should we only use it when >>> the test actually requires a specific GC configuration? >> >> I'll happily take guidance on this point. Only using it when tests >> actually requires a specific >> GC sounds OK. > > I'm also not sure, so my question was really a question. Is this how > we want to make sure that a generic test is only run once? There are > other ways...test groups, nightly batch configuration etc... > >> >>> >>> Also, the test use a lot of flags: >>> >>> "-XX:+UnlockExperimentalVMOptions", "-XX:G1LogLevel=finest", "-XX:+" >>> + gcFlag, "-Xmx10M", "-showversion", "-XX:+PrintGCDetails", >>> "-XX:+UseDynamicNumberOfGCThreads", "-XX:+TraceDynamicGCThreads" >>> >>> >>> I think this should be enough: >>> >>> "-XX:+" + gcFlag, "-Xmx10M", "-XX:+UseDynamicNumberOfGCThreads", >>> "-XX:+TraceDynamicGCThreads" >>> >>> Is there a particular reason to have the other flags? >> >> In some of my testing there was a failure when I ran with log level >> set to finest >> that I did not see when I used the default logging level. I cannot >> recall if it was >> actually this test but I decided to add finest to this test as a >> result of seeing >> that failure. > > I don't see why the G1 log level would affect this test. Can you try > to reproduce the issue? If not I would prefer to remove those flags. I removed the extra flags "-XX:+UnlockExperimentalVMOptions", "-XX:G1LogLevel=finest" If I remove the "-XX:+PrintGCDetails" the test passes with a recent build of gc_baseline. If I keep that flag, the gc_baseline build fails (I added the stack trace to the CR). It passes with -XX:+PrintGCDetails and this fix. If the log level is not finer the method note_gc_end() is not called and the failure happens in note_gc_end(). Latest delta webrev (only the test was changed). http://cr.openjdk.java.net/~jmasa/8017462/webrev_delta_02/ Full webrev http://cr.openjdk.java.net/~jmasa/8017462/webrev.02/ Thanks. Jon > >> >> Wow. I have not known that G1 logging is printed when PrintGCDetails is >> off. Is that really the intent? > > Yes, that was intentional when G1LogLevel was introduced. I'm not > saying it is the right choice, but it was intentional. All of this > will be replaced with the unified logging for JDK 9, so I doubt that > it is worth digging too deep into it now. > > Thanks, > Bengt > >> >> Jon >> >> >>> >>> Thanks, >>> Bengt >>> >>>> >>>> On 3/10/2015 9:26 AM, Jon Masamitsu wrote: >>>>> 8017462: G1: guarantee fails with UseDynamicNumberOfGCThreads >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8017462 >>>>> >>>>> When fewer than the maximum number of threads was being used for >>>>> a parallel section, phase times for the threads that did not >>>>> execute and >>>>> averages for the phase were misleading. The fix passes the active >>>>> number of >>>>> GC threads to the G1 phase timers. >>>>> >>>>> http://cr.openjdk.java.net/~jmasa/8017462/webrev.00/ >>>>> >>>>> Tested with gc_test_suite. >>>> >>> >> > From kim.barrett at oracle.com Tue Mar 31 17:48:27 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 31 Mar 2015 13:48:27 -0400 Subject: RFR: JDK-8076267 - Remove n_gens() In-Reply-To: <551A9DA1.8080804@oracle.com> References: <551A9DA1.8080804@oracle.com> Message-ID: <941252D1-BC52-433B-BF67-A9AF95B7D1E8@oracle.com> On Mar 31, 2015, at 9:14 AM, Jesper Wilhelmsson wrote: > > Hi, > > Please review this next cleanup in the backwaters of the generation array removal. This change removes the n_gens() method and the max_gens variable from GenCollectedHeap. > > Next in line in the cleanup queue is a change to remove the levels concept. Mostly all places where we today pass a "level" in the GC code can be removed, or be made more explicit by introducing two constants, YOUNG and OLD. Removing n_gens() and the levels touches upon the same code in many places and we could skip one, in some places somewhat ugly, intermediate version by doing both changes at the same time. The levels removal is a much larger and trickier change though, so to make it easier to review I choose to split these into two changes. Please keep this in mind when reviewing the current change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076267 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8076267/webrev.00/ I think YOUNG and OLD might be a little overly generic. And I?m not sure there?s a need to make them especially short either. ------------------------------------------------------------------------------ src/share/vm/memory/cardTableRS.cpp 47 int max_gens = 2; ... 53 for (int i = 0; i < max_gens + 1; i++) { These should be unsigned int or size_t types, rather than (signed) int. ------------------------------------------------------------------------------ src/share/vm/memory/genCollectedHeap.cpp 433 bool complete = full && (max_level == 1); I'd really like to have a name for that literal "1". Or at least a comment or something, if this code will be changing further with the cleanup of the level concept. Similarly here: 505 complete = complete || (max_level_collected == 1); Actually, there's a whole bunch of literal "1"s. I'm worried that in the future level cleanup it will be very easy to miss some of these. So I think it would be better to introduce the level constants now, even if the rest of the level cleanup isn't happening until later. ------------------------------------------------------------------------------ From jesper.wilhelmsson at oracle.com Tue Mar 31 18:30:09 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 31 Mar 2015 20:30:09 +0200 Subject: RFR: JDK-8076267 - Remove n_gens() In-Reply-To: <941252D1-BC52-433B-BF67-A9AF95B7D1E8@oracle.com> References: <551A9DA1.8080804@oracle.com> <941252D1-BC52-433B-BF67-A9AF95B7D1E8@oracle.com> Message-ID: <551AE7B1.5090305@oracle.com> Hi Kim, Thanks for reviewing! See comments below. A new webrev is available here: http://cr.openjdk.java.net/~jwilhelm/8076267/webrev.01/ Kim Barrett skrev den 31/3/15 19:48: > On Mar 31, 2015, at 9:14 AM, Jesper Wilhelmsson wrote: >> >> Hi, >> >> Please review this next cleanup in the backwaters of the generation array removal. This change removes the n_gens() method and the max_gens variable from GenCollectedHeap. >> >> Next in line in the cleanup queue is a change to remove the levels concept. Mostly all places where we today pass a "level" in the GC code can be removed, or be made more explicit by introducing two constants, YOUNG and OLD. Removing n_gens() and the levels touches upon the same code in many places and we could skip one, in some places somewhat ugly, intermediate version by doing both changes at the same time. The levels removal is a much larger and trickier change though, so to make it easier to review I choose to split these into two changes. Please keep this in mind when reviewing the current change. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076267 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8076267/webrev.00/ > > I think YOUNG and OLD might be a little overly generic. And I?m not sure there?s a need to make them especially short either. I agree. I didn't have the level-patch fresh in mind when writing. What I actually have in the patch right now is an enum in the Generation class: enum Type { Young, Old }; When using it the class name will be present as well as the constant giving the names context and meaning, Generation::Young, and Generation::Old. This also means that in this patch I change the type of any function that still needs to take a level as an argument from int to Generation::Type. So there should not be any risk of missing any stray 0's or 1's in the code, they will all be replaced with this new type. (Some of them will actually be removed since we don't need to pass around the level any more.) I'd prefer not to add this new type to this change however since this is one of the changes that makes the level cleanup large and tricky. > > ------------------------------------------------------------------------------ > src/share/vm/memory/cardTableRS.cpp > 47 int max_gens = 2; > ... > 53 for (int i = 0; i < max_gens + 1; i++) { > > These should be unsigned int or size_t types, rather than (signed) > int. Fixed. > > ------------------------------------------------------------------------------ > src/share/vm/memory/genCollectedHeap.cpp > 433 bool complete = full && (max_level == 1); > > I'd really like to have a name for that literal "1". Or at least a > comment or something, if this code will be changing further with the > cleanup of the level concept. > > Similarly here: > 505 complete = complete || (max_level_collected == 1); > > Actually, there's a whole bunch of literal "1"s. I'm worried that in > the future level cleanup it will be very easy to miss some of these. > So I think it would be better to introduce the level constants now, > even if the rest of the level cleanup isn't happening until later. As noted above I'd prefer not to add the new type in this change. I have added comments like /* young */ and /* old */ along with the 1's and 0's I touched in this change and a few more. But there are plenty of these magic level constants in the code (and all of them will disappear with the next change :)). Thanks, /Jesper From kim.barrett at oracle.com Tue Mar 31 19:41:36 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 31 Mar 2015 15:41:36 -0400 Subject: RFR: 8076265: Simplify deal_with_reference Message-ID: Please review this simplification and cleanup of CMTask::deal_with_reference. I will need a sponsor for this change. Removed _CHECK_BOTH_FINGERS_ macro, changing the code to assume it was true (as it always has been since it was introduced), eliminating some duplicated code. Simplfied the current region tests, making use of all the associated variables either being set or NULL together, so no need for multiple NULL checks. Added a helper function for logging and pushing objects on the mark stack, removing some (almost) code duplication. This is also the place where some forthcoming changes for 8069367 will end up. CR: https://bugs.openjdk.java.net/browse/JDK-8076265 Webrev: http://cr.openjdk.java.net/~kbarrett/8076265/webrev/ Testing: JPRT local RefWorkload with -XX:+UseG1GC local JTREG with -XX:+UseG1GC From kim.barrett at oracle.com Tue Mar 31 21:33:16 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 31 Mar 2015 17:33:16 -0400 Subject: RFR: JDK-8076267 - Remove n_gens() In-Reply-To: <551AE7B1.5090305@oracle.com> References: <551A9DA1.8080804@oracle.com> <941252D1-BC52-433B-BF67-A9AF95B7D1E8@oracle.com> <551AE7B1.5090305@oracle.com> Message-ID: <9798A00F-9EFC-4E3E-9C00-8747AD232354@oracle.com> On Mar 31, 2015, at 2:30 PM, Jesper Wilhelmsson wrote: > > Hi Kim, > > Thanks for reviewing! > > See comments below. A new webrev is available here: > > http://cr.openjdk.java.net/~jwilhelm/8076267/webrev.01/ Looks good. Some replies inline below. > Kim Barrett skrev den 31/3/15 19:48: >> On Mar 31, 2015, at 9:14 AM, Jesper Wilhelmsson wrote: >>> >>> Hi, >>> >>> Please review this next cleanup in the backwaters of the generation array removal. This change removes the n_gens() method and the max_gens variable from GenCollectedHeap. >>> >>> Next in line in the cleanup queue is a change to remove the levels concept. Mostly all places where we today pass a "level" in the GC code can be removed, or be made more explicit by introducing two constants, YOUNG and OLD. Removing n_gens() and the levels touches upon the same code in many places and we could skip one, in some places somewhat ugly, intermediate version by doing both changes at the same time. The levels removal is a much larger and trickier change though, so to make it easier to review I choose to split these into two changes. Please keep this in mind when reviewing the current change. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076267 >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8076267/webrev.00/ >> >> I think YOUNG and OLD might be a little overly generic. And I?m not sure there?s a need to make them especially short either. > > I agree. I didn't have the level-patch fresh in mind when writing. What I actually have in the patch right now is an enum in the Generation class: > > enum Type { > Young, > Old > }; > > When using it the class name will be present as well as the constant giving the names context and meaning, Generation::Young, and Generation::Old. Yes, that?s good. > This also means that in this patch I change the type of any function that still needs to take a level as an argument from int to Generation::Type. So there should not be any risk of missing any stray 0's or 1's in the code, they will all be replaced with this new type. (Some of them will actually be removed since we don't need to pass around the level any more.) > > I'd prefer not to add this new type to this change however since this is one of the changes that makes the level cleanup large and tricky. OK. >> ------------------------------------------------------------------------------ >> src/share/vm/memory/genCollectedHeap.cpp >> 433 bool complete = full && (max_level == 1); >> >> I'd really like to have a name for that literal "1". Or at least a >> comment or something, if this code will be changing further with the >> cleanup of the level concept. >> >> Similarly here: >> 505 complete = complete || (max_level_collected == 1); >> >> Actually, there's a whole bunch of literal "1"s. I'm worried that in >> the future level cleanup it will be very easy to miss some of these. >> So I think it would be better to introduce the level constants now, >> even if the rest of the level cleanup isn't happening until later. > > As noted above I'd prefer not to add the new type in this change. I have added comments like /* young */ and /* old */ along with the 1's and 0's I touched in this change and a few more. But there are plenty of these magic level constants in the code (and all of them will disappear with the next change :)). OK. From kim.barrett at oracle.com Tue Mar 31 23:59:49 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 31 Mar 2015 19:59:49 -0400 Subject: RFR (S): JDK-8076241: Remove unused methods mod_card_iterate() and non_clean_card_iterate_serial() In-Reply-To: <551A45E2.4000502@oracle.com> References: <55195B51.3030403@oracle.com> <15B61388-9257-466F-8355-867F30F49004@oracle.com> <551A45E2.4000502@oracle.com> Message-ID: <7D097C5D-A5E8-464B-8950-85F0007234F4@oracle.com> On Mar 31, 2015, at 2:59 AM, Bengt Rutisson wrote: > > On 2015-03-31 00:16, Kim Barrett wrote: >> ------------------------------------------------------------------------------ >> src/share/vm/memory/cardTableModRefBS.hpp >> 181 // XXX ??? MemRegionClosure above vs OopsInGenClosure below XXX >> 182 // XXX some new_dcto_cl's take OopClosure's, plus as above there are >> 183 // some MemRegionClosures. Clean this up everywhere. XXX >> >> This untouched comment is referring to the removed >> non_clean_card_iterate_serial function ("above"), so needs to be >> updated. It may be that the comment can be removed entirely now, >> possibly being moved to the technical debt wiki. > > Ah. Good point. I removed the comment and added this to the technical debt wiki: > > "CardTableModRefBS::dirty_card_iterate() works with a MemRegion and a MemRegionClosure. Other similar methods, such as CardTableModRefBS::non_clean_card_iterate_possibly_parallel() and CardTableModRefBS::process_stride() use OopsInGenClosure instead. Can we use a consistent API?? That works for me. >> ------------------------------------------------------------------------------ >> src/share/vm/memory/cardTableModRefBS.hpp >> 382 // Invoke "cl.do_MemRegion" on a set of MemRegions that collectively >> 383 // includes all the modified cards (expressing each card as a >> 384 // MemRegion). Thus, several modified cards may be lumped into one >> 385 // region. The regions are non-overlapping, and are visited in >> 386 // *decreasing* address order. (This order aids with imprecise card >> 387 // marking, where a dirty card may cause scanning, and summarization >> 388 // marking, of objects that extend onto subsequent cards.) >> >> This comment was the reason I'd deferred removing mod_card_iterate. So >> far as I can tell, this comment is the *only* place where there is any >> discussion whatsoever of why some card iterators scan backward. I >> wanted to find a new and better home for that information before >> deleting the comment. > > I see. I couldn't find a card iterator that scans backwards now. Do you have a pointer to one that still scans backwards? > > I'll push the change with the comment removed. I'm happy to find a new place for the comment if we have an iterators that scan backwards. I think the only one left is ClearNoncleanCardWrapper::do_MemRegion(). But I don?t guarantee there aren?t more. I was trying to build a list of all the card table iterators as part of working on https://bugs.openjdk.java.net/browse/JDK-8060244 There were a surprising number, all different; and I?m not sure I found them all either.