From bengt.rutisson at oracle.com Tue Dec 1 13:09:27 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 01 Dec 2015 14:09:27 +0100 Subject: RRF: JEP-271: Unified GC Logging In-Reply-To: <5655B0E2.6040009@oracle.com> References: <564DEAEB.90703@oracle.com> <56534C0D.3070209@oracle.com> <5655A994.7000304@oracle.com> <5655B0E2.6040009@oracle.com> Message-ID: <565D9C07.2080808@oracle.com> Hi everyone, Here are updated webrevs that include the comments on the last review request. HotSpot changes: http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/hotspot-webrev.02/ Complete changes: Diff compared to last webrev: http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/hotspot-webrev.01-02.diff/ JDK changes: Complete changes: http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.02/ Diff compared to last webrev: http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.01-02.diff/ Except for the comment that were discussed in this email thread there are a couple of other changes: - Most of the implementation parts in gcTraceTime.hpp were moved to gcTraceTime.inline.hpp. - New tests and new code that use logging were updated. - Some tests were changed to use less extensive logging. - A bug gave duplicate timing for Full GCs when going through GenCollectedHeap - The used calculation for G1 old logging could overflow. - The @ignore tag was added back to TestLogging.java. Thanks, Bengt On 2015-11-25 14:00, Bengt Rutisson wrote: > > Hi David, > > Thanks for looking at this again! > > On 2015-11-25 13:29, David Lindholm wrote: >> Hi Bengt, >> >> My code review for the rest of the files: >> >> defNewGeneration.cpp: >> >> 517-520: Indentation > > Fixed. > >> 766: Shouldn't the tags be "gc, promotion"? > > Yes. Fixed. > >> >> collectorPolicy.cpp: >> >> 489: Shouldn't the tags be "gc, heap"? > > Yes, fixed. > >> >> genCollectedHeap.cpp: >> >> 1150+1152: Indentation >> >> generation.cpp: >> >> 162: Indentation > > Fixed. > >> >> plab.cpp: >> >> 153: Plab_size = " SIZE_FORMAT " desired_net_plab_sz = " SIZE_FORMAT >> ": Why the capital P in this printout of one variable name but not >> the other? I think it should be consistent. > > Agreed. Fixed. > > >> >> referenceProcessor.cpp: >> >> 515: Indentation >> >> referenceProcessor.cpp: >> >> 948+953: Indentation >> >> metaspace.cpp: >> >> 1505: Indentation >> 1578+1580: Indentation >> 2695: Indentation >> >> runtimeService.cpp: >> >> 123-124: Indentation > > Fixed. > > Thanks, > Bengt > >> >> >> Thanks, >> David >> >> On 2015-11-23 18:25, Bengt Rutisson wrote: >>> >>> Hi everyone, >>> >>> Here is an updated webrev based on the comments from the first >>> review. The changes that have been discussed have only been to the >>> hotspot repo: >>> >>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.01/ >>> >>> The changes to the JDK repo are the same as in the first webrev: >>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/jdk-webrev.00/ >>> >>> >>> Some partial diffs to make it easier for those who already looked at >>> the first webrev. >>> >>> The unified logging framework was changed in the way it handles the >>> develop logging. Here are the changes I had to do to accommodate the >>> new develop logging: >>> >>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.01-develop-logging >>> >>> >>> Here are the changes I have made to address comments in the code >>> (based on top of the develop logging changes): >>> >>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.00-01-code-diff >>> >>> >>> And here are the changes that David has made to address comment in >>> the tests: >>> >>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.00-01-test-diff >>> >>> >>> Enjoy! >>> Bengt >>> >>> On 2015-11-19 16:29, Bengt Rutisson wrote: >>>> >>>> Hi everyone, >>>> >>>> After three pre-reviews it is time for the fist official review >>>> request for JEP-271 Unified GC Logging. >>>> >>>> http://openjdk.java.net/jeps/271 >>>> >>>> Most code changes are in the hotspot code: >>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/webrev.00/ >>>> >>>> Some tests in the JDK repo have been updated: >>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/jdk-webrev.00/ >>>> >>>> As with the pre-reviews I have put togther some examples of what >>>> the new logging looks like: >>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/compare.html >>>> >>>> The intent is that this should cover the bulk of the logging >>>> changes. There will most definitely be some follow up changes where >>>> we fix details in the log messages etc. >>>> >>>> Among many other old logging flags this changeset removes the two >>>> flags PringGC and PrintGCDetails. These two will be added back with >>>> a follow up changeset, but when they are added back they will be >>>> marked as deprecated. >>>> >>>> The reason for first removing them and then adding them back is to >>>> get testing without these flags. That way we will know that we >>>> clean out all usages of these flags from our testing. >>>> >>>> Thanks, >>>> Bengt >>> >> > From erik.helin at oracle.com Tue Dec 1 16:16:36 2015 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 1 Dec 2015 17:16:36 +0100 Subject: RFR: 8144315: update_rs is passed wrong object Message-ID: <20151201161636.GD2920@ehelin.jrpg.bea.com> Hi all, this patch fixes an issue with the patch for JDK-8144067. The problem is that the wrong oop is passed to update_rs when 'obj' gets forwarded. Bug: https://bugs.openjdk.java.net/browse/JDK-8144315 Webrev: http://cr.openjdk.java.net/~ehelin/8144315/webrev.00/ Testing: - GC Basher with full verification - GC test suite with full verification - JPRT Thanks, Erik From kim.barrett at oracle.com Tue Dec 1 18:06:59 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Dec 2015 13:06:59 -0500 Subject: RFR: 8144315: update_rs is passed wrong object In-Reply-To: <20151201161636.GD2920@ehelin.jrpg.bea.com> References: <20151201161636.GD2920@ehelin.jrpg.bea.com> Message-ID: <3888CFF4-BE32-4696-AED7-77D3E673570F@oracle.com> On Dec 1, 2015, at 11:16 AM, Erik Helin wrote: > > Hi all, > > this patch fixes an issue with the patch for JDK-8144067. The problem is > that the wrong oop is passed to update_rs when 'obj' gets forwarded. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8144315 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8144315/webrev.00/ > > Testing: > - GC Basher with full verification > - GC test suite with full verification > - JPRT > > Thanks, > Erik Ouch! Change looks good. From jon.masamitsu at oracle.com Tue Dec 1 18:41:32 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 1 Dec 2015 10:41:32 -0800 Subject: RFR: 8144315: update_rs is passed wrong object In-Reply-To: <20151201161636.GD2920@ehelin.jrpg.bea.com> References: <20151201161636.GD2920@ehelin.jrpg.bea.com> Message-ID: <565DE9DC.6020101@oracle.com> Change looks good. Reviewed. Jon On 12/1/2015 8:16 AM, Erik Helin wrote: > Hi all, > > this patch fixes an issue with the patch for JDK-8144067. The problem is > that the wrong oop is passed to update_rs when 'obj' gets forwarded. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8144315 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8144315/webrev.00/ > > Testing: > - GC Basher with full verification > - GC test suite with full verification > - JPRT > > Thanks, > Erik From alexander.harlap at oracle.com Tue Dec 1 20:45:33 2015 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Tue, 1 Dec 2015 15:45:33 -0500 Subject: Request for code review - JDK-8141123 Change int's to size_t in FreeIdSet In-Reply-To: <1448536437.2100.27.camel@oracle.com> References: <5627EB64.1070704@oracle.com> <5640D3F2.3080601@oracle.com> <56439D48.5000105@oracle.com> <1447320920.2312.29.camel@oracle.com> <1448536437.2100.27.camel@oracle.com> Message-ID: <565E06ED.2080309@oracle.com> Here is new version, to satisfy comments of Thomas, Kim and Tom. I hope it is better now. http://cr.openjdk.java.net/~aharlap/8141123/webrev.04/ Alex On 11/26/2015 6:13 AM, Thomas Schatzl wrote: > Hi, > > On Wed, 2015-11-25 at 17:34 -0500, Kim Barrett wrote: >> On Nov 12, 2015, at 4:35 AM, Thomas Schatzl wrote: >>> - FreeIdSet::set_safepoint() seems to be never called. I think it >>> allows you to remove a *lot* of unused stuff. >> Perhaps the bug here is that there should be calls to set_safepoint but they are missing? >> > apparently the functionality is not needed, that is, it has not even > been in use in the initial integration of G1 (and it has been added in > that change). > > So I suggest to just remove it and everything that depended on it > instead of trying to find out what this functionality may have been used > for. > > Thanks, > Thomas > > From tom.benson at oracle.com Tue Dec 1 21:37:15 2015 From: tom.benson at oracle.com (Tom Benson) Date: Tue, 1 Dec 2015 16:37:15 -0500 Subject: RFR (M): 8060697: Improve G1 Heap Growth Heuristics In-Reply-To: <565CAD31.1010207@oracle.com> References: <5653D33D.3090906@oracle.com> <72774236-F1E8-4D47-A202-5BED4646D24A@oracle.com> <5655C06D.1010209@oracle.com> <565CAD31.1010207@oracle.com> Message-ID: <565E130B.6010003@oracle.com> Hi Jon, Thanks very much for the review. On 11/30/2015 3:10 PM, Jon Masamitsu wrote: > Tom, > > http://cr.openjdk.java.net/~tbenson/8060697/webrev/src/share/vm/gc/g1/g1CollectorPolicy.cpp.frames.html > > 1053 // Compute the ratio of just this last pause time to the entire > time range stored > 1054 // in the vectors. > 1055 _last_pause_time_ratio = > 1056 (pause_time_ms * _recent_prev_end_times_for_all_gcs_sec->num()) / > interval_ms; > > _last_pause_time_ratio is the ratio of the last pause over the > average interval in the truncated sequence? By the latter > I mean > > (interval_ms / _recent_prev_end_times_for_all_gcs_sec->num()) > > If the truncated sequence has N sample and "interval_ms" is > measured from the oldest sample, I'm calling interval_ms / N > the average interval. > > Is my description correct? Why do you prefer that to the most recent > pause time ratio? Yes, your description is right. Basically I want to notice the *first* pause that goes over the threshold, rather than waiting for the average over the last 10 pauses to go over. The reason is that this will start the code looking for ratios that exceed the threshold (beginning a "sampling window" so to speak), and I want to do that as soon as possible. If by this: "Why do you prefer that to the most recent pause time ratio?" you mean "Why not just compare the last pause to the last single interval?", the reason is that comparing it to the entire range 'smooths over' some transiently-more-frequent GCs that don't really reflect a change in heap occupancy. I see this happening in specjbb sometimes. By only comparing against the last interval, needless growth happens more often, resulting in higher run-to-run variability. Another approach would be to raise the minimum number of threshold crossing pauses that are needed before triggering growth - but I don't want to delay that for cases where the need is real. Thomas commented to me that that transient behavior is likely to be due to something we ultimately want to fix, anyway. But the current approach of comparing against the whole recorded range seems to help alleviate the side effect of needless growth. > > Should the 1*M below be 1 region size? > 1545 const size_t min_expand_bytes = 1*M; Hmm, good question. I didn't change that. It could certainly be MIN_REGION_SIZE, which == 1*M. I think using the actual region size would likely only have an effect when the heap is nearly at minimum or maximum sizes. In between, the math is likely to result in a size larger than that anyway. I could try it. > > As the uncommitted space in the heap drops, the grow rate drops. > > > 1550 size_t expand_bytes_via_pct = > 1551 uncommitted_bytes * G1ExpandByPercentOfAvailable / 100; > > The scale_factor will increase that by up to a factor of 2, the policy > seems to grow slowly to the maximum. Is there a reason not to get > to the maximum heap size quickly? Yes, I thought about this as well. This attribute (shrinking the growth increment as we approach the limit) is there in both the old and new code, but the new code may scale the value up. What I considered, but didn't try, was to use a fixed percentage of the entire heap, once we have reached a certain threshold by doubling the size. That value would still be scaled according to the pause ratios. I decided not to pursue it for now, since the results looked acceptable and it could be done as a follow up. However, it won't be hard to try, and I can do so if there's agreement that the rest of this approach seems reasonable. Thanks, Tom > > Jon > > > On 11/25/2015 06:06 AM, Tom Benson wrote: >> Hi Kim, >> Thanks very much for the review. I've implemented all your suggestions. >> Down >> About this: >> >>> I suspect you are introducing some implicit conversions that will cause >>> problems for the SAP folks; see discussion of 8143215: >> >> ... I think there's one, which is: >> >> expand_bytes = expand_bytes * scale_factor; >> >> scale_factor is explicitly limited to being between 0.2 and 2.0, and >> expand_bytes is fraction of the heap size, so there's no chance of >> overflow. Would you object to the static cast in this case? How >> about with a comment? >> >> Tom >> >> On 11/24/2015 9:55 PM, Kim Barrett wrote: >>> On Nov 23, 2015, at 10:02 PM, Tom Benson wrote: >>>> Hi, >>>> Here is a proposed change to the G1 heap growth code for review. >>>> I've added a detailed description to the CR, but here is the short >>>> version: After a GC pause, the average ratio of time spent in >>>> recent GC pauses vs overall time is computed. If it exceeds >>>> GCTimeRatio, the heap is expanded by a fixed amount. With the new >>>> code, some deficiencies in the ratio tracking are addressed, and >>>> the expansion size is scaled according to how much the desired >>>> ratio is, on average, exceeded by. The target ratio itself is also >>>> scaled at the lowest heap sizes. >>>> >>>> The case that triggered this was actually JDK-8132077, where the >>>> JVM'08 Compress benchmark saw a 40% degradation. It was due to the >>>> heap being about half the size in some runs, because of the way >>>> heap growth worked. >>>> >>>> I'm still collecting the final performance data for this version, >>>> and will attach it to the CR. Earlier experimental versions showed >>>> good improvements in consistency of heap sizes. A couple of >>>> benchmarks average a percentage point or two lower, while others >>>> improve by that much or more. No growth percentage or scaling is >>>> going to be ideal for every test, but the goal was to maintain >>>> performance without growing too large. In fact, some tests now use >>>> much smaller heaps. >>>> >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8060697 >>>> Webrev: >>>> http://cr.openjdk.java.net/~tbenson/8060697/webrev/ >>> Generally looks good; just a few very minor things, most of which >>> you can >>> take or ignore as you prefer. I don't need a new webrev for any of >>> these. >>> >>> The comments were very helpful in understanding what's going on. >>> >>> I suspect you are introducing some implicit conversions that will cause >>> problems for the SAP folks; see discussion of 8143215: gcc 4.1.2: >>> fix three >>> issues breaking the build. But the resolution for that is still being >>> discussed, and we don't have an easy way to discover these for >>> ourselves, so >>> I don't think you should worry about it here right now. >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/gc/g1/g1CollectorPolicy.cpp >>> 1571 static double const MinScaleDownFactor = 0.2; >>> 1572 static double const MaxScaleUpFactor = 2; >>> 1573 static double const StartScaleDownAt = _gc_overhead_perc; >>> 1574 static double const StartScaleUpAt = _gc_overhead_perc * >>> 1.5; >>> 1575 static double const ScaleUpRange = _gc_overhead_perc * 2.0; >>> >>> I suggest these not be static. >>> >>> It doesn't really matter for the first two. >>> >>> But for the others, there is a hidden cost to making them static, >>> due to >>> some compilers ensuring thread-safe initialization. C++11 mandates >>> thread-safe initialization of function scoped statics. gcc has >>> implemented >>> that starting circa gcc4.0 (if I recall correctly), controlled by a CLA >>> (-f[no]-threadsafe-statics). Visual Studio 2013 also includes this >>> feature, >>> as part of their incremental rollout of C++11 (and later) features. >>> I don't >>> know about other compilers. >>> >>> The cost of making them static is likely at least comparable to >>> computing >>> them. And making them static implies the _gc_overhead_perc is >>> effectively a >>> constant, which appears to be true today, but who knows what will >>> happen >>> tomorrow. >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/gc/g1/g1CollectorPolicy.cpp >>> 1587 scale_factor = MAX2(scale_factor, >>> MinScaleDownFactor); >>> 1590 scale_factor = MIN2(scale_factor, >>> MaxScaleUpFactor); >>> >>> The explicit double template parameter isn't needed here, since the >>> arguments are already both doubles. >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/gc/g1/g1CollectorPolicy.cpp >>> 1525 threshold = (threshold * ((double)_g1->capacity() / >>> (double)(_g1->max_capacity() / 2))); >>> >>> This might be easier to read if it used "threshold *= ...". >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/gc/g1/g1CollectorPolicy.cpp >>> 1526 threshold = MAX2(threshold, 1); >>> >>> The explicit double template parameter wouldn't be needed if "1" was >>> replaced with "1.0". >>> >>> ------------------------------------------------------------------------------ >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Tue Dec 1 23:44:54 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 1 Dec 2015 15:44:54 -0800 Subject: RFR (M): 8060697: Improve G1 Heap Growth Heuristics In-Reply-To: <565E130B.6010003@oracle.com> References: <5653D33D.3090906@oracle.com> <72774236-F1E8-4D47-A202-5BED4646D24A@oracle.com> <5655C06D.1010209@oracle.com> <565CAD31.1010207@oracle.com> <565E130B.6010003@oracle.com> Message-ID: <565E30F6.5020201@oracle.com> On 12/1/2015 1:37 PM, Tom Benson wrote: > Hi Jon, > Thanks very much for the review. > > On 11/30/2015 3:10 PM, Jon Masamitsu wrote: >> Tom, >> >> http://cr.openjdk.java.net/~tbenson/8060697/webrev/src/share/vm/gc/g1/g1CollectorPolicy.cpp.frames.html >> >> 1053 // Compute the ratio of just this last pause time to the entire >> time range stored >> 1054 // in the vectors. >> 1055 _last_pause_time_ratio = >> 1056 (pause_time_ms * _recent_prev_end_times_for_all_gcs_sec->num()) >> / interval_ms; >> >> _last_pause_time_ratio is the ratio of the last pause over the >> average interval in the truncated sequence? By the latter >> I mean >> >> (interval_ms / _recent_prev_end_times_for_all_gcs_sec->num()) >> >> If the truncated sequence has N sample and "interval_ms" is >> measured from the oldest sample, I'm calling interval_ms / N >> the average interval. >> >> Is my description correct? Why do you prefer that to the most recent >> pause time ratio? > > Yes, your description is right. Basically I want to notice the > *first* pause that goes over the threshold, rather than waiting for > the average over the last 10 pauses to go over. The reason is that > this will start the code looking for ratios that exceed the threshold > (beginning a "sampling window" so to speak), and I want to do that as > soon as possible. OK. That sounds like a good policy. > > If by this: "Why do you prefer that to the most recent pause time > ratio?" you mean "Why not just compare the last pause to the last > single interval?", the reason is that comparing it to the entire range > 'smooths over' some transiently-more-frequent GCs that don't really > reflect a change in heap occupancy. I see this happening in specjbb > sometimes. By only comparing against the last interval, needless > growth happens more often, resulting in higher run-to-run > variability. Another approach would be to raise the minimum number > of threshold crossing pauses that are needed before triggering growth > - but I don't want to delay that for cases where the need is real. > Thomas commented to me that that transient behavior is likely to be > due to something we ultimately want to fix, anyway. But the current > approach of comparing against the whole recorded range seems to help > alleviate the side effect of needless growth. More sound reasoning. > > >> >> Should the 1*M below be 1 region size? >> 1545 const size_t min_expand_bytes = 1*M; > > Hmm, good question. I didn't change that. It could certainly be > MIN_REGION_SIZE, which == 1*M. I think using the actual region size > would likely only have an effect when the heap is nearly at minimum or > maximum sizes. In between, the math is likely to result in a size > larger than that anyway. I could try it. I was wondering what happens when the region size is 32M. Do you recall? > >> >> As the uncommitted space in the heap drops, the grow rate drops. >> >> >> 1550 size_t expand_bytes_via_pct = >> 1551 uncommitted_bytes * G1ExpandByPercentOfAvailable / 100; >> >> The scale_factor will increase that by up to a factor of 2, the policy >> seems to grow slowly to the maximum. Is there a reason not to get >> to the maximum heap size quickly? > > Yes, I thought about this as well. This attribute (shrinking the > growth increment as we approach the limit) is there in both the old > and new code, but the new code may scale the value up. What I > considered, but didn't try, was to use a fixed percentage of the > entire heap, once we have reached a certain threshold by doubling the > size. That value would still be scaled according to the pause > ratios. I decided not to pursue it for now, since the results looked > acceptable and it could be done as a follow up. Let that stand. I know that G1 historically has grown the heap based on how much uncommitted is left. Don't know if it is good or bad. I've just never gotten used to that approach. > > However, it won't be hard to try, and I can do so if there's agreement > that the rest of this approach seems reasonable. Some of my second guessing on this policy is that it seems rather complex. Someone will eventually ask for documentation on how the heap grows. Hope you're up to it. :-) I don't have any more comments. I'm good with it. Jon > Thanks, > Tom > >> >> Jon >> >> >> On 11/25/2015 06:06 AM, Tom Benson wrote: >>> Hi Kim, >>> Thanks very much for the review. I've implemented all your >>> suggestions. >>> Down >>> About this: >>> >>>> I suspect you are introducing some implicit conversions that will >>>> cause >>>> problems for the SAP folks; see discussion of 8143215: >>> >>> ... I think there's one, which is: >>> >>> expand_bytes = expand_bytes * scale_factor; >>> >>> scale_factor is explicitly limited to being between 0.2 and 2.0, and >>> expand_bytes is fraction of the heap size, so there's no chance of >>> overflow. Would you object to the static cast in this case? How >>> about with a comment? >>> >>> Tom >>> >>> On 11/24/2015 9:55 PM, Kim Barrett wrote: >>>> On Nov 23, 2015, at 10:02 PM, Tom Benson >>>> wrote: >>>>> Hi, >>>>> Here is a proposed change to the G1 heap growth code for review. >>>>> I've added a detailed description to the CR, but here is the short >>>>> version: After a GC pause, the average ratio of time spent in >>>>> recent GC pauses vs overall time is computed. If it exceeds >>>>> GCTimeRatio, the heap is expanded by a fixed amount. With the new >>>>> code, some deficiencies in the ratio tracking are addressed, and >>>>> the expansion size is scaled according to how much the desired >>>>> ratio is, on average, exceeded by. The target ratio itself is >>>>> also scaled at the lowest heap sizes. >>>>> >>>>> The case that triggered this was actually JDK-8132077, where the >>>>> JVM'08 Compress benchmark saw a 40% degradation. It was due to >>>>> the heap being about half the size in some runs, because of the >>>>> way heap growth worked. >>>>> >>>>> I'm still collecting the final performance data for this version, >>>>> and will attach it to the CR. Earlier experimental versions >>>>> showed good improvements in consistency of heap sizes. A couple >>>>> of benchmarks average a percentage point or two lower, while >>>>> others improve by that much or more. No growth percentage or >>>>> scaling is going to be ideal for every test, but the goal was to >>>>> maintain performance without growing too large. In fact, some >>>>> tests now use much smaller heaps. >>>>> >>>>> CR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8060697 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~tbenson/8060697/webrev/ >>>> Generally looks good; just a few very minor things, most of which >>>> you can >>>> take or ignore as you prefer. I don't need a new webrev for any of >>>> these. >>>> >>>> The comments were very helpful in understanding what's going on. >>>> >>>> I suspect you are introducing some implicit conversions that will >>>> cause >>>> problems for the SAP folks; see discussion of 8143215: gcc 4.1.2: >>>> fix three >>>> issues breaking the build. But the resolution for that is still being >>>> discussed, and we don't have an easy way to discover these for >>>> ourselves, so >>>> I don't think you should worry about it here right now. >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/share/vm/gc/g1/g1CollectorPolicy.cpp >>>> 1571 static double const MinScaleDownFactor = 0.2; >>>> 1572 static double const MaxScaleUpFactor = 2; >>>> 1573 static double const StartScaleDownAt = _gc_overhead_perc; >>>> 1574 static double const StartScaleUpAt = _gc_overhead_perc * >>>> 1.5; >>>> 1575 static double const ScaleUpRange = _gc_overhead_perc * 2.0; >>>> >>>> I suggest these not be static. >>>> >>>> It doesn't really matter for the first two. >>>> >>>> But for the others, there is a hidden cost to making them static, >>>> due to >>>> some compilers ensuring thread-safe initialization. C++11 mandates >>>> thread-safe initialization of function scoped statics. gcc has >>>> implemented >>>> that starting circa gcc4.0 (if I recall correctly), controlled by a >>>> CLA >>>> (-f[no]-threadsafe-statics). Visual Studio 2013 also includes this >>>> feature, >>>> as part of their incremental rollout of C++11 (and later) >>>> features. I don't >>>> know about other compilers. >>>> >>>> The cost of making them static is likely at least comparable to >>>> computing >>>> them. And making them static implies the _gc_overhead_perc is >>>> effectively a >>>> constant, which appears to be true today, but who knows what will >>>> happen >>>> tomorrow. >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/share/vm/gc/g1/g1CollectorPolicy.cpp >>>> 1587 scale_factor = MAX2(scale_factor, >>>> MinScaleDownFactor); >>>> 1590 scale_factor = MIN2(scale_factor, >>>> MaxScaleUpFactor); >>>> >>>> The explicit double template parameter isn't needed here, since the >>>> arguments are already both doubles. >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/share/vm/gc/g1/g1CollectorPolicy.cpp >>>> 1525 threshold = (threshold * ((double)_g1->capacity() / >>>> (double)(_g1->max_capacity() / 2))); >>>> >>>> This might be easier to read if it used "threshold *= ...". >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/share/vm/gc/g1/g1CollectorPolicy.cpp >>>> 1526 threshold = MAX2(threshold, 1); >>>> >>>> The explicit double template parameter wouldn't be needed if "1" was >>>> replaced with "1.0". >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Tue Dec 1 23:45:15 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Dec 2015 18:45:15 -0500 Subject: Request for code review - JDK-8141123 Change int's to size_t in FreeIdSet In-Reply-To: <1448536437.2100.27.camel@oracle.com> References: <5627EB64.1070704@oracle.com> <5640D3F2.3080601@oracle.com> <56439D48.5000105@oracle.com> <1447320920.2312.29.camel@oracle.com> <1448536437.2100.27.camel@oracle.com> Message-ID: <1DC292EE-6A66-4C82-A7C9-C0572B73B4A9@oracle.com> On Nov 26, 2015, at 6:13 AM, Thomas Schatzl wrote: > > Hi, > > On Wed, 2015-11-25 at 17:34 -0500, Kim Barrett wrote: >> On Nov 12, 2015, at 4:35 AM, Thomas Schatzl wrote: >>> >>> - FreeIdSet::set_safepoint() seems to be never called. I think it >>> allows you to remove a *lot* of unused stuff. >> >> Perhaps the bug here is that there should be calls to set_safepoint but they are missing? >> > > apparently the functionality is not needed, that is, it has not even > been in use in the initial integration of G1 (and it has been added in > that change). > > So I suggest to just remove it and everything that depended on it > instead of trying to find out what this functionality may have been used > for. Or this could be a "been there forever" latency bug. Consider a situation where concurrent refinement is significantly into the red zone, e.g. lots of mutator threads have decided they need to refine their own DCQ because concurrent refinement is significantly behind. Each of those mutator threads attempts to allocate a pseudo-worker_id from the FreeIdSet. If there are many such threads, some of them will block, waiting for a free id. Now we attempt to enter a safepoint. Not only do we now wait for all the mutator threads that are actively processing buffers to complete and move on to a safepoint check somewhere, but we also need to wait for the threads that were waiting for a free id. The set_safepoint function pretty clearly exists to cancel the latter delay. However, I wonder if a better approach might not be to change the mutex used for that free id allocation to be a safpoint checking mutex. [I think that would require an additional mutex for DCQS to protect its FreeIdSet, since presently the same mutex is used to protect the completed buffer list, and that gets called from GC worker threads, so can't check for safepoint.] However, given that we've apparently never had any callers of set_safepoint, it is perhaps OK to go ahead and remove it, and have additional followups to look into the various issues mentioned here. Note: This whole FreeIdSet thing seems like a whole lot of complex mechanism for what it accomplishes. There is presently one user of this facility, DirtyCardQueueSet::mut_process_buffer. It is used there to associate a pseudo-worker_id with a mutator (Java) thread that is going to process a dirty card buffer. That pseudo-worker_id is passed down through several layers of API until it reaches FromCardCache::contains_or_replace, where it is used as an index into a per-worker cache array. The FromCardCache has to be sized to account for both the actual worker threads and the (one and only) FreeIdSet associated with mut_process_buffer. For further followup, I think JavaThread::_claimed_par_id and the associated getter/setter are not needed. The only place they are used is where mut_process_buffer checks for the thread already having an id and only allocating one if it doesn't. But that's the only place where one gets allocated and assigned, and its always released on the way out. And mut_process_buffer never recursively calls itself. As a result, the check for an already assigned worker_id will never succeed. So the whole _claimed_par_id mechanism appears to be a waste of time and space. And while the thread field is named similarly to the FreeIdSet accessor (claim_par_id), there cannot be multiple FreeIdSets associated with the thread field. If I recall correctly, DirtyCardQueueSet is a singleton, and could be an AllStatic with a bit of work. Given that it is the only client of FreeIdSet, the latter's support for multiple sets is also unnecessary. And given there are no other clients of FreeIdSet, maybe that class should be an internal detail of DirtyCardQueueSet. From kim.barrett at oracle.com Wed Dec 2 01:23:53 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Dec 2015 20:23:53 -0500 Subject: Request for code review - JDK-8141123 Change int's to size_t in FreeIdSet In-Reply-To: <1DC292EE-6A66-4C82-A7C9-C0572B73B4A9@oracle.com> References: <5627EB64.1070704@oracle.com> <5640D3F2.3080601@oracle.com> <56439D48.5000105@oracle.com> <1447320920.2312.29.camel@oracle.com> <1448536437.2100.27.camel@oracle.com> <1DC292EE-6A66-4C82-A7C9-C0572B73B4A9@oracle.com> Message-ID: <8A457709-F9F0-439B-A46D-75C3808AE3F8@oracle.com> On Dec 1, 2015, at 6:45 PM, Kim Barrett wrote: > > However, given that we've apparently never had any callers of > set_safepoint, it is perhaps OK to go ahead and remove it, and have > additional followups to look into the various issues mentioned here. Yet more problems with the existing code. A FreeIdSet is constructed with a pointer to a Monitor, which is used to protect it. The Monitor that is provided for the FreeIdSet used by DirtyCardQueueSet is the Shared_DirtyCardQ_lock, which is actually a Mutex. Mutex doesn't support notify_all and wait, both of which are used by FreeIdSet. If enough threads attempt to allocate an id (in mut_process_buffer) that some will wait, the wait in claim_par_id and the associated notify_all in release_par_id will accidentally work, because Mutex is weirdly derived from Monitor rather than the other way around or some other arrangement, so that the Mutex* gets implicitly converted to a Monitor*, thereby slicing off Mutex::notify_all and Mutex::wait and instead using the Monitor functions. From kim.barrett at oracle.com Wed Dec 2 01:33:35 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Dec 2015 20:33:35 -0500 Subject: Request for code review - JDK-8141123 Change int's to size_t in FreeIdSet In-Reply-To: <8A457709-F9F0-439B-A46D-75C3808AE3F8@oracle.com> References: <5627EB64.1070704@oracle.com> <5640D3F2.3080601@oracle.com> <56439D48.5000105@oracle.com> <1447320920.2312.29.camel@oracle.com> <1448536437.2100.27.camel@oracle.com> <1DC292EE-6A66-4C82-A7C9-C0572B73B4A9@oracle.com> <8A457709-F9F0-439B-A46D-75C3808AE3F8@oracle.com> Message-ID: <8203D8D5-E389-41B9-A126-23F02ABE07C1@oracle.com> On Dec 1, 2015, at 8:23 PM, Kim Barrett wrote: > > On Dec 1, 2015, at 6:45 PM, Kim Barrett wrote: >> >> However, given that we've apparently never had any callers of >> set_safepoint, it is perhaps OK to go ahead and remove it, and have >> additional followups to look into the various issues mentioned here. > > Yet more problems with the existing code. > > A FreeIdSet is constructed with a pointer to a Monitor, which is used > to protect it. The Monitor that is provided for the FreeIdSet used by > DirtyCardQueueSet is the Shared_DirtyCardQ_lock, which is actually a > Mutex. No, I take this back. Wrong lock? From kim.barrett at oracle.com Wed Dec 2 01:54:15 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Dec 2015 20:54:15 -0500 Subject: Request for code review - JDK-8141123 Change int's to size_t in FreeIdSet In-Reply-To: <1DC292EE-6A66-4C82-A7C9-C0572B73B4A9@oracle.com> References: <5627EB64.1070704@oracle.com> <5640D3F2.3080601@oracle.com> <56439D48.5000105@oracle.com> <1447320920.2312.29.camel@oracle.com> <1448536437.2100.27.camel@oracle.com> <1DC292EE-6A66-4C82-A7C9-C0572B73B4A9@oracle.com> Message-ID: <4FB849E9-164A-4C23-BC9D-64748D4E021C@oracle.com> On Dec 1, 2015, at 6:45 PM, Kim Barrett wrote: > > If I recall correctly, DirtyCardQueueSet is a singleton, No, that?s the SATBMarkQueueSet. I think there are two DirtyCardQueueSets. Each of them has it?s own FreeIdSet. Fortunately, I think only one of those sets ever gets used. From thomas.schatzl at oracle.com Wed Dec 2 08:35:49 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 02 Dec 2015 09:35:49 +0100 Subject: Request for code review - JDK-8141123 Change int's to size_t in FreeIdSet In-Reply-To: <1DC292EE-6A66-4C82-A7C9-C0572B73B4A9@oracle.com> References: <5627EB64.1070704@oracle.com> <5640D3F2.3080601@oracle.com> <56439D48.5000105@oracle.com> <1447320920.2312.29.camel@oracle.com> <1448536437.2100.27.camel@oracle.com> <1DC292EE-6A66-4C82-A7C9-C0572B73B4A9@oracle.com> Message-ID: <1449045349.2642.14.camel@oracle.com> Hi, On Tue, 2015-12-01 at 18:45 -0500, Kim Barrett wrote: > On Nov 26, 2015, at 6:13 AM, Thomas Schatzl wrote: > > > > Hi, > > > > On Wed, 2015-11-25 at 17:34 -0500, Kim Barrett wrote: > >> On Nov 12, 2015, at 4:35 AM, Thomas Schatzl wrote: > >>> > >>> - FreeIdSet::set_safepoint() seems to be never called. I think it > >>> allows you to remove a *lot* of unused stuff. > >> > >> Perhaps the bug here is that there should be calls to set_safepoint but they are missing? > >> > > > > apparently the functionality is not needed, that is, it has not even > > been in use in the initial integration of G1 (and it has been added in > > that change). > > > > So I suggest to just remove it and everything that depended on it > > instead of trying to find out what this functionality may have been used > > for. > > Or this could be a "been there forever" latency bug. > > Consider a situation where concurrent refinement is significantly into > the red zone, e.g. lots of mutator threads have decided they need to > refine their own DCQ because concurrent refinement is significantly > behind. Each of those mutator threads attempts to allocate a > pseudo-worker_id from the FreeIdSet. If there are many such threads, > some of them will block, waiting for a free id. Now we attempt to > enter a safepoint. Not only do we now wait for all the mutator > threads that are actively processing buffers to complete and move on > to a safepoint check somewhere, but we also need to wait for the > threads that were waiting for a free id. The set_safepoint function > pretty clearly exists to cancel the latter delay. However, I wonder > if a better approach might not be to change the mutex used for that > free id allocation to be a safpoint checking mutex. [I think that > would require an additional mutex for DCQS to protect its FreeIdSet, > since presently the same mutex is used to protect the completed buffer > list, and that gets called from GC worker threads, so can't check for > safepoint.] > > However, given that we've apparently never had any callers of > set_safepoint, it is perhaps OK to go ahead and remove it, and have > additional followups to look into the various issues mentioned here. > > Note: This whole FreeIdSet thing seems like a whole lot of complex > mechanism for what it accomplishes. There is presently one user of > this facility, DirtyCardQueueSet::mut_process_buffer. It is used > there to associate a pseudo-worker_id with a mutator (Java) thread > that is going to process a dirty card buffer. That pseudo-worker_id > is passed down through several layers of API until it reaches > FromCardCache::contains_or_replace, where it is used as an index into > a per-worker cache array. The FromCardCache has to be sized to > account for both the actual worker threads and the (one and only) > FreeIdSet associated with mut_process_buffer. > > For further followup, I think JavaThread::_claimed_par_id and the > associated getter/setter are not needed. The only place they are used > is where mut_process_buffer checks for the thread already having an id > and only allocating one if it doesn't. But that's the only place > where one gets allocated and assigned, and its always released on the > way out. And mut_process_buffer never recursively calls itself. As a > result, the check for an already assigned worker_id will never > succeed. So the whole _claimed_par_id mechanism appears to be a waste > of time and space. And while the thread field is named similarly to > the FreeIdSet accessor (claim_par_id), there cannot be multiple > FreeIdSets associated with the thread field. > > If I recall correctly, DirtyCardQueueSet is a singleton, and could be > an AllStatic with a bit of work. Given that it is the only client of > FreeIdSet, the latter's support for multiple sets is also unnecessary. > And given there are no other clients of FreeIdSet, maybe that class > should be an internal detail of DirtyCardQueueSet. > ... and reading through all this investigation, actually I think the whole FreeIdSet is unnecessary. The mutator thread could just take any random valid thread id and the FromCardCache would still work (although at reduced efficiency, but that is the case in that situation already anyway). Ideally there would be some small extra cache, or we just do not use the cache in this situation which seems a reasonable option too (or let all mutators use a single equal extra id), to not thrash the FromCardCache of the refinement threads. I am leaving it to Alex and you to decide whether you want this cleanup as an intermediate step, or go for a full cleanup. Thanks, Thomas From bengt.rutisson at oracle.com Wed Dec 2 09:00:08 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 02 Dec 2015 10:00:08 +0100 Subject: RFR (M): JDK-8068394: Trace event for concurrent GC phases In-Reply-To: <5654B10E.1060701@oracle.com> References: <56282271.5090108@oracle.com> <56546233.20006@oracle.com> <5654B10E.1060701@oracle.com> Message-ID: <565EB318.8060607@oracle.com> Hi Sangheon, Sorry again for the late reply. Comments inline. On 2015-11-24 19:48, sangheon.kim wrote: > Hi Bengt, > > Thank you so much for reviewing this patch! > > On 11/24/2015 05:12 AM, Bengt Rutisson wrote: >> >> Hi Sangheon, >> >> Sorry for the very late reply to this review request. >> >> On 2015-10-22 01:40, sangheon.kim wrote: >>> Hi all, >>> >>> Can I get some reviews for this change of adding a trace event for >>> concurrent phases on CMS and G1? >>> >>> Currently we only measure pause times for major phases. >>> But I want to add 'concurrent mark' and 'concurrent sweep' phases >>> for CMS and 'concurrent mark' phase for G1. >>> To achieve this, I had to change ConcurrentGCTimer and related classes. >>> >>> This patch includes: >>> 1) A concurrent phase can be measured only from ConcurrentGCTimer >>> and measuring an overlap between concurrent and pause is not allowed >>> as currently we don't have that use case. And TimePartitions >>> class(or related classes) will be simpler than an overlap allowed case. >>> 2) I removed PausePhase and ConcurrentPhase which are derived from >>> GCPhase because I wanted to avoid heap allocation when adding to >>> GrowableArray. Instead introduced 'type' member variable at GCPhase. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8068394 >>> Webrev: http://cr.openjdk.java.net/~sangheki/8068394/webrev.00/ >> >> Nice work! It is great to get some timing information for the >> concurrent phases. > Thanks! > >> >> A few questions/comments: >> >> CMS. >> >> You have added timing events for the concurrent phases mark and >> sweep, but not for other concurrent phases (preclean, >> abortable_preclean and reset_concurrent). I think that if you moved >> your calls to _gc_timer_cm->register_gc_concurrent_start() and >> _gc_timer_cm->register_gc_concurrent_end() into the constructor and >> destructor of CMSPhaseAccounting you would automatically get timing >> events for all concurrent phases. > I also considered about this idea but I was not clear whether it is > good measurement especially for 'sweep'. > We are using CMSPhaseAccounting for 5 cases. > I think for 'mark' and 'preclean' they are okay. (there are > non-product functions call before CMSPhaseAccounting. But they are okay). > For 'abortable-preclean' and 'reset', they are good to have that. > But when it comes to 'sweep', there are timer and > CMSTokenSyncWithLocks related codes and I was not sure about these. > If you think they are also okay, I will change as you suggested. I think it is fine for the sweep part as well. If the CMSPhaseAccounting instance is not measuring the correct part of the work I think we should change it to measure what we want. That way we improve the existing measurements too. But as you stated in your follow up email, I think the sweep code is actually pretty much ok from this perspective. So, I would prefer to go with the CMSPhaseAccounting approach. > >> >> >> G1. >> >> I think the use of _concurrent_marking_from_roots is unfortunate. It >> would be much cleaner if >> ConcurrentMark::register_mark_from_roots_phase_end() called >> register_gc_concurrent_end() directly. > I wanted to avoid introducing the new flag but the reason of it was, > as you know, to handle 'abort'. > When 'abort' happens we do need to end all timers before calling > 'GCTracer::report_gc_end()'. > And at this point we need a way to know whether concurrent timer is > started or not. As I tried to describe I think you can extend the scope of the timing to cover the part until the marking thread discovers that the marking was aborted. Basically moving the timing in to ConcurrentMarkThread::run_service(). > >> I realize that this would change the timing for when a concurrent >> marking is aborted. The whole time for a full GC (or even several >> full GCs) would be included in the concurrent marking phase. But from >> a code perspective that is what happens, so maybe that is the correct >> time to report? Also, I think the logging is reported that way so if >> we want to make it easy to match the timing events with the logging >> we might want to use about the same scope for timing. >> >> Why do we only measure the concurrent mark phase for G1? > This is good question. :) > I was comparing CMS and G1 for major concurrent phases. > And the candidates were 'concurrent mark/sweep (CMS)' and 'concurrent > mark(G1)'. > >> Wouldn't it be good to measure all concurrent phases? > Okay, Stefan Karlsson also pointed to have them as well so I filed a > separate CR for this. > https://bugs.openjdk.java.net/browse/JDK-8143951 Ok. Is there a reason why we want to split this up into two changes? Why not add all the concurrent timing events at once? I'm ok with splitting it up into two changes, but then maybe the title for JDK-8068394 should be changed to indicate that it only adds events for the marking phase. Also, if we go with the CMSPhaseAccounting approach for CMS, you get events for all phases there. So, it will be a bit odd to have all concurrent phases handled for CMS but only concurrent mark for G1. > >> >> gcTraceSend.cpp >> >> 389 void visit(GCPhase* phase) { >> 390 switch (phase->type()) { >> 391 case GCPhase::PausePhaseType: >> 392 assert(phase->level() < PhasesStack::PHASE_LEVELS, "Need >> more event types for PausePhase"); >> 393 >> 394 switch (phase->level()) { >> 395 case 0: send_phase(phase); break; >> 396 case 1: send_phase(phase); >> break; >> 397 case 2: send_phase(phase); >> break; >> 398 case 3: send_phase(phase); >> break; >> 399 default: /* Ignore sending this phase */ break; >> 400 } >> 401 break; >> 402 >> 403 case GCPhase::ConcurrentPhaseType: >> 404 assert(phase->level() < 1, "There's only one level for >> ConcurrentPhase"); >> 405 >> 406 switch (phase->level()) { >> 407 case 0: send_phase(phase); break; >> 408 default: /* Ignore sending this phase */ break; >> 409 } >> 410 break; >> 411 } >> 412 } >> 413 }; >> >> Since there are only two values for GCPhase::PhaseType it seems a bit >> odd to use a switch statement. I think I would prefer to factor out >> the code for the different types a bit too. So, maybe something like: >> >> void visit(GCPhase* phase) { >> if (phase->type() == GCPhase::PausePhaseType) { >> visit_pause(phase); >> } else { >> assert(phase->type() == GCPhase::ConcurrentPhaseType, ""); >> visit_concurrent(phase); >> } >> } > This seems better. I will fix. Good. Thanks! Bengt > > Thanks, > Sangheon > > >> >> Thanks, >> Bengt >> >>> Testing: JPRT >>> >>> Thanks, >>> Sangheon >> > From thomas.schatzl at oracle.com Wed Dec 2 11:41:50 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 02 Dec 2015 12:41:50 +0100 Subject: RFR (M): 8060697: Improve G1 Heap Growth Heuristics In-Reply-To: <5653D33D.3090906@oracle.com> References: <5653D33D.3090906@oracle.com> Message-ID: <1449056510.2642.75.camel@oracle.com> Hi Tom, On Mon, 2015-11-23 at 22:02 -0500, Tom Benson wrote: > Hi, > Here is a proposed change to the G1 heap growth code for review. I've > added a detailed description to the CR, but here is the short version: > After a GC pause, the average ratio of time spent in recent GC pauses vs > overall time is computed. If it exceeds GCTimeRatio, the heap is > expanded by a fixed amount. With the new code, some deficiencies in the > ratio tracking are addressed, and the expansion size is scaled according > to how much the desired ratio is, on average, exceeded by. The target > ratio itself is also scaled at the lowest heap sizes. > > The case that triggered this was actually JDK-8132077, where the JVM'08 > Compress benchmark saw a 40% degradation. It was due to the heap being > about half the size in some runs, because of the way heap growth worked. > > I'm still collecting the final performance data for this version, and > will attach it to the CR. Earlier experimental versions showed good > improvements in consistency of heap sizes. A couple of benchmarks > average a percentage point or two lower, while others improve by that > much or more. No growth percentage or scaling is going to be ideal for > every test, but the goal was to maintain performance without growing too > large. In fact, some tests now use much smaller heaps. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8060697 > Webrev: > http://cr.openjdk.java.net/~tbenson/8060697/webrev/ > > Testing: Some potential improvements: - maybe extract the "_ratio_check_window_count == NumPrevPausesForHeuristics" term to a meaningful local variable to improve readability. E.g. max_window_samples_reached or something. Or add a new constant in that enum for that bound (MaxExpansionCheckWindowCount or whatever) so that it becomes clear(er) what this term is used for. - of the new member variables, it would be nice to document that _ratio_over_threshold* is about tracking exceeding the threshold short term, and _ratio_check_window_count about "long term". Maybe actually including "short" or "long"-term or "burst" words in the names. That would probably make it more clear why the value for MinOverThresholdForGrowth has been chosen to be smaller than NumPrevPausesForHeuristics (used for exceeding the threshold "long-term"). - the G1CollectorPolicy constructor may also call clear_ratio_check_data() instead of manually resetting in the initializer list. - I would prefer if _last_pause_time_ratio and its calculation were documented better. In the answer to Jon in the other email you clearly described why the _last_pause_time_ratio is calculated as it is. That is missing somewhere. // Compute the ratio of just this last pause time to the entire time // range stored in the vectors. Seems to mostly repeat what the code does. - the last_pause_time_ratio() getter seems to be superfluous as nobody from outside G1CollectorPolicy accesses it. Looks good otherwise. Thanks, Thomas From thomas.schatzl at oracle.com Wed Dec 2 12:00:51 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 02 Dec 2015 13:00:51 +0100 Subject: RFR (M): 8060697: Improve G1 Heap Growth Heuristics In-Reply-To: <1449056510.2642.75.camel@oracle.com> References: <5653D33D.3090906@oracle.com> <1449056510.2642.75.camel@oracle.com> Message-ID: <1449057651.2642.86.camel@oracle.com> Hi again, another comment: do you mind changing the early return in g1CollectorPolicy.cpp:1614 to an assignment to some kind of result-variable (e.g. expand_bytes initialized to zero), and add the remainder of that method in an else-block? The new expansion_amount() method seems to have grown significantly in size, and I am actually not really happy with that. Particularly I am not really fond of early return in large methods (i.e. I think some hidden request to look at possibilities to split that method into useful parts, try to separate out conditions etc). However, if you like it better the current way, that would be fine with me too. Thanks, Thomas On Wed, 2015-12-02 at 12:41 +0100, Thomas Schatzl wrote: > Hi Tom, > > On Mon, 2015-11-23 at 22:02 -0500, Tom Benson wrote: > > Hi, > > Here is a proposed change to the G1 heap growth code for review. I've > > added a detailed description to the CR, but here is the short version: > > After a GC pause, the average ratio of time spent in recent GC pauses vs > > overall time is computed. If it exceeds GCTimeRatio, the heap is > > expanded by a fixed amount. With the new code, some deficiencies in the > > ratio tracking are addressed, and the expansion size is scaled according > > to how much the desired ratio is, on average, exceeded by. The target > > ratio itself is also scaled at the lowest heap sizes. > > > > The case that triggered this was actually JDK-8132077, where the JVM'08 > > Compress benchmark saw a 40% degradation. It was due to the heap being > > about half the size in some runs, because of the way heap growth worked. > > > > I'm still collecting the final performance data for this version, and > > will attach it to the CR. Earlier experimental versions showed good > > improvements in consistency of heap sizes. A couple of benchmarks > > average a percentage point or two lower, while others improve by that > > much or more. No growth percentage or scaling is going to be ideal for > > every test, but the goal was to maintain performance without growing too > > large. In fact, some tests now use much smaller heaps. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8060697 > > Webrev: > > http://cr.openjdk.java.net/~tbenson/8060697/webrev/ > > > > Testing: > > Some potential improvements: > > - maybe extract the "_ratio_check_window_count == > NumPrevPausesForHeuristics" term to a meaningful local variable to > improve readability. E.g. max_window_samples_reached or something. > > Or add a new constant in that enum for that bound > (MaxExpansionCheckWindowCount or whatever) so that it becomes clear(er) > what this term is used for. > > - of the new member variables, it would be nice to document that > _ratio_over_threshold* is about tracking exceeding the threshold short > term, and _ratio_check_window_count about "long term". > > Maybe actually including "short" or "long"-term or "burst" words in the > names. > > That would probably make it more clear why the value for > MinOverThresholdForGrowth has been chosen to be smaller than > NumPrevPausesForHeuristics (used for exceeding the threshold > "long-term"). > > - the G1CollectorPolicy constructor may also call > clear_ratio_check_data() instead of manually resetting in the > initializer list. > > - I would prefer if _last_pause_time_ratio and its calculation were > documented better. In the answer to Jon in the other email you clearly > described why the _last_pause_time_ratio is calculated as it is. That is > missing somewhere. > > // Compute the ratio of just this last pause time to the entire time > // range stored in the vectors. > > Seems to mostly repeat what the code does. > > - the last_pause_time_ratio() getter seems to be superfluous as nobody > from outside G1CollectorPolicy accesses it. > > Looks good otherwise. sans the "static" variable comment from Kim. Thanks, Thomas From david.lindholm at oracle.com Wed Dec 2 13:07:34 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Wed, 2 Dec 2015 14:07:34 +0100 Subject: RRF: JEP-271: Unified GC Logging In-Reply-To: <565D9C07.2080808@oracle.com> References: <564DEAEB.90703@oracle.com> <56534C0D.3070209@oracle.com> <5655A994.7000304@oracle.com> <5655B0E2.6040009@oracle.com> <565D9C07.2080808@oracle.com> Message-ID: <565EED16.2080607@oracle.com> Hi Bengt, These changes looks good now. Reviewed. /David On 2015-12-01 14:09, Bengt Rutisson wrote: > > Hi everyone, > > Here are updated webrevs that include the comments on the last review > request. > > HotSpot changes: > http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/hotspot-webrev.02/ > > Complete changes: > > Diff compared to last webrev: > http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/hotspot-webrev.01-02.diff/ > > > > JDK changes: > > Complete changes: > http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.02/ > > Diff compared to last webrev: > http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.01-02.diff/ > > > > Except for the comment that were discussed in this email thread there > are a couple of other changes: > > - Most of the implementation parts in gcTraceTime.hpp were moved to > gcTraceTime.inline.hpp. > - New tests and new code that use logging were updated. > - Some tests were changed to use less extensive logging. > - A bug gave duplicate timing for Full GCs when going through > GenCollectedHeap > - The used calculation for G1 old logging could overflow. > - The @ignore tag was added back to TestLogging.java. > > Thanks, > Bengt > > On 2015-11-25 14:00, Bengt Rutisson wrote: >> >> Hi David, >> >> Thanks for looking at this again! >> >> On 2015-11-25 13:29, David Lindholm wrote: >>> Hi Bengt, >>> >>> My code review for the rest of the files: >>> >>> defNewGeneration.cpp: >>> >>> 517-520: Indentation >> >> Fixed. >> >>> 766: Shouldn't the tags be "gc, promotion"? >> >> Yes. Fixed. >> >>> >>> collectorPolicy.cpp: >>> >>> 489: Shouldn't the tags be "gc, heap"? >> >> Yes, fixed. >> >>> >>> genCollectedHeap.cpp: >>> >>> 1150+1152: Indentation >>> >>> generation.cpp: >>> >>> 162: Indentation >> >> Fixed. >> >>> >>> plab.cpp: >>> >>> 153: Plab_size = " SIZE_FORMAT " desired_net_plab_sz = " SIZE_FORMAT >>> ": Why the capital P in this printout of one variable name but not >>> the other? I think it should be consistent. >> >> Agreed. Fixed. >> >> >>> >>> referenceProcessor.cpp: >>> >>> 515: Indentation >>> >>> referenceProcessor.cpp: >>> >>> 948+953: Indentation >>> >>> metaspace.cpp: >>> >>> 1505: Indentation >>> 1578+1580: Indentation >>> 2695: Indentation >>> >>> runtimeService.cpp: >>> >>> 123-124: Indentation >> >> Fixed. >> >> Thanks, >> Bengt >> >>> >>> >>> Thanks, >>> David >>> >>> On 2015-11-23 18:25, Bengt Rutisson wrote: >>>> >>>> Hi everyone, >>>> >>>> Here is an updated webrev based on the comments from the first >>>> review. The changes that have been discussed have only been to the >>>> hotspot repo: >>>> >>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.01/ >>>> >>>> The changes to the JDK repo are the same as in the first webrev: >>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/jdk-webrev.00/ >>>> >>>> >>>> Some partial diffs to make it easier for those who already looked >>>> at the first webrev. >>>> >>>> The unified logging framework was changed in the way it handles the >>>> develop logging. Here are the changes I had to do to accommodate >>>> the new develop logging: >>>> >>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.01-develop-logging >>>> >>>> >>>> Here are the changes I have made to address comments in the code >>>> (based on top of the develop logging changes): >>>> >>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.00-01-code-diff >>>> >>>> >>>> And here are the changes that David has made to address comment in >>>> the tests: >>>> >>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.00-01-test-diff >>>> >>>> >>>> Enjoy! >>>> Bengt >>>> >>>> On 2015-11-19 16:29, Bengt Rutisson wrote: >>>>> >>>>> Hi everyone, >>>>> >>>>> After three pre-reviews it is time for the fist official review >>>>> request for JEP-271 Unified GC Logging. >>>>> >>>>> http://openjdk.java.net/jeps/271 >>>>> >>>>> Most code changes are in the hotspot code: >>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/webrev.00/ >>>>> >>>>> Some tests in the JDK repo have been updated: >>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/jdk-webrev.00/ >>>>> >>>>> As with the pre-reviews I have put togther some examples of what >>>>> the new logging looks like: >>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/compare.html >>>>> >>>>> The intent is that this should cover the bulk of the logging >>>>> changes. There will most definitely be some follow up changes >>>>> where we fix details in the log messages etc. >>>>> >>>>> Among many other old logging flags this changeset removes the two >>>>> flags PringGC and PrintGCDetails. These two will be added back >>>>> with a follow up changeset, but when they are added back they will >>>>> be marked as deprecated. >>>>> >>>>> The reason for first removing them and then adding them back is to >>>>> get testing without these flags. That way we will know that we >>>>> clean out all usages of these flags from our testing. >>>>> >>>>> Thanks, >>>>> Bengt >>>> >>> >> > From bengt.rutisson at oracle.com Wed Dec 2 13:47:04 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 2 Dec 2015 14:47:04 +0100 Subject: RRF: JEP-271: Unified GC Logging In-Reply-To: <565EED16.2080607@oracle.com> References: <564DEAEB.90703@oracle.com> <56534C0D.3070209@oracle.com> <5655A994.7000304@oracle.com> <5655B0E2.6040009@oracle.com> <565D9C07.2080808@oracle.com> <565EED16.2080607@oracle.com> Message-ID: <565EF658.60507@oracle.com> On 2015-12-02 14:07, David Lindholm wrote: > Hi Bengt, > > These changes looks good now. Reviewed. Thanks for looking at this, David! Bengt > > /David > > On 2015-12-01 14:09, Bengt Rutisson wrote: >> >> Hi everyone, >> >> Here are updated webrevs that include the comments on the last review >> request. >> >> HotSpot changes: >> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/hotspot-webrev.02/ >> >> >> Complete changes: >> >> Diff compared to last webrev: >> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/hotspot-webrev.01-02.diff/ >> >> >> >> JDK changes: >> >> Complete changes: >> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.02/ >> >> Diff compared to last webrev: >> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.01-02.diff/ >> >> >> >> Except for the comment that were discussed in this email thread there >> are a couple of other changes: >> >> - Most of the implementation parts in gcTraceTime.hpp were moved to >> gcTraceTime.inline.hpp. >> - New tests and new code that use logging were updated. >> - Some tests were changed to use less extensive logging. >> - A bug gave duplicate timing for Full GCs when going through >> GenCollectedHeap >> - The used calculation for G1 old logging could overflow. >> - The @ignore tag was added back to TestLogging.java. >> >> Thanks, >> Bengt >> >> On 2015-11-25 14:00, Bengt Rutisson wrote: >>> >>> Hi David, >>> >>> Thanks for looking at this again! >>> >>> On 2015-11-25 13:29, David Lindholm wrote: >>>> Hi Bengt, >>>> >>>> My code review for the rest of the files: >>>> >>>> defNewGeneration.cpp: >>>> >>>> 517-520: Indentation >>> >>> Fixed. >>> >>>> 766: Shouldn't the tags be "gc, promotion"? >>> >>> Yes. Fixed. >>> >>>> >>>> collectorPolicy.cpp: >>>> >>>> 489: Shouldn't the tags be "gc, heap"? >>> >>> Yes, fixed. >>> >>>> >>>> genCollectedHeap.cpp: >>>> >>>> 1150+1152: Indentation >>>> >>>> generation.cpp: >>>> >>>> 162: Indentation >>> >>> Fixed. >>> >>>> >>>> plab.cpp: >>>> >>>> 153: Plab_size = " SIZE_FORMAT " desired_net_plab_sz = " >>>> SIZE_FORMAT ": Why the capital P in this printout of one variable >>>> name but not the other? I think it should be consistent. >>> >>> Agreed. Fixed. >>> >>> >>>> >>>> referenceProcessor.cpp: >>>> >>>> 515: Indentation >>>> >>>> referenceProcessor.cpp: >>>> >>>> 948+953: Indentation >>>> >>>> metaspace.cpp: >>>> >>>> 1505: Indentation >>>> 1578+1580: Indentation >>>> 2695: Indentation >>>> >>>> runtimeService.cpp: >>>> >>>> 123-124: Indentation >>> >>> Fixed. >>> >>> Thanks, >>> Bengt >>> >>>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 2015-11-23 18:25, Bengt Rutisson wrote: >>>>> >>>>> Hi everyone, >>>>> >>>>> Here is an updated webrev based on the comments from the first >>>>> review. The changes that have been discussed have only been to the >>>>> hotspot repo: >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.01/ >>>>> >>>>> The changes to the JDK repo are the same as in the first webrev: >>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/jdk-webrev.00/ >>>>> >>>>> >>>>> Some partial diffs to make it easier for those who already looked >>>>> at the first webrev. >>>>> >>>>> The unified logging framework was changed in the way it handles >>>>> the develop logging. Here are the changes I had to do to >>>>> accommodate the new develop logging: >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.01-develop-logging >>>>> >>>>> >>>>> Here are the changes I have made to address comments in the code >>>>> (based on top of the develop logging changes): >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.00-01-code-diff >>>>> >>>>> >>>>> And here are the changes that David has made to address comment in >>>>> the tests: >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.00-01-test-diff >>>>> >>>>> >>>>> Enjoy! >>>>> Bengt >>>>> >>>>> On 2015-11-19 16:29, Bengt Rutisson wrote: >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> After three pre-reviews it is time for the fist official review >>>>>> request for JEP-271 Unified GC Logging. >>>>>> >>>>>> http://openjdk.java.net/jeps/271 >>>>>> >>>>>> Most code changes are in the hotspot code: >>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/webrev.00/ >>>>>> >>>>>> Some tests in the JDK repo have been updated: >>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/jdk-webrev.00/ >>>>>> >>>>>> >>>>>> As with the pre-reviews I have put togther some examples of what >>>>>> the new logging looks like: >>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/compare.html >>>>>> >>>>>> The intent is that this should cover the bulk of the logging >>>>>> changes. There will most definitely be some follow up changes >>>>>> where we fix details in the log messages etc. >>>>>> >>>>>> Among many other old logging flags this changeset removes the two >>>>>> flags PringGC and PrintGCDetails. These two will be added back >>>>>> with a follow up changeset, but when they are added back they >>>>>> will be marked as deprecated. >>>>>> >>>>>> The reason for first removing them and then adding them back is >>>>>> to get testing without these flags. That way we will know that we >>>>>> clean out all usages of these flags from our testing. >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>> >>>> >>> >> > From jon.masamitsu at oracle.com Wed Dec 2 14:09:23 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 2 Dec 2015 06:09:23 -0800 Subject: RFR (XXS): 8136680: Enable adaptive IHOP by default In-Reply-To: <565C88DD.4080507@oracle.com> References: <1448360063.2100.22.camel@oracle.com> <5654AD7C.8090607@oracle.com> <1448533219.2100.12.camel@oracle.com> <565C88DD.4080507@oracle.com> Message-ID: <565EFB93.4090602@oracle.com> Thomas, Hearing no concerns by others about the naming, your latest changes are still good. Reviewed. Jon On 11/30/2015 9:35 AM, Jon Masamitsu wrote: > > > On 11/26/2015 02:20 AM, Thomas Schatzl wrote: >> Hi Jon, >> >> thanks for the review. >> >> On Tue, 2015-11-24 at 10:33 -0800, Jon Masamitsu wrote: >>> Thomas, Looks good. >>> >>> >>> 36 product(bool, G1UseAdaptiveIHOP, true, \ >>> 37 "Adaptively adjust InitiatingHeapOccupancyPercent >>> from the " \ >>> 38 "initial value. The policy tries to start marking as late as " \ >>> 39 "possible.") >>> >>> Let me suggest an alternate comment though. >>> >>> "Dynamically adjust the initiating heap occupancy from the initial >>> value of >>> InitiatingHeapOccupancyPercent. The policy attempts to start >>> marking in >>> time based on application behavior." >>> >> Much better. Updated webrev at >> http://cr.openjdk.java.net/~tschatzl/8136680/webrev.1/ > > Thanks. > >> >>> Do we need G1 in the name of the flag? Would UseAdaptiveIHOP be >>> sufficient? Or maybe UseDynamicIHOP? Or (I write this with some >>> trepidation) would the flag be better named >>> UseAdaptiveInitiatingHeapOccupancy >>> or UseDynamicInitiatingHeapOccupancy? >>> >> As for Adaptive vs. Dynamic, I think Adaptive captures the spirit of the >> change better. Also I have not seen other similar flags using Dynamic, >> but Adaptive. > > "Adaptive" it is then. > >> >> As for adding "G1" in front of the flag or not, not sure. CMS also has >> its flags prepended with "CMS". Maybe other people have stronger >> opinions about this, I would be okay with either. > > I thought about it because "InitiatingHeapOccupancyPercent" does > have the "G1". But if no one else speaks up on this, leave the "G1" > in the name. > >> >> I also thought about using the long forms, but I think they are too >> long :) > > Ok. I can live with it. > > Reviewed. > > Jon > >>> I'm asking the question now because I don't want to ask it the next >>> time >>> we do a cleanup of flag names. I can live with any of the above. >> Thanks, >> Thomas >> >> > From thomas.schatzl at oracle.com Wed Dec 2 14:21:44 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 02 Dec 2015 15:21:44 +0100 Subject: RFR (XXS): 8136680: Enable adaptive IHOP by default In-Reply-To: <565EFB93.4090602@oracle.com> References: <1448360063.2100.22.camel@oracle.com> <5654AD7C.8090607@oracle.com> <1448533219.2100.12.camel@oracle.com> <565C88DD.4080507@oracle.com> <565EFB93.4090602@oracle.com> Message-ID: <1449066104.2642.96.camel@oracle.com> Hi Jon, On Wed, 2015-12-02 at 06:09 -0800, Jon Masamitsu wrote: > Thomas, > > Hearing no concerns by others about the naming, > your latest changes are still good. > > Reviewed. > thanks. Since I have the "go" from SQE for integration of this change I will do so tomorrow as is unless somebody objects. Thanks, Thomas From mikael.gerdin at oracle.com Wed Dec 2 14:23:54 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 2 Dec 2015 15:23:54 +0100 Subject: RFR (XXS): 8136680: Enable adaptive IHOP by default In-Reply-To: <1449066104.2642.96.camel@oracle.com> References: <1448360063.2100.22.camel@oracle.com> <5654AD7C.8090607@oracle.com> <1448533219.2100.12.camel@oracle.com> <565C88DD.4080507@oracle.com> <565EFB93.4090602@oracle.com> <1449066104.2642.96.camel@oracle.com> Message-ID: <565EFEFA.7@oracle.com> On 2015-12-02 15:21, Thomas Schatzl wrote: > Hi Jon, > > On Wed, 2015-12-02 at 06:09 -0800, Jon Masamitsu wrote: >> Thomas, >> >> Hearing no concerns by others about the naming, >> your latest changes are still good. >> >> Reviewed. >> > > thanks. Since I have the "go" from SQE for integration of this change > I will do so tomorrow as is unless somebody objects. Sounds good. /Mikael > > Thanks, > Thomas > > From erik.helin at oracle.com Wed Dec 2 14:25:43 2015 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 2 Dec 2015 15:25:43 +0100 Subject: RFR (XXS): 8136680: Enable adaptive IHOP by default In-Reply-To: <565EFEFA.7@oracle.com> References: <1448360063.2100.22.camel@oracle.com> <5654AD7C.8090607@oracle.com> <1448533219.2100.12.camel@oracle.com> <565C88DD.4080507@oracle.com> <565EFB93.4090602@oracle.com> <1449066104.2642.96.camel@oracle.com> <565EFEFA.7@oracle.com> Message-ID: <20151202142543.GF2920@ehelin.jrpg.bea.com> On 2015-12-02, Mikael Gerdin wrote: > On 2015-12-02 15:21, Thomas Schatzl wrote: > >Hi Jon, > > > >On Wed, 2015-12-02 at 06:09 -0800, Jon Masamitsu wrote: > >>Thomas, > >> > >>Hearing no concerns by others about the naming, > >>your latest changes are still good. > >> > >>Reviewed. > >> > > > > thanks. Since I have the "go" from SQE for integration of this change > >I will do so tomorrow as is unless somebody objects. > > Sounds good. Looks good to me as well. Thanks, Erik > /Mikael > > > > >Thanks, > > Thomas > > > > > From kirk.pepperdine at gmail.com Wed Dec 2 15:13:11 2015 From: kirk.pepperdine at gmail.com (kirk.pepperdine at gmail.com) Date: Wed, 2 Dec 2015 16:13:11 +0100 Subject: RRF: JEP-271: Unified GC Logging In-Reply-To: <565EF658.60507@oracle.com> References: <564DEAEB.90703@oracle.com> <56534C0D.3070209@oracle.com> <5655A994.7000304@oracle.com> <5655B0E2.6040009@oracle.com> <565D9C07.2080808@oracle.com> <565EED16.2080607@oracle.com> <565EF658.60507@oracle.com> Message-ID: Hi, I?m surprised that -Xmx512m is still being used here given that -mx is the fully supported method of specifying max heap size. Regards, Kirk > On Dec 2, 2015, at 2:47 PM, Bengt Rutisson wrote: > > > > On 2015-12-02 14:07, David Lindholm wrote: >> Hi Bengt, >> >> These changes looks good now. Reviewed. > > > Thanks for looking at this, David! > > Bengt > >> >> /David >> >> On 2015-12-01 14:09, Bengt Rutisson wrote: >>> >>> Hi everyone, >>> >>> Here are updated webrevs that include the comments on the last review request. >>> >>> HotSpot changes: >>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/hotspot-webrev.02/ >>> >>> Complete changes: >>> >>> Diff compared to last webrev: >>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/hotspot-webrev.01-02.diff/ >>> >>> >>> JDK changes: >>> >>> Complete changes: >>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.02/ >>> >>> Diff compared to last webrev: >>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.01-02.diff/ >>> >>> >>> Except for the comment that were discussed in this email thread there are a couple of other changes: >>> >>> - Most of the implementation parts in gcTraceTime.hpp were moved to gcTraceTime.inline.hpp. >>> - New tests and new code that use logging were updated. >>> - Some tests were changed to use less extensive logging. >>> - A bug gave duplicate timing for Full GCs when going through GenCollectedHeap >>> - The used calculation for G1 old logging could overflow. >>> - The @ignore tag was added back to TestLogging.java. >>> >>> Thanks, >>> Bengt >>> >>> On 2015-11-25 14:00, Bengt Rutisson wrote: >>>> >>>> Hi David, >>>> >>>> Thanks for looking at this again! >>>> >>>> On 2015-11-25 13:29, David Lindholm wrote: >>>>> Hi Bengt, >>>>> >>>>> My code review for the rest of the files: >>>>> >>>>> defNewGeneration.cpp: >>>>> >>>>> 517-520: Indentation >>>> >>>> Fixed. >>>> >>>>> 766: Shouldn't the tags be "gc, promotion"? >>>> >>>> Yes. Fixed. >>>> >>>>> >>>>> collectorPolicy.cpp: >>>>> >>>>> 489: Shouldn't the tags be "gc, heap"? >>>> >>>> Yes, fixed. >>>> >>>>> >>>>> genCollectedHeap.cpp: >>>>> >>>>> 1150+1152: Indentation >>>>> >>>>> generation.cpp: >>>>> >>>>> 162: Indentation >>>> >>>> Fixed. >>>> >>>>> >>>>> plab.cpp: >>>>> >>>>> 153: Plab_size = " SIZE_FORMAT " desired_net_plab_sz = " SIZE_FORMAT ": Why the capital P in this printout of one variable name but not the other? I think it should be consistent. >>>> >>>> Agreed. Fixed. >>>> >>>> >>>>> >>>>> referenceProcessor.cpp: >>>>> >>>>> 515: Indentation >>>>> >>>>> referenceProcessor.cpp: >>>>> >>>>> 948+953: Indentation >>>>> >>>>> metaspace.cpp: >>>>> >>>>> 1505: Indentation >>>>> 1578+1580: Indentation >>>>> 2695: Indentation >>>>> >>>>> runtimeService.cpp: >>>>> >>>>> 123-124: Indentation >>>> >>>> Fixed. >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 2015-11-23 18:25, Bengt Rutisson wrote: >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> Here is an updated webrev based on the comments from the first review. The changes that have been discussed have only been to the hotspot repo: >>>>>> >>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.01/ >>>>>> >>>>>> The changes to the JDK repo are the same as in the first webrev: >>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/jdk-webrev.00/ >>>>>> >>>>>> >>>>>> Some partial diffs to make it easier for those who already looked at the first webrev. >>>>>> >>>>>> The unified logging framework was changed in the way it handles the develop logging. Here are the changes I had to do to accommodate the new develop logging: >>>>>> >>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.01-develop-logging >>>>>> >>>>>> Here are the changes I have made to address comments in the code (based on top of the develop logging changes): >>>>>> >>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.00-01-code-diff >>>>>> >>>>>> And here are the changes that David has made to address comment in the tests: >>>>>> >>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.00-01-test-diff >>>>>> >>>>>> Enjoy! >>>>>> Bengt >>>>>> >>>>>> On 2015-11-19 16:29, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> After three pre-reviews it is time for the fist official review request for JEP-271 Unified GC Logging. >>>>>>> >>>>>>> http://openjdk.java.net/jeps/271 >>>>>>> >>>>>>> Most code changes are in the hotspot code: >>>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/webrev.00/ >>>>>>> >>>>>>> Some tests in the JDK repo have been updated: >>>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/jdk-webrev.00/ >>>>>>> >>>>>>> As with the pre-reviews I have put togther some examples of what the new logging looks like: >>>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/compare.html >>>>>>> >>>>>>> The intent is that this should cover the bulk of the logging changes. There will most definitely be some follow up changes where we fix details in the log messages etc. >>>>>>> >>>>>>> Among many other old logging flags this changeset removes the two flags PringGC and PrintGCDetails. These two will be added back with a follow up changeset, but when they are added back they will be marked as deprecated. >>>>>>> >>>>>>> The reason for first removing them and then adding them back is to get testing without these flags. That way we will know that we clean out all usages of these flags from our testing. >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.johansson at oracle.com Wed Dec 2 15:23:50 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 2 Dec 2015 16:23:50 +0100 Subject: RFR: 8144486: Change G1UpdateRSOrPushRefOopClosure to inherit OopClosure Message-ID: <565F0D06.4010405@oracle.com> Hi, Please review this change for: https://bugs.openjdk.java.net/browse/JDK-8144486 Webrev: http://cr.openjdk.java.net/~sjohanss/8138888/8144486/hotspot.00/ Background: When iterating objects with oop_iterate() there is a special case for InstanceRefKlass, if the closure overrides apply_to_weak_ref_discovered_field() to return true, the closure will be applied to the discovered field, even if the normal checks prevents it. This special treatment is needed in certain situations, but it is not obvious if it should be done when iterating the object. Currently only G1 closures override apply_to_weak_ref_discovered_field() and many of them seem to do it without any reason. My initial plan [1] was to remove all usage of this special casing but after discussions I realized it would be easier to see the effects if doing this one closure at a time. Summary: This change is for G1UpdateRSOrPushRefOopClosure which is never used with oop_iterate and therefore does not need to override apply_to_weak_ref_discovered_field(). There is also no need to inherit ExtendedOopClosure, so it's changed to inherit OopClosure instead. Testing: * JPRT * RBT Thanks, Stefan [1] https://bugs.openjdk.java.net/browse/JDK-8138888 From stefan.johansson at oracle.com Wed Dec 2 15:55:01 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 2 Dec 2015 16:55:01 +0100 Subject: RFR: 8144505: Change G1ParCopyHelper to inherit OopClosure Message-ID: <565F1455.50809@oracle.com> Hi, Please review this change for: https://bugs.openjdk.java.net/browse/JDK-8144505 Webrev: http://cr.openjdk.java.net/~sjohanss/8138888/8144505/hotspot.00/ Background: When iterating objects with oop_iterate() there is a special case for InstanceRefKlass, if the closure overrides apply_to_weak_ref_discovered_field() to return true, the closure will be applied to the discovered field, even if the normal checks prevents it. This special treatment is needed in certain situations, but it is not obvious if it should be done when iterating the object. Currently only G1 closures override apply_to_weak_ref_discovered_field() and many of them seem to do it without any reason. My initial plan [1] was to remove all usage of this special casing but after discussions I realized it would be easier to see the effects if doing this one closure at a time. Summary: G1ParCopyClosure is only used as a normal OopClosure. It inherits from G1ParCopyHelper which in turn inherits G1ParClosureSuper. G1ParClosureSuper overrides apply_to_weak_ref_discovered_field() to return true but since G1ParCopyClosure is never used with oop_iterate() it doesn't need to inherit this functionality. G1ParCopyHelper can instead be changed to inherit directly from OopClosure, and this way we have one closure less depending on apply_to_weak_ref_discovered_field(). Testing: * JPRT * RBT Thanks, Stefan [1] https://bugs.openjdk.java.net/browse/JDK-8138888 From mikael.gerdin at oracle.com Wed Dec 2 16:01:05 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 2 Dec 2015 17:01:05 +0100 Subject: RFR: 8144486: Change G1UpdateRSOrPushRefOopClosure to inherit OopClosure In-Reply-To: <565F0D06.4010405@oracle.com> References: <565F0D06.4010405@oracle.com> Message-ID: <565F15C1.6040002@oracle.com> On 2015-12-02 16:23, Stefan Johansson wrote: > Hi, > > Please review this change for: > https://bugs.openjdk.java.net/browse/JDK-8144486 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8138888/8144486/hotspot.00/ Looks good. /Mikael > > Background: > When iterating objects with oop_iterate() there is a special case for > InstanceRefKlass, if the closure overrides > apply_to_weak_ref_discovered_field() to return true, the closure will be > applied to the discovered field, even if the normal checks prevents it. > This special treatment is needed in certain situations, but it is not > obvious if it should be done when iterating the object. Currently only > G1 closures override apply_to_weak_ref_discovered_field() and many of > them seem to do it without any reason. My initial plan [1] was to remove > all usage of this special casing but after discussions I realized it > would be easier to see the effects if doing this one closure at a time. > > Summary: > This change is for G1UpdateRSOrPushRefOopClosure which is never used > with oop_iterate and therefore does not need to override > apply_to_weak_ref_discovered_field(). There is also no need to inherit > ExtendedOopClosure, so it's changed to inherit OopClosure instead. > > Testing: > * JPRT > * RBT > > Thanks, > Stefan > > [1] https://bugs.openjdk.java.net/browse/JDK-8138888 From mikael.gerdin at oracle.com Wed Dec 2 16:28:23 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 2 Dec 2015 17:28:23 +0100 Subject: RFR: 8144505: Change G1ParCopyHelper to inherit OopClosure In-Reply-To: <565F1455.50809@oracle.com> References: <565F1455.50809@oracle.com> Message-ID: <565F1C27.7080800@oracle.com> Hi Stefan, On 2015-12-02 16:55, Stefan Johansson wrote: > Hi, > > Please review this change for: > https://bugs.openjdk.java.net/browse/JDK-8144505 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8138888/8144505/hotspot.00/ 88 // Add back base class for metadata 89 class G1ParCopyHelper : public OopClosure { 90 protected: 91 uint _worker_id; // Cache value from par_scan_state. 92 Klass* _scanned_klass; 93 G1CollectedHeap* _g1; 94 ConcurrentMark* _cm; 95 G1ParScanThreadState* _par_scan_state; 96 That's a weird ordering of the fields, why not just move the heap an par scan state pointers to before the other fields, just as if they were still in the parent class? Otherwise it looks good. /Mikael > > Background: > When iterating objects with oop_iterate() there is a special case for > InstanceRefKlass, if the closure overrides > apply_to_weak_ref_discovered_field() to return true, the closure will be > applied to the discovered field, even if the normal checks prevents it. > This special treatment is needed in certain situations, but it is not > obvious if it should be done when iterating the object. Currently only > G1 closures override apply_to_weak_ref_discovered_field() and many of > them seem to do it without any reason. My initial plan [1] was to remove > all usage of this special casing but after discussions I realized it > would be easier to see the effects if doing this one closure at a time. > > Summary: > G1ParCopyClosure is only used as a normal OopClosure. It inherits from > G1ParCopyHelper which in turn inherits G1ParClosureSuper. > G1ParClosureSuper overrides apply_to_weak_ref_discovered_field() to > return true but since G1ParCopyClosure is never used with oop_iterate() > it doesn't need to inherit this functionality. G1ParCopyHelper can > instead be changed to inherit directly from OopClosure, and this way we > have one closure less depending on apply_to_weak_ref_discovered_field(). > > Testing: > * JPRT > * RBT > > Thanks, > Stefan > > [1] https://bugs.openjdk.java.net/browse/JDK-8138888 From stefan.johansson at oracle.com Wed Dec 2 16:33:51 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 2 Dec 2015 17:33:51 +0100 Subject: RFR: 8144505: Change G1ParCopyHelper to inherit OopClosure In-Reply-To: <565F1C27.7080800@oracle.com> References: <565F1455.50809@oracle.com> <565F1C27.7080800@oracle.com> Message-ID: <565F1D6F.5010807@oracle.com> On 2015-12-02 17:28, Mikael Gerdin wrote: > Hi Stefan, > > On 2015-12-02 16:55, Stefan Johansson wrote: >> Hi, >> >> Please review this change for: >> https://bugs.openjdk.java.net/browse/JDK-8144505 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8138888/8144505/hotspot.00/ > > 88 // Add back base class for metadata > 89 class G1ParCopyHelper : public OopClosure { > 90 protected: > 91 uint _worker_id; // Cache value from par_scan_state. > 92 Klass* _scanned_klass; > 93 G1CollectedHeap* _g1; > 94 ConcurrentMark* _cm; > 95 G1ParScanThreadState* _par_scan_state; > 96 > > That's a weird ordering of the fields, why not just move the heap an > par scan state pointers to before the other fields, just as if they > were still in the parent class? > I agree, fixed. New webrev: http://cr.openjdk.java.net/~sjohanss/8138888/8144505/hotspot.01/ Thanks for reviewing, Stefan > Otherwise it looks good. > /Mikael > >> >> Background: >> When iterating objects with oop_iterate() there is a special case for >> InstanceRefKlass, if the closure overrides >> apply_to_weak_ref_discovered_field() to return true, the closure will be >> applied to the discovered field, even if the normal checks prevents it. >> This special treatment is needed in certain situations, but it is not >> obvious if it should be done when iterating the object. Currently only >> G1 closures override apply_to_weak_ref_discovered_field() and many of >> them seem to do it without any reason. My initial plan [1] was to remove >> all usage of this special casing but after discussions I realized it >> would be easier to see the effects if doing this one closure at a time. >> >> Summary: >> G1ParCopyClosure is only used as a normal OopClosure. It inherits from >> G1ParCopyHelper which in turn inherits G1ParClosureSuper. >> G1ParClosureSuper overrides apply_to_weak_ref_discovered_field() to >> return true but since G1ParCopyClosure is never used with oop_iterate() >> it doesn't need to inherit this functionality. G1ParCopyHelper can >> instead be changed to inherit directly from OopClosure, and this way we >> have one closure less depending on apply_to_weak_ref_discovered_field(). >> >> Testing: >> * JPRT >> * RBT >> >> Thanks, >> Stefan >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8138888 > From stefan.karlsson at oracle.com Wed Dec 2 17:12:40 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 2 Dec 2015 18:12:40 +0100 Subject: RFR: 8144505: Change G1ParCopyHelper to inherit OopClosure In-Reply-To: <565F1D6F.5010807@oracle.com> References: <565F1455.50809@oracle.com> <565F1C27.7080800@oracle.com> <565F1D6F.5010807@oracle.com> Message-ID: <565F2688.7050303@oracle.com> Hi Stefan, On 2015-12-02 17:33, Stefan Johansson wrote: > > > On 2015-12-02 17:28, Mikael Gerdin wrote: >> Hi Stefan, >> >> On 2015-12-02 16:55, Stefan Johansson wrote: >>> Hi, >>> >>> Please review this change for: >>> https://bugs.openjdk.java.net/browse/JDK-8144505 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sjohanss/8138888/8144505/hotspot.00/ >> >> 88 // Add back base class for metadata >> 89 class G1ParCopyHelper : public OopClosure { >> 90 protected: >> 91 uint _worker_id; // Cache value from par_scan_state. >> 92 Klass* _scanned_klass; >> 93 G1CollectedHeap* _g1; >> 94 ConcurrentMark* _cm; >> 95 G1ParScanThreadState* _par_scan_state; >> 96 >> >> That's a weird ordering of the fields, why not just move the heap an >> par scan state pointers to before the other fields, just as if they >> were still in the parent class? >> > I agree, fixed. > > New webrev: > http://cr.openjdk.java.net/~sjohanss/8138888/8144505/hotspot.01/ Looks good. StefanK > > Thanks for reviewing, > Stefan > >> Otherwise it looks good. >> /Mikael >> >>> >>> Background: >>> When iterating objects with oop_iterate() there is a special case for >>> InstanceRefKlass, if the closure overrides >>> apply_to_weak_ref_discovered_field() to return true, the closure >>> will be >>> applied to the discovered field, even if the normal checks prevents it. >>> This special treatment is needed in certain situations, but it is not >>> obvious if it should be done when iterating the object. Currently only >>> G1 closures override apply_to_weak_ref_discovered_field() and many of >>> them seem to do it without any reason. My initial plan [1] was to >>> remove >>> all usage of this special casing but after discussions I realized it >>> would be easier to see the effects if doing this one closure at a time. >>> >>> Summary: >>> G1ParCopyClosure is only used as a normal OopClosure. It inherits from >>> G1ParCopyHelper which in turn inherits G1ParClosureSuper. >>> G1ParClosureSuper overrides apply_to_weak_ref_discovered_field() to >>> return true but since G1ParCopyClosure is never used with oop_iterate() >>> it doesn't need to inherit this functionality. G1ParCopyHelper can >>> instead be changed to inherit directly from OopClosure, and this way we >>> have one closure less depending on >>> apply_to_weak_ref_discovered_field(). >>> >>> Testing: >>> * JPRT >>> * RBT >>> >>> Thanks, >>> Stefan >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8138888 >> > From stefan.karlsson at oracle.com Wed Dec 2 17:14:30 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 2 Dec 2015 18:14:30 +0100 Subject: RFR: 8144486: Change G1UpdateRSOrPushRefOopClosure to inherit OopClosure In-Reply-To: <565F15C1.6040002@oracle.com> References: <565F0D06.4010405@oracle.com> <565F15C1.6040002@oracle.com> Message-ID: <565F26F6.3090302@oracle.com> Looks good. StefanK On 2015-12-02 17:01, Mikael Gerdin wrote: > On 2015-12-02 16:23, Stefan Johansson wrote: >> Hi, >> >> Please review this change for: >> https://bugs.openjdk.java.net/browse/JDK-8144486 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8138888/8144486/hotspot.00/ > > Looks good. > /Mikael > >> >> Background: >> When iterating objects with oop_iterate() there is a special case for >> InstanceRefKlass, if the closure overrides >> apply_to_weak_ref_discovered_field() to return true, the closure will be >> applied to the discovered field, even if the normal checks prevents it. >> This special treatment is needed in certain situations, but it is not >> obvious if it should be done when iterating the object. Currently only >> G1 closures override apply_to_weak_ref_discovered_field() and many of >> them seem to do it without any reason. My initial plan [1] was to remove >> all usage of this special casing but after discussions I realized it >> would be easier to see the effects if doing this one closure at a time. >> >> Summary: >> This change is for G1UpdateRSOrPushRefOopClosure which is never used >> with oop_iterate and therefore does not need to override >> apply_to_weak_ref_discovered_field(). There is also no need to inherit >> ExtendedOopClosure, so it's changed to inherit OopClosure instead. >> >> Testing: >> * JPRT >> * RBT >> >> Thanks, >> Stefan >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8138888 > From jon.masamitsu at oracle.com Wed Dec 2 17:46:19 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 2 Dec 2015 09:46:19 -0800 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <4BB8301E-2D01-4172-8628-753073B9D5DB@oracle.com> References: <56450520.6060706@oracle.com> <565631DC.1010800@oracle.com> <565C8575.6050004@oracle.com> <4BB8301E-2D01-4172-8628-753073B9D5DB@oracle.com> Message-ID: <565F2E6B.30802@oracle.com> On 11/30/2015 11:47 AM, Kim Barrett wrote: > On Nov 30, 2015, at 12:20 PM, Jon Masamitsu wrote: >>> src/share/vm/runtime/os.cpp >>> 319 VM_Version::vm_init_before_ergo(); >>> >>> This call is in generic code, but only two definitions have been >>> provided, for sparc and x86. Missing are aarch64, ppc, and zero. >>> >> Add vm_init_before_ergo() for those even though JPRT does not >> build them? I don't need to be convinced to do it. Just >> encouraged. Say "do it" and I'll do it. > I think you should do it, rather than knowingly breaking the build for those targets when the needed code is so trivial. > Here's the webrev for the delta for review comments to this point. http://cr.openjdk.java.net/~jmasa/8133023/delta.04/ Webrev for complete patch is here. http://cr.openjdk.java.net/~jmasa/8133023/webrev.04/ Jon From sangheon.kim at oracle.com Wed Dec 2 18:08:40 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 2 Dec 2015 10:08:40 -0800 Subject: RFR (M): JDK-8068394: Trace event for concurrent GC phases In-Reply-To: <565EB318.8060607@oracle.com> References: <56282271.5090108@oracle.com> <56546233.20006@oracle.com> <5654B10E.1060701@oracle.com> <565EB318.8060607@oracle.com> Message-ID: <565F33A8.6060608@oracle.com> Hi Bengt, On 12/02/2015 01:00 AM, Bengt Rutisson wrote: > > Hi Sangheon, > > Sorry again for the late reply. Comments inline. No not at all. Thank you for taking time for this review! > > On 2015-11-24 19:48, sangheon.kim wrote: >> Hi Bengt, >> >> Thank you so much for reviewing this patch! >> >> On 11/24/2015 05:12 AM, Bengt Rutisson wrote: >>> >>> Hi Sangheon, >>> >>> Sorry for the very late reply to this review request. >>> >>> On 2015-10-22 01:40, sangheon.kim wrote: >>>> Hi all, >>>> >>>> Can I get some reviews for this change of adding a trace event for >>>> concurrent phases on CMS and G1? >>>> >>>> Currently we only measure pause times for major phases. >>>> But I want to add 'concurrent mark' and 'concurrent sweep' phases >>>> for CMS and 'concurrent mark' phase for G1. >>>> To achieve this, I had to change ConcurrentGCTimer and related >>>> classes. >>>> >>>> This patch includes: >>>> 1) A concurrent phase can be measured only from ConcurrentGCTimer >>>> and measuring an overlap between concurrent and pause is not >>>> allowed as currently we don't have that use case. And >>>> TimePartitions class(or related classes) will be simpler than an >>>> overlap allowed case. >>>> 2) I removed PausePhase and ConcurrentPhase which are derived from >>>> GCPhase because I wanted to avoid heap allocation when adding to >>>> GrowableArray. Instead introduced 'type' member variable at GCPhase. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8068394 >>>> Webrev: http://cr.openjdk.java.net/~sangheki/8068394/webrev.00/ >>> >>> Nice work! It is great to get some timing information for the >>> concurrent phases. >> Thanks! >> >>> >>> A few questions/comments: >>> >>> CMS. >>> >>> You have added timing events for the concurrent phases mark and >>> sweep, but not for other concurrent phases (preclean, >>> abortable_preclean and reset_concurrent). I think that if you moved >>> your calls to _gc_timer_cm->register_gc_concurrent_start() and >>> _gc_timer_cm->register_gc_concurrent_end() into the constructor and >>> destructor of CMSPhaseAccounting you would automatically get timing >>> events for all concurrent phases. >> I also considered about this idea but I was not clear whether it is >> good measurement especially for 'sweep'. >> We are using CMSPhaseAccounting for 5 cases. >> I think for 'mark' and 'preclean' they are okay. (there are >> non-product functions call before CMSPhaseAccounting. But they are >> okay). >> For 'abortable-preclean' and 'reset', they are good to have that. >> But when it comes to 'sweep', there are timer and >> CMSTokenSyncWithLocks related codes and I was not sure about these. >> If you think they are also okay, I will change as you suggested. > > I think it is fine for the sweep part as well. If the > CMSPhaseAccounting instance is not measuring the correct part of the > work I think we should change it to measure what we want. That way we > improve the existing measurements too. > > But as you stated in your follow up email, I think the sweep code is > actually pretty much ok from this perspective. > > So, I would prefer to go with the CMSPhaseAccounting approach. Okay, I already changed as you suggested. :) > > >> >>> >>> >>> G1. >>> >>> I think the use of _concurrent_marking_from_roots is unfortunate. It >>> would be much cleaner if >>> ConcurrentMark::register_mark_from_roots_phase_end() called >>> register_gc_concurrent_end() directly. >> I wanted to avoid introducing the new flag but the reason of it was, >> as you know, to handle 'abort'. >> When 'abort' happens we do need to end all timers before calling >> 'GCTracer::report_gc_end()'. >> And at this point we need a way to know whether concurrent timer is >> started or not. > > As I tried to describe I think you can extend the scope of the timing > to cover the part until the marking thread discovers that the marking > was aborted. Basically moving the timing in to > ConcurrentMarkThread::run_service(). Oh, I mis-understood your point. Sorry. I will try your recommendation. > >> >>> I realize that this would change the timing for when a concurrent >>> marking is aborted. The whole time for a full GC (or even several >>> full GCs) would be included in the concurrent marking phase. But >>> from a code perspective that is what happens, so maybe that is the >>> correct time to report? Also, I think the logging is reported that >>> way so if we want to make it easy to match the timing events with >>> the logging we might want to use about the same scope for timing. >>> >>> Why do we only measure the concurrent mark phase for G1? >> This is good question. :) >> I was comparing CMS and G1 for major concurrent phases. >> And the candidates were 'concurrent mark/sweep (CMS)' and 'concurrent >> mark(G1)'. >> >>> Wouldn't it be good to measure all concurrent phases? >> Okay, Stefan Karlsson also pointed to have them as well so I filed a >> separate CR for this. >> https://bugs.openjdk.java.net/browse/JDK-8143951 > > Ok. Is there a reason why we want to split this up into two changes? > Why not add all the concurrent timing events at once? > > I'm ok with splitting it up into two changes, but then maybe the title > for JDK-8068394 should be changed to indicate that it only adds events > for the marking phase. Also, if we go with the CMSPhaseAccounting > approach for CMS, you get events for all phases there. So, it will be > a bit odd to have all concurrent phases handled for CMS but only > concurrent mark for G1. You are correct and I agree with you. The only reason of split was due to limited time for FC. But as we have enough time, let me close JDK-8143951 and include concurrent mark for G1 as well. > >> >>> >>> gcTraceSend.cpp >>> >>> 389 void visit(GCPhase* phase) { >>> 390 switch (phase->type()) { >>> 391 case GCPhase::PausePhaseType: >>> 392 assert(phase->level() < PhasesStack::PHASE_LEVELS, >>> "Need more event types for PausePhase"); >>> 393 >>> 394 switch (phase->level()) { >>> 395 case 0: send_phase(phase); break; >>> 396 case 1: send_phase(phase); >>> break; >>> 397 case 2: send_phase(phase); >>> break; >>> 398 case 3: send_phase(phase); >>> break; >>> 399 default: /* Ignore sending this phase */ break; >>> 400 } >>> 401 break; >>> 402 >>> 403 case GCPhase::ConcurrentPhaseType: >>> 404 assert(phase->level() < 1, "There's only one level for >>> ConcurrentPhase"); >>> 405 >>> 406 switch (phase->level()) { >>> 407 case 0: send_phase(phase); >>> break; >>> 408 default: /* Ignore sending this phase */ break; >>> 409 } >>> 410 break; >>> 411 } >>> 412 } >>> 413 }; >>> >>> Since there are only two values for GCPhase::PhaseType it seems a >>> bit odd to use a switch statement. I think I would prefer to factor >>> out the code for the different types a bit too. So, maybe something >>> like: >>> >>> void visit(GCPhase* phase) { >>> if (phase->type() == GCPhase::PausePhaseType) { >>> visit_pause(phase); >>> } else { >>> assert(phase->type() == GCPhase::ConcurrentPhaseType, ""); >>> visit_concurrent(phase); >>> } >>> } >> This seems better. I will fix. > > Good. Thanks! :) I will post next webrev when I'm ready, including JDK-8143951 part as well. Thanks, Sangheon > > Bengt > >> >> Thanks, >> Sangheon >> >> >>> >>> Thanks, >>> Bengt >>> >>>> Testing: JPRT >>>> >>>> Thanks, >>>> Sangheon >>> >> > From kim.barrett at oracle.com Wed Dec 2 18:37:44 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Dec 2015 13:37:44 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do Message-ID: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> Please review this change to PhantomReference processing, changing the GC-based notification to automatically clear the referent. This change provides performance benefits by eliminating the work involved in keeping the otherwise inaccessible referent objects alive, as required by the existing specification. This not only immediately removes some work, but may enable further performance improvements. It also allows the referent objects to be immediately reclaimed in the GC cycle in which they were determined to be inaccessible, rather than lingering as a form of floating garbage until the application deals with the notified reference. This change results in a behavioral change to application code, as demonstrated by the associated test. Under the old specification, a reference R with referent X may be kept alive because it is referenced by an otherwise inaccessible referent Y of phantom reference P. This will result in X being treated as strongly referenced and prevent R from being notified, even if R is a phantom reference and X has become inaccessible to the application. With this change, Y is reclaimed when it becomes inaccessible and P is notified, and no longer prevents X from itself becoming a candidate for reclaimation once it is no longer accessible to the application. While this is a change in behavior, it seems unlikely to affect applications negatively. CR: https://bugs.openjdk.java.net/browse/JDK-8071507 Webrevs: http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/ http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ Testing: jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK) From mandy.chung at oracle.com Wed Dec 2 18:58:46 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Dec 2015 10:58:46 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> Message-ID: <97DB8CEB-69E0-4A97-BF03-10E984AD6F13@oracle.com> Kim, Thanks for sending this out. I like the 1-line fix in hotspot - simple and sweet. Mandy > On Dec 2, 2015, at 10:37 AM, Kim Barrett wrote: > > Please review this change to PhantomReference processing, changing the > GC-based notification to automatically clear the referent. > > This change provides performance benefits by eliminating the work > involved in keeping the otherwise inaccessible referent objects alive, > as required by the existing specification. This not only immediately > removes some work, but may enable further performance improvements. > It also allows the referent objects to be immediately reclaimed in > the GC cycle in which they were determined to be inaccessible, rather > than lingering as a form of floating garbage until the application > deals with the notified reference. > > This change results in a behavioral change to application code, as > demonstrated by the associated test. Under the old specification, a > reference R with referent X may be kept alive because it is referenced > by an otherwise inaccessible referent Y of phantom reference P. This > will result in X being treated as strongly referenced and prevent R > from being notified, even if R is a phantom reference and X has become > inaccessible to the application. With this change, Y is reclaimed > when it becomes inaccessible and P is notified, and no longer prevents > X from itself becoming a candidate for reclaimation once it is no > longer accessible to the application. While this is a change in > behavior, it seems unlikely to affect applications negatively. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8071507 > > Webrevs: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/ > http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ > > Testing: > jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK) > From kim.barrett at oracle.com Wed Dec 2 18:59:20 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Dec 2015 13:59:20 -0500 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <565F2E6B.30802@oracle.com> References: <56450520.6060706@oracle.com> <565631DC.1010800@oracle.com> <565C8575.6050004@oracle.com> <4BB8301E-2D01-4172-8628-753073B9D5DB@oracle.com> <565F2E6B.30802@oracle.com> Message-ID: <6FF53C6C-C2DF-4A44-8664-0D84B29772D5@oracle.com> On Dec 2, 2015, at 12:46 PM, Jon Masamitsu wrote: > > > > On 11/30/2015 11:47 AM, Kim Barrett wrote: >> On Nov 30, 2015, at 12:20 PM, Jon Masamitsu wrote: >>>> src/share/vm/runtime/os.cpp >>>> 319 VM_Version::vm_init_before_ergo(); >>>> >>>> This call is in generic code, but only two definitions have been >>>> provided, for sparc and x86. Missing are aarch64, ppc, and zero. >>>> >>> Add vm_init_before_ergo() for those even though JPRT does not >>> build them? I don't need to be convinced to do it. Just >>> encouraged. Say "do it" and I'll do it. >> I think you should do it, rather than knowingly breaking the build for those targets when the needed code is so trivial. >> > > Here's the webrev for the delta for review comments to this point. > > http://cr.openjdk.java.net/~jmasa/8133023/delta.04/ > > Webrev for complete patch is here. > > http://cr.openjdk.java.net/~jmasa/8133023/webrev.04/ Rather than the various platform-specific nop definitions, how about using the same trick used for VM_Version::early_initialize, e.g. Abstract_VM_Version provides a nop definition, and platforms that need additional behavior override that definition in their VM_Version definitions. So here we would have (in runtime/vm_version.hpp) class Abstract_VM_Version ? { ? public: static void init_before_ergo() { } ? }; From tom.benson at oracle.com Wed Dec 2 19:21:09 2015 From: tom.benson at oracle.com (Tom Benson) Date: Wed, 2 Dec 2015 14:21:09 -0500 Subject: RFR (M): 8060697: Improve G1 Heap Growth Heuristics In-Reply-To: <565E30F6.5020201@oracle.com> References: <5653D33D.3090906@oracle.com> <72774236-F1E8-4D47-A202-5BED4646D24A@oracle.com> <5655C06D.1010209@oracle.com> <565CAD31.1010207@oracle.com> <565E130B.6010003@oracle.com> <565E30F6.5020201@oracle.com> Message-ID: <565F44A5.7080205@oracle.com> Hi Jon, On 12/1/2015 6:44 PM, Jon Masamitsu wrote: > > > On 12/1/2015 1:37 PM, Tom Benson wrote: >> Hi Jon, >> Thanks very much for the review. >> >> On 11/30/2015 3:10 PM, Jon Masamitsu wrote: >>> Tom, >>> >>> http://cr.openjdk.java.net/~tbenson/8060697/webrev/src/share/vm/gc/g1/g1CollectorPolicy.cpp.frames.html >>> >>> 1053 // Compute the ratio of just this last pause time to the entire >>> time range stored >>> 1054 // in the vectors. >>> 1055 _last_pause_time_ratio = >>> 1056 (pause_time_ms * _recent_prev_end_times_for_all_gcs_sec->num()) >>> / interval_ms; >>> >>> _last_pause_time_ratio is the ratio of the last pause over the >>> average interval in the truncated sequence? By the latter >>> I mean >>> >>> (interval_ms / _recent_prev_end_times_for_all_gcs_sec->num()) >>> >>> If the truncated sequence has N sample and "interval_ms" is >>> measured from the oldest sample, I'm calling interval_ms / N >>> the average interval. >>> >>> Is my description correct? Why do you prefer that to the most recent >>> pause time ratio? >> >> Yes, your description is right. Basically I want to notice the >> *first* pause that goes over the threshold, rather than waiting for >> the average over the last 10 pauses to go over. The reason is that >> this will start the code looking for ratios that exceed the threshold >> (beginning a "sampling window" so to speak), and I want to do that as >> soon as possible. > > OK. That sounds like a good policy. > >> >> If by this: "Why do you prefer that to the most recent pause time >> ratio?" you mean "Why not just compare the last pause to the last >> single interval?", the reason is that comparing it to the entire >> range 'smooths over' some transiently-more-frequent GCs that don't >> really reflect a change in heap occupancy. I see this happening in >> specjbb sometimes. By only comparing against the last interval, >> needless growth happens more often, resulting in higher run-to-run >> variability. Another approach would be to raise the minimum number >> of threshold crossing pauses that are needed before triggering growth >> - but I don't want to delay that for cases where the need is real. >> Thomas commented to me that that transient behavior is likely to be >> due to something we ultimately want to fix, anyway. But the current >> approach of comparing against the whole recorded range seems to help >> alleviate the side effect of needless growth. > > More sound reasoning. > >> >> >>> >>> Should the 1*M below be 1 region size? >>> 1545 const size_t min_expand_bytes = 1*M; >> >> Hmm, good question. I didn't change that. It could certainly be >> MIN_REGION_SIZE, which == 1*M. I think using the actual region size >> would likely only have an effect when the heap is nearly at minimum >> or maximum sizes. In between, the math is likely to result in a size >> larger than that anyway. I could try it. > > I was wondering what happens when the region size is 32M. Do you > recall? > The region size isn't a factor in the expansion amount computation. The expand code that later uses what it returned rounds up to a multiple of region size. With that in mind, it doesn't really matter what min_expand_bytes is, as long as it's less than or equal to HeapRegion::GrainBytes... And greater than zero. I currently have it at min_region_size, but think it makes sense to change to GrainBytes. >> >>> >>> As the uncommitted space in the heap drops, the grow rate drops. >>> >>> >>> 1550 size_t expand_bytes_via_pct = >>> 1551 uncommitted_bytes * G1ExpandByPercentOfAvailable / 100; >>> >>> The scale_factor will increase that by up to a factor of 2, the policy >>> seems to grow slowly to the maximum. Is there a reason not to get >>> to the maximum heap size quickly? >> >> Yes, I thought about this as well. This attribute (shrinking the >> growth increment as we approach the limit) is there in both the old >> and new code, but the new code may scale the value up. What I >> considered, but didn't try, was to use a fixed percentage of the >> entire heap, once we have reached a certain threshold by doubling the >> size. That value would still be scaled according to the pause >> ratios. I decided not to pursue it for now, since the results >> looked acceptable and it could be done as a follow up. > > Let that stand. I know that G1 historically has grown the heap based > on how > much uncommitted is left. Don't know if it is good or bad. I've just > never gotten > used to that approach. Well, I tried it. IE, I changed the code to use a fixed 10% of the reserved size once the size was at least 20% of reserved, rather than using 20% of the remaining uncommitted space. Results were not very different. The max heap size for tests that were well into that threshold were a little different. The main change was that for those that go to max heap (such as the compiler tests in jvm08), the top size is reached much more quickly, with one or two large increments replacing many smaller ones. Which is good. If I were going to make the change to commit it, I'd want to experiment more with the percentage. I'd hold off on it, though. The main goal of the current change is to get the variability under control. Next phase of heap sizing work can consider the fixed increment. > >> >> However, it won't be hard to try, and I can do so if there's >> agreement that the rest of this approach seems reasonable. > > Some of my second guessing on this policy is that it seems rather > complex. Someone will eventually ask for documentation on how > the heap grows. Hope you're up to it. :-) > > I don't have any more comments. I'm good with it. OK, thanks. Tom > > Jon > >> Thanks, >> Tom >> >>> >>> Jon >>> >>> >>> On 11/25/2015 06:06 AM, Tom Benson wrote: >>>> Hi Kim, >>>> Thanks very much for the review. I've implemented all your >>>> suggestions. >>>> Down >>>> About this: >>>> >>>>> I suspect you are introducing some implicit conversions that will >>>>> cause >>>>> problems for the SAP folks; see discussion of 8143215: >>>> >>>> ... I think there's one, which is: >>>> >>>> expand_bytes = expand_bytes * scale_factor; >>>> >>>> scale_factor is explicitly limited to being between 0.2 and 2.0, >>>> and expand_bytes is fraction of the heap size, so there's no chance >>>> of overflow. Would you object to the static cast in this case? >>>> How about with a comment? >>>> >>>> Tom >>>> >>>> On 11/24/2015 9:55 PM, Kim Barrett wrote: >>>>> On Nov 23, 2015, at 10:02 PM, Tom Benson >>>>> wrote: >>>>>> Hi, >>>>>> Here is a proposed change to the G1 heap growth code for review. >>>>>> I've added a detailed description to the CR, but here is the >>>>>> short version: After a GC pause, the average ratio of time spent >>>>>> in recent GC pauses vs overall time is computed. If it exceeds >>>>>> GCTimeRatio, the heap is expanded by a fixed amount. With the >>>>>> new code, some deficiencies in the ratio tracking are addressed, >>>>>> and the expansion size is scaled according to how much the >>>>>> desired ratio is, on average, exceeded by. The target ratio >>>>>> itself is also scaled at the lowest heap sizes. >>>>>> >>>>>> The case that triggered this was actually JDK-8132077, where the >>>>>> JVM'08 Compress benchmark saw a 40% degradation. It was due to >>>>>> the heap being about half the size in some runs, because of the >>>>>> way heap growth worked. >>>>>> >>>>>> I'm still collecting the final performance data for this version, >>>>>> and will attach it to the CR. Earlier experimental versions >>>>>> showed good improvements in consistency of heap sizes. A couple >>>>>> of benchmarks average a percentage point or two lower, while >>>>>> others improve by that much or more. No growth percentage or >>>>>> scaling is going to be ideal for every test, but the goal was to >>>>>> maintain performance without growing too large. In fact, some >>>>>> tests now use much smaller heaps. >>>>>> >>>>>> CR: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8060697 >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~tbenson/8060697/webrev/ >>>>> Generally looks good; just a few very minor things, most of which >>>>> you can >>>>> take or ignore as you prefer. I don't need a new webrev for any >>>>> of these. >>>>> >>>>> The comments were very helpful in understanding what's going on. >>>>> >>>>> I suspect you are introducing some implicit conversions that will >>>>> cause >>>>> problems for the SAP folks; see discussion of 8143215: gcc 4.1.2: >>>>> fix three >>>>> issues breaking the build. But the resolution for that is still >>>>> being >>>>> discussed, and we don't have an easy way to discover these for >>>>> ourselves, so >>>>> I don't think you should worry about it here right now. >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> src/share/vm/gc/g1/g1CollectorPolicy.cpp >>>>> 1571 static double const MinScaleDownFactor = 0.2; >>>>> 1572 static double const MaxScaleUpFactor = 2; >>>>> 1573 static double const StartScaleDownAt = _gc_overhead_perc; >>>>> 1574 static double const StartScaleUpAt = _gc_overhead_perc >>>>> * 1.5; >>>>> 1575 static double const ScaleUpRange = _gc_overhead_perc * >>>>> 2.0; >>>>> >>>>> I suggest these not be static. >>>>> >>>>> It doesn't really matter for the first two. >>>>> >>>>> But for the others, there is a hidden cost to making them static, >>>>> due to >>>>> some compilers ensuring thread-safe initialization. C++11 mandates >>>>> thread-safe initialization of function scoped statics. gcc has >>>>> implemented >>>>> that starting circa gcc4.0 (if I recall correctly), controlled by >>>>> a CLA >>>>> (-f[no]-threadsafe-statics). Visual Studio 2013 also includes >>>>> this feature, >>>>> as part of their incremental rollout of C++11 (and later) >>>>> features. I don't >>>>> know about other compilers. >>>>> >>>>> The cost of making them static is likely at least comparable to >>>>> computing >>>>> them. And making them static implies the _gc_overhead_perc is >>>>> effectively a >>>>> constant, which appears to be true today, but who knows what will >>>>> happen >>>>> tomorrow. >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> src/share/vm/gc/g1/g1CollectorPolicy.cpp >>>>> 1587 scale_factor = MAX2(scale_factor, >>>>> MinScaleDownFactor); >>>>> 1590 scale_factor = MIN2(scale_factor, >>>>> MaxScaleUpFactor); >>>>> >>>>> The explicit double template parameter isn't needed here, since the >>>>> arguments are already both doubles. >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> src/share/vm/gc/g1/g1CollectorPolicy.cpp >>>>> 1525 threshold = (threshold * ((double)_g1->capacity() / >>>>> (double)(_g1->max_capacity() / 2))); >>>>> >>>>> This might be easier to read if it used "threshold *= ...". >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> src/share/vm/gc/g1/g1CollectorPolicy.cpp >>>>> 1526 threshold = MAX2(threshold, 1); >>>>> >>>>> The explicit double template parameter wouldn't be needed if "1" was >>>>> replaced with "1.0". >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Wed Dec 2 19:22:06 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Dec 2015 14:22:06 -0500 Subject: Request for code review - JDK-8141123 Change int's to size_t in FreeIdSet In-Reply-To: <565E06ED.2080309@oracle.com> References: <5627EB64.1070704@oracle.com> <5640D3F2.3080601@oracle.com> <56439D48.5000105@oracle.com> <1447320920.2312.29.camel@oracle.com> <1448536437.2100.27.camel@oracle.com> <565E06ED.2080309@oracle.com> Message-ID: <229C649D-7269-422E-9D52-3E614002DD10@oracle.com> On Dec 1, 2015, at 3:45 PM, Alexander Harlap wrote: > > Here is new version, to satisfy comments of Thomas, Kim and Tom. > I hope it is better now. > > http://cr.openjdk.java.net/~aharlap/8141123/webrev.04/ ------------------------------------------------------------------------------ src/share/vm/gc/shared/workgroup.cpp 504 FreeIdSet::FreeIdSet(uint size, Monitor* mon) : ... 508 _ids = NEW_C_HEAP_ARRAY(uint, size, mtGC); 509 for (uint i = 0; i < size - 1; i++) { ... 512 _ids[size-1] = end_of_list; // end of list. [Pre-existing issue] I think the allocation should be size+1, the iteration limit should be size, and the end_of_list sentinal installed at _ids[size]. As it is now, the set size is actually one less than size. This would be particularly problematic if the set were given a size of one. Since the only caller uses the number of processors as the size, the set would be empty if there were only one processor. That's not really the target audience for G1, but still... Sorry I missed this earlier. From kim.barrett at oracle.com Wed Dec 2 21:08:26 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Dec 2015 16:08:26 -0500 Subject: Request for code review - JDK-8141123 Change int's to size_t in FreeIdSet In-Reply-To: <1449045349.2642.14.camel@oracle.com> References: <5627EB64.1070704@oracle.com> <5640D3F2.3080601@oracle.com> <56439D48.5000105@oracle.com> <1447320920.2312.29.camel@oracle.com> <1448536437.2100.27.camel@oracle.com> <1DC292EE-6A66-4C82-A7C9-C0572B73B4A9@oracle.com> <1449045349.2642.14.camel@oracle.com> Message-ID: On Dec 2, 2015, at 3:35 AM, Thomas Schatzl wrote: > > Hi, > > On Tue, 2015-12-01 at 18:45 -0500, Kim Barrett wrote: >> On Nov 26, 2015, at 6:13 AM, Thomas Schatzl wrote: >>> >>> Hi, >>> >>> On Wed, 2015-11-25 at 17:34 -0500, Kim Barrett wrote: >>>> On Nov 12, 2015, at 4:35 AM, Thomas Schatzl wrote: >>>>> >>>>> - FreeIdSet::set_safepoint() seems to be never called. I think it >>>>> allows you to remove a *lot* of unused stuff. >>>> >>>> Perhaps the bug here is that there should be calls to set_safepoint but they are missing? >>>> >>> >>> apparently the functionality is not needed, that is, it has not even >>> been in use in the initial integration of G1 (and it has been added in >>> that change). >>> >>> So I suggest to just remove it and everything that depended on it >>> instead of trying to find out what this functionality may have been used >>> for. >> >> Or this could be a "been there forever" latency bug. >> [?] > > ... and reading through all this investigation, actually I think the > whole FreeIdSet is unnecessary. The mutator thread could just take any > random valid thread id and the FromCardCache would still work (although > at reduced efficiency, but that is the case in that situation already > anyway). > > Ideally there would be some small extra cache, or we just do not use the > cache in this situation which seems a reasonable option too (or let all > mutators use a single equal extra id), to not thrash the FromCardCache > of the refinement threads. > > I am leaving it to Alex and you to decide whether you want this cleanup > as an intermediate step, or go for a full cleanup. I'm fine with treating the work Alex has done so far as a good intermediate cleanup. I'll file followup bugs about the additional issues uncovered here. Attempting to eliminate FreeIdSet certainly has appeal. However, I don't have any intuition about the importance of the FromCardCache, which makes me reluctant to prevent the mutator threads from using it. But I'd be even more uncomfortable allowing mutator threads to *simultaneously* share a worker_id / cache key. I think the races that would ensue are, in the current code, probably harmless. But having the code that enables the race be far away from where the race occurs makes me quite nervous. From thomas.schatzl at oracle.com Wed Dec 2 21:44:12 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 02 Dec 2015 22:44:12 +0100 Subject: Request for code review - JDK-8141123 Change int's to size_t in FreeIdSet In-Reply-To: References: <5627EB64.1070704@oracle.com> <5640D3F2.3080601@oracle.com> <56439D48.5000105@oracle.com> <1447320920.2312.29.camel@oracle.com> <1448536437.2100.27.camel@oracle.com> <1DC292EE-6A66-4C82-A7C9-C0572B73B4A9@oracle.com> <1449045349.2642.14.camel@oracle.com> Message-ID: <1449092652.4376.18.camel@oracle.com> Hi, On Wed, 2015-12-02 at 16:08 -0500, Kim Barrett wrote: > On Dec 2, 2015, at 3:35 AM, Thomas Schatzl wrote: > > > > Hi, > > > > On Tue, 2015-12-01 at 18:45 -0500, Kim Barrett wrote: > >> On Nov 26, 2015, at 6:13 AM, Thomas Schatzl wrote: > >>> > >>> Hi, > >>> > [...] > > ... and reading through all this investigation, actually I think the > > whole FreeIdSet is unnecessary. The mutator thread could just take any > > random valid thread id and the FromCardCache would still work (although > > at reduced efficiency, but that is the case in that situation already > > anyway). > > > > Ideally there would be some small extra cache, or we just do not use the > > cache in this situation which seems a reasonable option too (or let all > > mutators use a single equal extra id), to not thrash the FromCardCache > > of the refinement threads. > > > > I am leaving it to Alex and you to decide whether you want this cleanup > > as an intermediate step, or go for a full cleanup. > > I'm fine with treating the work Alex has done so far as a good > intermediate cleanup. I'll file followup bugs about the additional > issues uncovered here. > > Attempting to eliminate FreeIdSet certainly has appeal. However, I > don't have any intuition about the importance of the FromCardCache, The fromcardcache caches for every combination of thread id and region which card has most recently been added to the remembered set. It purely acts as a filter of repeated attempts to add the same card by the same thread to the remembered set. It seems to be quite effective at doing so in many cases. > which makes me reluctant to prevent the mutator threads from using it. > But I'd be even more uncomfortable allowing mutator threads to > *simultaneously* share a worker_id / cache key. I think the races > that would ensue are, in the current code, probably harmless. But >From what I looked at, they are harmless. Sharing a single thread id may or may not be less problematic than for every insert check whether the given thread id is the special thread id. The existing rset code already seems have the requirement to be able to handle parallel card insertion attempts with the same thread id. I think in the situation of a claimed thread id from the free-id-set by mutator threads matches one of a refinement thread. Or native code always using thread id zero to add remembered set entries... > having the code that enables the race be far away from where the race > occurs makes me quite nervous. I agree to some degree. The problem is that the rset implementation needs to handle this situation already anyway. It's just a matter of exploiting this requirement again vs. decreased complexity in the refinement handling. I know what I would choose if I were asked, and somebody verified again what I described above - only had a brief look, and using some details from memory. Thanks, Thomas From bengt.rutisson at oracle.com Thu Dec 3 08:03:45 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 3 Dec 2015 09:03:45 +0100 Subject: RFR (M): JDK-8068394: Trace event for concurrent GC phases In-Reply-To: <565F33A8.6060608@oracle.com> References: <56282271.5090108@oracle.com> <56546233.20006@oracle.com> <5654B10E.1060701@oracle.com> <565EB318.8060607@oracle.com> <565F33A8.6060608@oracle.com> Message-ID: <565FF761.30200@oracle.com> Hi Sangheon, This all sounds good. Looking forward to the next webrev. Thanks, Bengt On 2015-12-02 19:08, sangheon.kim wrote: > Hi Bengt, > > > On 12/02/2015 01:00 AM, Bengt Rutisson wrote: >> >> Hi Sangheon, >> >> Sorry again for the late reply. Comments inline. > No not at all. > Thank you for taking time for this review! > >> >> On 2015-11-24 19:48, sangheon.kim wrote: >>> Hi Bengt, >>> >>> Thank you so much for reviewing this patch! >>> >>> On 11/24/2015 05:12 AM, Bengt Rutisson wrote: >>>> >>>> Hi Sangheon, >>>> >>>> Sorry for the very late reply to this review request. >>>> >>>> On 2015-10-22 01:40, sangheon.kim wrote: >>>>> Hi all, >>>>> >>>>> Can I get some reviews for this change of adding a trace event for >>>>> concurrent phases on CMS and G1? >>>>> >>>>> Currently we only measure pause times for major phases. >>>>> But I want to add 'concurrent mark' and 'concurrent sweep' phases >>>>> for CMS and 'concurrent mark' phase for G1. >>>>> To achieve this, I had to change ConcurrentGCTimer and related >>>>> classes. >>>>> >>>>> This patch includes: >>>>> 1) A concurrent phase can be measured only from ConcurrentGCTimer >>>>> and measuring an overlap between concurrent and pause is not >>>>> allowed as currently we don't have that use case. And >>>>> TimePartitions class(or related classes) will be simpler than an >>>>> overlap allowed case. >>>>> 2) I removed PausePhase and ConcurrentPhase which are derived from >>>>> GCPhase because I wanted to avoid heap allocation when adding to >>>>> GrowableArray. Instead introduced 'type' member variable at GCPhase. >>>>> >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8068394 >>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8068394/webrev.00/ >>>> >>>> Nice work! It is great to get some timing information for the >>>> concurrent phases. >>> Thanks! >>> >>>> >>>> A few questions/comments: >>>> >>>> CMS. >>>> >>>> You have added timing events for the concurrent phases mark and >>>> sweep, but not for other concurrent phases (preclean, >>>> abortable_preclean and reset_concurrent). I think that if you moved >>>> your calls to _gc_timer_cm->register_gc_concurrent_start() and >>>> _gc_timer_cm->register_gc_concurrent_end() into the constructor and >>>> destructor of CMSPhaseAccounting you would automatically get timing >>>> events for all concurrent phases. >>> I also considered about this idea but I was not clear whether it is >>> good measurement especially for 'sweep'. >>> We are using CMSPhaseAccounting for 5 cases. >>> I think for 'mark' and 'preclean' they are okay. (there are >>> non-product functions call before CMSPhaseAccounting. But they are >>> okay). >>> For 'abortable-preclean' and 'reset', they are good to have that. >>> But when it comes to 'sweep', there are timer and >>> CMSTokenSyncWithLocks related codes and I was not sure about these. >>> If you think they are also okay, I will change as you suggested. >> >> I think it is fine for the sweep part as well. If the >> CMSPhaseAccounting instance is not measuring the correct part of the >> work I think we should change it to measure what we want. That way we >> improve the existing measurements too. >> >> But as you stated in your follow up email, I think the sweep code is >> actually pretty much ok from this perspective. >> >> So, I would prefer to go with the CMSPhaseAccounting approach. > Okay, I already changed as you suggested. :) > >> >> >>> >>>> >>>> >>>> G1. >>>> >>>> I think the use of _concurrent_marking_from_roots is unfortunate. >>>> It would be much cleaner if >>>> ConcurrentMark::register_mark_from_roots_phase_end() called >>>> register_gc_concurrent_end() directly. >>> I wanted to avoid introducing the new flag but the reason of it was, >>> as you know, to handle 'abort'. >>> When 'abort' happens we do need to end all timers before calling >>> 'GCTracer::report_gc_end()'. >>> And at this point we need a way to know whether concurrent timer is >>> started or not. >> >> As I tried to describe I think you can extend the scope of the timing >> to cover the part until the marking thread discovers that the marking >> was aborted. Basically moving the timing in to >> ConcurrentMarkThread::run_service(). > Oh, I mis-understood your point. Sorry. > I will try your recommendation. > >> >>> >>>> I realize that this would change the timing for when a concurrent >>>> marking is aborted. The whole time for a full GC (or even several >>>> full GCs) would be included in the concurrent marking phase. But >>>> from a code perspective that is what happens, so maybe that is the >>>> correct time to report? Also, I think the logging is reported that >>>> way so if we want to make it easy to match the timing events with >>>> the logging we might want to use about the same scope for timing. >>>> >>>> Why do we only measure the concurrent mark phase for G1? >>> This is good question. :) >>> I was comparing CMS and G1 for major concurrent phases. >>> And the candidates were 'concurrent mark/sweep (CMS)' and >>> 'concurrent mark(G1)'. >>> >>>> Wouldn't it be good to measure all concurrent phases? >>> Okay, Stefan Karlsson also pointed to have them as well so I filed a >>> separate CR for this. >>> https://bugs.openjdk.java.net/browse/JDK-8143951 >> >> Ok. Is there a reason why we want to split this up into two changes? >> Why not add all the concurrent timing events at once? >> >> I'm ok with splitting it up into two changes, but then maybe the >> title for JDK-8068394 should be changed to indicate that it only adds >> events for the marking phase. Also, if we go with the >> CMSPhaseAccounting approach for CMS, you get events for all phases >> there. So, it will be a bit odd to have all concurrent phases handled >> for CMS but only concurrent mark for G1. > You are correct and I agree with you. > The only reason of split was due to limited time for FC. > But as we have enough time, let me close JDK-8143951 and include > concurrent mark for G1 as well. > >> >>> >>>> >>>> gcTraceSend.cpp >>>> >>>> 389 void visit(GCPhase* phase) { >>>> 390 switch (phase->type()) { >>>> 391 case GCPhase::PausePhaseType: >>>> 392 assert(phase->level() < PhasesStack::PHASE_LEVELS, >>>> "Need more event types for PausePhase"); >>>> 393 >>>> 394 switch (phase->level()) { >>>> 395 case 0: send_phase(phase); break; >>>> 396 case 1: send_phase(phase); >>>> break; >>>> 397 case 2: send_phase(phase); >>>> break; >>>> 398 case 3: send_phase(phase); >>>> break; >>>> 399 default: /* Ignore sending this phase */ break; >>>> 400 } >>>> 401 break; >>>> 402 >>>> 403 case GCPhase::ConcurrentPhaseType: >>>> 404 assert(phase->level() < 1, "There's only one level for >>>> ConcurrentPhase"); >>>> 405 >>>> 406 switch (phase->level()) { >>>> 407 case 0: send_phase(phase); >>>> break; >>>> 408 default: /* Ignore sending this phase */ break; >>>> 409 } >>>> 410 break; >>>> 411 } >>>> 412 } >>>> 413 }; >>>> >>>> Since there are only two values for GCPhase::PhaseType it seems a >>>> bit odd to use a switch statement. I think I would prefer to factor >>>> out the code for the different types a bit too. So, maybe something >>>> like: >>>> >>>> void visit(GCPhase* phase) { >>>> if (phase->type() == GCPhase::PausePhaseType) { >>>> visit_pause(phase); >>>> } else { >>>> assert(phase->type() == GCPhase::ConcurrentPhaseType, ""); >>>> visit_concurrent(phase); >>>> } >>>> } >>> This seems better. I will fix. >> >> Good. Thanks! > :) > > I will post next webrev when I'm ready, including JDK-8143951 part as > well. > > Thanks, > Sangheon > > >> >> Bengt >> >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> Testing: JPRT >>>>> >>>>> Thanks, >>>>> Sangheon >>>> >>> >> > From bengt.rutisson at oracle.com Thu Dec 3 08:16:57 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 3 Dec 2015 09:16:57 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> Message-ID: <565FFA79.4040600@oracle.com> Hi Kim, Thanks for pushing this through! Looks good. Bengt On 2015-12-02 19:37, Kim Barrett wrote: > Please review this change to PhantomReference processing, changing the > GC-based notification to automatically clear the referent. > > This change provides performance benefits by eliminating the work > involved in keeping the otherwise inaccessible referent objects alive, > as required by the existing specification. This not only immediately > removes some work, but may enable further performance improvements. > It also allows the referent objects to be immediately reclaimed in > the GC cycle in which they were determined to be inaccessible, rather > than lingering as a form of floating garbage until the application > deals with the notified reference. > > This change results in a behavioral change to application code, as > demonstrated by the associated test. Under the old specification, a > reference R with referent X may be kept alive because it is referenced > by an otherwise inaccessible referent Y of phantom reference P. This > will result in X being treated as strongly referenced and prevent R > from being notified, even if R is a phantom reference and X has become > inaccessible to the application. With this change, Y is reclaimed > when it becomes inaccessible and P is notified, and no longer prevents > X from itself becoming a candidate for reclaimation once it is no > longer accessible to the application. While this is a change in > behavior, it seems unlikely to affect applications negatively. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8071507 > > Webrevs: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/ > http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ > > Testing: > jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK) > From peter.levart at gmail.com Thu Dec 3 13:01:28 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 3 Dec 2015 14:01:28 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> Message-ID: <56603D28.6040206@gmail.com> Hi Kim, Kudos for finding an observable change in behavior. Although the specification could also be read in a way so that this would not be observable. Originally it states: "Unlike soft and weak references, phantom references are not automatically cleared by the garbage collector as they are enqueued. *An object that is reachable via phantom references will remain so* until all such references are cleared or themselves become unreachable." I read this as: "... An object that is reachable via phantom references will remain phantom reachable ..." If phantom-reachable objects have links among them, this doesn't make them strongly reachable. So I would argue that when both roots to O1 and O2 (in the test) are finally removed, O1 and O2 should be considered phantom-reachable, regardless of the link from O1 -> O2. When root to O2 is removed before the 2nd GC round, P2 should be notified as O2 transitions from reachable -> phantom reachable. This is no different from the situation when both roots to O1 and O2 are removed at the same time before a GC round: both P1 and P2 are notified. Anyway, this change is good. I would only rephrase this statement in package-info.java a bit: 96 * Soft and weak references are automatically cleared by the collector 97 * before being added to the queues with which they are registered, if any, 98 * hence they need not be registered with a queue in order to be useful. 99 * Phantom references, by contrast, do not allow their referents to be 100 * retrieved, so they must be registered with a queue. Perhaps to something like: Soft, weak and phantom references are automatically cleared by the collector before being added to the queues with which they are registered, if any. While Soft and weak references allow access to the referent before they are cleared, and hence need not be registered with a queue in order to be useful, Phantom references prevent access to the referent and are only useful when registered with a queue. Regards, Peter On 12/02/2015 07:37 PM, Kim Barrett wrote: > Please review this change to PhantomReference processing, changing the > GC-based notification to automatically clear the referent. > > This change provides performance benefits by eliminating the work > involved in keeping the otherwise inaccessible referent objects alive, > as required by the existing specification. This not only immediately > removes some work, but may enable further performance improvements. > It also allows the referent objects to be immediately reclaimed in > the GC cycle in which they were determined to be inaccessible, rather > than lingering as a form of floating garbage until the application > deals with the notified reference. > > This change results in a behavioral change to application code, as > demonstrated by the associated test. Under the old specification, a > reference R with referent X may be kept alive because it is referenced > by an otherwise inaccessible referent Y of phantom reference P. This > will result in X being treated as strongly referenced and prevent R > from being notified, even if R is a phantom reference and X has become > inaccessible to the application. With this change, Y is reclaimed > when it becomes inaccessible and P is notified, and no longer prevents > X from itself becoming a candidate for reclaimation once it is no > longer accessible to the application. While this is a change in > behavior, it seems unlikely to affect applications negatively. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8071507 > > Webrevs: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/ > http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ > > Testing: > jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Thu Dec 3 13:55:20 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 3 Dec 2015 13:55:20 +0000 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> Hi Kim, I really would appreciate if we could get this fixed soon. Maybe we can submit my version and if we put a comment into 8135181 that points to this change, the questionable casts can be identified later on, too. The broken build hinders our work. I have to manually fix our nightbuilds all the time, and my colleagues stomped into this and fixed it in their workspace locally. Any webrev we prepare we have to patch with this change ... So I really would like to see this resolved. The change is now pending since 19.11. I rebased my webrev, which also contains some more casts for issues poping up since my first attempt to fix this: http://cr.openjdk.java.net/~goetz/webrevs/8143215-gcc412/webrev.01/ (Kim, you've seen this before). Best regards, Goetz > -----Original Message----- > From: Kim Barrett [mailto:kim.barrett at oracle.com] > Sent: Freitag, 20. November 2015 02:05 > To: Lindenmaier, Goetz > Cc: hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. > > On Nov 19, 2015, at 4:44 AM, Lindenmaier, Goetz > wrote: > > > > OK, so I went back and checked it all ... > > 1.) -Wconversion is set since ever: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/3e82d72933d0 > > 2.) The warning is not triggered by -Wconversion, it is enabled per default > in gcc 4.1.2: > > Does the warning still occur if -Wconversion is explicitly turn it > off, e.g. add -Wno-conversion? Unfortunately, after reading these > > http://lists.apple.com/archives/xcode-users/2005/Oct/msg00147.html > https://gcc.gnu.org/wiki/NewWconversion > > I suspect it does, which would be unfortunate. But confirmation would > be helpful, and would strongly affect my opinion about how to proceed. > > [Note that the NewWconversion page suggests we really ought not be > using the pre-gcc4.3 -Wconversion either. But if -Wno-conversion > doesn't do anything useful for you then that's a separate issue.] > > An important (to me) reason to not hide these warnings via unchecked > casts is that doing so makes it harder to properly address > JDK-8135181, because some of the places that ought to be modified as > part of that will be harder to find. > > > And I would really appreciate if the following two issues could be kept > separate: > > > > - Decision what compiler is supported with which settings. > > - Fixes for a supported compiler/flag combination. > > I don't think those are separable. If a particular configuration > rejects otherwise working code, then the configuration ought to be > looked at. Even if it's decided that the code must be changed rather > than the configuration, if the modified code is clearly a workaround > rather than a "natural" alternative, I think the workaround should be > made obvious and traceable to the problematic configuration. > Otherwise, future readers cannot tell whether the code is odd for a > good reason, and the workaround is hard to clean up in the future. > > The fact that this particular problem has been cropping up repeatedly > suggests to me that some concerted effort should be applied to the > problem. I spent a little bit of time today prototyping an > integer_cast function, which would cover most of the cases mentioned > in JDK-8135181 and all in the changeset under discussion. It doesn't > look too difficult, but I haven't finished or really tested it yet. From thomas.schatzl at oracle.com Thu Dec 3 14:03:14 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 03 Dec 2015 15:03:14 +0100 Subject: RFR (XXS): 8144583: Test sanity/ExecuteInternalVMTests.java fails Message-ID: <1449151394.2385.34.camel@oracle.com> Hi all, can I have reviews for this removal of an internal VM test that is susceptible to races with the application? It uses some global data structures (the PRT free list), and depending on the activity of the application, the guarantee in there may fail. As fix I removed the test completely. There is no way this issue can be fixed with a reasonable effort, and that part of the remset code is planned to be removed anyway. CR: https://bugs.openjdk.java.net/browse/JDK-8144583 Webrev: http://cr.openjdk.java.net/~tschatzl/8144583/webrev/ Testing: local builds Thanks, Thomas From jesper.wilhelmsson at oracle.com Thu Dec 3 14:22:33 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 3 Dec 2015 15:22:33 +0100 Subject: RFR (XXS): 8144583: Test sanity/ExecuteInternalVMTests.java fails In-Reply-To: <1449151394.2385.34.camel@oracle.com> References: <1449151394.2385.34.camel@oracle.com> Message-ID: <56605029.8060705@oracle.com> Looks good! /Jesper Den 3/12/15 kl. 15:03, skrev Thomas Schatzl: > Hi all, > > can I have reviews for this removal of an internal VM test that is > susceptible to races with the application? It uses some global data > structures (the PRT free list), and depending on the activity of the > application, the guarantee in there may fail. > > As fix I removed the test completely. There is no way this issue can be > fixed with a reasonable effort, and that part of the remset code is > planned to be removed anyway. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8144583 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8144583/webrev/ > Testing: > local builds > > Thanks, > Thomas > From stefan.johansson at oracle.com Thu Dec 3 15:50:25 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 3 Dec 2015 16:50:25 +0100 Subject: RFR: 8144584: Change FilterIntoCSClosure to inherit OopClosure Message-ID: <566064C1.5030107@oracle.com> Hi, Please review this change for: https://bugs.openjdk.java.net/browse/JDK-8144584 Webrev: http://cr.openjdk.java.net/~sjohanss/8138888/8144584/hotspot.00/ Background: When iterating objects with oop_iterate() there is a special case for InstanceRefKlass, if the closure overrides apply_to_weak_ref_discovered_field() to return true, the closure will be applied to the discovered field, even if the normal checks prevents it. This special treatment is needed in certain situations, but it is not obvious if it should be done when iterating the object. Currently only G1 closures override apply_to_weak_ref_discovered_field() and many of them seem to do it without any reason. My initial plan [1] was to remove all usage of this special casing but after discussions I realized it would be easier to see the effects if doing this one closure at a time. Summary: FilterIntoCSClosure is yet another closure that inherits ExtendedOopClosure, but is only used as an OopClosure. The closure is now days only used in one place and the DirtyCardToOopClosure* member is never initialized or used so I removed it. Testing: * JPRT * RBT Thanks, Stefan [1] https://bugs.openjdk.java.net/browse/JDK-8138888 From alexander.harlap at oracle.com Thu Dec 3 16:20:08 2015 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Thu, 3 Dec 2015 11:20:08 -0500 Subject: Request for code review - JDK-8141123 Change int's to size_t in FreeIdSet In-Reply-To: <229C649D-7269-422E-9D52-3E614002DD10@oracle.com> References: <5627EB64.1070704@oracle.com> <5640D3F2.3080601@oracle.com> <56439D48.5000105@oracle.com> <1447320920.2312.29.camel@oracle.com> <1448536437.2100.27.camel@oracle.com> <565E06ED.2080309@oracle.com> <229C649D-7269-422E-9D52-3E614002DD10@oracle.com> Message-ID: <56606BB8.7090706@oracle.com> Hi Kim, Actually existing code is correct. We should look at FreeIdSet::claim_par_id() to see it: uint FreeIdSet::claim_par_id() { MutexLockerEx x(_mon, Mutex::_no_safepoint_check_flag); while (_hd == end_of_list) { _waiters++; _mon->wait(Mutex::_no_safepoint_check_flag); _waiters--; } uint res = _hd; _hd = _ids[res]; _ids[res] = claimed; // For debugging. _claimed++; return res; } Let assume size=1. At first call to claim_par_id() it will return 0, but it cannot return 1 ( desired behavior) If we follow you suggestion, than at size=1 At first call to claim_par_id() it will return 0, and at sequential (without call to release_par_id()) it will return 1 - wrong behavior. Thank you, Alex On 12/2/2015 2:22 PM, Kim Barrett wrote: > On Dec 1, 2015, at 3:45 PM, Alexander Harlap wrote: >> Here is new version, to satisfy comments of Thomas, Kim and Tom. >> I hope it is better now. >> >> http://cr.openjdk.java.net/~aharlap/8141123/webrev.04/ > ------------------------------------------------------------------------------ > src/share/vm/gc/shared/workgroup.cpp > 504 FreeIdSet::FreeIdSet(uint size, Monitor* mon) : > ... > 508 _ids = NEW_C_HEAP_ARRAY(uint, size, mtGC); > 509 for (uint i = 0; i < size - 1; i++) { > ... > 512 _ids[size-1] = end_of_list; // end of list. > > [Pre-existing issue] > I think the allocation should be size+1, the iteration limit should be > size, and the end_of_list sentinal installed at _ids[size]. As it is > now, the set size is actually one less than size. This would be > particularly problematic if the set were given a size of one. Since > the only caller uses the number of processors as the size, the set > would be empty if there were only one processor. That's not really > the target audience for G1, but still... > > Sorry I missed this earlier. > From tom.benson at oracle.com Thu Dec 3 16:40:51 2015 From: tom.benson at oracle.com (Tom Benson) Date: Thu, 3 Dec 2015 11:40:51 -0500 Subject: RFR (M): 8060697: Improve G1 Heap Growth Heuristics In-Reply-To: <1449057651.2642.86.camel@oracle.com> References: <5653D33D.3090906@oracle.com> <1449056510.2642.75.camel@oracle.com> <1449057651.2642.86.camel@oracle.com> Message-ID: <56607093.3010102@oracle.com> Hi Thomas, Thanks very much for the review. Updated webrevs (including the suggestions from Kim and Jon) are in: http://cr.openjdk.java.net/~tbenson/8060697/webrev.01.vs.00/ - incremental http://cr.openjdk.java.net/~tbenson/8060697/webrev.01/ - full Comments in line: On 12/2/2015 7:00 AM, Thomas Schatzl wrote: > Hi again, > > another comment: do you mind changing the early return in > g1CollectorPolicy.cpp:1614 to an assignment to some kind of > result-variable (e.g. expand_bytes initialized to zero), and add the > remainder of that method in an else-block? > > The new expansion_amount() method seems to have grown significantly in > size, and I am actually not really happy with that. > > Particularly I am not really fond of early return in large methods (i.e. > I think some hidden request to look at possibilities to split that > method into useful parts, try to separate out conditions etc). > > However, if you like it better the current way, that would be fine with > me too. OK, I've eliminated the early return. I don't think the method is *that* large if you take out all the block comments and block of constant decls. 8^) > > Thanks, > Thomas > > On Wed, 2015-12-02 at 12:41 +0100, Thomas Schatzl wrote: >> Hi Tom, >> >> On Mon, 2015-11-23 at 22:02 -0500, Tom Benson wrote: >>> Hi, >>> Here is a proposed change to the G1 heap growth code for review. I've >>> added a detailed description to the CR, but here is the short version: >>> After a GC pause, the average ratio of time spent in recent GC pauses vs >>> overall time is computed. If it exceeds GCTimeRatio, the heap is >>> expanded by a fixed amount. With the new code, some deficiencies in the >>> ratio tracking are addressed, and the expansion size is scaled according >>> to how much the desired ratio is, on average, exceeded by. The target >>> ratio itself is also scaled at the lowest heap sizes. >>> >>> The case that triggered this was actually JDK-8132077, where the JVM'08 >>> Compress benchmark saw a 40% degradation. It was due to the heap being >>> about half the size in some runs, because of the way heap growth worked. >>> >>> I'm still collecting the final performance data for this version, and >>> will attach it to the CR. Earlier experimental versions showed good >>> improvements in consistency of heap sizes. A couple of benchmarks >>> average a percentage point or two lower, while others improve by that >>> much or more. No growth percentage or scaling is going to be ideal for >>> every test, but the goal was to maintain performance without growing too >>> large. In fact, some tests now use much smaller heaps. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8060697 >>> Webrev: >>> http://cr.openjdk.java.net/~tbenson/8060697/webrev/ >>> >>> Testing: >> Some potential improvements: >> >> - maybe extract the "_ratio_check_window_count == >> NumPrevPausesForHeuristics" term to a meaningful local variable to >> improve readability. E.g. max_window_samples_reached or something. >> >> Or add a new constant in that enum for that bound >> (MaxExpansionCheckWindowCount or whatever) so that it becomes clear(er) >> what this term is used for. I added a boolean filled_history_buffer to represent that the count has reached the limit. >> >> - of the new member variables, it would be nice to document that >> _ratio_over_threshold* is about tracking exceeding the threshold short >> term, and _ratio_check_window_count about "long term". >> >> Maybe actually including "short" or "long"-term or "burst" words in the >> names. I changed the name of _ratio_check_window_count to _pauses_since_start to tie it more to NumPrevPausesForHeuristics. I think that, plus the comment I added at the definition of MinOverThresholdForGrowth should make it a little clearer. I didn't want to use "short/long" because we're really talking about 4 vs 10, and the 10 is also used in the definition of recent_gc_times, so it's not really "long". >> >> That would probably make it more clear why the value for >> MinOverThresholdForGrowth has been chosen to be smaller than >> NumPrevPausesForHeuristics (used for exceeding the threshold >> "long-term"). I added a comment that should help. >> >> - the G1CollectorPolicy constructor may also call >> clear_ratio_check_data() instead of manually resetting in the >> initializer list. Done. >> >> - I would prefer if _last_pause_time_ratio and its calculation were >> documented better. In the answer to Jon in the other email you clearly >> described why the _last_pause_time_ratio is calculated as it is. That is >> missing somewhere. >> >> // Compute the ratio of just this last pause time to the entire time >> // range stored in the vectors. >> >> Seems to mostly repeat what the code does. Done. >> >> - the last_pause_time_ratio() getter seems to be superfluous as nobody >> from outside G1CollectorPolicy accesses it. OK, took it out. >> >> Looks good otherwise. > sans the "static" variable comment from Kim. > > Thanks, > Thomas > > Thanks, Tom From mandy.chung at oracle.com Thu Dec 3 17:01:02 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Dec 2015 09:01:02 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <56603D28.6040206@gmail.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> Message-ID: <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> > On Dec 3, 2015, at 5:01 AM, Peter Levart wrote: > > I would only rephrase this statement in package-info.java a bit: > > 96 * Soft and weak references are automatically cleared by the collector > 97 * before being added to the queues with which they are registered, if any, > 98 * hence they need not be registered with a queue in order to be useful. > 99 * Phantom references, by contrast, do not allow their referents to be > 100 * retrieved, so they must be registered with a queue. Kim brought up the potential confusion on the above wordings. To me this is clear when I read it as a fresh reader (not comparing the before and after). The confusion could be due to the section header ?Automatically-cleared references?. This paragraph talks about the need of registering references (soft/weak refs vs phantom refs). I thought about (1) changing the section header to ?Registering references?, or (2) a small rewording like this: *

Automatically-cleared references

* - * Soft and weak references are automatically cleared by the collector - * before being added to the queues with which they are registered, if - * any. Therefore soft and weak references need not be registered - * with a queue in order to be useful, while phantom references do. - * An object that is reachable via phantom references will remain so - * until all such references are cleared or themselves become - * unreachable. + * References are automatically cleared by the collector before being + * added to the queues with which they are registered, if any. + * Soft and weak references allow their referents to be retrieved, + * hence they need not be registered with a queue in order to be useful. + * Phantom references, by contrast, do not allow their referents to be + * retrieved, so they must be registered with a queue. Mandy From mikael.vidstedt at oracle.com Thu Dec 3 17:33:24 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 3 Dec 2015 09:33:24 -0800 Subject: RFR (XS): 8144605: Invalid format specifier when printing in_cset_state_t Message-ID: <56607CE4.6050402@oracle.com> Please review this small change which fixes the format specifier used when printing in_cset_state_t values. The size of the in_cset_state_t type is platform specific, and in particular it is an intptr_t on SPARC, meaning %d won't cut it. There's already a helpful CSETSTATE_FORMAT macro definition, and this change just updates to use that. Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8144605/webrev.00/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8144605 Cheers, Mikael From peter.levart at gmail.com Thu Dec 3 18:14:36 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 3 Dec 2015 19:14:36 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> Message-ID: <5660868C.3050509@gmail.com> On 12/03/2015 06:01 PM, Mandy Chung wrote: >> On Dec 3, 2015, at 5:01 AM, Peter Levart wrote: >> >> I would only rephrase this statement in package-info.java a bit: >> >> 96 * Soft and weak references are automatically cleared by the collector >> 97 * before being added to the queues with which they are registered, if any, >> 98 * hence they need not be registered with a queue in order to be useful. >> 99 * Phantom references, by contrast, do not allow their referents to be >> 100 * retrieved, so they must be registered with a queue. > Kim brought up the potential confusion on the above wordings. To me this is clear when I read it as a fresh reader (not comparing the before and after). The confusion could be due to the section header ?Automatically-cleared references?. This paragraph talks about the need of registering references (soft/weak refs vs phantom refs). I thought about (1) changing the section header to ?Registering references?, or (2) a small rewording like this: > > *

Automatically-cleared references

> * > - * Soft and weak references are automatically cleared by the collector > - * before being added to the queues with which they are registered, if > - * any. Therefore soft and weak references need not be registered > - * with a queue in order to be useful, while phantom references do. > - * An object that is reachable via phantom references will remain so > - * until all such references are cleared or themselves become > - * unreachable. > + * References are automatically cleared by the collector before being > + * added to the queues with which they are registered, if any. > + * Soft and weak references allow their referents to be retrieved, > + * hence they need not be registered with a queue in order to be useful. > + * Phantom references, by contrast, do not allow their referents to be > + * retrieved, so they must be registered with a queue. Or: ..., so they are only useful if they are registered with a queue. Better, yes. Regards, Peter > Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Thu Dec 3 19:59:50 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 3 Dec 2015 14:59:50 -0500 Subject: Request for code review - JDK-8141123 Change int's to size_t in FreeIdSet In-Reply-To: <56606BB8.7090706@oracle.com> References: <5627EB64.1070704@oracle.com> <5640D3F2.3080601@oracle.com> <56439D48.5000105@oracle.com> <1447320920.2312.29.camel@oracle.com> <1448536437.2100.27.camel@oracle.com> <565E06ED.2080309@oracle.com> <229C649D-7269-422E-9D52-3E614002DD10@oracle.com> <56606BB8.7090706@oracle.com> Message-ID: <2B2EB965-0A58-4E3D-BF81-188F6C016794@oracle.com> On Dec 3, 2015, at 11:20 AM, Alexander Harlap wrote: > > Hi Kim, > > Actually existing code is correct. We should look at FreeIdSet::claim_par_id() to see it: You are correct; the code was more clever than I was yesterday. OK, changes look good. From kim.barrett at oracle.com Thu Dec 3 20:06:10 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 3 Dec 2015 15:06:10 -0500 Subject: Request for code review - JDK-8141123 Change int's to size_t in FreeIdSet In-Reply-To: <1449092652.4376.18.camel@oracle.com> References: <5627EB64.1070704@oracle.com> <5640D3F2.3080601@oracle.com> <56439D48.5000105@oracle.com> <1447320920.2312.29.camel@oracle.com> <1448536437.2100.27.camel@oracle.com> <1DC292EE-6A66-4C82-A7C9-C0572B73B4A9@oracle.com> <1449045349.2642.14.camel@oracle.com> <1449092652.4376.18.camel@oracle.com> Message-ID: <7B807ECE-45C8-4480-8E36-9B72B16B955B@oracle.com> On Dec 2, 2015, at 4:44 PM, Thomas Schatzl wrote: > > On Wed, 2015-12-02 at 16:08 -0500, Kim Barrett wrote: >> Attempting to eliminate FreeIdSet certainly has appeal. However, I >> don't have any intuition about the importance of the FromCardCache, > > The fromcardcache caches for every combination of thread id and region > which card has most recently been added to the remembered set. > > It purely acts as a filter of repeated attempts to add the same card by > the same thread to the remembered set. It seems to be quite effective at > doing so in many cases. That confirms my understanding of what it does. Thanks. It helps when several locations covered by a card refer to objects that are in the same region. And that does seem like a common case. We can take further discussion elsewhere and let this review thread be closed out. From kim.barrett at oracle.com Thu Dec 3 20:08:03 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 3 Dec 2015 15:08:03 -0500 Subject: RFR (M): 8060697: Improve G1 Heap Growth Heuristics In-Reply-To: <56607093.3010102@oracle.com> References: <5653D33D.3090906@oracle.com> <1449056510.2642.75.camel@oracle.com> <1449057651.2642.86.camel@oracle.com> <56607093.3010102@oracle.com> Message-ID: <0AB0B848-BAFC-4A3F-B14B-8845C6FCFFE0@oracle.com> On Dec 3, 2015, at 11:40 AM, Tom Benson wrote: > > Hi Thomas, > Thanks very much for the review. Updated webrevs (including the suggestions from Kim and Jon) are in: > > http://cr.openjdk.java.net/~tbenson/8060697/webrev.01.vs.00/ - incremental > http://cr.openjdk.java.net/~tbenson/8060697/webrev.01/ - full One minor comment, which you can use or ignore. Otherwise, looks better than the last time I thought it looked good. ------------------------------------------------------------------------------ src/share/vm/gc/g1/g1CollectorPolicy.cpp 1627 threshold *= (double)_g1->capacity() / (double)(_g1->max_capacity() / 2); Changing "2" => "2.0" would make both casts to double redundant, assuming the round-down in "(_g1->max_capacity() / 2)" isn't important. From alexander.harlap at oracle.com Thu Dec 3 20:57:00 2015 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Thu, 3 Dec 2015 15:57:00 -0500 Subject: Need a sponsor for push 8141123 into jd9/hs-rt Message-ID: <5660AC9C.4070408@oracle.com> I need a sponsor to push attached 8141123 - Cleanup in FreeIdSet Alex -------------- next part -------------- # HG changeset patch # User aharlap # Date 1449175072 18000 # Node ID 9f985b855fcb54d0d32f3708015f1cae40dc3658 # Parent 3148b7fc645f35c158fa287426b2de64281ec131 8141123: Cleanup in FreeIdSet Summary: Some members of FreeIdSet should be size_t instead of ints. Also remove unused code Reviewed-by: tschatzl, kbarrett, tbenson diff -r 3148b7fc645f -r 9f985b855fcb src/share/vm/gc/g1/dirtyCardQueue.cpp --- a/src/share/vm/gc/g1/dirtyCardQueue.cpp Wed Dec 02 10:17:31 2015 +0100 +++ b/src/share/vm/gc/g1/dirtyCardQueue.cpp Thu Dec 03 15:37:52 2015 -0500 @@ -112,7 +112,7 @@ fl_owner); set_buffer_size(G1UpdateBufferSize); _shared_dirty_card_queue.set_lock(lock); - _free_ids = new FreeIdSet((int) num_par_ids(), _cbl_mon); + _free_ids = new FreeIdSet(num_par_ids(), _cbl_mon); } void DirtyCardQueueSet::handle_zero_index_for_thread(JavaThread* t) { diff -r 3148b7fc645f -r 9f985b855fcb src/share/vm/gc/shared/workgroup.cpp --- a/src/share/vm/gc/shared/workgroup.cpp Wed Dec 02 10:17:31 2015 +0100 +++ b/src/share/vm/gc/shared/workgroup.cpp Thu Dec 03 15:37:52 2015 -0500 @@ -501,122 +501,42 @@ return false; } -bool FreeIdSet::_stat_init = false; -FreeIdSet* FreeIdSet::_sets[NSets]; -bool FreeIdSet::_safepoint; - -FreeIdSet::FreeIdSet(int sz, Monitor* mon) : - _sz(sz), _mon(mon), _hd(0), _waiters(0), _index(-1), _claimed(0) +FreeIdSet::FreeIdSet(uint size, Monitor* mon) : + _size(size), _mon(mon), _hd(0), _waiters(0), _claimed(0) { - _ids = NEW_C_HEAP_ARRAY(int, sz, mtInternal); - for (int i = 0; i < sz; i++) _ids[i] = i+1; - _ids[sz-1] = end_of_list; // end of list. - if (_stat_init) { - for (int j = 0; j < NSets; j++) _sets[j] = NULL; - _stat_init = true; + guarantee(size != 0, "must be"); + _ids = NEW_C_HEAP_ARRAY(uint, size, mtGC); + for (uint i = 0; i < size - 1; i++) { + _ids[i] = i+1; } - // Add to sets. (This should happen while the system is still single-threaded.) - for (int j = 0; j < NSets; j++) { - if (_sets[j] == NULL) { - _sets[j] = this; - _index = j; - break; - } - } - guarantee(_index != -1, "Too many FreeIdSets in use!"); + _ids[size-1] = end_of_list; // end of list. } FreeIdSet::~FreeIdSet() { - _sets[_index] = NULL; - FREE_C_HEAP_ARRAY(int, _ids); + FREE_C_HEAP_ARRAY(uint, _ids); } -void FreeIdSet::set_safepoint(bool b) { - _safepoint = b; - if (b) { - for (int j = 0; j < NSets; j++) { - if (_sets[j] != NULL && _sets[j]->_waiters > 0) { - Monitor* mon = _sets[j]->_mon; - mon->lock_without_safepoint_check(); - mon->notify_all(); - mon->unlock(); - } - } - } -} - -#define FID_STATS 0 - -int FreeIdSet::claim_par_id() { -#if FID_STATS - thread_t tslf = thr_self(); - tty->print("claim_par_id[%d]: sz = %d, claimed = %d\n", tslf, _sz, _claimed); -#endif +uint FreeIdSet::claim_par_id() { MutexLockerEx x(_mon, Mutex::_no_safepoint_check_flag); - while (!_safepoint && _hd == end_of_list) { + while (_hd == end_of_list) { _waiters++; -#if FID_STATS - if (_waiters > 5) { - tty->print("claim_par_id waiting[%d]: %d waiters, %d claimed.\n", - tslf, _waiters, _claimed); - } -#endif _mon->wait(Mutex::_no_safepoint_check_flag); _waiters--; } - if (_hd == end_of_list) { -#if FID_STATS - tty->print("claim_par_id[%d]: returning EOL.\n", tslf); -#endif - return -1; - } else { - int res = _hd; - _hd = _ids[res]; - _ids[res] = claimed; // For debugging. - _claimed++; -#if FID_STATS - tty->print("claim_par_id[%d]: returning %d, claimed = %d.\n", - tslf, res, _claimed); -#endif - return res; - } + uint res = _hd; + _hd = _ids[res]; + _ids[res] = claimed; // For debugging. + _claimed++; + return res; } -bool FreeIdSet::claim_perm_id(int i) { - assert(0 <= i && i < _sz, "Out of range."); - MutexLockerEx x(_mon, Mutex::_no_safepoint_check_flag); - int prev = end_of_list; - int cur = _hd; - while (cur != end_of_list) { - if (cur == i) { - if (prev == end_of_list) { - _hd = _ids[cur]; - } else { - _ids[prev] = _ids[cur]; - } - _ids[cur] = claimed; - _claimed++; - return true; - } else { - prev = cur; - cur = _ids[cur]; - } - } - return false; - -} - -void FreeIdSet::release_par_id(int id) { +void FreeIdSet::release_par_id(uint id) { MutexLockerEx x(_mon, Mutex::_no_safepoint_check_flag); assert(_ids[id] == claimed, "Precondition."); _ids[id] = _hd; _hd = id; _claimed--; -#if FID_STATS - tty->print("[%d] release_par_id(%d), waiters =%d, claimed = %d.\n", - thr_self(), id, _waiters, _claimed); -#endif - if (_waiters > 0) - // Notify all would be safer, but this is OK, right? + if (_waiters > 0) { _mon->notify_all(); + } } diff -r 3148b7fc645f -r 9f985b855fcb src/share/vm/gc/shared/workgroup.hpp --- a/src/share/vm/gc/shared/workgroup.hpp Wed Dec 02 10:17:31 2015 +0100 +++ b/src/share/vm/gc/shared/workgroup.hpp Thu Dec 03 15:37:52 2015 -0500 @@ -379,42 +379,29 @@ }; // Represents a set of free small integer ids. -class FreeIdSet : public CHeapObj { +class FreeIdSet : public CHeapObj { enum { - end_of_list = -1, - claimed = -2 + end_of_list = UINT_MAX, + claimed = UINT_MAX - 1 }; - int _sz; + uint _size; Monitor* _mon; - int* _ids; - int _hd; - int _waiters; - int _claimed; - - static bool _safepoint; - typedef FreeIdSet* FreeIdSetPtr; - static const int NSets = 10; - static FreeIdSetPtr _sets[NSets]; - static bool _stat_init; - int _index; + uint* _ids; + uint _hd; + uint _waiters; + uint _claimed; public: - FreeIdSet(int sz, Monitor* mon); + FreeIdSet(uint size, Monitor* mon); ~FreeIdSet(); - static void set_safepoint(bool b); + // Returns an unclaimed parallel id (waiting for one to be released if + // necessary). + uint claim_par_id(); - // Attempt to claim the given id permanently. Returns "true" iff - // successful. - bool claim_perm_id(int i); - - // Returns an unclaimed parallel id (waiting for one to be released if - // necessary). Returns "-1" if a GC wakes up a wait for an id. - int claim_par_id(); - - void release_par_id(int id); + void release_par_id(uint id); }; #endif // SHARE_VM_GC_SHARED_WORKGROUP_HPP From kim.barrett at oracle.com Thu Dec 3 22:33:10 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 3 Dec 2015 17:33:10 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <5660868C.3050509@gmail.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> Message-ID: <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> On Dec 3, 2015, at 1:14 PM, Peter Levart wrote: > > On 12/03/2015 06:01 PM, Mandy Chung wrote: >>> On Dec 3, 2015, at 5:01 AM, Peter Levart >>> wrote: >>> >>> I would only rephrase this statement in package-info.java a bit: >>> >>> 96 * Soft and weak references are automatically cleared by the collector >>> 97 * before being added to the queues with which they are registered, if any, >>> 98 * hence they need not be registered with a queue in order to be useful. >>> 99 * Phantom references, by contrast, do not allow their referents to be >>> 100 * retrieved, so they must be registered with a queue. >>> >> Kim brought up the potential confusion on the above wordings. [?] >> >> *

Automatically-cleared references

>> * >> - * Soft and weak references are automatically cleared by the collector >> - * before being added to the queues with which they are registered, if >> - * any. Therefore soft and weak references need not be registered >> - * with a queue in order to be useful, while phantom references do. >> - * An object that is reachable via phantom references will remain so >> - * until all such references are cleared or themselves become >> - * unreachable. >> + * References are automatically cleared by the collector before being >> + * added to the queues with which they are registered, if any. >> + * Soft and weak references allow their referents to be retrieved, >> + * hence they need not be registered with a queue in order to be useful. >> + * Phantom references, by contrast, do not allow their referents to be >> + * retrieved, so they must be registered with a queue. >> > > Or: > > ..., so they are only useful if they are registered with a queue. Drawing on the various suggestions so far, how about this: ----- Soft, weak, and phantom references are automatically cleared by the collector before being added to the queues with which they are registered, if any. Soft and weak references allow access to the referent before they are cleared, and hence need not be registered with a queue in order to be useful. Phantom references, by contrast, prevent access to the referent, so they are only useful when registered with a queue. ----- I prefer the explicit list in the opening sentence, rather than collapsing that to just "References", to avoid any possible confusion that this might apply to (the internal and undocumented, but visible in the code) FinalReference. I included a serial comma in the list; I generally prefer that usage, and it's consistent with earlier usage on the same page. In the final sentence, I prefer to avoid the use of "must", especially without any "to be useful" qualification, as that sounds like it might be a formal requirement, and that would be inconsistent with the PhantomReference constructor documentation. The second sentence (about soft and weak references) could be deleted, along with the "by contrast" phrase in the third, without loss of information. It does save the reader a bit of inference though. [Indeed, this whole section isn't strictly necessary; all of it can be inferred from information in other places.] From kim.barrett at oracle.com Thu Dec 3 22:52:44 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 3 Dec 2015 17:52:44 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <56603D28.6040206@gmail.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> Message-ID: <074EE4DF-17FB-46D1-B2C7-33E868E8DEC7@oracle.com> On Dec 3, 2015, at 8:01 AM, Peter Levart wrote: > > Hi Kim, > > Kudos for finding an observable change in behavior. Although the specification could also be read in a way so that this would not be observable. Originally it states: > > "Unlike soft and weak references, phantom references are not automatically cleared by the garbage collector as they are enqueued. An object that is reachable via phantom references will remain so until all such references are cleared or themselves become unreachable." > > I read this as: "... An object that is reachable via phantom references will remain phantom reachable ..." > > If phantom-reachable objects have links among them, this doesn't make them strongly reachable. > > So I would argue that when both roots to O1 and O2 (in the test) are finally removed, O1 and O2 should be considered phantom-reachable, regardless of the link from O1 -> O2. When root to O2 is removed before the 2nd GC round, P2 should be notified as O2 transitions from reachable -> phantom reachable. This is no different from the situation when both roots to O1 and O2 are removed at the same time before a GC round: both P1 and P2 are notified. I don't think that reading is correct. Consider the case of R being a weak (not phantom) reference. In that case, X can never be "phantom reachable", because the definition of that state includes "some phantom reference refers to it". If, in the scenario described, the reference from O to X did not prevent (the weak) R from being cleared and notified, the special rule for phantom references would have no visible impact. In which case we wouldn't need to change the specification; we could just change the implementation and claim there was no specified visible difference. From kim.barrett at oracle.com Thu Dec 3 22:53:27 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 3 Dec 2015 17:53:27 -0500 Subject: Need a sponsor for push 8141123 into jd9/hs-rt In-Reply-To: <5660AC9C.4070408@oracle.com> References: <5660AC9C.4070408@oracle.com> Message-ID: <16DB2341-2162-422E-A1DD-7347FC9BCAD9@oracle.com> On Dec 3, 2015, at 3:57 PM, Alexander Harlap wrote: > > I need a sponsor to push attached 8141123 - Cleanup in FreeIdSet I can do that. From Peter.B.Kessler at Oracle.COM Thu Dec 3 22:59:04 2015 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Thu, 03 Dec 2015 14:59:04 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> Message-ID: <5660C938.7030309@Oracle.COM> On 12/ 3/15 02:33 PM, Kim Barrett wrote: > On Dec 3, 2015, at 1:14 PM, Peter Levart wrote: >> >> On 12/03/2015 06:01 PM, Mandy Chung wrote: >>>> On Dec 3, 2015, at 5:01 AM, Peter Levart >>>> wrote: >>>> >>>> I would only rephrase this statement in package-info.java a bit: >>>> >>>> 96 * Soft and weak references are automatically cleared by the collector >>>> 97 * before being added to the queues with which they are registered, if any, >>>> 98 * hence they need not be registered with a queue in order to be useful. >>>> 99 * Phantom references, by contrast, do not allow their referents to be >>>> 100 * retrieved, so they must be registered with a queue. >>>> >>> Kim brought up the potential confusion on the above wordings. [?] >>> >>> *

Automatically-cleared references

>>> * >>> - * Soft and weak references are automatically cleared by the collector >>> - * before being added to the queues with which they are registered, if >>> - * any. Therefore soft and weak references need not be registered >>> - * with a queue in order to be useful, while phantom references do. >>> - * An object that is reachable via phantom references will remain so >>> - * until all such references are cleared or themselves become >>> - * unreachable. >>> + * References are automatically cleared by the collector before being >>> + * added to the queues with which they are registered, if any. >>> + * Soft and weak references allow their referents to be retrieved, >>> + * hence they need not be registered with a queue in order to be useful. >>> + * Phantom references, by contrast, do not allow their referents to be >>> + * retrieved, so they must be registered with a queue. >>> >> >> Or: >> >> ..., so they are only useful if they are registered with a queue. > > Drawing on the various suggestions so far, how about this: > > ----- > > Soft, weak, and phantom references are automatically cleared by the > collector before being added to the queues with which they are > registered, if any. Soft and weak references allow access to the > referent before they are cleared, and hence need not be registered > with a queue in order to be useful. Phantom references, by contrast, > prevent access to the referent, so they are only useful when > registered with a queue. > > ----- > > I prefer the explicit list in the opening sentence, rather than > collapsing that to just "References", to avoid any possible confusion > that this might apply to (the internal and undocumented, but visible > in the code) FinalReference. > > I included a serial comma in the list; I generally prefer that usage, > and it's consistent with earlier usage on the same page. > > In the final sentence, I prefer to avoid the use of "must", especially > without any "to be useful" qualification, as that sounds like it might > be a formal requirement, and that would be inconsistent with the > PhantomReference constructor documentation. > > The second sentence (about soft and weak references) could be deleted, > along with the "by contrast" phrase in the third, without loss of > information. It does save the reader a bit of inference though. In a paragraph about when references are cleared and queued, the important point is that you can tell whether the referent of a soft or weak reference is no longer reachable either by testing whether get() returns null, or by polling the queue for the reference. In contrast, phantom references always return null from get(), so to determine if the referent is no longer reachable, you have to look at the queue with which the phantom reference was registered. ... peter > > [Indeed, this whole section isn't strictly necessary; all of it can be > inferred from information in other places.] From mandy.chung at oracle.com Thu Dec 3 23:04:22 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Dec 2015 15:04:22 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> Message-ID: > On Dec 3, 2015, at 2:33 PM, Kim Barrett wrote: > > I prefer the explicit list in the opening sentence, rather than > collapsing that to just "References", to avoid any possible confusion > that this might apply to (the internal and undocumented, but visible > in the code) FinalReference. The explicit list was what I tried to avoid as it?s repeated in the other sentences. FinalReference is not part of java.lang.ref spec and I don?t think it could cause any confusion. > > I included a serial comma in the list; I generally prefer that usage, > and it's consistent with earlier usage on the same page. > > In the final sentence, I prefer to avoid the use of "must", especially > without any "to be useful" qualification, as that sounds like it might > be a formal requirement, and that would be inconsistent with the > PhantomReference constructor documentation. > > The second sentence (about soft and weak references) could be deleted, > along with the "by contrast" phrase in the third, without loss of > information. It does save the reader a bit of inference though. > > [Indeed, this whole section isn't strictly necessary; all of it can be > inferred from information in other places.] Agree. This section is no longer necessary and maybe just remove it: --- a/src/java.base/share/classes/java/lang/ref/package-info.java +++ b/src/java.base/share/classes/java/lang/ref/package-info.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 2003, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1998, 2015, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -43,8 +43,7 @@ * implementing memory-sensitive caches, weak references are for * implementing canonicalizing mappings that do not prevent their keys * (or values) from being reclaimed, and phantom references are for - * scheduling pre-mortem cleanup actions in a more flexible way than - * is possible with the Java finalization mechanism. + * scheduling post-mortem cleanup actions. * *

Each reference-object type is implemented by a subclass of the * abstract base {@link java.lang.ref.Reference} class. @@ -64,9 +63,9 @@ * object with a reference queue at the time the reference * object is created. Some time after the garbage collector * determines that the reachability of the referent has changed to the - * value corresponding to the type of the reference, it will add the - * reference to the associated queue. At this point, the reference is - * considered to be enqueued. The program may remove + * value corresponding to the type of the reference, it will clear the + * reference and add it to the associated queue. At this point, the + * reference is considered to be enqueued. The program may remove * references from a queue either by polling or by blocking until a * reference becomes available. Reference queues are implemented by * the {@link java.lang.ref.ReferenceQueue} class. @@ -92,16 +91,6 @@ * structure, this check will add little overhead to the hashtable * access methods. * - *

Automatically-cleared references

- * - * Soft and weak references are automatically cleared by the collector - * before being added to the queues with which they are registered, if - * any. Therefore soft and weak references need not be registered - * with a queue in order to be useful, while phantom references do. - * An object that is reachable via phantom references will remain so - * until all such references are cleared or themselves become - * unreachable. - * * *

Reachability

* Mandy From mikael.vidstedt at oracle.com Fri Dec 4 00:08:52 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 3 Dec 2015 16:08:52 -0800 Subject: RFR (S): 8144663: Invalid constraints in memset_with_concurrent_readers_sparc.cpp inline assembly Message-ID: <5660D994.4050006@oracle.com> Please review this change which fixes the constraints used in the inline assembly snippets in memset_with_concurrent_readers_sparc.cpp. Bug: https://bugs.openjdk.java.net/browse/JDK-8144663 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8144663/webrev.00/webrev/ The bug has more information, but in short the "+" needs to be the first character in the constraints string, and when used the corresponding constraint needs to be listed in the output constraints. I also took the liberty of clarifying one of the comments a bit, hopefully it's now ever so slightly more clear that the registers listed in the output constraints, while indeed being outputs, are only used as temporaries/are overwritten. Finally, I fixed a couple of comparisons of unsigned vs signed types - BytesPerWord is "unfortunately" signed. Tested using the -XX:+ExecuteInternalVMTests tests. Cheers, Mikael From kim.barrett at oracle.com Fri Dec 4 00:15:40 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 3 Dec 2015 19:15:40 -0500 Subject: RFR (S): 8144663: Invalid constraints in memset_with_concurrent_readers_sparc.cpp inline assembly In-Reply-To: <5660D994.4050006@oracle.com> References: <5660D994.4050006@oracle.com> Message-ID: <9AD84417-BAF3-4712-A0C3-C1C9F8E0E864@oracle.com> On Dec 3, 2015, at 7:08 PM, Mikael Vidstedt wrote: > > > Please review this change which fixes the constraints used in the inline assembly snippets in memset_with_concurrent_readers_sparc.cpp. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8144663 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8144663/webrev.00/webrev/ Looks good. And my apologies for getting the syntax wrong in the first place. From kim.barrett at oracle.com Fri Dec 4 00:25:06 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 3 Dec 2015 19:25:06 -0500 Subject: RFR (XS): 8144605: Invalid format specifier when printing in_cset_state_t In-Reply-To: <56607CE4.6050402@oracle.com> References: <56607CE4.6050402@oracle.com> Message-ID: <64C83D4E-003E-471C-A030-62B37B6CBAA5@oracle.com> On Dec 3, 2015, at 12:33 PM, Mikael Vidstedt wrote: > > > Please review this small change which fixes the format specifier used when printing in_cset_state_t values. The size of the in_cset_state_t type is platform specific, and in particular it is an intptr_t on SPARC, meaning %d won't cut it. There's already a helpful CSETSTATE_FORMAT macro definition, and this change just updates to use that. > > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8144605/webrev.00/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8144605 Looks good. From kim.barrett at oracle.com Fri Dec 4 00:35:33 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 3 Dec 2015 19:35:33 -0500 Subject: RFR: 8144584: Change FilterIntoCSClosure to inherit OopClosure In-Reply-To: <566064C1.5030107@oracle.com> References: <566064C1.5030107@oracle.com> Message-ID: On Dec 3, 2015, at 10:50 AM, Stefan Johansson wrote: > > Hi, > > Please review this change for: > https://bugs.openjdk.java.net/browse/JDK-8144584 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8138888/8144584/hotspot.00/ Looks good. From per.liden at oracle.com Fri Dec 4 07:16:36 2015 From: per.liden at oracle.com (Per Liden) Date: Fri, 4 Dec 2015 08:16:36 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> Message-ID: <56613DD4.40600@oracle.com> Hi Kim, On 2015-12-02 19:37, Kim Barrett wrote: > Please review this change to PhantomReference processing, changing the > GC-based notification to automatically clear the referent. > > This change provides performance benefits by eliminating the work > involved in keeping the otherwise inaccessible referent objects alive, > as required by the existing specification. This not only immediately > removes some work, but may enable further performance improvements. > It also allows the referent objects to be immediately reclaimed in > the GC cycle in which they were determined to be inaccessible, rather > than lingering as a form of floating garbage until the application > deals with the notified reference. > > This change results in a behavioral change to application code, as > demonstrated by the associated test. Under the old specification, a > reference R with referent X may be kept alive because it is referenced > by an otherwise inaccessible referent Y of phantom reference P. This > will result in X being treated as strongly referenced and prevent R > from being notified, even if R is a phantom reference and X has become > inaccessible to the application. With this change, Y is reclaimed > when it becomes inaccessible and P is notified, and no longer prevents > X from itself becoming a candidate for reclaimation once it is no > longer accessible to the application. While this is a change in > behavior, it seems unlikely to affect applications negatively. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8071507 > > Webrevs: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/ test/java/lang/ref/PhantomReferentClearing.java: 85 // Delete root -> O1, collect, verify P1 notified, P2 not notified. 86 O1 = null; 87 System.gc(); 88 if (Q1.remove(ENQUEUE_TIMEOUT) == null) { 89 throw new RuntimeException("P1 not notified by O1 deletion"); 90 } else if (Q2.remove(ENQUEUE_TIMEOUT) != null) { 91 throw new RuntimeException("P2 notified by O1 deletion."); 92 } 93 94 // Delete root -> O2, collect. P2 should be notified. 95 O2 = null; 96 System.gc(); 97 if (Q2.remove(ENQUEUE_TIMEOUT) == null) { 98 throw new RuntimeException("P2 not notified by O2 deletion"); 99 } The calls to System.gc() isn't guaranteed to do what the test expects here. As you know, System.gc(), might not actually do anything, depending on which collector is used and the current circumstances (GC locker held, a concurrent GC is already in process, etc). To make the test robust I'd suggest you call System.gc() and check the queue in a loop, and fail after some reasonable amount of time/iterations. cheers, /Per > http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ > > Testing: > jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK) > From thomas.schatzl at oracle.com Fri Dec 4 08:23:05 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 04 Dec 2015 09:23:05 +0100 Subject: RFR (XS): 8144605: Invalid format specifier when printing in_cset_state_t In-Reply-To: <56607CE4.6050402@oracle.com> References: <56607CE4.6050402@oracle.com> Message-ID: <1449217385.2316.3.camel@oracle.com> Hi, On Thu, 2015-12-03 at 09:33 -0800, Mikael Vidstedt wrote: > Please review this small change which fixes the format specifier used > when printing in_cset_state_t values. The size of the in_cset_state_t > type is platform specific, and in particular it is an intptr_t on SPARC, > meaning %d won't cut it. There's already a helpful CSETSTATE_FORMAT > macro definition, and this change just updates to use that. > > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8144605/webrev.00/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8144605 looks good. Thomas From mikael.gerdin at oracle.com Fri Dec 4 08:42:45 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 4 Dec 2015 09:42:45 +0100 Subject: RFR: 8144584: Change FilterIntoCSClosure to inherit OopClosure In-Reply-To: <566064C1.5030107@oracle.com> References: <566064C1.5030107@oracle.com> Message-ID: <56615205.6010501@oracle.com> Hi Stefan, On 2015-12-03 16:50, Stefan Johansson wrote: > Hi, > > Please review this change for: > https://bugs.openjdk.java.net/browse/JDK-8144584 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8138888/8144584/hotspot.00/ Looks good. /Mikael > > Background: > When iterating objects with oop_iterate() there is a special case for > InstanceRefKlass, if the closure overrides > apply_to_weak_ref_discovered_field() to return true, the closure will be > applied to the discovered field, even if the normal checks prevents it. > This special treatment is needed in certain situations, but it is not > obvious if it should be done when iterating the object. Currently only > G1 closures override apply_to_weak_ref_discovered_field() and many of > them seem to do it without any reason. My initial plan [1] was to remove > all usage of this special casing but after discussions I realized it > would be easier to see the effects if doing this one closure at a time. > > Summary: > FilterIntoCSClosure is yet another closure that inherits > ExtendedOopClosure, but is only used as an OopClosure. The closure is > now days only used in one place and the DirtyCardToOopClosure* member is > never initialized or used so I removed it. > > Testing: > * JPRT > * RBT > > Thanks, > Stefan > > [1] https://bugs.openjdk.java.net/browse/JDK-8138888 From peter.levart at gmail.com Fri Dec 4 12:35:18 2015 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 4 Dec 2015 13:35:18 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <56613DD4.40600@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56613DD4.40600@oracle.com> Message-ID: <56618886.50309@gmail.com> On 12/04/2015 08:16 AM, Per Liden wrote: > > test/java/lang/ref/PhantomReferentClearing.java: > > 85 // Delete root -> O1, collect, verify P1 notified, P2 not > notified. > 86 O1 = null; > 87 System.gc(); > 88 if (Q1.remove(ENQUEUE_TIMEOUT) == null) { > 89 throw new RuntimeException("P1 not notified by O1 > deletion"); > 90 } else if (Q2.remove(ENQUEUE_TIMEOUT) != null) { > 91 throw new RuntimeException("P2 notified by O1 > deletion."); > 92 } > 93 > 94 // Delete root -> O2, collect. P2 should be notified. > 95 O2 = null; > 96 System.gc(); > 97 if (Q2.remove(ENQUEUE_TIMEOUT) == null) { > 98 throw new RuntimeException("P2 not notified by O2 > deletion"); > 99 } > > The calls to System.gc() isn't guaranteed to do what the test expects > here. As you know, System.gc(), might not actually do anything, > depending on which collector is used and the current circumstances (GC > locker held, a concurrent GC is already in process, etc). To make the > test robust I'd suggest you call System.gc() and check the queue in a > loop, and fail after some reasonable amount of time/iterations. Whether you poll the queue for some time T or you remove from queue with timeout of T, it doesn't matter. The Reference(s) are enqueued by a ReferenceHandler thread and the thread waiting in remove() will get notified when a reference gets enqueued... Regards, Peter > > cheers, > /Per > >> http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ >> >> Testing: >> jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK) >> From tom.benson at oracle.com Fri Dec 4 13:48:24 2015 From: tom.benson at oracle.com (Tom Benson) Date: Fri, 4 Dec 2015 08:48:24 -0500 Subject: RFR (M): 8060697: Improve G1 Heap Growth Heuristics In-Reply-To: <0AB0B848-BAFC-4A3F-B14B-8845C6FCFFE0@oracle.com> References: <5653D33D.3090906@oracle.com> <1449056510.2642.75.camel@oracle.com> <1449057651.2642.86.camel@oracle.com> <56607093.3010102@oracle.com> <0AB0B848-BAFC-4A3F-B14B-8845C6FCFFE0@oracle.com> Message-ID: <566199A8.2000508@oracle.com> Hi Kim, Thanks again. In this case, I actually prefer an explicit cast rather than relying on the presence of ".0" at the end of the compound expression to get the correct result. However, I could get rid of the second cast. What would you think of that, and would you want to see a new webrev? Tom On 12/3/2015 3:08 PM, Kim Barrett wrote: > On Dec 3, 2015, at 11:40 AM, Tom Benson wrote: >> Hi Thomas, >> Thanks very much for the review. Updated webrevs (including the suggestions from Kim and Jon) are in: >> >> http://cr.openjdk.java.net/~tbenson/8060697/webrev.01.vs.00/ - incremental >> http://cr.openjdk.java.net/~tbenson/8060697/webrev.01/ - full > One minor comment, which you can use or ignore. Otherwise, looks > better than the last time I thought it looked good. > > ------------------------------------------------------------------------------ > src/share/vm/gc/g1/g1CollectorPolicy.cpp > 1627 threshold *= (double)_g1->capacity() / (double)(_g1->max_capacity() / 2); > > Changing "2" => "2.0" would make both casts to double redundant, > assuming the round-down in "(_g1->max_capacity() / 2)" isn't > important. > > From stefan.johansson at oracle.com Fri Dec 4 14:01:15 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 4 Dec 2015 15:01:15 +0100 Subject: RFR: 8144701: Change three G1 remembererd set closures to be OopClosures Message-ID: <56619CAB.4080103@oracle.com> Hi, Please review this change for: https://bugs.openjdk.java.net/browse/JDK-8144701 Webrev: http://cr.openjdk.java.net/~sjohanss/8138888/8144701/hotspot.00 Summary: While working on JDK-8138888 and its sub-tasks I found three closures that inherited ExtendedOopClosure even though they were only used as normal OopClosures. I've changed them to inherit OopClosure and removed them from the list of closures in g1_specialized_oop_closures.hpp. Testing: * RBT (currently running) Thanks, Stefan From per.liden at oracle.com Fri Dec 4 14:17:25 2015 From: per.liden at oracle.com (Per Liden) Date: Fri, 4 Dec 2015 15:17:25 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <56618886.50309@gmail.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56613DD4.40600@oracle.com> <56618886.50309@gmail.com> Message-ID: <5661A075.9080602@oracle.com> Hi Peter, On 2015-12-04 13:35, Peter Levart wrote: > > > On 12/04/2015 08:16 AM, Per Liden wrote: >> >> test/java/lang/ref/PhantomReferentClearing.java: >> >> 85 // Delete root -> O1, collect, verify P1 notified, P2 not >> notified. >> 86 O1 = null; >> 87 System.gc(); >> 88 if (Q1.remove(ENQUEUE_TIMEOUT) == null) { >> 89 throw new RuntimeException("P1 not notified by O1 >> deletion"); >> 90 } else if (Q2.remove(ENQUEUE_TIMEOUT) != null) { >> 91 throw new RuntimeException("P2 notified by O1 >> deletion."); >> 92 } >> 93 >> 94 // Delete root -> O2, collect. P2 should be notified. >> 95 O2 = null; >> 96 System.gc(); >> 97 if (Q2.remove(ENQUEUE_TIMEOUT) == null) { >> 98 throw new RuntimeException("P2 not notified by O2 >> deletion"); >> 99 } >> >> The calls to System.gc() isn't guaranteed to do what the test expects >> here. As you know, System.gc(), might not actually do anything, >> depending on which collector is used and the current circumstances (GC >> locker held, a concurrent GC is already in process, etc). To make the >> test robust I'd suggest you call System.gc() and check the queue in a >> loop, and fail after some reasonable amount of time/iterations. > > Whether you poll the queue for some time T or you remove from queue with > timeout of T, it doesn't matter. The Reference(s) are enqueued by a > ReferenceHandler thread and the thread waiting in remove() will get > notified when a reference gets enqueued... I think you maybe missed my point. There's no guarantee that a call to System.gc() will cause reference processing to happen at all, and if it happens there's no guarantee that it will discover P1/P2 here. In this specific test it's very likely to happen, but that's a different story. I still don't think this test should rely on a behavior that isn't guaranteed by the spec. cheers, /Per > > Regards, Peter > >> >> cheers, >> /Per >> >>> http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ >>> >>> Testing: >>> jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK) >>> > From mikael.gerdin at oracle.com Fri Dec 4 14:18:03 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 4 Dec 2015 15:18:03 +0100 Subject: RFR: 8144701: Change three G1 remembererd set closures to be OopClosures In-Reply-To: <56619CAB.4080103@oracle.com> References: <56619CAB.4080103@oracle.com> Message-ID: <5661A09B.8000609@oracle.com> Hi Stefan, On 2015-12-04 15:01, Stefan Johansson wrote: > Hi, > > Please review this change for: > https://bugs.openjdk.java.net/browse/JDK-8144701 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8138888/8144701/hotspot.00 Looks good to me. /Mikael > > Summary: > While working on JDK-8138888 and its sub-tasks I found three closures > that inherited ExtendedOopClosure even though they were only used as > normal OopClosures. I've changed them to inherit OopClosure and removed > them from the list of closures in g1_specialized_oop_closures.hpp. > > Testing: > * RBT (currently running) > > Thanks, > Stefan > From stefan.karlsson at oracle.com Fri Dec 4 14:19:40 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 4 Dec 2015 15:19:40 +0100 Subject: RFR: 8144701: Change three G1 remembererd set closures to be OopClosures In-Reply-To: <56619CAB.4080103@oracle.com> References: <56619CAB.4080103@oracle.com> Message-ID: <5661A0FC.5030707@oracle.com> On 2015-12-04 15:01, Stefan Johansson wrote: > Hi, > > Please review this change for: > https://bugs.openjdk.java.net/browse/JDK-8144701 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8138888/8144701/hotspot.00 Looks good. StefanK > > Summary: > While working on JDK-8138888 and its sub-tasks I found three closures > that inherited ExtendedOopClosure even though they were only used as > normal OopClosures. I've changed them to inherit OopClosure and > removed them from the list of closures in > g1_specialized_oop_closures.hpp. > > Testing: > * RBT (currently running) > > Thanks, > Stefan > From erik.helin at oracle.com Fri Dec 4 14:32:54 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 4 Dec 2015 15:32:54 +0100 Subject: RFR: 8144712: Remove g1RootClosures.inline.hpp Message-ID: <20151204143254.GA17632@ehelin.jrpg.bea.com> Hi all, this small patches removes the no longer needed file g1RootClosures.inline.hpp. The class G1EvacuationClosures can live in g1RootClosures.hpp and G1SharedClosures gets its own file. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8144712 Webrev: http://cr.openjdk.java.net/~ehelin/8144712/webrev.00/ Testing: - JPRT - GC test suite with full verification Thanks, Erik From mikael.gerdin at oracle.com Fri Dec 4 14:37:01 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 4 Dec 2015 15:37:01 +0100 Subject: RFR: 8144712: Remove g1RootClosures.inline.hpp In-Reply-To: <20151204143254.GA17632@ehelin.jrpg.bea.com> References: <20151204143254.GA17632@ehelin.jrpg.bea.com> Message-ID: <5661A50D.5070108@oracle.com> Hi Erikm On 2015-12-04 15:32, Erik Helin wrote: > Hi all, > > this small patches removes the no longer needed file > g1RootClosures.inline.hpp. The class G1EvacuationClosures can live in > g1RootClosures.hpp and G1SharedClosures gets its own file. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8144712 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8144712/webrev.00/ Looks kick-ass! /Mikael > > Testing: > - JPRT > - GC test suite with full verification > > Thanks, > Erik > From stefan.karlsson at oracle.com Fri Dec 4 14:40:29 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 4 Dec 2015 15:40:29 +0100 Subject: RFR: 8144712: Remove g1RootClosures.inline.hpp In-Reply-To: <20151204143254.GA17632@ehelin.jrpg.bea.com> References: <20151204143254.GA17632@ehelin.jrpg.bea.com> Message-ID: <5661A5DD.2040609@oracle.com> On 2015-12-04 15:32, Erik Helin wrote: > Hi all, > > this small patches removes the no longer needed file > g1RootClosures.inline.hpp. The class G1EvacuationClosures can live in > g1RootClosures.hpp and G1SharedClosures gets its own file. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8144712 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8144712/webrev.00/ Looks good. StefanK > > Testing: > - JPRT > - GC test suite with full verification > > Thanks, > Erik From mikael.gerdin at oracle.com Fri Dec 4 14:44:47 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 4 Dec 2015 15:44:47 +0100 Subject: RFR: JDK-8144464 : WB method to start G1 concurrent mark cycle should be introduced In-Reply-To: References: Message-ID: <5661A6DF.3020507@oracle.com> Hi Shafi, this belongs on the gc-dev list. Redirecting... On 2015-12-04 07:09, Shafi Ahmad wrote: > Hi, > > > > Please review the backport of bug: "JDK-8144464: WB method to start G1 concurrent mark cycle should be introduced" to jdk8u-dev > > > > Webrev: http://cr.openjdk.java.net/~poonam/8144464/webrev.00/ > > jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8065579 > > Backport bug: https://bugs.openjdk.java.net/browse/JDK-8144464 > > Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1c207cfc557b > > > > Test: Run jprt and relevant jtreg test. > > > > Regards, > > Shafi > From mikael.gerdin at oracle.com Fri Dec 4 15:18:28 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 4 Dec 2015 16:18:28 +0100 Subject: RFR (S): 8144714 Add extension point to G1 evacuation closures Message-ID: <5661AEC4.3040805@oracle.com> Hi all, Please review this small change to add a hook in the G1 evacuation path. This allows extension code to register regions which are otherwise interesting to the GC and get notifications when pointers into such regions are encountered. Testing: JPRT, gc test suite Performance: This additional branch in G1ParScanClosure introduces a slight regression of about 1-2% in GC pause times. I have some performance fixes to make up for that regression in the pipe. webrev: http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/ bug: https://bugs.openjdk.java.net/browse/JDK-8144714 Thanks /Mikael From peter.levart at gmail.com Fri Dec 4 15:24:50 2015 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 4 Dec 2015 16:24:50 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <5661A075.9080602@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56613DD4.40600@oracle.com> <56618886.50309@gmail.com> <5661A075.9080602@oracle.com> Message-ID: <5661B042.20704@gmail.com> On 12/04/2015 03:17 PM, Per Liden wrote: > Hi Peter, > > On 2015-12-04 13:35, Peter Levart wrote: >> >> >> On 12/04/2015 08:16 AM, Per Liden wrote: >>> >>> test/java/lang/ref/PhantomReferentClearing.java: >>> >>> 85 // Delete root -> O1, collect, verify P1 notified, P2 not >>> notified. >>> 86 O1 = null; >>> 87 System.gc(); >>> 88 if (Q1.remove(ENQUEUE_TIMEOUT) == null) { >>> 89 throw new RuntimeException("P1 not notified by O1 >>> deletion"); >>> 90 } else if (Q2.remove(ENQUEUE_TIMEOUT) != null) { >>> 91 throw new RuntimeException("P2 notified by O1 >>> deletion."); >>> 92 } >>> 93 >>> 94 // Delete root -> O2, collect. P2 should be notified. >>> 95 O2 = null; >>> 96 System.gc(); >>> 97 if (Q2.remove(ENQUEUE_TIMEOUT) == null) { >>> 98 throw new RuntimeException("P2 not notified by O2 >>> deletion"); >>> 99 } >>> >>> The calls to System.gc() isn't guaranteed to do what the test expects >>> here. As you know, System.gc(), might not actually do anything, >>> depending on which collector is used and the current circumstances (GC >>> locker held, a concurrent GC is already in process, etc). To make the >>> test robust I'd suggest you call System.gc() and check the queue in a >>> loop, and fail after some reasonable amount of time/iterations. >> >> Whether you poll the queue for some time T or you remove from queue with >> timeout of T, it doesn't matter. The Reference(s) are enqueued by a >> ReferenceHandler thread and the thread waiting in remove() will get >> notified when a reference gets enqueued... > > I think you maybe missed my point. There's no guarantee that a call to > System.gc() will cause reference processing to happen at all, and if > it happens there's no guarantee that it will discover P1/P2 here. In > this specific test it's very likely to happen, but that's a different > story. I still don't think this test should rely on a behavior that > isn't guaranteed by the spec. Ah, you meant to call both System.gc() and queue.poll() in a loop. Sorry, I haven't understood you at first. I agree that would be better. Short of System.gc(), is there anything else that could be used to trigger GC processing more reliably? What about a loop that allocates until OOME is thrown and then releases everything so application can recover: static void triggerGC() { try { Object garbage = null; while(true) { Object[] chunk = new Object[1<<16]; chunk[0] = garbage; garbage = chunk; } } catch (OutOfMemoryError e) { // ignore } } I think most GCs guarantee they run the GC before VM throws OOME. Such test would have to be executed in othrevm with small heap: -Xmx16m or so... Regards, Peter > > cheers, > /Per > >> >> Regards, Peter >> >>> >>> cheers, >>> /Per >>> >>>> http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ >>>> >>>> Testing: >>>> jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK) >>>> >> From erik.helin at oracle.com Fri Dec 4 15:48:27 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 4 Dec 2015 16:48:27 +0100 Subject: RFR (S): 8144714 Add extension point to G1 evacuation closures In-Reply-To: <5661AEC4.3040805@oracle.com> References: <5661AEC4.3040805@oracle.com> Message-ID: <20151204154827.GB17632@ehelin.jrpg.bea.com> On 2015-12-04, Mikael Gerdin wrote: > Hi all, > > Please review this small change to add a hook in the G1 evacuation path. > This allows extension code to register regions which are otherwise > interesting to the GC and get notifications when pointers into such regions > are encountered. > > Testing: JPRT, gc test suite > Performance: > This additional branch in G1ParScanClosure introduces a slight regression of > about 1-2% in GC pause times. I have some performance fixes to make up for > that regression in the pipe. > > webrev: http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/ Looks good, Reviewed. There seems to be an extra newline at the end of g1ParScanThreadState_ext.cpp, can you fix that before you push? Thanks, Erik > bug: https://bugs.openjdk.java.net/browse/JDK-8144714 > > Thanks > /Mikael From kim.barrett at oracle.com Fri Dec 4 15:49:14 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 4 Dec 2015 10:49:14 -0500 Subject: RFR (M): 8060697: Improve G1 Heap Growth Heuristics In-Reply-To: <566199A8.2000508@oracle.com> References: <5653D33D.3090906@oracle.com> <1449056510.2642.75.camel@oracle.com> <1449057651.2642.86.camel@oracle.com> <56607093.3010102@oracle.com> <0AB0B848-BAFC-4A3F-B14B-8845C6FCFFE0@oracle.com> <566199A8.2000508@oracle.com> Message-ID: On Dec 4, 2015, at 8:48 AM, Tom Benson wrote: > > Hi Kim, > Thanks again. In this case, I actually prefer an explicit cast rather than relying on the presence of ".0" at the end of the compound expression to get the correct result. However, I could get rid of the second cast. What would you think of that, and would you want to see a new webrev? Any of the options discussed, including leaving as is, is ok with me. And no, I don?t need another webrev. From tom.benson at oracle.com Fri Dec 4 16:45:26 2015 From: tom.benson at oracle.com (Tom Benson) Date: Fri, 4 Dec 2015 11:45:26 -0500 Subject: RFR (M): 8060697: Improve G1 Heap Growth Heuristics In-Reply-To: References: <5653D33D.3090906@oracle.com> <1449056510.2642.75.camel@oracle.com> <1449057651.2642.86.camel@oracle.com> <56607093.3010102@oracle.com> <0AB0B848-BAFC-4A3F-B14B-8845C6FCFFE0@oracle.com> <566199A8.2000508@oracle.com> Message-ID: <5661C326.5050105@oracle.com> OK. I'll leave it as-is unless Jon or Thomas express a preference. Tnx, Tom On 12/4/2015 10:49 AM, Kim Barrett wrote: > On Dec 4, 2015, at 8:48 AM, Tom Benson wrote: >> Hi Kim, >> Thanks again. In this case, I actually prefer an explicit cast rather than relying on the presence of ".0" at the end of the compound expression to get the correct result. However, I could get rid of the second cast. What would you think of that, and would you want to see a new webrev? > Any of the options discussed, including leaving as is, is ok with me. And no, I don?t need another webrev. > From jon.masamitsu at oracle.com Fri Dec 4 17:42:53 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 4 Dec 2015 09:42:53 -0800 Subject: RFR (S): 8144714 Add extension point to G1 evacuation closures In-Reply-To: <5661AEC4.3040805@oracle.com> References: <5661AEC4.3040805@oracle.com> Message-ID: <5661D09D.3060309@oracle.com> Mikael, Looks good. Couple of minor points. http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/src/share/vm/gc/g1/g1InCSetState.hpp.frames.html Is the Ext value explained by the comment "The other values ..."? If it does apply to the Ext value, I don't understand. "getting to the next generation" doesn't seem to apply. Actually, I don't understand that comment with respect to Humongous either. 56 // The other values are simply encoded in increasing generation order, which 57 // makes getting the next generation fast by a simple increment. 58 Ext = -2, // Extension point http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/src/share/vm/gc/g1/g1ParScanThreadState_ext.cpp.frames.html Lines 39 and 40 not particularly useful? 37 template void G1ParScanThreadState::do_oop_ext(oop* ref); 38 template void G1ParScanThreadState::do_oop_ext(narrowOop* ref); 39 40 Jon On 12/4/2015 7:18 AM, Mikael Gerdin wrote: > Hi all, > > Please review this small change to add a hook in the G1 evacuation path. > This allows extension code to register regions which are otherwise > interesting to the GC and get notifications when pointers into such > regions are encountered. > > Testing: JPRT, gc test suite > Performance: > This additional branch in G1ParScanClosure introduces a slight > regression of about 1-2% in GC pause times. I have some performance > fixes to make up for that regression in the pipe. > > webrev: http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/ > bug: https://bugs.openjdk.java.net/browse/JDK-8144714 > > Thanks > /Mikael From kim.barrett at oracle.com Fri Dec 4 18:07:44 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 4 Dec 2015 13:07:44 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> Message-ID: <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> On Dec 3, 2015, at 6:04 PM, Mandy Chung wrote: > >> [Indeed, this whole section isn't strictly necessary; all of it can be >> inferred from information in other places.] > > Agree. This section is no longer necessary and maybe just remove it: I wasn't actually intending to suggest removal. It seems like there is useful overview information to be had here, rather than requiring readers to make not necessarily obvious inferences. My impression is that readability is valued more highly than terseness in Java documentation. From kim.barrett at oracle.com Fri Dec 4 18:16:47 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 4 Dec 2015 13:16:47 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <56613DD4.40600@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56613DD4.40600@oracle.com> Message-ID: <05734348-D522-464B-9133-CA64793E8979@oracle.com> On Dec 4, 2015, at 2:16 AM, Per Liden wrote: > > On 2015-12-02 19:37, Kim Barrett wrote: >> Please review this change to PhantomReference processing, changing the >> GC-based notification to automatically clear the referent. >> >> [?] >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8071507 >> >> Webrevs: >> http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/ > > test/java/lang/ref/PhantomReferentClearing.java: > > 85 // Delete root -> O1, collect, verify P1 notified, P2 not notified. > 86 O1 = null; > 87 System.gc(); > 88 if (Q1.remove(ENQUEUE_TIMEOUT) == null) { > 89 throw new RuntimeException("P1 not notified by O1 deletion"); > 90 } else if (Q2.remove(ENQUEUE_TIMEOUT) != null) { > 91 throw new RuntimeException("P2 notified by O1 deletion."); > 92 } > 93 > 94 // Delete root -> O2, collect. P2 should be notified. > 95 O2 = null; > 96 System.gc(); > 97 if (Q2.remove(ENQUEUE_TIMEOUT) == null) { > 98 throw new RuntimeException("P2 not notified by O2 deletion"); > 99 } > > The calls to System.gc() isn't guaranteed to do what the test expects here. As you know, System.gc(), might not actually do anything, depending on which collector is used and the current circumstances (GC locker held, a concurrent GC is already in process, etc). To make the test robust I'd suggest you call System.gc() and check the queue in a loop, and fail after some reasonable amount of time/iterations. I'd rather not clutter and uglify this and other tests to deal with a problem we don't (so far as I can tell) presently actually have. If a problem does arise, the form of that problem will help guide what the solution needs to be. I suspect adding something to WhiteBox would be the proper approach, so that it can be shared with other tests of this form. From thomas.schatzl at oracle.com Fri Dec 4 19:03:21 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 04 Dec 2015 20:03:21 +0100 Subject: RFR (XXS): 8144690: g1Predictions.hpp includes allocation.inline.hpp Message-ID: <1449255801.2160.2.camel@oracle.com> Hi all, we should not reference .inline.hpp files in .hpp files as per coding standards. G1Predictions.hpp violates this, including allocation.inline.hpp. This patch fixes this problem simply by removing the offending include: g1Predictions.hpp does not need allocations.inline.hpp at all. CR: https://bugs.openjdk.java.net/browse/JDK-8144690 Webrev: http://cr.openjdk.java.net/~tschatzl/8144690/webrev/ Testing: Building all targets in jprt Thanks, Thomas From jon.masamitsu at oracle.com Fri Dec 4 19:03:48 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 4 Dec 2015 11:03:48 -0800 Subject: RFR (M): 8060697: Improve G1 Heap Growth Heuristics In-Reply-To: <5661C326.5050105@oracle.com> References: <5653D33D.3090906@oracle.com> <1449056510.2642.75.camel@oracle.com> <1449057651.2642.86.camel@oracle.com> <56607093.3010102@oracle.com> <0AB0B848-BAFC-4A3F-B14B-8845C6FCFFE0@oracle.com> <566199A8.2000508@oracle.com> <5661C326.5050105@oracle.com> Message-ID: <5661E394.1050103@oracle.com> On 12/4/2015 8:45 AM, Tom Benson wrote: > OK. I'll leave it as-is unless Jon or Thomas express a preference. Tnx, > Tom I have no preference. Jon > > On 12/4/2015 10:49 AM, Kim Barrett wrote: >> On Dec 4, 2015, at 8:48 AM, Tom Benson wrote: >>> Hi Kim, >>> Thanks again. In this case, I actually prefer an explicit cast >>> rather than relying on the presence of ".0" at the end of the >>> compound expression to get the correct result. However, I could get >>> rid of the second cast. What would you think of that, and would you >>> want to see a new webrev? >> Any of the options discussed, including leaving as is, is ok with >> me. And no, I don?t need another webrev. >> > From stefan.karlsson at oracle.com Fri Dec 4 19:03:51 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 04 Dec 2015 20:03:51 +0100 Subject: RFR (XXS): 8144690: g1Predictions.hpp includes allocation.inline.hpp In-Reply-To: <1449255801.2160.2.camel@oracle.com> References: <1449255801.2160.2.camel@oracle.com> Message-ID: <5661E397.6020806@oracle.com> Looks good. Thanks, StefanK On 2015-12-04 20:03, Thomas Schatzl wrote: > Hi all, > > we should not reference .inline.hpp files in .hpp files as per coding > standards. G1Predictions.hpp violates this, including > allocation.inline.hpp. > > This patch fixes this problem simply by removing the offending include: > g1Predictions.hpp does not need allocations.inline.hpp at all. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8144690 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8144690/webrev/ > Testing: > Building all targets in jprt > > Thanks, > Thomas > From jon.masamitsu at oracle.com Fri Dec 4 19:12:12 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 4 Dec 2015 11:12:12 -0800 Subject: RFR (XXS): 8144690: g1Predictions.hpp includes allocation.inline.hpp In-Reply-To: <1449255801.2160.2.camel@oracle.com> References: <1449255801.2160.2.camel@oracle.com> Message-ID: <5661E58C.7060209@oracle.com> Looks good. Jon On 12/4/2015 11:03 AM, Thomas Schatzl wrote: > Hi all, > > we should not reference .inline.hpp files in .hpp files as per coding > standards. G1Predictions.hpp violates this, including > allocation.inline.hpp. > > This patch fixes this problem simply by removing the offending include: > g1Predictions.hpp does not need allocations.inline.hpp at all. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8144690 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8144690/webrev/ > Testing: > Building all targets in jprt > > Thanks, > Thomas > From kim.barrett at oracle.com Fri Dec 4 19:16:14 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 4 Dec 2015 14:16:14 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <05734348-D522-464B-9133-CA64793E8979@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56613DD4.40600@oracle.com> <05734348-D522-464B-9133-CA64793E8979@oracle.com> Message-ID: On Dec 4, 2015, at 1:16 PM, Kim Barrett wrote: > > I'd rather not clutter and uglify this and other tests to deal with a > problem we don't (so far as I can tell) presently actually have. If a > problem does arise, the form of that problem will help guide what the > solution needs to be. I suspect adding something to WhiteBox would be > the proper approach, so that it can be shared with other tests of this > form. But maybe I should use WhiteBox.fullGC instead of System.gc? From mandy.chung at oracle.com Fri Dec 4 21:58:55 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 4 Dec 2015 13:58:55 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> Message-ID: <80575736-AB1F-4B01-B272-1CA7BBD08ACB@oracle.com> > On Dec 4, 2015, at 10:07 AM, Kim Barrett wrote: > > On Dec 3, 2015, at 6:04 PM, Mandy Chung wrote: >> >>> [Indeed, this whole section isn't strictly necessary; all of it can be >>> inferred from information in other places.] >> >> Agree. This section is no longer necessary and maybe just remove it: > > I wasn't actually intending to suggest removal. It seems like there > is useful overview information to be had here, rather than requiring > readers to make not necessarily obvious inferences. My impression is > that readability is valued more highly than terseness in Java > documentation. Actually I considered to remove it in the past but just tried to minimize the spec change. I believe one purpose of that section was intended to call out the difference that PhantomReference is not automatically-cleared that is no longer true. In addition it?s clearly mentioned in PhantomReference constructor. I don?t see the need for it in the package summary. The reader will look at the PhantomRefererence to use it.. "It is possible to create a phantom reference with a null queue, but such a reference is completely useless: Its get method will always return null and, since it does not have a queue, it will never be enqueued.? The puzzling part to me is why PhantomReference accepts null ReferenceQueue. I can?t evaluate how high of the source incompatibility risk if we fixed it but I may propose that in a future release until I have cycle. Mandy From mikael.vidstedt at oracle.com Sat Dec 5 01:32:34 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 4 Dec 2015 17:32:34 -0800 Subject: RFR (S): 8144663: Invalid constraints in memset_with_concurrent_readers_sparc.cpp inline assembly In-Reply-To: <9AD84417-BAF3-4712-A0C3-C1C9F8E0E864@oracle.com> References: <5660D994.4050006@oracle.com> <9AD84417-BAF3-4712-A0C3-C1C9F8E0E864@oracle.com> Message-ID: <56623EB2.9010101@oracle.com> On 2015-12-03 16:15, Kim Barrett wrote: > On Dec 3, 2015, at 7:08 PM, Mikael Vidstedt wrote: >> >> Please review this change which fixes the constraints used in the inline assembly snippets in memset_with_concurrent_readers_sparc.cpp. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8144663 >> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8144663/webrev.00/webrev/ > Looks good. And my apologies for getting the syntax wrong in the first place. > Thanks for the review, and for making testing it a breeze with the unit test in -XX:+ExecuteInternalVMTests! Cheers, Mikael From peter.levart at gmail.com Sat Dec 5 11:12:20 2015 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 5 Dec 2015 12:12:20 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <80575736-AB1F-4B01-B272-1CA7BBD08ACB@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> <80575736-AB1F-4B01-B272-1CA7BBD08ACB@oracle.com> Message-ID: <5662C694.9040306@gmail.com> On 12/04/2015 10:58 PM, Mandy Chung wrote: > "It is possible to create a phantom reference with a null queue, but such a reference is completely useless: Its get method will always return null and, since it does not have a queue, it will never be enqueued.? > > The puzzling part to me is why PhantomReference accepts null ReferenceQueue. I can?t evaluate how high of the source incompatibility risk if we fixed it but I may propose that in a future release until I have cycle. > > Mandy Well, it is not completely useless for PhantomReference to accept null ReferenceQueue. It's sometimes useful to have a common subtype of PhantomReference where most of instances perform a function of PhantomReference, but some instances are just there to provide the "glue" in the data structure. See the implementation of java.lang.ref.Cleaner and it's "root" nodes of a doubly-linked list ;-) Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Sat Dec 5 16:28:27 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 5 Dec 2015 08:28:27 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <5662C694.9040306@gmail.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> <80575736-AB1F-4B01-B272-1CA7BBD08ACB@oracle.com> <5662C694.9040306@gmail.com> Message-ID: > On Dec 5, 2015, at 3:12 AM, Peter Levart wrote: > > > > On 12/04/2015 10:58 PM, Mandy Chung wrote: >> "It is possible to create a phantom reference with a null queue, but such a reference is completely useless: Its get method will always return null and, since it does not have a queue, it will never be enqueued.? >> >> The puzzling part to me is why PhantomReference accepts null ReferenceQueue. I can?t evaluate how high of the source incompatibility risk if we fixed it but I may propose that in a future release until I have cycle. >> >> Mandy >> > > Well, it is not completely useless for PhantomReference to accept null ReferenceQueue. It's sometimes useful to have a common subtype of PhantomReference where most of instances perform a function of PhantomReference, but some instances are just there to provide the "glue" in the data structure. See the implementation of java.lang.ref.Cleaner and it's "root" nodes of a doubly-linked list ;-) That?s right. There may likely be some reason why it takes the null ReferenceQueue as noted in this comment in sun.misc.Cleaner: // Dummy reference queue, needed because the PhantomReference constructor // insists that we pass a queue. Mandy From peter.levart at gmail.com Sat Dec 5 18:23:15 2015 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 5 Dec 2015 19:23:15 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> <80575736-AB1F-4B01-B272-1CA7BBD08ACB@oracle.com> <5662C694.9040306@gmail.com> Message-ID: <56632B93.6070105@gmail.com> On 12/05/2015 05:28 PM, Mandy Chung wrote: >> On Dec 5, 2015, at 3:12 AM, Peter Levart wrote: >> >> >> >> On 12/04/2015 10:58 PM, Mandy Chung wrote: >>> "It is possible to create a phantom reference with a null queue, but such a reference is completely useless: Its get method will always return null and, since it does not have a queue, it will never be enqueued.? >>> >>> The puzzling part to me is why PhantomReference accepts null ReferenceQueue. I can?t evaluate how high of the source incompatibility risk if we fixed it but I may propose that in a future release until I have cycle. >>> >>> Mandy >>> >> Well, it is not completely useless for PhantomReference to accept null ReferenceQueue. It's sometimes useful to have a common subtype of PhantomReference where most of instances perform a function of PhantomReference, but some instances are just there to provide the "glue" in the data structure. See the implementation of java.lang.ref.Cleaner and it's "root" nodes of a doubly-linked list ;-) > That?s right. > > There may likely be some reason why it takes the null ReferenceQueue as noted in this comment in sun.misc.Cleaner: > // Dummy reference queue, needed because the PhantomReference constructor > // insists that we pass a queue. > > Mandy Digging up the src.jar of JDK 1.2.2, here's what the constructor of PhantomReference looked like: /** * Creates a new phantom reference that refers to the given object and * is registered with the given queue. * * @throws NullPointerException If the queue argument * is null */ public PhantomReference(Object referent, ReferenceQueue q) { super(referent, q); } ...so it seems Mark wanted PhantomReference constructor to throw NPE. But implementation did not do that (here's also the constructor of Reference): Reference(Object referent, ReferenceQueue queue) { this.referent = referent; if (referent == null) { /* Immediately make this instance inactive */ this.queue = ReferenceQueue.NULL; this.next = this; } else { this.queue = (queue == null) ? ReferenceQueue.NULL : queue; this.next = null; } } ...and so the spec. has probably been modified to follow the standing behavior. Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Sat Dec 5 21:30:52 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 5 Dec 2015 16:30:52 -0500 Subject: RFR (S): 8144714 Add extension point to G1 evacuation closures In-Reply-To: <5661D09D.3060309@oracle.com> References: <5661AEC4.3040805@oracle.com> <5661D09D.3060309@oracle.com> Message-ID: On Dec 4, 2015, at 12:42 PM, Jon Masamitsu wrote: > > http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/src/share/vm/gc/g1/g1ParScanThreadState_ext.cpp.frames.html > > Lines 39 and 40 not particularly useful? > > 37 template void G1ParScanThreadState::do_oop_ext(oop* ref); > 38 template void G1ParScanThreadState::do_oop_ext(narrowOop* ref); > 39 > 40 These are explicit instantiations of the immediately preceding definition. From per.liden at oracle.com Mon Dec 7 07:26:41 2015 From: per.liden at oracle.com (Per Liden) Date: Mon, 7 Dec 2015 08:26:41 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <05734348-D522-464B-9133-CA64793E8979@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56613DD4.40600@oracle.com> <05734348-D522-464B-9133-CA64793E8979@oracle.com> Message-ID: <566534B1.7030401@oracle.com> On 2015-12-04 19:16, Kim Barrett wrote: > On Dec 4, 2015, at 2:16 AM, Per Liden wrote: >> >> On 2015-12-02 19:37, Kim Barrett wrote: >>> Please review this change to PhantomReference processing, changing the >>> GC-based notification to automatically clear the referent. >>> >>> [?] >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8071507 >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/ >> >> test/java/lang/ref/PhantomReferentClearing.java: >> >> 85 // Delete root -> O1, collect, verify P1 notified, P2 not notified. >> 86 O1 = null; >> 87 System.gc(); >> 88 if (Q1.remove(ENQUEUE_TIMEOUT) == null) { >> 89 throw new RuntimeException("P1 not notified by O1 deletion"); >> 90 } else if (Q2.remove(ENQUEUE_TIMEOUT) != null) { >> 91 throw new RuntimeException("P2 notified by O1 deletion."); >> 92 } >> 93 >> 94 // Delete root -> O2, collect. P2 should be notified. >> 95 O2 = null; >> 96 System.gc(); >> 97 if (Q2.remove(ENQUEUE_TIMEOUT) == null) { >> 98 throw new RuntimeException("P2 not notified by O2 deletion"); >> 99 } >> >> The calls to System.gc() isn't guaranteed to do what the test expects here. As you know, System.gc(), might not actually do anything, depending on which collector is used and the current circumstances (GC locker held, a concurrent GC is already in process, etc). To make the test robust I'd suggest you call System.gc() and check the queue in a loop, and fail after some reasonable amount of time/iterations. > > I'd rather not clutter and uglify this and other tests to deal with a > problem we don't (so far as I can tell) presently actually have. If a > problem does arise, the form of that problem will help guide what the > solution needs to be. I suspect adding something to WhiteBox would be > the proper approach, so that it can be shared with other tests of this > form. We do actually have this problem today, i.e. there are cases where our collectors will not do a "full GC" as a result of a call to System.gc(). One example would be if the GC-locker is active. However, it's seems very unlikely that this particular test would provoking such a condition. Our current WhiteBox API for FullGC is prone to the same issue. Maybe it would be a good idea to strengthen that API and used that in the future for tests like this. I understand if you don't want to take on this problem here and now, given that we have other test which is very similar to this one, and they seem to have worked so far without issues. cheers, /Per From david.lindholm at oracle.com Mon Dec 7 08:36:43 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Mon, 7 Dec 2015 09:36:43 +0100 Subject: RFR (S): 8144714 Add extension point to G1 evacuation closures In-Reply-To: References: <5661AEC4.3040805@oracle.com> <5661D09D.3060309@oracle.com> Message-ID: <5665451B.8090504@oracle.com> On 2015-12-05 22:30, Kim Barrett wrote: > On Dec 4, 2015, at 12:42 PM, Jon Masamitsu wrote: >> http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/src/share/vm/gc/g1/g1ParScanThreadState_ext.cpp.frames.html >> >> Lines 39 and 40 not particularly useful? >> >> 37 template void G1ParScanThreadState::do_oop_ext(oop* ref); >> 38 template void G1ParScanThreadState::do_oop_ext(narrowOop* ref); >> 39 >> 40 > These are explicit instantiations of the immediately preceding definition. > They look like empty lines to me. :-) Erik also pointed out that there is one extra newline at the end of this file, and that should be fixed before the push. Thanks, /David From marcus.larsson at oracle.com Mon Dec 7 09:27:59 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 7 Dec 2015 10:27:59 +0100 Subject: RFR (XS): Forward port of 8065331: Add trace events for failed allocations In-Reply-To: <55DD8F43.7070003@oracle.com> References: <55DACA18.2070605@oracle.com> <55DD8F43.7070003@oracle.com> Message-ID: <5665511F.8000509@oracle.com> Hi all, Still need approval for this forward port. New webrev due to changes in how GCId works: http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.01/ Had to add a peek method in order to find the pending GC id for the event. This and the changes to includes should be the only things differing from the original patch. Thanks, Marcus On 2015-08-26 12:04, Marcus Larsson wrote: > Ping! > > On 2015-08-24 09:39, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to forward port the JEP-242 event >> to JDK9. The patch was originally reviewed in April/March [1], but >> was only integrated in 8u60. The original patch no longer applies >> cleanly to 9, due to directory restructuring and changes to includes, >> so I need a quick re-review for this. >> >> The new patch has updated #includes for the new directory structure >> but should otherwise be identical to the previous patch. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.00/ >> >> Original webrev: >> http://cr.openjdk.java.net/~mlarsson/8065331/webrev.02/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8065331 >> >> Thanks, >> Marcus >> >> [1]: >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-March/012408.html > From Sergey.Bylokhov at oracle.com Mon Dec 7 13:49:23 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 7 Dec 2015 16:49:23 +0300 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <56632B93.6070105@gmail.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> <80575736-AB1F-4B01-B272-1CA7BBD08ACB@oracle.com> <5662C694.9040306@gmail.com> <56632B93.6070105@gmail.com> Message-ID: <56658E63.8070607@oracle.com> On 05.12.15 21:23, Peter Levart wrote: > Digging up the src.jar of JDK 1.2.2, here's what the constructor of > PhantomReference looked like: > > /** > * Creates a new phantom reference that refers to the given object and > * is registered with the given queue. > * > * @throws NullPointerException If the queue argument > * is null > */ > public PhantomReference(Object referent, ReferenceQueue q) { > super(referent, q); > } > > > ...so it seems Mark wanted PhantomReference constructor to throw NPE. > But implementation did not do that (here's also the constructor of > Reference): > > > Reference(Object referent, ReferenceQueue queue) { > this.referent = referent; > if (referent == null) { > /* Immediately make this instance inactive */ > this.queue = ReferenceQueue.NULL; > this.next = this; > } else { > this.queue = (queue == null) ? ReferenceQueue.NULL : queue; > this.next = null; > } > } > > > ...and so the spec. has probably been modified to follow the standing > behavior. Looks like it was updated in jdk5: https://bugs.openjdk.java.net/browse/JDK-4239039 -- Best regards, Sergey. From bengt.rutisson at oracle.com Mon Dec 7 13:53:28 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 07 Dec 2015 14:53:28 +0100 Subject: RRF: JEP-271: Unified GC Logging In-Reply-To: <565D9C07.2080808@oracle.com> References: <564DEAEB.90703@oracle.com> <56534C0D.3070209@oracle.com> <5655A994.7000304@oracle.com> <5655B0E2.6040009@oracle.com> <565D9C07.2080808@oracle.com> Message-ID: <56658F58.1040409@oracle.com> Hi all, Jenny noticed a bug in the heap transition information for G1 (Survivors were reported twice). Here's an updated webrev of the hotspot repo that contains the fix for that: http://cr.openjdk.java.net/~brutisso/JEP-271/review.03/hotspot-webrev.03/ Here is the diff compared to the last webrev: http://cr.openjdk.java.net/~brutisso/JEP-271/review.03/hotspot-webrev.02-03.diff/ Here is the diff compared to webrev.01 in case someone has reviewed webrev.01 but not webrev.02 yet: http://cr.openjdk.java.net/~brutisso/JEP-271/review.03/hotspot-webrev.01-03.diff/ The JDK repo is unchanged, so thes links are still valid to use for review: http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.02/ http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.01-02.diff/ Thanks, Bengt On 2015-12-01 14:09, Bengt Rutisson wrote: > > Hi everyone, > > Here are updated webrevs that include the comments on the last review > request. > > HotSpot changes: > http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/hotspot-webrev.02/ > > Complete changes: > > Diff compared to last webrev: > http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/hotspot-webrev.01-02.diff/ > > > > JDK changes: > > Complete changes: > http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.02/ > > Diff compared to last webrev: > http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.01-02.diff/ > > > > Except for the comment that were discussed in this email thread there > are a couple of other changes: > > - Most of the implementation parts in gcTraceTime.hpp were moved to > gcTraceTime.inline.hpp. > - New tests and new code that use logging were updated. > - Some tests were changed to use less extensive logging. > - A bug gave duplicate timing for Full GCs when going through > GenCollectedHeap > - The used calculation for G1 old logging could overflow. > - The @ignore tag was added back to TestLogging.java. > > Thanks, > Bengt > > On 2015-11-25 14:00, Bengt Rutisson wrote: >> >> Hi David, >> >> Thanks for looking at this again! >> >> On 2015-11-25 13:29, David Lindholm wrote: >>> Hi Bengt, >>> >>> My code review for the rest of the files: >>> >>> defNewGeneration.cpp: >>> >>> 517-520: Indentation >> >> Fixed. >> >>> 766: Shouldn't the tags be "gc, promotion"? >> >> Yes. Fixed. >> >>> >>> collectorPolicy.cpp: >>> >>> 489: Shouldn't the tags be "gc, heap"? >> >> Yes, fixed. >> >>> >>> genCollectedHeap.cpp: >>> >>> 1150+1152: Indentation >>> >>> generation.cpp: >>> >>> 162: Indentation >> >> Fixed. >> >>> >>> plab.cpp: >>> >>> 153: Plab_size = " SIZE_FORMAT " desired_net_plab_sz = " SIZE_FORMAT >>> ": Why the capital P in this printout of one variable name but not >>> the other? I think it should be consistent. >> >> Agreed. Fixed. >> >> >>> >>> referenceProcessor.cpp: >>> >>> 515: Indentation >>> >>> referenceProcessor.cpp: >>> >>> 948+953: Indentation >>> >>> metaspace.cpp: >>> >>> 1505: Indentation >>> 1578+1580: Indentation >>> 2695: Indentation >>> >>> runtimeService.cpp: >>> >>> 123-124: Indentation >> >> Fixed. >> >> Thanks, >> Bengt >> >>> >>> >>> Thanks, >>> David >>> >>> On 2015-11-23 18:25, Bengt Rutisson wrote: >>>> >>>> Hi everyone, >>>> >>>> Here is an updated webrev based on the comments from the first >>>> review. The changes that have been discussed have only been to the >>>> hotspot repo: >>>> >>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.01/ >>>> >>>> The changes to the JDK repo are the same as in the first webrev: >>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/jdk-webrev.00/ >>>> >>>> >>>> Some partial diffs to make it easier for those who already looked >>>> at the first webrev. >>>> >>>> The unified logging framework was changed in the way it handles the >>>> develop logging. Here are the changes I had to do to accommodate >>>> the new develop logging: >>>> >>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.01-develop-logging >>>> >>>> >>>> Here are the changes I have made to address comments in the code >>>> (based on top of the develop logging changes): >>>> >>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.00-01-code-diff >>>> >>>> >>>> And here are the changes that David has made to address comment in >>>> the tests: >>>> >>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.00-01-test-diff >>>> >>>> >>>> Enjoy! >>>> Bengt >>>> >>>> On 2015-11-19 16:29, Bengt Rutisson wrote: >>>>> >>>>> Hi everyone, >>>>> >>>>> After three pre-reviews it is time for the fist official review >>>>> request for JEP-271 Unified GC Logging. >>>>> >>>>> http://openjdk.java.net/jeps/271 >>>>> >>>>> Most code changes are in the hotspot code: >>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/webrev.00/ >>>>> >>>>> Some tests in the JDK repo have been updated: >>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/jdk-webrev.00/ >>>>> >>>>> As with the pre-reviews I have put togther some examples of what >>>>> the new logging looks like: >>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/compare.html >>>>> >>>>> The intent is that this should cover the bulk of the logging >>>>> changes. There will most definitely be some follow up changes >>>>> where we fix details in the log messages etc. >>>>> >>>>> Among many other old logging flags this changeset removes the two >>>>> flags PringGC and PrintGCDetails. These two will be added back >>>>> with a follow up changeset, but when they are added back they will >>>>> be marked as deprecated. >>>>> >>>>> The reason for first removing them and then adding them back is to >>>>> get testing without these flags. That way we will know that we >>>>> clean out all usages of these flags from our testing. >>>>> >>>>> Thanks, >>>>> Bengt >>>> >>> >> > From stefan.johansson at oracle.com Mon Dec 7 16:46:24 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 7 Dec 2015 17:46:24 +0100 Subject: RRF: JEP-271: Unified GC Logging In-Reply-To: <56658F58.1040409@oracle.com> References: <564DEAEB.90703@oracle.com> <56534C0D.3070209@oracle.com> <5655A994.7000304@oracle.com> <5655B0E2.6040009@oracle.com> <565D9C07.2080808@oracle.com> <56658F58.1040409@oracle.com> Message-ID: <5665B7E0.7020204@oracle.com> Hi Bengt, On 2015-12-07 14:53, Bengt Rutisson wrote: > > Hi all, > > Jenny noticed a bug in the heap transition information for G1 > (Survivors were reported twice). Here's an updated webrev of the > hotspot repo that contains the fix for that: > > http://cr.openjdk.java.net/~brutisso/JEP-271/review.03/hotspot-webrev.03/ Look good, just one minor thing: src/share/vm/gc/shared/collectorPolicy.cpp 556 log_trace(heap)("2: Minimum young " SIZE_FORMAT " Initial young " SIZE_FORMAT " Maximum young " SIZE_FORMAT, 557 _min_young_size, _initial_young_size, _max_young_size); ... 573 log_trace(heap)("Minimum old " SIZE_FORMAT " Initial old " SIZE_FORMAT " Maximum old " SIZE_FORMAT, 574 _min_old_size, _initial_old_size, _max_old_size); Those two log-statements should use the gc tag, like the statement on line 489. > > Here is the diff compared to the last webrev: > http://cr.openjdk.java.net/~brutisso/JEP-271/review.03/hotspot-webrev.02-03.diff/ > > > Here is the diff compared to webrev.01 in case someone has reviewed > webrev.01 but not webrev.02 yet: > > http://cr.openjdk.java.net/~brutisso/JEP-271/review.03/hotspot-webrev.01-03.diff/ > > > > The JDK repo is unchanged, so thes links are still valid to use for > review: > > http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.02/ > http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.01-02.diff/ > This looks good. Thanks, StefanJ > > Thanks, > Bengt > > > On 2015-12-01 14:09, Bengt Rutisson wrote: >> >> Hi everyone, >> >> Here are updated webrevs that include the comments on the last review >> request. >> >> HotSpot changes: >> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/hotspot-webrev.02/ >> >> >> Complete changes: >> >> Diff compared to last webrev: >> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/hotspot-webrev.01-02.diff/ >> >> >> >> JDK changes: >> >> Complete changes: >> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.02/ >> >> Diff compared to last webrev: >> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.01-02.diff/ >> >> >> >> Except for the comment that were discussed in this email thread there >> are a couple of other changes: >> >> - Most of the implementation parts in gcTraceTime.hpp were moved to >> gcTraceTime.inline.hpp. >> - New tests and new code that use logging were updated. >> - Some tests were changed to use less extensive logging. >> - A bug gave duplicate timing for Full GCs when going through >> GenCollectedHeap >> - The used calculation for G1 old logging could overflow. >> - The @ignore tag was added back to TestLogging.java. >> >> Thanks, >> Bengt >> >> On 2015-11-25 14:00, Bengt Rutisson wrote: >>> >>> Hi David, >>> >>> Thanks for looking at this again! >>> >>> On 2015-11-25 13:29, David Lindholm wrote: >>>> Hi Bengt, >>>> >>>> My code review for the rest of the files: >>>> >>>> defNewGeneration.cpp: >>>> >>>> 517-520: Indentation >>> >>> Fixed. >>> >>>> 766: Shouldn't the tags be "gc, promotion"? >>> >>> Yes. Fixed. >>> >>>> >>>> collectorPolicy.cpp: >>>> >>>> 489: Shouldn't the tags be "gc, heap"? >>> >>> Yes, fixed. >>> >>>> >>>> genCollectedHeap.cpp: >>>> >>>> 1150+1152: Indentation >>>> >>>> generation.cpp: >>>> >>>> 162: Indentation >>> >>> Fixed. >>> >>>> >>>> plab.cpp: >>>> >>>> 153: Plab_size = " SIZE_FORMAT " desired_net_plab_sz = " >>>> SIZE_FORMAT ": Why the capital P in this printout of one variable >>>> name but not the other? I think it should be consistent. >>> >>> Agreed. Fixed. >>> >>> >>>> >>>> referenceProcessor.cpp: >>>> >>>> 515: Indentation >>>> >>>> referenceProcessor.cpp: >>>> >>>> 948+953: Indentation >>>> >>>> metaspace.cpp: >>>> >>>> 1505: Indentation >>>> 1578+1580: Indentation >>>> 2695: Indentation >>>> >>>> runtimeService.cpp: >>>> >>>> 123-124: Indentation >>> >>> Fixed. >>> >>> Thanks, >>> Bengt >>> >>>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 2015-11-23 18:25, Bengt Rutisson wrote: >>>>> >>>>> Hi everyone, >>>>> >>>>> Here is an updated webrev based on the comments from the first >>>>> review. The changes that have been discussed have only been to the >>>>> hotspot repo: >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.01/ >>>>> >>>>> The changes to the JDK repo are the same as in the first webrev: >>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/jdk-webrev.00/ >>>>> >>>>> >>>>> Some partial diffs to make it easier for those who already looked >>>>> at the first webrev. >>>>> >>>>> The unified logging framework was changed in the way it handles >>>>> the develop logging. Here are the changes I had to do to >>>>> accommodate the new develop logging: >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.01-develop-logging >>>>> >>>>> >>>>> Here are the changes I have made to address comments in the code >>>>> (based on top of the develop logging changes): >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.00-01-code-diff >>>>> >>>>> >>>>> And here are the changes that David has made to address comment in >>>>> the tests: >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.00-01-test-diff >>>>> >>>>> >>>>> Enjoy! >>>>> Bengt >>>>> >>>>> On 2015-11-19 16:29, Bengt Rutisson wrote: >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> After three pre-reviews it is time for the fist official review >>>>>> request for JEP-271 Unified GC Logging. >>>>>> >>>>>> http://openjdk.java.net/jeps/271 >>>>>> >>>>>> Most code changes are in the hotspot code: >>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/webrev.00/ >>>>>> >>>>>> Some tests in the JDK repo have been updated: >>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/jdk-webrev.00/ >>>>>> >>>>>> >>>>>> As with the pre-reviews I have put togther some examples of what >>>>>> the new logging looks like: >>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/compare.html >>>>>> >>>>>> The intent is that this should cover the bulk of the logging >>>>>> changes. There will most definitely be some follow up changes >>>>>> where we fix details in the log messages etc. >>>>>> >>>>>> Among many other old logging flags this changeset removes the two >>>>>> flags PringGC and PrintGCDetails. These two will be added back >>>>>> with a follow up changeset, but when they are added back they >>>>>> will be marked as deprecated. >>>>>> >>>>>> The reason for first removing them and then adding them back is >>>>>> to get testing without these flags. That way we will know that we >>>>>> clean out all usages of these flags from our testing. >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>> >>>> >>> >> > From jon.masamitsu at oracle.com Mon Dec 7 18:04:04 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 7 Dec 2015 10:04:04 -0800 Subject: RFR (S): 8144714 Add extension point to G1 evacuation closures In-Reply-To: <5665451B.8090504@oracle.com> References: <5661AEC4.3040805@oracle.com> <5661D09D.3060309@oracle.com> <5665451B.8090504@oracle.com> Message-ID: <5665CA14.8050906@oracle.com> On 12/07/2015 12:36 AM, David Lindholm wrote: > On 2015-12-05 22:30, Kim Barrett wrote: >> On Dec 4, 2015, at 12:42 PM, Jon Masamitsu >> wrote: >>> http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/src/share/vm/gc/g1/g1ParScanThreadState_ext.cpp.frames.html >>> >>> >>> Lines 39 and 40 not particularly useful? >>> >>> 37 template void G1ParScanThreadState::do_oop_ext(oop* ref); >>> 38 template void >>> G1ParScanThreadState::do_oop_ext(narrowOop* ref); >>> 39 >>> 40 >> These are explicit instantiations of the immediately preceding >> definition. >> > > They look like empty lines to me. :-) Yes, I should speak more plainly. Jon > Erik also pointed out that there is one extra newline at the end of > this file, and that should be fixed before the push. > > Thanks, > /David From kim.barrett at oracle.com Mon Dec 7 18:43:46 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 7 Dec 2015 13:43:46 -0500 Subject: RFR (S): 8144714 Add extension point to G1 evacuation closures In-Reply-To: <5665CA14.8050906@oracle.com> References: <5661AEC4.3040805@oracle.com> <5661D09D.3060309@oracle.com> <5665451B.8090504@oracle.com> <5665CA14.8050906@oracle.com> Message-ID: <6B80D104-FDD2-425D-A3D7-610A20E9266A@oracle.com> On Dec 7, 2015, at 1:04 PM, Jon Masamitsu wrote: > > > > On 12/07/2015 12:36 AM, David Lindholm wrote: >> On 2015-12-05 22:30, Kim Barrett wrote: >>> On Dec 4, 2015, at 12:42 PM, Jon Masamitsu wrote: >>>> http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/src/share/vm/gc/g1/g1ParScanThreadState_ext.cpp.frames.html >>>> >>>> Lines 39 and 40 not particularly useful? >>>> >>>> 37 template void G1ParScanThreadState::do_oop_ext(oop* ref); >>>> 38 template void G1ParScanThreadState::do_oop_ext(narrowOop* ref); >>>> 39 >>>> 40 >>> These are explicit instantiations of the immediately preceding definition. >> >> They look like empty lines to me. :-) > > Yes, I should speak more plainly. Oh, now I see. Never mind. From kim.barrett at oracle.com Tue Dec 8 00:30:47 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 7 Dec 2015 19:30:47 -0500 Subject: RFR (M): 8060697: Improve G1 Heap Growth Heuristics In-Reply-To: <56607093.3010102@oracle.com> References: <5653D33D.3090906@oracle.com> <1449056510.2642.75.camel@oracle.com> <1449057651.2642.86.camel@oracle.com> <56607093.3010102@oracle.com> Message-ID: <78EB4021-4190-45CF-960A-875995A463E5@oracle.com> On Dec 3, 2015, at 11:40 AM, Tom Benson wrote: > > Updated webrevs (including the suggestions from Kim and Jon) are in: > > http://cr.openjdk.java.net/~tbenson/8060697/webrev.01.vs.00/ - incremental > http://cr.openjdk.java.net/~tbenson/8060697/webrev.01/ - full I'd previously overlooked the removal of the const qualifier from G1CollectorPolicy::expansion_amount. This was done to permit some member variables to be updated to accumulate additional information (specifically, the fields that are reset by the new clear_ratio_check_data). But the function name "expansion_amount" looks to me like an accessor or compute function, and not something that modifies the policy object. I don't have a good alternative (either structure or naming) to offer right now, but maybe you or someone else might think of something. Or maybe I'm the only one (somewhat) bothered by this. From tom.benson at oracle.com Tue Dec 8 01:35:27 2015 From: tom.benson at oracle.com (Tom Benson) Date: Mon, 7 Dec 2015 20:35:27 -0500 Subject: RFR (M): 8060697: Improve G1 Heap Growth Heuristics In-Reply-To: <78EB4021-4190-45CF-960A-875995A463E5@oracle.com> References: <5653D33D.3090906@oracle.com> <1449056510.2642.75.camel@oracle.com> <1449057651.2642.86.camel@oracle.com> <56607093.3010102@oracle.com> <78EB4021-4190-45CF-960A-875995A463E5@oracle.com> Message-ID: <566633DF.4030009@oracle.com> Hi Kim, Yes, that's it exactly. I'm not bothered by it, but am open to suggestions if someone feels strongly. Tnx, Tom On 12/7/2015 7:30 PM, Kim Barrett wrote: > On Dec 3, 2015, at 11:40 AM, Tom Benson wrote: >> Updated webrevs (including the suggestions from Kim and Jon) are in: >> >> http://cr.openjdk.java.net/~tbenson/8060697/webrev.01.vs.00/ - incremental >> http://cr.openjdk.java.net/~tbenson/8060697/webrev.01/ - full > I'd previously overlooked the removal of the const qualifier from > G1CollectorPolicy::expansion_amount. This was done to permit some > member variables to be updated to accumulate additional information > (specifically, the fields that are reset by the new > clear_ratio_check_data). But the function name "expansion_amount" > looks to me like an accessor or compute function, and not something > that modifies the policy object. > > I don't have a good alternative (either structure or naming) to offer > right now, but maybe you or someone else might think of something. Or > maybe I'm the only one (somewhat) bothered by this. > From bengt.rutisson at oracle.com Tue Dec 8 09:14:13 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 08 Dec 2015 10:14:13 +0100 Subject: RRF: JEP-271: Unified GC Logging In-Reply-To: <5665B7E0.7020204@oracle.com> References: <564DEAEB.90703@oracle.com> <56534C0D.3070209@oracle.com> <5655A994.7000304@oracle.com> <5655B0E2.6040009@oracle.com> <565D9C07.2080808@oracle.com> <56658F58.1040409@oracle.com> <5665B7E0.7020204@oracle.com> Message-ID: <56669F65.6090906@oracle.com> Hi Stefan, On 2015-12-07 17:46, Stefan Johansson wrote: > Hi Bengt, > > On 2015-12-07 14:53, Bengt Rutisson wrote: >> >> Hi all, >> >> Jenny noticed a bug in the heap transition information for G1 >> (Survivors were reported twice). Here's an updated webrev of the >> hotspot repo that contains the fix for that: >> >> http://cr.openjdk.java.net/~brutisso/JEP-271/review.03/hotspot-webrev.03/ >> > Look good, just one minor thing: > src/share/vm/gc/shared/collectorPolicy.cpp > 556 log_trace(heap)("2: Minimum young " SIZE_FORMAT " Initial > young " SIZE_FORMAT " Maximum young " SIZE_FORMAT, > 557 _min_young_size, _initial_young_size, > _max_young_size); > ... > 573 log_trace(heap)("Minimum old " SIZE_FORMAT " Initial old " > SIZE_FORMAT " Maximum old " SIZE_FORMAT, > 574 _min_old_size, _initial_old_size, _max_old_size); > > Those two log-statements should use the gc tag, like the statement on > line 489. Good point. Fixed. > >> >> Here is the diff compared to the last webrev: >> http://cr.openjdk.java.net/~brutisso/JEP-271/review.03/hotspot-webrev.02-03.diff/ >> >> >> Here is the diff compared to webrev.01 in case someone has reviewed >> webrev.01 but not webrev.02 yet: >> >> http://cr.openjdk.java.net/~brutisso/JEP-271/review.03/hotspot-webrev.01-03.diff/ >> >> >> >> The JDK repo is unchanged, so thes links are still valid to use for >> review: >> >> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.02/ >> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.01-02.diff/ >> > This looks good. Thanks for looking at this! Bengt > > Thanks, > StefanJ > >> >> Thanks, >> Bengt >> >> >> On 2015-12-01 14:09, Bengt Rutisson wrote: >>> >>> Hi everyone, >>> >>> Here are updated webrevs that include the comments on the last >>> review request. >>> >>> HotSpot changes: >>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/hotspot-webrev.02/ >>> >>> >>> Complete changes: >>> >>> Diff compared to last webrev: >>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/hotspot-webrev.01-02.diff/ >>> >>> >>> >>> JDK changes: >>> >>> Complete changes: >>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.02/ >>> >>> Diff compared to last webrev: >>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.02/jdk-webrev.01-02.diff/ >>> >>> >>> >>> Except for the comment that were discussed in this email thread >>> there are a couple of other changes: >>> >>> - Most of the implementation parts in gcTraceTime.hpp were moved to >>> gcTraceTime.inline.hpp. >>> - New tests and new code that use logging were updated. >>> - Some tests were changed to use less extensive logging. >>> - A bug gave duplicate timing for Full GCs when going through >>> GenCollectedHeap >>> - The used calculation for G1 old logging could overflow. >>> - The @ignore tag was added back to TestLogging.java. >>> >>> Thanks, >>> Bengt >>> >>> On 2015-11-25 14:00, Bengt Rutisson wrote: >>>> >>>> Hi David, >>>> >>>> Thanks for looking at this again! >>>> >>>> On 2015-11-25 13:29, David Lindholm wrote: >>>>> Hi Bengt, >>>>> >>>>> My code review for the rest of the files: >>>>> >>>>> defNewGeneration.cpp: >>>>> >>>>> 517-520: Indentation >>>> >>>> Fixed. >>>> >>>>> 766: Shouldn't the tags be "gc, promotion"? >>>> >>>> Yes. Fixed. >>>> >>>>> >>>>> collectorPolicy.cpp: >>>>> >>>>> 489: Shouldn't the tags be "gc, heap"? >>>> >>>> Yes, fixed. >>>> >>>>> >>>>> genCollectedHeap.cpp: >>>>> >>>>> 1150+1152: Indentation >>>>> >>>>> generation.cpp: >>>>> >>>>> 162: Indentation >>>> >>>> Fixed. >>>> >>>>> >>>>> plab.cpp: >>>>> >>>>> 153: Plab_size = " SIZE_FORMAT " desired_net_plab_sz = " >>>>> SIZE_FORMAT ": Why the capital P in this printout of one variable >>>>> name but not the other? I think it should be consistent. >>>> >>>> Agreed. Fixed. >>>> >>>> >>>>> >>>>> referenceProcessor.cpp: >>>>> >>>>> 515: Indentation >>>>> >>>>> referenceProcessor.cpp: >>>>> >>>>> 948+953: Indentation >>>>> >>>>> metaspace.cpp: >>>>> >>>>> 1505: Indentation >>>>> 1578+1580: Indentation >>>>> 2695: Indentation >>>>> >>>>> runtimeService.cpp: >>>>> >>>>> 123-124: Indentation >>>> >>>> Fixed. >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 2015-11-23 18:25, Bengt Rutisson wrote: >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> Here is an updated webrev based on the comments from the first >>>>>> review. The changes that have been discussed have only been to >>>>>> the hotspot repo: >>>>>> >>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.01/ >>>>>> >>>>>> The changes to the JDK repo are the same as in the first webrev: >>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/jdk-webrev.00/ >>>>>> >>>>>> >>>>>> >>>>>> Some partial diffs to make it easier for those who already looked >>>>>> at the first webrev. >>>>>> >>>>>> The unified logging framework was changed in the way it handles >>>>>> the develop logging. Here are the changes I had to do to >>>>>> accommodate the new develop logging: >>>>>> >>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.01-develop-logging >>>>>> >>>>>> >>>>>> Here are the changes I have made to address comments in the code >>>>>> (based on top of the develop logging changes): >>>>>> >>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.00-01-code-diff >>>>>> >>>>>> >>>>>> And here are the changes that David has made to address comment >>>>>> in the tests: >>>>>> >>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.01/webrev.00-01-test-diff >>>>>> >>>>>> >>>>>> Enjoy! >>>>>> Bengt >>>>>> >>>>>> On 2015-11-19 16:29, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> After three pre-reviews it is time for the fist official review >>>>>>> request for JEP-271 Unified GC Logging. >>>>>>> >>>>>>> http://openjdk.java.net/jeps/271 >>>>>>> >>>>>>> Most code changes are in the hotspot code: >>>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/webrev.00/ >>>>>>> >>>>>>> Some tests in the JDK repo have been updated: >>>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/jdk-webrev.00/ >>>>>>> >>>>>>> >>>>>>> As with the pre-reviews I have put togther some examples of what >>>>>>> the new logging looks like: >>>>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/compare.html >>>>>>> >>>>>>> The intent is that this should cover the bulk of the logging >>>>>>> changes. There will most definitely be some follow up changes >>>>>>> where we fix details in the log messages etc. >>>>>>> >>>>>>> Among many other old logging flags this changeset removes the >>>>>>> two flags PringGC and PrintGCDetails. These two will be added >>>>>>> back with a follow up changeset, but when they are added back >>>>>>> they will be marked as deprecated. >>>>>>> >>>>>>> The reason for first removing them and then adding them back is >>>>>>> to get testing without these flags. That way we will know that >>>>>>> we clean out all usages of these flags from our testing. >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>>> >>>>> >>>> >>> >> > From mikael.gerdin at oracle.com Tue Dec 8 12:59:34 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 8 Dec 2015 13:59:34 +0100 Subject: RFR (S): 8144714 Add extension point to G1 evacuation closures In-Reply-To: <5661D09D.3060309@oracle.com> References: <5661AEC4.3040805@oracle.com> <5661D09D.3060309@oracle.com> Message-ID: <5666D436.4070907@oracle.com> Hi Jon, On 2015-12-04 18:42, Jon Masamitsu wrote: > Mikael, > > Looks good. Couple of minor points. > > http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/src/share/vm/gc/g1/g1InCSetState.hpp.frames.html > > > Is the Ext value explained by the comment "The other values ..."? If it > does apply > to the Ext value, I don't understand. "getting to the next generation" > doesn't seem > to apply. Actually, I don't understand that comment with respect to > Humongous either. > > 56 // The other values are simply encoded in increasing > generation order, which > 57 // makes getting the next generation fast by a simple increment. > 58 Ext = -2, // Extension point The comment appears to be a bit outdated, I suggest changing it to: // Selection of the values were driven to micro-optimize the encoding and // frequency of the checks. // The most common check is whether the region is in the collection set or not, // this encoding allows us to use an > 0 check. // The positive values are encoded in increasing generation order, which // makes getting the next generation fast by a simple increment. They are also // used to index into arrays. // The negative values are used for objects requiring various special cases, // for example eager reclamation of humongous objects. > > > http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/src/share/vm/gc/g1/g1ParScanThreadState_ext.cpp.frames.html > > > Lines 39 and 40 not particularly useful? FWIW, I understood that you meant the empty lines, I'll remove them. :) /Mikael > > 37 template void G1ParScanThreadState::do_oop_ext(oop* ref); > 38 template void G1ParScanThreadState::do_oop_ext(narrowOop* > ref); > 39 > 40 > > Jon > > > On 12/4/2015 7:18 AM, Mikael Gerdin wrote: >> Hi all, >> >> Please review this small change to add a hook in the G1 evacuation path. >> This allows extension code to register regions which are otherwise >> interesting to the GC and get notifications when pointers into such >> regions are encountered. >> >> Testing: JPRT, gc test suite >> Performance: >> This additional branch in G1ParScanClosure introduces a slight >> regression of about 1-2% in GC pause times. I have some performance >> fixes to make up for that regression in the pipe. >> >> webrev: http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8144714 >> >> Thanks >> /Mikael > From stefan.johansson at oracle.com Tue Dec 8 13:42:29 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 8 Dec 2015 14:42:29 +0100 Subject: RFR: 8144908: Remove apply_to_weak_ref_discovered_field override for UpdateRSOopClosure Message-ID: <5666DE45.70802@oracle.com> Hi, Please review this change for: https://bugs.openjdk.java.net/browse/JDK-8144908 Webrev: http://cr.openjdk.java.net/~sjohanss/8138888/8144908/hotspot.00/ Background: When iterating objects with oop_iterate() there is a special case for InstanceRefKlass, if the closure overrides apply_to_weak_ref_discovered_field() to return true, the closure will be applied to the discovered field, even if the normal checks prevents it. This special treatment is needed in certain situations, but it is not obvious if it should be done when iterating the object. Currently only G1 closures override apply_to_weak_ref_discovered_field() and many of them seem to do it without any reason. My initial plan [1] was to remove all usage of this special casing but after discussions I realized it would be easier to see the effects if doing this one closure at a time. Summary: UpdateRSOopClosure is used to re-build the remembered sets after a G1 full GC. This is done after reference discovery and enqueuing (to the pending list) has been completed, so all discovered references have their next-field set. Before the full GC is started all references discovered by the concurrent-mark reference processor is clear to allow them to be discovered during the full GC. So at the point of applying the UpdateRSOopClosure, no references should have their discovered field set but still be active (next == null). So overriding apply_to_weak_ref_discovered_field to make sure the discovered field is handled doesn't have any effect. Either the discovered and next field are both set and thus gets handled the normal way, or the discovered field is not set and there is no reason to handle it at all. Testing: * RBT * GC-test-suite run locally with small heap (to trigger full GC) and verification turned on. Thanks, Stefan [1] https://bugs.openjdk.java.net/browse/JDK-8138888 From kim.barrett at oracle.com Tue Dec 8 16:12:21 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Dec 2015 11:12:21 -0500 Subject: RFR: 8144908: Remove apply_to_weak_ref_discovered_field override for UpdateRSOopClosure In-Reply-To: <5666DE45.70802@oracle.com> References: <5666DE45.70802@oracle.com> Message-ID: <586C6D69-0349-40F7-93D2-E5A9C5F73E48@oracle.com> On Dec 8, 2015, at 8:42 AM, Stefan Johansson wrote: > > Hi, > > Please review this change for: > https://bugs.openjdk.java.net/browse/JDK-8144908 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8138888/8144908/hotspot.00/ Looks good. I noticed you also removed the commented out override of idempotent. Is there a task to do anything with that? I looked a while ago, and I think there were no classes that provided a definition other than the default one that returns false. I think there were a couple that were commented out, like this one. Probably there should be an RFE to either actually use it, or get rid of it. > Background: > When iterating objects with oop_iterate() there is a special case for InstanceRefKlass, if the closure overrides apply_to_weak_ref_discovered_field() to return true, the closure will be applied to the discovered field, even if the normal checks prevents it. This special treatment is needed in certain situations, but it is not obvious if it should be done when iterating the object. Currently only G1 closures override apply_to_weak_ref_discovered_field() and many of them seem to do it without any reason. My initial plan [1] was to remove all usage of this special casing but after discussions I realized it would be easier to see the effects if doing this one closure at a time. > > Summary: > UpdateRSOopClosure is used to re-build the remembered sets after a G1 full GC. This is done after reference discovery and enqueuing (to the pending list) has been completed, so all discovered references have their next-field set. Before the full GC is started all references discovered by the concurrent-mark reference processor is clear to allow them to be discovered during the full GC. > > So at the point of applying the UpdateRSOopClosure, no references should have their discovered field set but still be active (next == null). So overriding apply_to_weak_ref_discovered_field to make sure the discovered field is handled doesn't have any effect. Either the discovered and next field are both set and thus gets handled the normal way, or the discovered field is not set and there is no reason to handle it at all. > > Testing: > * RBT > * GC-test-suite run locally with small heap (to trigger full GC) and verification turned on. > > Thanks, > Stefan > > [1] https://bugs.openjdk.java.net/browse/JDK-8138888 From jon.masamitsu at oracle.com Tue Dec 8 20:34:28 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 8 Dec 2015 12:34:28 -0800 Subject: RFR: 8144908: Remove apply_to_weak_ref_discovered_field override for UpdateRSOopClosure In-Reply-To: <5666DE45.70802@oracle.com> References: <5666DE45.70802@oracle.com> Message-ID: <56673ED4.7020309@oracle.com> Stefan, At line 41 in "share/vm/oops/instanceRefKlass.inline.hpp" 38 void InstanceRefKlass::oop_oop_iterate_ref_processing_specialized(oop obj, OopClosureType* closure, Contains& contains) { 39 T* disc_addr = (T*)java_lang_ref_Reference::discovered_addr(obj); 40 if (closure->apply_to_weak_ref_discovered_field()) { 41 Devirtualizer::do_oop(closure, disc_addr); 42 } you're saying that the "next" field of "obj" is non-null? Did you try adding a guarantee to that effect and run your testing (without your change, of course)? Jon On 12/8/2015 5:42 AM, Stefan Johansson wrote: > Hi, > > Please review this change for: > https://bugs.openjdk.java.net/browse/JDK-8144908 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8138888/8144908/hotspot.00/ > > Background: > When iterating objects with oop_iterate() there is a special case for > InstanceRefKlass, if the closure overrides > apply_to_weak_ref_discovered_field() to return true, the closure will > be applied to the discovered field, even if the normal checks prevents > it. This special treatment is needed in certain situations, but it is > not obvious if it should be done when iterating the object. Currently > only G1 closures override apply_to_weak_ref_discovered_field() and > many of them seem to do it without any reason. My initial plan [1] was > to remove all usage of this special casing but after discussions I > realized it would be easier to see the effects if doing this one > closure at a time. > > Summary: > UpdateRSOopClosure is used to re-build the remembered sets after a G1 > full GC. This is done after reference discovery and enqueuing (to the > pending list) has been completed, so all discovered references have > their next-field set. Before the full GC is started all references > discovered by the concurrent-mark reference processor is clear to > allow them to be discovered during the full GC. > > So at the point of applying the UpdateRSOopClosure, no references > should have their discovered field set but still be active (next == > null). So overriding apply_to_weak_ref_discovered_field to make sure > the discovered field is handled doesn't have any effect. Either the > discovered and next field are both set and thus gets handled the > normal way, or the discovered field is not set and there is no reason > to handle it at all. > > Testing: > * RBT > * GC-test-suite run locally with small heap (to trigger full GC) and > verification turned on. > > Thanks, > Stefan > > [1] https://bugs.openjdk.java.net/browse/JDK-8138888 From kim.barrett at oracle.com Tue Dec 8 21:16:52 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Dec 2015 16:16:52 -0500 Subject: RFR: 8144908: Remove apply_to_weak_ref_discovered_field override for UpdateRSOopClosure In-Reply-To: <56673ED4.7020309@oracle.com> References: <5666DE45.70802@oracle.com> <56673ED4.7020309@oracle.com> Message-ID: <53A60769-933C-4D41-80DF-ABB57EFE9E7C@oracle.com> On Dec 8, 2015, at 3:34 PM, Jon Masamitsu wrote: > > Stefan, > > At line 41 in "share/vm/oops/instanceRefKlass.inline.hpp" > > 38 void InstanceRefKlass::oop_oop_iterate_ref_processing_specialized(oop obj, OopClosureType* closure, > Contains& contains) { > 39 T* disc_addr = (T*)java_lang_ref_Reference::discovered_addr(obj); > 40 if (closure->apply_to_weak_ref_discovered_field()) { > 41 Devirtualizer::do_oop(closure, disc_addr); > 42 } > > you're saying that the "next" field of "obj" is > non-null? Did you try adding a guarantee to that > effect and run your testing (without your change, > of course)? If next is NULL then, for the specific closure in question, discovered must also be NULL here. There is no point in applying closure to the NULL-valued discovered field. There are other closures for which that relationship between next and discovered doesn?t hold, but we think it will turn out that none of them have apply_to_weak_ref_discovered_field returning true. Note that if next is non-NULL, then the closure will be applied to discovered in the normal path, and there is no need for this special case forced application (and is in fact duplicating work at present, which could be a bug on its own, except we think the special case is going away). From jon.masamitsu at oracle.com Tue Dec 8 22:41:32 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 8 Dec 2015 14:41:32 -0800 Subject: RFR(S): 8132723, 8132724: Add tests which check that soft/weak references to humongous objects should work correctly In-Reply-To: <5654B509.9030409@oracle.com> References: <5654B509.9030409@oracle.com> Message-ID: <56675C9C.3000705@oracle.com> Kirill, Test looks good. One enhancement you might consider (not necessarily for this integration) is to print out "adr" and the g1 region for "adr" if the test fails. I'm guessing you can get the g1 region from WB. If the test fails and you have the list of g1 regions (it would be in the hs_err log file), the first thing you might want to do is look up the g1 region to see if there is anything unexpected about it. Just something to consider. Jon On 11/24/2015 11:05 AM, Kirill Zhaldybin wrote: > Hi! > > Could you please review the following patch that adds a test that > checks that soft/weak references to humongous objects work correctly? > > The test checks that weak and soft references behave correspondingly > to actual object behavior: > 1. If an object is collected a weak/soft reference .get() should > return null. > 2. If an object is not collected a weak/soft reference .get() should > not return null. > > Two White Box API methods were added: > 1. g1BelongsToHumongousRegion which checks that address belongs to > humongous region > 2. g1BelongsToFreeRegion which checks that address belongs to free region > These methods do not impact G1 performance/stability since they don't > change anything in G1 execution. > > The only used method from gc/testlibrary is waitTillCMCFinished, which > is under review here - > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-November/015643.html > > > CR: https://bugs.openjdk.java.net/browse/JDK-8132723 > https://bugs.openjdk.java.net/browse/JDK-8132724 > > Webrev: > main: > http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132724/webrev.02/main/ > hotspot: > http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132724/webrev.02/hotspot/ > > Thank you. > > Regards, Kirill From david.lindholm at oracle.com Wed Dec 9 09:12:34 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Wed, 9 Dec 2015 10:12:34 +0100 Subject: RFR(XS): JDK-8144837: Improve the printout of heap regions in hs_err dump files. Message-ID: <5667F082.7050004@oracle.com> Hi, Please review the following patch that changes the format for the heap region printouts in hs_err files and when running with -XX:+PrintHeapAtGCExtended The old format looked like this: AC 0 F TS 5 PTAMS 0x00000005cbc00000 NTAMS 0x00000005cbc00000 space 2048K, 0% used [0x00000005cbc00000, 0x00000005cbe00000) AC 0 S CS TS 7 PTAMS 0x00000005cbe00000 NTAMS 0x00000005cbe00000 space 2048K, 100% used [0x00000005cbe00000, 0x00000005cc000000) AC 0 F TS 5 PTAMS 0x00000005cc000000 NTAMS 0x00000005cc000000 space 2048K, 0% used [0x00000005cc000000, 0x00000005cc200000) The new format looks like this: [ 21][0x00000005cd000000, 0x00000005cd000000, 0x00000005cd200000][ 0%][ F][ ][TS 7][AC 0][TAMS 0x00000005cd000000, 0x00000005cd000000] [ 22][0x00000005cd200000, 0x00000005cd400000, 0x00000005cd400000][100%][ S][CS][TS 9][AC 0][TAMS 0x00000005cd200000, 0x00000005cd200000] [ 23][0x00000005cd400000, 0x00000005cd600000, 0x00000005cd600000][100%][ S][CS][TS 9][AC 0][TAMS 0x00000005cd400000, 0x00000005cd400000] The first number is the index, and for each heap region we print bottom, top and end. Bug: https://bugs.openjdk.java.net/browse/JDK-8144837 Webrev: http://cr.openjdk.java.net/~david/JDK-8144837/webrev.00/ Thanks, David From stefan.johansson at oracle.com Wed Dec 9 09:20:04 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 9 Dec 2015 10:20:04 +0100 Subject: RFR: 8144908: Remove apply_to_weak_ref_discovered_field override for UpdateRSOopClosure In-Reply-To: <53A60769-933C-4D41-80DF-ABB57EFE9E7C@oracle.com> References: <5666DE45.70802@oracle.com> <56673ED4.7020309@oracle.com> <53A60769-933C-4D41-80DF-ABB57EFE9E7C@oracle.com> Message-ID: <5667F244.7040403@oracle.com> On 2015-12-08 22:16, Kim Barrett wrote: > On Dec 8, 2015, at 3:34 PM, Jon Masamitsu wrote: >> Stefan, >> >> At line 41 in "share/vm/oops/instanceRefKlass.inline.hpp" >> >> 38 void InstanceRefKlass::oop_oop_iterate_ref_processing_specialized(oop obj, OopClosureType* closure, >> Contains& contains) { >> 39 T* disc_addr = (T*)java_lang_ref_Reference::discovered_addr(obj); >> 40 if (closure->apply_to_weak_ref_discovered_field()) { >> 41 Devirtualizer::do_oop(closure, disc_addr); >> 42 } >> >> you're saying that the "next" field of "obj" is >> non-null? Did you try adding a guarantee to that >> effect and run your testing (without your change, >> of course)? > If next is NULL then, for the specific closure in question, discovered must also be NULL here. There is no point in applying closure to the NULL-valued discovered field. There are other closures for which that relationship between next and discovered doesn?t hold, but we think it will turn out that none of them have apply_to_weak_ref_discovered_field returning true. > > Note that if next is non-NULL, then the closure will be applied to discovered in the normal path, and there is no need for this special case forced application (and is in fact duplicating work at present, which could be a bug on its own, except we think the special case is going away). > > As Kim say, for this specific closure the assumption holds, but it's not true for all closures. Some time ago I did test-runs with extra debug code to see which closures were applied with discovered field set but next field NULL. The two closures that showed up was: FilterOutOfRegionClosure G1ParPushHeapRSClosure They both have apply_to_weak_ref_discovered_field returning true, but to me it is not clear that they need it. My goal is to remove all other use of apply_to_weak_ref_discovered_field first and then attack those two. Either by somehow showing that the special case is no longer needed or by handling the discovered field (or actually the discovered list) some other way. From thomas.schatzl at oracle.com Wed Dec 9 09:57:25 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 09 Dec 2015 10:57:25 +0100 Subject: RFR (M): 8060697: Improve G1 Heap Growth Heuristics In-Reply-To: <566633DF.4030009@oracle.com> References: <5653D33D.3090906@oracle.com> <1449056510.2642.75.camel@oracle.com> <1449057651.2642.86.camel@oracle.com> <56607093.3010102@oracle.com> <78EB4021-4190-45CF-960A-875995A463E5@oracle.com> <566633DF.4030009@oracle.com> Message-ID: <1449655045.2195.3.camel@oracle.com> Hi, On Mon, 2015-12-07 at 20:35 -0500, Tom Benson wrote: > Hi Kim, > Yes, that's it exactly. I'm not bothered by it, but am open to > suggestions if someone feels strongly. > Tnx, > Tom > > On 12/7/2015 7:30 PM, Kim Barrett wrote: > > On Dec 3, 2015, at 11:40 AM, Tom Benson wrote: > >> Updated webrevs (including the suggestions from Kim and Jon) are in: > >> > >> http://cr.openjdk.java.net/~tbenson/8060697/webrev.01.vs.00/ - incremental > >> http://cr.openjdk.java.net/~tbenson/8060697/webrev.01/ - full > > I'd previously overlooked the removal of the const qualifier from > > G1CollectorPolicy::expansion_amount. This was done to permit some > > member variables to be updated to accumulate additional information > > (specifically, the fields that are reset by the new > > clear_ratio_check_data). But the function name "expansion_amount" > > looks to me like an accessor or compute function, and not something > > that modifies the policy object. > > > > I don't have a good alternative (either structure or naming) to offer > > right now, but maybe you or someone else might think of something. Or > > maybe I'm the only one (somewhat) bothered by this. > > > I already noticed that, but I have not good advice for that either. Looked at latest changes again, looks good. No preference about the (double) casts in the other email. Thanks, Thomas From thomas.schatzl at oracle.com Wed Dec 9 10:08:10 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 09 Dec 2015 11:08:10 +0100 Subject: RFR (XXS): 8144690: g1Predictions.hpp includes allocation.inline.hpp In-Reply-To: <5661E58C.7060209@oracle.com> References: <1449255801.2160.2.camel@oracle.com> <5661E58C.7060209@oracle.com> Message-ID: <1449655690.2195.5.camel@oracle.com> Hi Stefan and Jon, On Fri, 2015-12-04 at 11:12 -0800, Jon Masamitsu wrote: > Looks good. > > Jon thanks for the reviews. Thomas From marcus.larsson at oracle.com Wed Dec 9 11:57:56 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 9 Dec 2015 12:57:56 +0100 Subject: RFR (XS): Forward port of 8065331: Add trace events for failed allocations In-Reply-To: <5665511F.8000509@oracle.com> References: <55DACA18.2070605@oracle.com> <55DD8F43.7070003@oracle.com> <5665511F.8000509@oracle.com> Message-ID: <56681744.4030907@oracle.com> Hi, After offline discussions with Bengt, I've decided to omit the Pending GCId from the event. The ID used previously was never guaranteed to be correct, since it came from the peek() method. Sometimes a GCId would be skipped which then caused some of the events to have an "invalid" GCId. Grouping these events together with some GC will now instead have to be done by the event timestamps. New webrev: http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.02/ Incremental: http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.01-02/ Thanks, Marcus On 2015-12-07 10:27, Marcus Larsson wrote: > Hi all, > > Still need approval for this forward port. > > New webrev due to changes in how GCId works: > http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.01/ > > Had to add a peek method in order to find the pending GC id for the > event. > This and the changes to includes should be the only things differing > from the original patch. > > Thanks, > Marcus > > On 2015-08-26 12:04, Marcus Larsson wrote: >> Ping! >> >> On 2015-08-24 09:39, Marcus Larsson wrote: >>> Hi, >>> >>> Please review the following patch to forward port the JEP-242 event >>> to JDK9. The patch was originally reviewed in April/March [1], but >>> was only integrated in 8u60. The original patch no longer applies >>> cleanly to 9, due to directory restructuring and changes to >>> includes, so I need a quick re-review for this. >>> >>> The new patch has updated #includes for the new directory structure >>> but should otherwise be identical to the previous patch. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.00/ >>> >>> Original webrev: >>> http://cr.openjdk.java.net/~mlarsson/8065331/webrev.02/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8065331 >>> >>> Thanks, >>> Marcus >>> >>> [1]: >>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-March/012408.html >> > From stefan.karlsson at oracle.com Wed Dec 9 12:32:44 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 9 Dec 2015 13:32:44 +0100 Subject: RFR(XS): JDK-8144837: Improve the printout of heap regions in hs_err dump files. In-Reply-To: <5667F082.7050004@oracle.com> References: <5667F082.7050004@oracle.com> Message-ID: <56681F6C.7050206@oracle.com> Hi David, On 2015-12-09 10:12, David Lindholm wrote: > Hi, > > Please review the following patch that changes the format for the heap > region printouts in hs_err files and when running with > -XX:+PrintHeapAtGCExtended > > The old format looked like this: > > AC 0 F TS 5 PTAMS 0x00000005cbc00000 NTAMS > 0x00000005cbc00000 space 2048K, 0% used [0x00000005cbc00000, > 0x00000005cbe00000) > AC 0 S CS TS 7 PTAMS 0x00000005cbe00000 NTAMS > 0x00000005cbe00000 space 2048K, 100% used [0x00000005cbe00000, > 0x00000005cc000000) > AC 0 F TS 5 PTAMS 0x00000005cc000000 NTAMS > 0x00000005cc000000 space 2048K, 0% used [0x00000005cc000000, > 0x00000005cc200000) > > The new format looks like this: > > [ 21][0x00000005cd000000, 0x00000005cd000000, 0x00000005cd200000][ > 0%][ F][ ][TS 7][AC 0][TAMS 0x00000005cd000000, 0x00000005cd000000] > [ 22][0x00000005cd200000, 0x00000005cd400000, > 0x00000005cd400000][100%][ S][CS][TS 9][AC 0][TAMS > 0x00000005cd200000, 0x00000005cd200000] > [ 23][0x00000005cd400000, 0x00000005cd600000, > 0x00000005cd600000][100%][ S][CS][TS 9][AC 0][TAMS > 0x00000005cd400000, 0x00000005cd400000] Could we use pipes instead of the square brackets. Too me that reduces the clutter a bit: | 21|0x00000005cd000000, 0x00000005cd000000, 0x00000005cd200000| 0%| F| |TS 7|AC 0|TAMS 0x00000005cd000000, 0x00000005cd000000| | 22|0x00000005cd200000, 0x00000005cd400000, 0x00000005cd400000|100%| S|CS|TS 9|AC 0|TAMS 0x00000005cd200000, 0x00000005cd200000| | 23|0x00000005cd400000, 0x00000005cd600000, 0x00000005cd600000|100%| S|CS|TS 9|AC 0|TAMS 0x00000005cd400000, 0x00000005cd400000| Thanks, StefanK > > The first number is the index, and for each heap region we print > bottom, top and end. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8144837 > Webrev: http://cr.openjdk.java.net/~david/JDK-8144837/webrev.00/ > > > Thanks, > David From david.lindholm at oracle.com Wed Dec 9 12:29:00 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Wed, 9 Dec 2015 13:29:00 +0100 Subject: RFR(XS): JDK-8144837: Improve the printout of heap regions in hs_err dump files. In-Reply-To: <56681F6C.7050206@oracle.com> References: <5667F082.7050004@oracle.com> <56681F6C.7050206@oracle.com> Message-ID: <56681E8C.7040101@oracle.com> Hi Stefan, On 2015-12-09 13:32, Stefan Karlsson wrote: > Hi David, > > On 2015-12-09 10:12, David Lindholm wrote: >> Hi, >> >> Please review the following patch that changes the format for the >> heap region printouts in hs_err files and when running with >> -XX:+PrintHeapAtGCExtended >> >> The old format looked like this: >> >> AC 0 F TS 5 PTAMS 0x00000005cbc00000 NTAMS >> 0x00000005cbc00000 space 2048K, 0% used [0x00000005cbc00000, >> 0x00000005cbe00000) >> AC 0 S CS TS 7 PTAMS 0x00000005cbe00000 NTAMS >> 0x00000005cbe00000 space 2048K, 100% used [0x00000005cbe00000, >> 0x00000005cc000000) >> AC 0 F TS 5 PTAMS 0x00000005cc000000 NTAMS >> 0x00000005cc000000 space 2048K, 0% used [0x00000005cc000000, >> 0x00000005cc200000) >> >> The new format looks like this: >> >> [ 21][0x00000005cd000000, 0x00000005cd000000, 0x00000005cd200000][ >> 0%][ F][ ][TS 7][AC 0][TAMS 0x00000005cd000000, 0x00000005cd000000] >> [ 22][0x00000005cd200000, 0x00000005cd400000, >> 0x00000005cd400000][100%][ S][CS][TS 9][AC 0][TAMS >> 0x00000005cd200000, 0x00000005cd200000] >> [ 23][0x00000005cd400000, 0x00000005cd600000, >> 0x00000005cd600000][100%][ S][CS][TS 9][AC 0][TAMS >> 0x00000005cd400000, 0x00000005cd400000] > > Could we use pipes instead of the square brackets. Too me that reduces > the clutter a bit: > | 21|0x00000005cd000000, 0x00000005cd000000, 0x00000005cd200000| 0%| > F| |TS 7|AC 0|TAMS 0x00000005cd000000, 0x00000005cd000000| > | 22|0x00000005cd200000, 0x00000005cd400000, 0x00000005cd400000|100%| > S|CS|TS 9|AC 0|TAMS 0x00000005cd200000, 0x00000005cd200000| > | 23|0x00000005cd400000, 0x00000005cd600000, 0x00000005cd600000|100%| > S|CS|TS 9|AC 0|TAMS 0x00000005cd400000, 0x00000005cd400000| Sure. New webrev: http://cr.openjdk.java.net/~david/JDK-8144837/webrev.01/ Thanks, David > Thanks, > StefanK > >> >> The first number is the index, and for each heap region we print >> bottom, top and end. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8144837 >> Webrev: http://cr.openjdk.java.net/~david/JDK-8144837/webrev.00/ >> >> >> Thanks, >> David > From stefan.johansson at oracle.com Wed Dec 9 12:46:07 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 9 Dec 2015 13:46:07 +0100 Subject: RFR(XS): JDK-8144837: Improve the printout of heap regions in hs_err dump files. In-Reply-To: <56681E8C.7040101@oracle.com> References: <5667F082.7050004@oracle.com> <56681F6C.7050206@oracle.com> <56681E8C.7040101@oracle.com> Message-ID: <5668228F.8010304@oracle.com> Hi David, On 2015-12-09 13:29, David Lindholm wrote: > Hi Stefan, > > On 2015-12-09 13:32, Stefan Karlsson wrote: >> Hi David, >> >> On 2015-12-09 10:12, David Lindholm wrote: >>> Hi, >>> >>> Please review the following patch that changes the format for the >>> heap region printouts in hs_err files and when running with >>> -XX:+PrintHeapAtGCExtended >>> >>> The old format looked like this: >>> >>> AC 0 F TS 5 PTAMS 0x00000005cbc00000 NTAMS >>> 0x00000005cbc00000 space 2048K, 0% used [0x00000005cbc00000, >>> 0x00000005cbe00000) >>> AC 0 S CS TS 7 PTAMS 0x00000005cbe00000 NTAMS >>> 0x00000005cbe00000 space 2048K, 100% used [0x00000005cbe00000, >>> 0x00000005cc000000) >>> AC 0 F TS 5 PTAMS 0x00000005cc000000 NTAMS >>> 0x00000005cc000000 space 2048K, 0% used [0x00000005cc000000, >>> 0x00000005cc200000) >>> >>> The new format looks like this: >>> >>> [ 21][0x00000005cd000000, 0x00000005cd000000, 0x00000005cd200000][ >>> 0%][ F][ ][TS 7][AC 0][TAMS 0x00000005cd000000, 0x00000005cd000000] >>> [ 22][0x00000005cd200000, 0x00000005cd400000, >>> 0x00000005cd400000][100%][ S][CS][TS 9][AC 0][TAMS >>> 0x00000005cd200000, 0x00000005cd200000] >>> [ 23][0x00000005cd400000, 0x00000005cd600000, >>> 0x00000005cd600000][100%][ S][CS][TS 9][AC 0][TAMS >>> 0x00000005cd400000, 0x00000005cd400000] >> >> Could we use pipes instead of the square brackets. Too me that >> reduces the clutter a bit: >> | 21|0x00000005cd000000, 0x00000005cd000000, 0x00000005cd200000| 0%| >> F| |TS 7|AC 0|TAMS 0x00000005cd000000, 0x00000005cd000000| >> | 22|0x00000005cd200000, 0x00000005cd400000, >> 0x00000005cd400000|100%| S|CS|TS 9|AC 0|TAMS 0x00000005cd200000, >> 0x00000005cd200000| >> | 23|0x00000005cd400000, 0x00000005cd600000, >> 0x00000005cd600000|100%| S|CS|TS 9|AC 0|TAMS 0x00000005cd400000, >> 0x00000005cd400000| > > Sure. New webrev: > > http://cr.openjdk.java.net/~david/JDK-8144837/webrev.01/ > Looks good, I think this is a great improvement. Thanks, Stefan > Thanks, > David > >> Thanks, >> StefanK >> >>> >>> The first number is the index, and for each heap region we print >>> bottom, top and end. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144837 >>> Webrev: http://cr.openjdk.java.net/~david/JDK-8144837/webrev.00/ >>> >>> >>> Thanks, >>> David >> > From stefan.johansson at oracle.com Wed Dec 9 12:55:29 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 9 Dec 2015 13:55:29 +0100 Subject: RFR: 8144908: Remove apply_to_weak_ref_discovered_field override for UpdateRSOopClosure In-Reply-To: <586C6D69-0349-40F7-93D2-E5A9C5F73E48@oracle.com> References: <5666DE45.70802@oracle.com> <586C6D69-0349-40F7-93D2-E5A9C5F73E48@oracle.com> Message-ID: <566824C1.9050603@oracle.com> On 2015-12-08 17:12, Kim Barrett wrote: > On Dec 8, 2015, at 8:42 AM, Stefan Johansson wrote: >> Hi, >> >> Please review this change for: >> https://bugs.openjdk.java.net/browse/JDK-8144908 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8138888/8144908/hotspot.00/ > Looks good. Thanks. > > I noticed you also removed the commented out override of idempotent. Is there a task to do anything with that? I looked a while ago, and I think there were no classes that provided a definition other than the default one that returns false. I think there were a couple that were commented out, like this one. Probably there should be an RFE to either actually use it, or get rid of it. Yeah, I did. Maybe this should have been left to a cleanup removing idempotent for good, but the risk is that someone misses that since it's commented out. I didn't find an RFE for it when doing a quick search but I certainly think we should add one. I could not find anyone overriding it either, so I think it can be removed pretty safely. I'll file an RFE for it. >> Background: >> When iterating objects with oop_iterate() there is a special case for InstanceRefKlass, if the closure overrides apply_to_weak_ref_discovered_field() to return true, the closure will be applied to the discovered field, even if the normal checks prevents it. This special treatment is needed in certain situations, but it is not obvious if it should be done when iterating the object. Currently only G1 closures override apply_to_weak_ref_discovered_field() and many of them seem to do it without any reason. My initial plan [1] was to remove all usage of this special casing but after discussions I realized it would be easier to see the effects if doing this one closure at a time. >> >> Summary: >> UpdateRSOopClosure is used to re-build the remembered sets after a G1 full GC. This is done after reference discovery and enqueuing (to the pending list) has been completed, so all discovered references have their next-field set. Before the full GC is started all references discovered by the concurrent-mark reference processor is clear to allow them to be discovered during the full GC. >> >> So at the point of applying the UpdateRSOopClosure, no references should have their discovered field set but still be active (next == null). So overriding apply_to_weak_ref_discovered_field to make sure the discovered field is handled doesn't have any effect. Either the discovered and next field are both set and thus gets handled the normal way, or the discovered field is not set and there is no reason to handle it at all. >> >> Testing: >> * RBT >> * GC-test-suite run locally with small heap (to trigger full GC) and verification turned on. >> >> Thanks, >> Stefan >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8138888 > From tom.benson at oracle.com Wed Dec 9 13:15:55 2015 From: tom.benson at oracle.com (Tom Benson) Date: Wed, 9 Dec 2015 08:15:55 -0500 Subject: RFR (M): 8060697: Improve G1 Heap Growth Heuristics In-Reply-To: <1449655045.2195.3.camel@oracle.com> References: <5653D33D.3090906@oracle.com> <1449056510.2642.75.camel@oracle.com> <1449057651.2642.86.camel@oracle.com> <56607093.3010102@oracle.com> <78EB4021-4190-45CF-960A-875995A463E5@oracle.com> <566633DF.4030009@oracle.com> <1449655045.2195.3.camel@oracle.com> Message-ID: <5668298B.6020803@oracle.com> Hi Thomas, OK, thanks very much. Now looking for a sponsor to push the changes... Thomas, Kim, or Jon? Tnx, Tom On 12/9/2015 4:57 AM, Thomas Schatzl wrote: > Hi, > > On Mon, 2015-12-07 at 20:35 -0500, Tom Benson wrote: >> Hi Kim, >> Yes, that's it exactly. I'm not bothered by it, but am open to >> suggestions if someone feels strongly. >> Tnx, >> Tom >> >> On 12/7/2015 7:30 PM, Kim Barrett wrote: >>> On Dec 3, 2015, at 11:40 AM, Tom Benson wrote: >>>> Updated webrevs (including the suggestions from Kim and Jon) are in: >>>> >>>> http://cr.openjdk.java.net/~tbenson/8060697/webrev.01.vs.00/ - incremental >>>> http://cr.openjdk.java.net/~tbenson/8060697/webrev.01/ - full >>> I'd previously overlooked the removal of the const qualifier from >>> G1CollectorPolicy::expansion_amount. This was done to permit some >>> member variables to be updated to accumulate additional information >>> (specifically, the fields that are reset by the new >>> clear_ratio_check_data). But the function name "expansion_amount" >>> looks to me like an accessor or compute function, and not something >>> that modifies the policy object. >>> >>> I don't have a good alternative (either structure or naming) to offer >>> right now, but maybe you or someone else might think of something. Or >>> maybe I'm the only one (somewhat) bothered by this. >>> > I already noticed that, but I have not good advice for that either. > > Looked at latest changes again, looks good. > > No preference about the (double) casts in the other email. > > Thanks, > Thomas > From thomas.schatzl at oracle.com Wed Dec 9 13:17:52 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 09 Dec 2015 14:17:52 +0100 Subject: RFR (M): 8060697: Improve G1 Heap Growth Heuristics In-Reply-To: <5668298B.6020803@oracle.com> References: <5653D33D.3090906@oracle.com> <1449056510.2642.75.camel@oracle.com> <1449057651.2642.86.camel@oracle.com> <56607093.3010102@oracle.com> <78EB4021-4190-45CF-960A-875995A463E5@oracle.com> <566633DF.4030009@oracle.com> <1449655045.2195.3.camel@oracle.com> <5668298B.6020803@oracle.com> Message-ID: <1449667072.2195.11.camel@oracle.com> Hi, On Wed, 2015-12-09 at 08:15 -0500, Tom Benson wrote: > Hi Thomas, > OK, thanks very much. > Now looking for a sponsor to push the changes... Thomas, Kim, or Jon? > Tnx, > Tom I can sponsor it. Please send me a complete changeset to push. Thanks, Thomas From stefan.karlsson at oracle.com Wed Dec 9 13:49:49 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 9 Dec 2015 14:49:49 +0100 Subject: RFR(XS): JDK-8144837: Improve the printout of heap regions in hs_err dump files. In-Reply-To: <56681E8C.7040101@oracle.com> References: <5667F082.7050004@oracle.com> <56681F6C.7050206@oracle.com> <56681E8C.7040101@oracle.com> Message-ID: <5668317D.1030106@oracle.com> Hi David, On 2015-12-09 13:29, David Lindholm wrote: > Hi Stefan, > > On 2015-12-09 13:32, Stefan Karlsson wrote: >> Hi David, >> >> On 2015-12-09 10:12, David Lindholm wrote: >>> Hi, >>> >>> Please review the following patch that changes the format for the >>> heap region printouts in hs_err files and when running with >>> -XX:+PrintHeapAtGCExtended >>> >>> The old format looked like this: >>> >>> AC 0 F TS 5 PTAMS 0x00000005cbc00000 NTAMS >>> 0x00000005cbc00000 space 2048K, 0% used [0x00000005cbc00000, >>> 0x00000005cbe00000) >>> AC 0 S CS TS 7 PTAMS 0x00000005cbe00000 NTAMS >>> 0x00000005cbe00000 space 2048K, 100% used [0x00000005cbe00000, >>> 0x00000005cc000000) >>> AC 0 F TS 5 PTAMS 0x00000005cc000000 NTAMS >>> 0x00000005cc000000 space 2048K, 0% used [0x00000005cc000000, >>> 0x00000005cc200000) >>> >>> The new format looks like this: >>> >>> [ 21][0x00000005cd000000, 0x00000005cd000000, 0x00000005cd200000][ >>> 0%][ F][ ][TS 7][AC 0][TAMS 0x00000005cd000000, 0x00000005cd000000] >>> [ 22][0x00000005cd200000, 0x00000005cd400000, >>> 0x00000005cd400000][100%][ S][CS][TS 9][AC 0][TAMS >>> 0x00000005cd200000, 0x00000005cd200000] >>> [ 23][0x00000005cd400000, 0x00000005cd600000, >>> 0x00000005cd600000][100%][ S][CS][TS 9][AC 0][TAMS >>> 0x00000005cd400000, 0x00000005cd400000] >> >> Could we use pipes instead of the square brackets. Too me that >> reduces the clutter a bit: >> | 21|0x00000005cd000000, 0x00000005cd000000, 0x00000005cd200000| 0%| >> F| |TS 7|AC 0|TAMS 0x00000005cd000000, 0x00000005cd000000| >> | 22|0x00000005cd200000, 0x00000005cd400000, >> 0x00000005cd400000|100%| S|CS|TS 9|AC 0|TAMS 0x00000005cd200000, >> 0x00000005cd200000| >> | 23|0x00000005cd400000, 0x00000005cd600000, >> 0x00000005cd600000|100%| S|CS|TS 9|AC 0|TAMS 0x00000005cd400000, >> 0x00000005cd400000| > > Sure. New webrev: > > http://cr.openjdk.java.net/~david/JDK-8144837/webrev.01/ Looks good! Thanks, StefanK > > Thanks, > David > >> Thanks, >> StefanK >> >>> >>> The first number is the index, and for each heap region we print >>> bottom, top and end. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144837 >>> Webrev: http://cr.openjdk.java.net/~david/JDK-8144837/webrev.00/ >>> >>> >>> Thanks, >>> David >> > From jon.masamitsu at oracle.com Wed Dec 9 14:27:44 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 9 Dec 2015 06:27:44 -0800 Subject: RFR (S): 8144714 Add extension point to G1 evacuation closures In-Reply-To: <5666D436.4070907@oracle.com> References: <5661AEC4.3040805@oracle.com> <5661D09D.3060309@oracle.com> <5666D436.4070907@oracle.com> Message-ID: <56683A60.8060001@oracle.com> On 12/08/2015 04:59 AM, Mikael Gerdin wrote: > Hi Jon, > > On 2015-12-04 18:42, Jon Masamitsu wrote: >> Mikael, >> >> Looks good. Couple of minor points. >> >> http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/src/share/vm/gc/g1/g1InCSetState.hpp.frames.html >> >> >> >> Is the Ext value explained by the comment "The other values ..."? If it >> does apply >> to the Ext value, I don't understand. "getting to the next generation" >> doesn't seem >> to apply. Actually, I don't understand that comment with respect to >> Humongous either. >> >> 56 // The other values are simply encoded in increasing >> generation order, which >> 57 // makes getting the next generation fast by a simple >> increment. >> 58 Ext = -2, // Extension point > > The comment appears to be a bit outdated, I suggest changing it to: > // Selection of the values were driven to micro-optimize the encoding and > // frequency of the checks. > // The most common check is whether the region is in the collection > set or not, > // this encoding allows us to use an > 0 check. > // The positive values are encoded in increasing generation order, which > // makes getting the next generation fast by a simple increment. They > are also > // used to index into arrays. > // The negative values are used for objects requiring various special > cases, > // for example eager reclamation of humongous objects. Thanks for the update of the comment. Looks good. Jon > >> >> >> http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/src/share/vm/gc/g1/g1ParScanThreadState_ext.cpp.frames.html >> >> >> >> Lines 39 and 40 not particularly useful? > > FWIW, I understood that you meant the empty lines, I'll remove them. :) > > /Mikael > >> >> 37 template void G1ParScanThreadState::do_oop_ext(oop* ref); >> 38 template void G1ParScanThreadState::do_oop_ext(narrowOop* >> ref); >> 39 >> 40 >> >> Jon >> >> >> On 12/4/2015 7:18 AM, Mikael Gerdin wrote: >>> Hi all, >>> >>> Please review this small change to add a hook in the G1 evacuation >>> path. >>> This allows extension code to register regions which are otherwise >>> interesting to the GC and get notifications when pointers into such >>> regions are encountered. >>> >>> Testing: JPRT, gc test suite >>> Performance: >>> This additional branch in G1ParScanClosure introduces a slight >>> regression of about 1-2% in GC pause times. I have some performance >>> fixes to make up for that regression in the pipe. >>> >>> webrev: http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8144714 >>> >>> Thanks >>> /Mikael >> > From jon.masamitsu at oracle.com Wed Dec 9 14:30:32 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 9 Dec 2015 06:30:32 -0800 Subject: RFR: 8144908: Remove apply_to_weak_ref_discovered_field override for UpdateRSOopClosure In-Reply-To: <5667F244.7040403@oracle.com> References: <5666DE45.70802@oracle.com> <56673ED4.7020309@oracle.com> <53A60769-933C-4D41-80DF-ABB57EFE9E7C@oracle.com> <5667F244.7040403@oracle.com> Message-ID: <56683B08.8060707@oracle.com> Thanks Kim and Stefan for the explanation. Change looks good. Jon On 12/09/2015 01:20 AM, Stefan Johansson wrote: > > > On 2015-12-08 22:16, Kim Barrett wrote: >> On Dec 8, 2015, at 3:34 PM, Jon Masamitsu >> wrote: >>> Stefan, >>> >>> At line 41 in "share/vm/oops/instanceRefKlass.inline.hpp" >>> >>> 38 void >>> InstanceRefKlass::oop_oop_iterate_ref_processing_specialized(oop >>> obj, OopClosureType* closure, >>> Contains& contains) { >>> 39 T* disc_addr = >>> (T*)java_lang_ref_Reference::discovered_addr(obj); >>> 40 if (closure->apply_to_weak_ref_discovered_field()) { >>> 41 Devirtualizer::do_oop(closure, disc_addr); >>> 42 } >>> >>> you're saying that the "next" field of "obj" is >>> non-null? Did you try adding a guarantee to that >>> effect and run your testing (without your change, >>> of course)? >> If next is NULL then, for the specific closure in question, >> discovered must also be NULL here. There is no point in applying >> closure to the NULL-valued discovered field. There are other >> closures for which that relationship between next and discovered >> doesn?t hold, but we think it will turn out that none of them have >> apply_to_weak_ref_discovered_field returning true. >> >> Note that if next is non-NULL, then the closure will be applied to >> discovered in the normal path, and there is no need for this special >> case forced application (and is in fact duplicating work at present, >> which could be a bug on its own, except we think the special case is >> going away). >> >> > As Kim say, for this specific closure the assumption holds, but it's > not true for all closures. Some time ago I did test-runs with extra > debug code to see which closures were applied with discovered field > set but next field NULL. The two closures that showed up was: > FilterOutOfRegionClosure > G1ParPushHeapRSClosure > > They both have apply_to_weak_ref_discovered_field returning true, but > to me it is not clear that they need it. My goal is to remove all > other use of apply_to_weak_ref_discovered_field first and then attack > those two. Either by somehow showing that the special case is no > longer needed or by handling the discovered field (or actually the > discovered list) some other way. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Wed Dec 9 14:38:54 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 9 Dec 2015 15:38:54 +0100 Subject: RFR (S): 8144714 Add extension point to G1 evacuation closures In-Reply-To: <56683A60.8060001@oracle.com> References: <5661AEC4.3040805@oracle.com> <5661D09D.3060309@oracle.com> <5666D436.4070907@oracle.com> <56683A60.8060001@oracle.com> Message-ID: <56683CFE.9080304@oracle.com> On 2015-12-09 15:27, Jon Masamitsu wrote: > > > On 12/08/2015 04:59 AM, Mikael Gerdin wrote: >> Hi Jon, >> >> On 2015-12-04 18:42, Jon Masamitsu wrote: >>> Mikael, >>> >>> Looks good. Couple of minor points. >>> >>> http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/src/share/vm/gc/g1/g1InCSetState.hpp.frames.html >>> >>> >>> >>> Is the Ext value explained by the comment "The other values ..."? If it >>> does apply >>> to the Ext value, I don't understand. "getting to the next generation" >>> doesn't seem >>> to apply. Actually, I don't understand that comment with respect to >>> Humongous either. >>> >>> 56 // The other values are simply encoded in increasing >>> generation order, which >>> 57 // makes getting the next generation fast by a simple >>> increment. >>> 58 Ext = -2, // Extension point >> >> The comment appears to be a bit outdated, I suggest changing it to: >> // Selection of the values were driven to micro-optimize the encoding and >> // frequency of the checks. >> // The most common check is whether the region is in the collection >> set or not, >> // this encoding allows us to use an > 0 check. >> // The positive values are encoded in increasing generation order, which >> // makes getting the next generation fast by a simple increment. They >> are also >> // used to index into arrays. >> // The negative values are used for objects requiring various special >> cases, >> // for example eager reclamation of humongous objects. > > Thanks for the update of the comment. Looks good. Thanks Jon! /Mikael > > Jon > >> >>> >>> >>> http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/src/share/vm/gc/g1/g1ParScanThreadState_ext.cpp.frames.html >>> >>> >>> >>> Lines 39 and 40 not particularly useful? >> >> FWIW, I understood that you meant the empty lines, I'll remove them. :) >> >> /Mikael >> >>> >>> 37 template void G1ParScanThreadState::do_oop_ext(oop* ref); >>> 38 template void G1ParScanThreadState::do_oop_ext(narrowOop* >>> ref); >>> 39 >>> 40 >>> >>> Jon >>> >>> >>> On 12/4/2015 7:18 AM, Mikael Gerdin wrote: >>>> Hi all, >>>> >>>> Please review this small change to add a hook in the G1 evacuation >>>> path. >>>> This allows extension code to register regions which are otherwise >>>> interesting to the GC and get notifications when pointers into such >>>> regions are encountered. >>>> >>>> Testing: JPRT, gc test suite >>>> Performance: >>>> This additional branch in G1ParScanClosure introduces a slight >>>> regression of about 1-2% in GC pause times. I have some performance >>>> fixes to make up for that regression in the pipe. >>>> >>>> webrev: http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8144714 >>>> >>>> Thanks >>>> /Mikael >>> >> > From jon.masamitsu at oracle.com Wed Dec 9 18:08:43 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 9 Dec 2015 10:08:43 -0800 Subject: Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly In-Reply-To: <56450520.6060706@oracle.com> References: <56450520.6060706@oracle.com> Message-ID: <56686E2B.6020809@oracle.com> For completeness the final version of the webrev is http://cr.openjdk.java.net/~jmasa/8133023/webrev.07/ Thanks all. Jon On 11/12/2015 01:31 PM, Jon Masamitsu wrote: > GC calls VM_Version::calc_parallel_worker_threads() to determine > the number of GC threads to create. On Sparc it checks for newer > Niagara hardware to decide the proper scaling of the GC threads with > the hardware threads. calc_parallel_worker_threads() was being called > before enough information was gathered to determine the Sparc hardware. > > Moved the gathering of information needed to earlier in the JVM > initialization. > > http://cr.openjdk.java.net/~jmasa/8133023/webrev.00/ > > https://bugs.openjdk.java.net/browse/JDK-8133023 > > Thanks. > > Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.provino at oracle.com Wed Dec 9 18:30:01 2015 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 9 Dec 2015 13:30:01 -0500 Subject: RFR (XXS) JDK-8139768 Running with -XX:CMSOldPLABNumRefills=2147483648 causes EXCEPTION_INT_DIVIDE_BY_ZERO on Windows i586 Message-ID: <56687329.8030506@oracle.com> Please review this very small change. CR: https://bugs.openjdk.java.net/browse/JDK-8139768 Webrev: http://cr.openjdk.java.net/~jprovino/8139768/webrev.00 thanks. joe From joseph.provino at oracle.com Wed Dec 9 18:31:58 2015 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 9 Dec 2015 13:31:58 -0500 Subject: RFR (XXS) JDK-8139871 G1CollectorPolicy::_cur_mark_stop_world_time_ms is never read from Message-ID: <5668739E.20202@oracle.com> Please review this very small change. It's removal of unneeded code. CR: https://bugs.openjdk.java.net/browse/JDK-8139871 Webrev: http://cr.openjdk.java.net/~jprovino/8139871/webrev.00 Thanks. joe From tom.benson at oracle.com Wed Dec 9 18:52:29 2015 From: tom.benson at oracle.com (Tom Benson) Date: Wed, 9 Dec 2015 13:52:29 -0500 Subject: RFR (XXS) JDK-8139768 Running with -XX:CMSOldPLABNumRefills=2147483648 causes EXCEPTION_INT_DIVIDE_BY_ZERO on Windows i586 In-Reply-To: <56687329.8030506@oracle.com> References: <56687329.8030506@oracle.com> Message-ID: <5668786D.7000408@oracle.com> Hi Joe, There's a problem with the comment "... the denominator can become zero before of integer overflow", but the code looks OK. Tom On 12/9/2015 1:30 PM, Joseph Provino wrote: > Please review this very small change. > > CR: https://bugs.openjdk.java.net/browse/JDK-8139768 > > Webrev: http://cr.openjdk.java.net/~jprovino/8139768/webrev.00 > > thanks. > > joe From joseph.provino at oracle.com Wed Dec 9 18:55:02 2015 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 9 Dec 2015 13:55:02 -0500 Subject: RFR (XXS) JDK-8139768 Running with -XX:CMSOldPLABNumRefills=2147483648 causes EXCEPTION_INT_DIVIDE_BY_ZERO on Windows i586 In-Reply-To: <5668786D.7000408@oracle.com> References: <56687329.8030506@oracle.com> <5668786D.7000408@oracle.com> Message-ID: <56687906.8000406@oracle.com> I changed the comment: /* * On a 32-bit VM, the denominator can become zero because of integer overflow, * which is why there is a cast to double. */ On 12/9/2015 1:52 PM, Tom Benson wrote: > Hi Joe, > There's a problem with the comment "... the denominator can become > zero before of integer overflow", but the code looks OK. > Tom > > > On 12/9/2015 1:30 PM, Joseph Provino wrote: >> Please review this very small change. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8139768 >> >> Webrev: http://cr.openjdk.java.net/~jprovino/8139768/webrev.00 >> >> thanks. >> >> joe > From jesper.wilhelmsson at oracle.com Wed Dec 9 19:03:53 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 9 Dec 2015 20:03:53 +0100 Subject: RFR (XXS) JDK-8139768 Running with -XX:CMSOldPLABNumRefills=2147483648 causes EXCEPTION_INT_DIVIDE_BY_ZERO on Windows i586 In-Reply-To: <56687329.8030506@oracle.com> References: <56687329.8030506@oracle.com> Message-ID: <56687B19.3030000@oracle.com> Hi Joe, Looks OK, but there is one thing I'm not 100% sure about, what is the precedence in C++, will the cast to double be done before or after the multiplication? I'm thinking that maybe you need ((double)CMSOldPLABToleranceFactor)*... If the overflow happens and the zero is then cast to double, I guess that the division might go through anyway since there is no exact floating point zero, so it may hide the bug rather than fixing it. I'm not sure if this is a real issue. /Jesper Den 9/12/15 kl. 19:30, skrev Joseph Provino: > Please review this very small change. > > CR: https://bugs.openjdk.java.net/browse/JDK-8139768 > > Webrev: http://cr.openjdk.java.net/~jprovino/8139768/webrev.00 > > thanks. > > joe From tom.benson at oracle.com Wed Dec 9 19:29:20 2015 From: tom.benson at oracle.com (Tom Benson) Date: Wed, 9 Dec 2015 14:29:20 -0500 Subject: RFR (XXS) JDK-8139871 G1CollectorPolicy::_cur_mark_stop_world_time_ms is never read from In-Reply-To: <5668739E.20202@oracle.com> References: <5668739E.20202@oracle.com> Message-ID: <56688110.2080505@oracle.com> Looks good. Tom On 12/9/2015 1:31 PM, Joseph Provino wrote: > Please review this very small change. It's removal of unneeded code. > > CR: https://bugs.openjdk.java.net/browse/JDK-8139871 > > Webrev: http://cr.openjdk.java.net/~jprovino/8139871/webrev.00 > > Thanks. > > joe From jesper.wilhelmsson at oracle.com Wed Dec 9 19:35:36 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 9 Dec 2015 20:35:36 +0100 Subject: RFR (XXS) JDK-8139871 G1CollectorPolicy::_cur_mark_stop_world_time_ms is never read from In-Reply-To: <5668739E.20202@oracle.com> References: <5668739E.20202@oracle.com> Message-ID: <56688288.9020504@oracle.com> Looks good! /Jesper Den 9/12/15 kl. 19:31, skrev Joseph Provino: > Please review this very small change. It's removal of unneeded code. > > CR: https://bugs.openjdk.java.net/browse/JDK-8139871 > > Webrev: http://cr.openjdk.java.net/~jprovino/8139871/webrev.00 > > Thanks. > > joe From thomas.schatzl at oracle.com Wed Dec 9 19:43:05 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 09 Dec 2015 20:43:05 +0100 Subject: RFR (XXS) JDK-8139871 G1CollectorPolicy::_cur_mark_stop_world_time_ms is never read from In-Reply-To: <5668739E.20202@oracle.com> References: <5668739E.20202@oracle.com> Message-ID: <1449690185.5433.0.camel@oracle.com> Hi, On Wed, 2015-12-09 at 13:31 -0500, Joseph Provino wrote: > Please review this very small change. It's removal of unneeded code. > > CR: https://bugs.openjdk.java.net/browse/JDK-8139871 > > Webrev: http://cr.openjdk.java.net/~jprovino/8139871/webrev.00 > looks good. Thomas From stefan.karlsson at oracle.com Wed Dec 9 19:48:58 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 09 Dec 2015 20:48:58 +0100 Subject: RFR (XXS) JDK-8139871 G1CollectorPolicy::_cur_mark_stop_world_time_ms is never read from In-Reply-To: <5668739E.20202@oracle.com> References: <5668739E.20202@oracle.com> Message-ID: <566885AA.7070101@oracle.com> Hi Joe, On 2015-12-09 19:31, Joseph Provino wrote: > Please review this very small change. It's removal of unneeded code. > > CR: https://bugs.openjdk.java.net/browse/JDK-8139871 > > Webrev: http://cr.openjdk.java.net/~jprovino/8139871/webrev.00 The mark_init_elapsed_time_ms parameter seems unused now: void G1CollectorPolicy::record_concurrent_mark_init_end(double mark_init_elapsed_time_ms) { collector_state()->set_during_marking(true); assert(!collector_state()->initiate_conc_mark_if_possible(), "we should have cleared it by now"); collector_state()->set_during_initial_mark_pause(false); - _cur_mark_stop_world_time_ms = mark_init_elapsed_time_ms; } Otherwise, this looks good. For future reviews, could you use the official webrev script at: http://hg.openjdk.java.net/code-tools/webrev/ The udiffs view is broken in the version your are using. Thanks, StefanK > > joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Wed Dec 9 19:51:16 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 09 Dec 2015 20:51:16 +0100 Subject: RFR (XXS) JDK-8139768 Running with -XX:CMSOldPLABNumRefills=2147483648 causes EXCEPTION_INT_DIVIDE_BY_ZERO on Windows i586 In-Reply-To: <56687329.8030506@oracle.com> References: <56687329.8030506@oracle.com> Message-ID: <56688634.5040201@oracle.com> Hi Joe, On 2015-12-09 19:30, Joseph Provino wrote: > Please review this very small change. > > CR: https://bugs.openjdk.java.net/browse/JDK-8139768 > > Webrev: http://cr.openjdk.java.net/~jprovino/8139768/webrev.00 The rest of the file uses // for the comments. Could you change your comment to be consistent with the rest of the file? // Lacking sufficient experience, CMSOldPLABResizeQuicker is disabled by // default. if (ResizeOldPLAB && CMSOldPLABResizeQuicker) { - size_t multiple = _num_blocks[word_sz]/(CMSOldPLABToleranceFactor*CMSOldPLABNumRefills*n_blks); + /* + * On a 32-bit VM, the denominator can become zero before of integer overflow + * which is why there is cast to double. + */ + size_t multiple = (size_t) (_num_blocks[word_sz]/((double)CMSOldPLABToleranceFactor*CMSOldPLABNumRefills*n_blks)); Thanks, StefanK > > thanks. > > joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.provino at oracle.com Wed Dec 9 21:07:31 2015 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 9 Dec 2015 16:07:31 -0500 Subject: RFR (XXS) JDK-8139768 Running with -XX:CMSOldPLABNumRefills=2147483648 causes EXCEPTION_INT_DIVIDE_BY_ZERO on Windows i586 In-Reply-To: <56687B19.3030000@oracle.com> References: <56687329.8030506@oracle.com> <56687B19.3030000@oracle.com> Message-ID: <56689813.7030608@oracle.com> On 12/9/2015 2:03 PM, Jesper Wilhelmsson wrote: > Hi Joe, > > Looks OK, but there is one thing I'm not 100% sure about, what is the > precedence in C++, will the cast to double be done before or after the > multiplication? > > I'm thinking that maybe you need ((double)CMSOldPLABToleranceFactor)*... > > If the overflow happens and the zero is then cast to double, I guess > that the division might go through anyway since there is no exact > floating point zero, so it may hide the bug rather than fixing it. I'm > not sure if this is a real issue. I thought the cast to double would bind more tightly than the multiply. But to be safe, I'll add the parens. thanks. joe > > /Jesper > > > Den 9/12/15 kl. 19:30, skrev Joseph Provino: >> Please review this very small change. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8139768 >> >> Webrev: http://cr.openjdk.java.net/~jprovino/8139768/webrev.00 >> >> thanks. >> >> joe From kim.barrett at oracle.com Thu Dec 10 00:23:46 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 9 Dec 2015 19:23:46 -0500 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> Message-ID: <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> On Dec 3, 2015, at 8:55 AM, Lindenmaier, Goetz wrote: > > I really would appreciate if we could get this fixed soon. > Maybe we can submit my version and if we put a comment into > 8135181 that points to this change, the questionable casts can be > identified later on, too. I?m not sure that?s really worth the time. Addressing 8135181 well is going to require looking over a lot of existing code for these sorts of things anyway. I don?t think having a few specifically noted there is going to make much difference. > The broken build hinders our work. I have to manually fix our nightbuilds all > the time, and my colleagues stomped into this and fixed it in their workspace > locally. Any webrev we prepare we have to patch with this change ... > So I really would like to see this resolved. > > The change is now pending since 19.11. Thanks for your patience. This set of proposed changes raised some more global issues. I?ve tried to capture some of the discussion of those in 8135181 comments, with this change to go ahead (subject to detailed review), without being blocked while discussion of those larger issues has time to bake. > I rebased my webrev, which also contains some more casts > for issues poping up since my first attempt to fix this: > http://cr.openjdk.java.net/~goetz/webrevs/8143215-gcc412/webrev.01/ > (Kim, you've seen this before). ------------------------------------------------------------------------------ src/share/vm/gc/g1/concurrentG1RefineThread.cpp File is in both webrev.00 and webrev.01, but no changes in either? ------------------------------------------------------------------------------ src/share/vm/gc/g1/g1CollectorPolicy.cpp 538 return update_young_list_max_and_target_length((size_t)get_new_prediction(_rs_lengths_seq)); There are a couple of these conversions of get_new_prediction in this change set, and several others pre-existing. Rather than continuing to scatter casts about, I think better would be to have a variant of get_new_prediction that returns a size_t rather than a double, with the conversion centralized there. get_new_size_prediction? get_predicted_size? Let the bikeshedding begin! ------------------------------------------------------------------------------ src/share/vm/gc/g1/g1IHOPControl.cpp 145 double safe_total_heap_percentage = MIN2((double)(_heap_reserve_percent + _heap_waste_percent), 100.0); 146 147 return (size_t)MIN2( 148 (G1CollectedHeap::heap()->max_capacity() * (100.0 - safe_total_heap_percentage) / 100.0), 149 (_target_occupancy * (100.0 - (float)_heap_waste_percent) / 100.0) 150 ); [Pre-existing] It's not clear why line 145 involves floating point at all. [New] Why was a float cast added on line 149? I looked at rewriting this to use only integer calculations, by first dividing the LHS of the multiplication operations by 100, then performing scaling. The absolute rounding error would be small, making the relative rounding error likely insignificant. It obfuscates the code a bit though. ------------------------------------------------------------------------------ src/share/vm/gc/g1/g1IHOPControl.cpp 164 ((size_t)(pred_marking_time * pred_promotion_rate) + Rather than inserting a cast into the middle of the computation, I think I'd rather see a new variable introduced for the converted value, e.g. size_t pred_promotion_size = ... ------------------------------------------------------------------------------ src/share/vm/gc/g1/g1IHOPControl.cpp 178 void G1AdaptiveIHOPControl::update_allocation_info(double allocation_time_s, size_t allocated_bytes, 179 size_t additional_buffer_size) { Change was to add a line break before the last parameter. Please, if breaking up parameter lists like that, put all of the parameters on separate lines. ------------------------------------------------------------------------------ From kim.barrett at oracle.com Thu Dec 10 01:41:53 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 9 Dec 2015 20:41:53 -0500 Subject: RFR (S): 8144714 Add extension point to G1 evacuation closures In-Reply-To: <5661AEC4.3040805@oracle.com> References: <5661AEC4.3040805@oracle.com> Message-ID: <48209F5B-1A69-4E86-82CB-B7F61A2757CF@oracle.com> On Dec 4, 2015, at 10:18 AM, Mikael Gerdin wrote: > > Hi all, > > Please review this small change to add a hook in the G1 evacuation path. > This allows extension code to register regions which are otherwise interesting to the GC and get notifications when pointers into such regions are encountered. > > Testing: JPRT, gc test suite > Performance: > This additional branch in G1ParScanClosure introduces a slight regression of about 1-2% in GC pause times. I have some performance fixes to make up for that regression in the pipe. > > webrev: http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/ > bug: https://bugs.openjdk.java.net/browse/JDK-8144714 > > Thanks > /Mikael I'm still not planning to fully review this change, but I happened to be looking at G1ParScanClosure and remembered the code to add the extension point, and wondered if it might be improved. ------------------------------------------------------------------------------ src/share/vm/gc/g1/g1OopClosures.inline.hpp 91 if (state.is_humongous()) { 92 _g1->set_humongous_is_live(obj); 93 } else if (state.is_ext()) { 94 _par_scan_state->do_oop_ext(p); 95 } Would it be worthwhile changing this to if (state.is_humongous_or_ext()) { if (state.is_humongous()) { _g1->set_humongous_is_live(obj); } else { _par_scan_state->do_oop_ext(p); } } where bool InCSetState::is_humongous_or_ext() const { return _value < NotInCSet; } This would have one conditional branch vs two for objects in regions that are neither humongous nor ext, at the cost of always having two conditional branches for humongous objects, which are presumably relatively rare. That seems like a win when ext isn't being used. Or instead of adding a new function, maybe promote is_default() out of #ifdef ASSERT and use if (!state.is_default()) { if (state.is_humongous()) { _g1->set_humongous_is_live(obj); } else { _par_scan_state->do_oop_ext(p); } } ------------------------------------------------------------------------------ From kim.barrett at oracle.com Thu Dec 10 03:50:25 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 9 Dec 2015 22:50:25 -0500 Subject: RFR (S): 8144714 Add extension point to G1 evacuation closures In-Reply-To: <5661AEC4.3040805@oracle.com> References: <5661AEC4.3040805@oracle.com> Message-ID: On Dec 4, 2015, at 10:18 AM, Mikael Gerdin wrote: > > Hi all, > > Please review this small change to add a hook in the G1 evacuation path. > This allows extension code to register regions which are otherwise interesting to the GC and get notifications when pointers into such regions are encountered. > > Testing: JPRT, gc test suite > Performance: > This additional branch in G1ParScanClosure introduces a slight regression of about 1-2% in GC pause times. I have some performance fixes to make up for that regression in the pipe. > > webrev: http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/ > bug: https://bugs.openjdk.java.net/browse/JDK-8144714 > > Thanks > /Mikael Another possible optimization to mitigate the extension point? I think before the addition of the extension point support, is_in_cset_or_humongous should have been _value != NotInCSet, and is_default should have been _value == NotInCSet (the latter is part of the proposed change). With the extension point support, it might be better to use the encoding Humongous = -2 Ext = -1 With that encoding, is_in_cset_or_humongous can be written as static_cast(_value + 1) > 1 // NotInCSet + 1 With that encoding, is_valid would need to revert back to comparing against Humongous rather than Ext as the boundary value. This encoding would change branch if _value > 0 to handle_in_cset_or_humongous branch if _value == Humongous to handle_in_cset_or_humongous // ! is_in_cset_or_humongous to branch if (unsigned)(_value + 1) > 1 to handle_in_cset_or_humongous // ! is_in_cset_or_humongous If the ! is_in_cset_or_humongous case is common, this could be a win. I also looked at this encoding: Ext = -2 NotInCSet = -1 Humongous = 0 Young = 1 Old = 2 is_in_cset := _value > Humongous is_in_cset_or_humongous := _value >= Humongous But there seem to be a bunch of places that break the abstraction and have assumptions about the non-negative part of the current encoding. From thomas.schatzl at oracle.com Thu Dec 10 08:09:06 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 10 Dec 2015 09:09:06 +0100 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> Message-ID: <1449734946.2249.7.camel@oracle.com> Hi Kim, On Wed, 2015-12-09 at 19:23 -0500, Kim Barrett wrote: > On Dec 3, 2015, at 8:55 AM, Lindenmaier, Goetz wrote: > > > > I really would appreciate if we could get this fixed soon. > > Maybe we can submit my version and if we put a comment into > > 8135181 that points to this change, the questionable casts can be > > identified later on, too. [...] > ------------------------------------------------------------------------------ > src/share/vm/gc/g1/g1CollectorPolicy.cpp > 538 return update_young_list_max_and_target_length((size_t)get_new_prediction(_rs_lengths_seq)); > > There are a couple of these conversions of get_new_prediction in this > change set, and several others pre-existing. Rather than continuing > to scatter casts about, I think better would be to have a variant of > get_new_prediction that returns a size_t rather than a double, with > the conversion centralized there. > > get_new_size_prediction? get_predicted_size? Let the bikeshedding > begin! Fwiw I would prefer the first option :) > ------------------------------------------------------------------------------ > src/share/vm/gc/g1/g1IHOPControl.cpp > 145 double safe_total_heap_percentage = MIN2((double)(_heap_reserve_percent + _heap_waste_percent), 100.0); > 146 > 147 return (size_t)MIN2( > 148 (G1CollectedHeap::heap()->max_capacity() * (100.0 - safe_total_heap_percentage) / 100.0), > 149 (_target_occupancy * (100.0 - (float)_heap_waste_percent) / 100.0) > 150 ); > > [Pre-existing] > It's not clear why line 145 involves floating point at all. Integer/size_t overflow (on 32 bit platforms) for the first term. Now you can argue that the FP conversion may incur lots of rounding too on very large values of max_capacity(). It's probably better to use integer calculations throughout here. I have not found a helper method that does that correctly without potential overflow. > [New] > Why was a float cast added on line 149? > > I looked at rewriting this to use only integer calculations, by first > dividing the LHS of the multiplication operations by 100, then > performing scaling. The absolute rounding error would be small, making > the relative rounding error likely insignificant. It obfuscates the > code a bit though. It would be fine with me to change this as suggested, however it would be great if that change would not be hidden in a fix-the-casts CR. Thanks, Thomas From mikael.gerdin at oracle.com Thu Dec 10 08:22:29 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 10 Dec 2015 09:22:29 +0100 Subject: RFR (S): 8144714 Add extension point to G1 evacuation closures In-Reply-To: References: <5661AEC4.3040805@oracle.com> Message-ID: <56693645.6060308@oracle.com> Hi Kim, On 2015-12-10 04:50, Kim Barrett wrote: > On Dec 4, 2015, at 10:18 AM, Mikael Gerdin wrote: >> >> Hi all, >> >> Please review this small change to add a hook in the G1 evacuation path. >> This allows extension code to register regions which are otherwise interesting to the GC and get notifications when pointers into such regions are encountered. >> >> Testing: JPRT, gc test suite >> Performance: >> This additional branch in G1ParScanClosure introduces a slight regression of about 1-2% in GC pause times. I have some performance fixes to make up for that regression in the pipe. >> >> webrev: http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8144714 >> >> Thanks >> /Mikael > > Another possible optimization to mitigate the extension point? > > I think before the addition of the extension point support, > is_in_cset_or_humongous should have been _value != NotInCSet, > and is_default should have been _value == NotInCSet (the latter is > part of the proposed change). > > With the extension point support, it might be better to use the > encoding > > Humongous = -2 > Ext = -1 > > With that encoding, is_in_cset_or_humongous can be written as > > static_cast(_value + 1) > 1 // NotInCSet + 1 > > With that encoding, is_valid would need to revert back to comparing > against Humongous rather than Ext as the boundary value. > > This encoding would change > > branch if _value > 0 to handle_in_cset_or_humongous > branch if _value == Humongous to handle_in_cset_or_humongous > // ! is_in_cset_or_humongous > > to > > branch if (unsigned)(_value + 1) > 1 to handle_in_cset_or_humongous > // ! is_in_cset_or_humongous > > If the ! is_in_cset_or_humongous case is common, this could be a win. > > I also looked at this encoding: > > Ext = -2 > NotInCSet = -1 > Humongous = 0 > Young = 1 > Old = 2 > > is_in_cset := _value > Humongous > is_in_cset_or_humongous := _value >= Humongous > > But there seem to be a bunch of places that break the abstraction and > have assumptions about the non-negative part of the current encoding. Thanks for the suggestions! Since I've already stated my plan to do further performance work in order to reduce the impact of this change and you've stated that you don't plan to fully review this change would you be ok with me pushing this as-is and look into investigating your suggestions post-integration? /Mikael- > From goetz.lindenmaier at sap.com Thu Dec 10 09:18:42 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 10 Dec 2015 09:18:42 +0000 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> Hi, Seeing Mikaels mail, I did not convert the computation in g1IHOPControl.cpp:145 ff. I changed though the computations in gcTraceSend.cpp. Please check whether I should move the division to be performed before the multiplication. See more comments inline below. New webrev: http://cr.openjdk.java.net/~goetz/webrevs/8143215-gcc412/webrev.03/index.html Best regards, Goetz. > -----Original Message----- > From: Kim Barrett [mailto:kim.barrett at oracle.com] > Sent: Thursday, December 10, 2015 1:24 AM > To: Lindenmaier, Goetz > Cc: hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. > > On Dec 3, 2015, at 8:55 AM, Lindenmaier, Goetz > wrote: > > > > I really would appreciate if we could get this fixed soon. > > Maybe we can submit my version and if we put a comment into > > 8135181 that points to this change, the questionable casts can be > > identified later on, too. > > I'm not sure that's really worth the time. Addressing 8135181 well is going to > require looking over a lot of existing code for these sorts of things anyway. I > don't think having a few specifically noted there is going to make much > difference. > > > The broken build hinders our work. I have to manually fix our nightbuilds all > > the time, and my colleagues stomped into this and fixed it in their > workspace > > locally. Any webrev we prepare we have to patch with this change ... > > So I really would like to see this resolved. > > > > The change is now pending since 19.11. > > Thanks for your patience. This set of proposed changes raised some more > global > issues. I've tried to capture some of the discussion of those in 8135181 > comments, > with this change to go ahead (subject to detailed review), without being > blocked while > discussion of those larger issues has time to bake. > > > I rebased my webrev, which also contains some more casts > > for issues poping up since my first attempt to fix this: > > http://cr.openjdk.java.net/~goetz/webrevs/8143215-gcc412/webrev.01/ > > (Kim, you've seen this before). > > ------------------------------------------------------------------------------ > src/share/vm/gc/g1/concurrentG1RefineThread.cpp > > File is in both webrev.00 and webrev.01, but no changes in either? There is a line feed missing at the end. That's not visible in the diffs, look at the patch itself. > ------------------------------------------------------------------------------ > src/share/vm/gc/g1/g1CollectorPolicy.cpp > 538 return > update_young_list_max_and_target_length((size_t)get_new_prediction(_r > s_lengths_seq)); > > There are a couple of these conversions of get_new_prediction in this > change set, and several others pre-existing. Rather than continuing > to scatter casts about, I think better would be to have a variant of > get_new_prediction that returns a size_t rather than a double, with > the conversion centralized there. > > get_new_size_prediction? get_predicted_size? Let the bikeshedding > begin! I introduced get_new_size_prediction() as Mikael said. > ------------------------------------------------------------------------------ > src/share/vm/gc/g1/g1IHOPControl.cpp > 145 double safe_total_heap_percentage = > MIN2((double)(_heap_reserve_percent + _heap_waste_percent), 100.0); > 146 > 147 return (size_t)MIN2( > 148 (G1CollectedHeap::heap()->max_capacity() * (100.0 - > safe_total_heap_percentage) / 100.0), > 149 (_target_occupancy * (100.0 - (float)_heap_waste_percent) / 100.0) > 150 ); > > [Pre-existing] > It's not clear why line 145 involves floating point at all. > > [New] > Why was a float cast added on line 149? I just added the cast, as Mikael said changing this should be a different changeset. > I looked at rewriting this to use only integer calculations, by first > dividing the LHS of the multiplication operations by 100, then > performing scaling. The absolute rounding error would be small, making > the relative rounding error likely insignificant. It obfuscates the > code a bit though. > > ------------------------------------------------------------------------------ > src/share/vm/gc/g1/g1IHOPControl.cpp > 164 ((size_t)(pred_marking_time * pred_promotion_rate) + > > Rather than inserting a cast into the middle of the computation, I > think I'd rather see a new variable introduced for the converted > value, e.g. size_t pred_promotion_size = ... Good point, fixed. > ------------------------------------------------------------------------------ > src/share/vm/gc/g1/g1IHOPControl.cpp > 178 void G1AdaptiveIHOPControl::update_allocation_info(double > allocation_time_s, size_t allocated_bytes, > 179 size_t additional_buffer_size) { > > Change was to add a line break before the last parameter. Please, if > breaking up parameter lists like that, put all of the parameters on > separate lines. Fixed > ------------------------------------------------------------------------------ From bengt.rutisson at oracle.com Thu Dec 10 09:26:00 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 10 Dec 2015 10:26:00 +0100 Subject: RFR (XS): Forward port of 8065331: Add trace events for failed allocations In-Reply-To: <56681744.4030907@oracle.com> References: <55DACA18.2070605@oracle.com> <55DD8F43.7070003@oracle.com> <5665511F.8000509@oracle.com> <56681744.4030907@oracle.com> Message-ID: <56694528.70605@oracle.com> Hi Marcus, Looks good. Bengt On 2015-12-09 12:57, Marcus Larsson wrote: > Hi, > > After offline discussions with Bengt, I've decided to omit the Pending > GCId from the event. The ID used previously was never guaranteed to be > correct, since it came from the peek() method. Sometimes a GCId would > be skipped which then caused some of the events to have an "invalid" > GCId. Grouping these events together with some GC will now instead > have to be done by the event timestamps. > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.02/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.01-02/ > > Thanks, > Marcus > > On 2015-12-07 10:27, Marcus Larsson wrote: >> Hi all, >> >> Still need approval for this forward port. >> >> New webrev due to changes in how GCId works: >> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.01/ >> >> Had to add a peek method in order to find the pending GC id for the >> event. >> This and the changes to includes should be the only things differing >> from the original patch. >> >> Thanks, >> Marcus >> >> On 2015-08-26 12:04, Marcus Larsson wrote: >>> Ping! >>> >>> On 2015-08-24 09:39, Marcus Larsson wrote: >>>> Hi, >>>> >>>> Please review the following patch to forward port the JEP-242 event >>>> to JDK9. The patch was originally reviewed in April/March [1], but >>>> was only integrated in 8u60. The original patch no longer applies >>>> cleanly to 9, due to directory restructuring and changes to >>>> includes, so I need a quick re-review for this. >>>> >>>> The new patch has updated #includes for the new directory structure >>>> but should otherwise be identical to the previous patch. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.00/ >>>> >>>> Original webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8065331/webrev.02/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8065331 >>>> >>>> Thanks, >>>> Marcus >>>> >>>> [1]: >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-March/012408.html >>> >> > From kim.barrett at oracle.com Thu Dec 10 13:40:54 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 10 Dec 2015 08:40:54 -0500 Subject: RFR (S): 8144714 Add extension point to G1 evacuation closures In-Reply-To: <56693645.6060308@oracle.com> References: <5661AEC4.3040805@oracle.com> <56693645.6060308@oracle.com> Message-ID: <7340D289-8289-4E95-9E5E-481359091390@oracle.com> On Dec 10, 2015, at 3:22 AM, Mikael Gerdin wrote: > > Thanks for the suggestions! > Since I've already stated my plan to do further performance work in order to reduce the impact of this change and you've stated that you don't plan to fully review this change would you be ok with me pushing this as-is and look into investigating your suggestions post-integration? That?s fine with me. From bengt.rutisson at oracle.com Thu Dec 10 15:09:33 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 10 Dec 2015 16:09:33 +0100 Subject: RFR: JDK-8145092: Use Unified Logging for the GC logging Message-ID: <566995AD.1000505@oracle.com> Hi all, The changes for JEP 271, have been reviewed and discussed in this email thread: RRF: JEP-271: Unified GC Logging http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-November/thread.html#15555 However, the JEP JBS issue can not be used in the commit message for pushing the changes, so I have filed this RFE to do the push: Use Unified Logging for the GC logging https://bugs.openjdk.java.net/browse/JDK-8145092 Here are the webrevs that address the comments from the JEP-271 review thread: http://cr.openjdk.java.net/~brutisso/8145092/hotspot-webrev.00/ http://cr.openjdk.java.net/~brutisso/8145092/jdk-webrev.00/ Thanks, Bengt From stefan.johansson at oracle.com Thu Dec 10 15:30:13 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 10 Dec 2015 16:30:13 +0100 Subject: RFR: JDK-8145092: Use Unified Logging for the GC logging In-Reply-To: <566995AD.1000505@oracle.com> References: <566995AD.1000505@oracle.com> Message-ID: <56699A85.2090701@oracle.com> Hi Bengt, On 2015-12-10 16:09, Bengt Rutisson wrote: > > Hi all, > > The changes for JEP 271, have been reviewed and discussed in this > email thread: > > RRF: JEP-271: Unified GC Logging > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-November/thread.html#15555 > > > However, the JEP JBS issue can not be used in the commit message for > pushing the changes, so I have filed this RFE to do the push: > > Use Unified Logging for the GC logging > https://bugs.openjdk.java.net/browse/JDK-8145092 > > Here are the webrevs that address the comments from the JEP-271 review > thread: > > http://cr.openjdk.java.net/~brutisso/8145092/hotspot-webrev.00/ > http://cr.openjdk.java.net/~brutisso/8145092/jdk-webrev.00/ As I've said in the other thread, looks good! Thanks, Stefan > > Thanks, > Bengt From kirill.zhaldybin at oracle.com Thu Dec 10 15:42:11 2015 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Thu, 10 Dec 2015 18:42:11 +0300 Subject: RFR(S): 8132723, 8132724: Add tests which check that soft/weak references to humongous objects should work correctly In-Reply-To: <56675C9C.3000705@oracle.com> References: <5654B509.9030409@oracle.com> <56675C9C.3000705@oracle.com> Message-ID: <56699D53.5060208@oracle.com> Jon, Thank you very much for reviewing this. I will add the enhancement you proposed in a separate fix. Regards, Kirill On 09.12.2015 01:41, Jon Masamitsu wrote: > Kirill, > > Test looks good. > > One enhancement you might consider (not necessarily for this > integration) is to print out "adr" and the g1 region for "adr" if the > test fails. I'm guessing you can get the g1 region from WB. If the > test fails > and you have the list of g1 regions (it would be in the hs_err log file), > the first thing you might want to do is look up the g1 region to > see if there is anything unexpected about it. Just something to > consider. > > Jon > > > On 11/24/2015 11:05 AM, Kirill Zhaldybin wrote: >> Hi! >> >> Could you please review the following patch that adds a test that >> checks that soft/weak references to humongous objects work correctly? >> >> The test checks that weak and soft references behave correspondingly >> to actual object behavior: >> 1. If an object is collected a weak/soft reference .get() should >> return null. >> 2. If an object is not collected a weak/soft reference .get() should >> not return null. >> >> Two White Box API methods were added: >> 1. g1BelongsToHumongousRegion which checks that address belongs to >> humongous region >> 2. g1BelongsToFreeRegion which checks that address belongs to free region >> These methods do not impact G1 performance/stability since they don't >> change anything in G1 execution. >> >> The only used method from gc/testlibrary is waitTillCMCFinished, which >> is under review here - >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-November/015643.html >> >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8132723 >> https://bugs.openjdk.java.net/browse/JDK-8132724 >> >> Webrev: >> main: >> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132724/webrev.02/main/ >> hotspot: >> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132724/webrev.02/hotspot/ >> >> >> Thank you. >> >> Regards, Kirill > From bengt.rutisson at oracle.com Thu Dec 10 15:51:43 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 10 Dec 2015 16:51:43 +0100 Subject: RFR: JDK-8145092: Use Unified Logging for the GC logging In-Reply-To: <56699A85.2090701@oracle.com> References: <566995AD.1000505@oracle.com> <56699A85.2090701@oracle.com> Message-ID: <56699F8F.3080005@oracle.com> On 2015-12-10 16:30, Stefan Johansson wrote: > Hi Bengt, > > On 2015-12-10 16:09, Bengt Rutisson wrote: >> >> Hi all, >> >> The changes for JEP 271, have been reviewed and discussed in this >> email thread: >> >> RRF: JEP-271: Unified GC Logging >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-November/thread.html#15555 >> >> >> However, the JEP JBS issue can not be used in the commit message for >> pushing the changes, so I have filed this RFE to do the push: >> >> Use Unified Logging for the GC logging >> https://bugs.openjdk.java.net/browse/JDK-8145092 >> >> Here are the webrevs that address the comments from the JEP-271 >> review thread: >> >> http://cr.openjdk.java.net/~brutisso/8145092/hotspot-webrev.00/ >> http://cr.openjdk.java.net/~brutisso/8145092/jdk-webrev.00/ > As I've said in the other thread, looks good! Thanks, Stefan! Bengt > > Thanks, > Stefan > >> >> Thanks, >> Bengt > From david.lindholm at oracle.com Thu Dec 10 16:30:14 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Thu, 10 Dec 2015 17:30:14 +0100 Subject: RFR: JDK-8145092: Use Unified Logging for the GC logging In-Reply-To: <566995AD.1000505@oracle.com> References: <566995AD.1000505@oracle.com> Message-ID: <5669A896.6050301@oracle.com> Bengt, These changes (still) looks good! Thanks, David On 2015-12-10 16:09, Bengt Rutisson wrote: > > Hi all, > > The changes for JEP 271, have been reviewed and discussed in this > email thread: > > RRF: JEP-271: Unified GC Logging > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-November/thread.html#15555 > > > However, the JEP JBS issue can not be used in the commit message for > pushing the changes, so I have filed this RFE to do the push: > > Use Unified Logging for the GC logging > https://bugs.openjdk.java.net/browse/JDK-8145092 > > Here are the webrevs that address the comments from the JEP-271 review > thread: > > http://cr.openjdk.java.net/~brutisso/8145092/hotspot-webrev.00/ > http://cr.openjdk.java.net/~brutisso/8145092/jdk-webrev.00/ > > Thanks, > Bengt From david.lindholm at oracle.com Thu Dec 10 16:45:17 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Thu, 10 Dec 2015 17:45:17 +0100 Subject: RFR: 8144996: Replace the HeapRegionSetCount class with an uint Message-ID: <5669AC1D.5010805@oracle.com> Hi, Please review this cleanup patch that removes the HeapRegionSetCount class and replaces it with an uint. Bug: https://bugs.openjdk.java.net/browse/JDK-8144996 Webrev: http://cr.openjdk.java.net/~david/JDK-8144996/webrev.00/ Testing: JPRT and running jmap executing the heapsummary command verifying that it still print correct values. Thanks, David From bengt.rutisson at oracle.com Thu Dec 10 17:52:03 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 10 Dec 2015 18:52:03 +0100 Subject: RFR: JDK-8145092: Use Unified Logging for the GC logging In-Reply-To: <5669A896.6050301@oracle.com> References: <566995AD.1000505@oracle.com> <5669A896.6050301@oracle.com> Message-ID: <5669BBC3.1080508@oracle.com> On 2015-12-10 17:30, David Lindholm wrote: > Bengt, > > These changes (still) looks good! Thanks, David! Bengt > > Thanks, > David > > On 2015-12-10 16:09, Bengt Rutisson wrote: >> >> Hi all, >> >> The changes for JEP 271, have been reviewed and discussed in this >> email thread: >> >> RRF: JEP-271: Unified GC Logging >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-November/thread.html#15555 >> >> >> However, the JEP JBS issue can not be used in the commit message for >> pushing the changes, so I have filed this RFE to do the push: >> >> Use Unified Logging for the GC logging >> https://bugs.openjdk.java.net/browse/JDK-8145092 >> >> Here are the webrevs that address the comments from the JEP-271 >> review thread: >> >> http://cr.openjdk.java.net/~brutisso/8145092/hotspot-webrev.00/ >> http://cr.openjdk.java.net/~brutisso/8145092/jdk-webrev.00/ >> >> Thanks, >> Bengt > From joseph.provino at oracle.com Thu Dec 10 18:44:46 2015 From: joseph.provino at oracle.com (Joseph Provino) Date: Thu, 10 Dec 2015 13:44:46 -0500 Subject: RFR (XXS) JDK-8139768 Running with -XX:CMSOldPLABNumRefills=2147483648 causes EXCEPTION_INT_DIVIDE_BY_ZERO on Windows i586 In-Reply-To: <56688634.5040201@oracle.com> References: <56687329.8030506@oracle.com> <56688634.5040201@oracle.com> Message-ID: <5669C81E.1070602@oracle.com> Updated webrev: http://cr.openjdk.java.net/~jprovino/8139768/webrev.01 On 12/9/2015 2:51 PM, Stefan Karlsson wrote: > Hi Joe, > > On 2015-12-09 19:30, Joseph Provino wrote: >> Please review this very small change. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8139768 >> >> Webrev: http://cr.openjdk.java.net/~jprovino/8139768/webrev.00 > > The rest of the file uses // for the comments. Could you change your > comment to be consistent with the rest of the file? > > // Lacking sufficient experience, CMSOldPLABResizeQuicker is disabled by > // default. > if (ResizeOldPLAB && CMSOldPLABResizeQuicker) { > - size_t multiple = _num_blocks[word_sz]/(CMSOldPLABToleranceFactor*CMSOldPLABNumRefills*n_blks); > + /* > + * On a 32-bit VM, the denominator can become zero before of integer overflow > + * which is why there is cast to double. > + */ > + size_t multiple = (size_t) (_num_blocks[word_sz]/((double)CMSOldPLABToleranceFactor*CMSOldPLABNumRefills*n_blks)); > > Thanks, > StefanK >> >> thanks. >> >> joe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Thu Dec 10 19:50:56 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 10 Dec 2015 11:50:56 -0800 Subject: Request for review (s) - 8145031: Add regression test for 8133023 Message-ID: <5669D7A0.8000201@oracle.com> The cause of the failure in 8133023 was the calculation of the ParallelGCThreads using information that had not yet been initialized. Add a test that checks that, after full initialization, the fresh calculation of ParallelGCThreads is consistent with the value calculated earlier. http://cr.openjdk.java.net/~jmasa/8145031/webrev.00/ CR: https://bugs.openjdk.java.net/browse/JDK-8145031 Tested with and without the fix for 8133023. Thanks. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.wilhelmsson at oracle.com Thu Dec 10 22:00:15 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 10 Dec 2015 23:00:15 +0100 Subject: RFR (XXS) JDK-8139768 Running with -XX:CMSOldPLABNumRefills=2147483648 causes EXCEPTION_INT_DIVIDE_BY_ZERO on Windows i586 In-Reply-To: <5669C81E.1070602@oracle.com> References: <56687329.8030506@oracle.com> <56688634.5040201@oracle.com> <5669C81E.1070602@oracle.com> Message-ID: <5669F5EF.3020702@oracle.com> Looks good! /Jesper Den 10/12/15 kl. 19:44, skrev Joseph Provino: > Updated webrev: http://cr.openjdk.java.net/~jprovino/8139768/webrev.01 > > > > On 12/9/2015 2:51 PM, Stefan Karlsson wrote: >> Hi Joe, >> >> On 2015-12-09 19:30, Joseph Provino wrote: >>> Please review this very small change. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8139768 >>> >>> Webrev: http://cr.openjdk.java.net/~jprovino/8139768/webrev.00 >> >> The rest of the file uses // for the comments. Could you change your comment >> to be consistent with the rest of the file? >> >> // Lacking sufficient experience, CMSOldPLABResizeQuicker is disabled by >> // default. >> if (ResizeOldPLAB && CMSOldPLABResizeQuicker) { >> - size_t multiple = _num_blocks[word_sz]/(CMSOldPLABToleranceFactor*CMSOldPLABNumRefills*n_blks); >> + /* >> + * On a 32-bit VM, the denominator can become zero before of integer overflow >> + * which is why there is cast to double. >> + */ >> + size_t multiple = (size_t) (_num_blocks[word_sz]/((double)CMSOldPLABToleranceFactor*CMSOldPLABNumRefills*n_blks)); >> >> Thanks, >> StefanK >>> >>> thanks. >>> >>> joe >> > From kim.barrett at oracle.com Thu Dec 10 23:58:48 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 10 Dec 2015 18:58:48 -0500 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> Message-ID: <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> On Dec 10, 2015, at 4:18 AM, Lindenmaier, Goetz wrote: > > Hi, > > Seeing Mikaels mail, I did not convert the computation in > g1IHOPControl.cpp:145 ff. OK. I?ll file an RFE for that. > I changed though the computations in gcTraceSend.cpp. > Please check whether I should move the division to > be performed before the multiplication. I checked these, and they are ok in your latest version. > > See more comments inline below. > > New webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8143215-gcc412/webrev.03/index.html Looks good. >> get_new_size_prediction? get_predicted_size? Let the bikeshedding >> begin! > I introduced get_new_size_prediction() as Mikael said. Mikael => Thomas. From kim.barrett at oracle.com Fri Dec 11 00:17:43 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 10 Dec 2015 19:17:43 -0500 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> Message-ID: <2635C2D3-034D-4FC4-B9A4-5FB1673523DE@oracle.com> On Dec 10, 2015, at 6:58 PM, Kim Barrett wrote: > > On Dec 10, 2015, at 4:18 AM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> Seeing Mikaels mail, I did not convert the computation in >> g1IHOPControl.cpp:145 ff. > > OK. I?ll file an RFE for that. On looking at it again, unless Thomas really wants that change, I think we should leave it (with just Goetz's conversion at the end). The rewrite to only use integer arithmetic is sufficiently obfuscating that I don?t think it?s worthwhile. From goetz.lindenmaier at sap.com Fri Dec 11 10:52:59 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 11 Dec 2015 10:52:59 +0000 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EDDF76@DEWDFEMB12A.global.corp.sap> Hi Kim, > Looks good. Thanks! I'm very relieved :) Ouch ... I wanted to make a new webrev including all the reviewers and rebased, and found this: concurrentMarkSweepGeneration.cpp:2734: warning: converting to jlong from double g1CollectedHeap.cpp:3624: warning: passing double for argument 1 to static double TimeHelper::counter_to_seconds(jlong) I corrected this in this new webrev, I hope this doesn't cause another long round of reviews (please!). http://cr.openjdk.java.net/~goetz/webrevs/8143215-gcc412/webrev.04/ Best regards, Goetz. Incremental change: diff -r 73e267ddd93d src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp --- a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Wed Nov 18 11:31:59 2015 +0100 +++ b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Fri Dec 11 11:42:52 2015 +0100 @@ -2731,7 +2731,7 @@ // Not MT-safe; so do not pass around these StackObj's // where they may be accessed by other threads. jlong wallclock_millis() { - return TimeHelper::counter_to_millis(os::elapsed_counter() - _trace_time.start_time()); + return (jlong)TimeHelper::counter_to_millis(os::elapsed_counter() - _trace_time.start_time()); } }; diff -r 73e267ddd93d src/share/vm/gc/g1/g1CollectedHeap.cpp --- a/src/share/vm/gc/g1/g1CollectedHeap.cpp Wed Nov 18 11:31:59 2015 +0100 +++ b/src/share/vm/gc/g1/g1CollectedHeap.cpp Fri Dec 11 11:42:52 2015 +0100 @@ -3621,7 +3621,7 @@ log_info(gc)("To-space exhausted"); } - double pause_time_sec = TimeHelper::counter_to_seconds(pause_time_counter); + double pause_time_sec = TimeHelper::counter_to_seconds((jlong)pause_time_counter); g1_policy()->print_phases(pause_time_sec); g1_policy()->print_detailed_heap_transition(); > -----Original Message----- > From: Kim Barrett [mailto:kim.barrett at oracle.com] > Sent: Freitag, 11. Dezember 2015 00:59 > To: Lindenmaier, Goetz > Cc: hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. > > On Dec 10, 2015, at 4:18 AM, Lindenmaier, Goetz > wrote: > > > > Hi, > > > > Seeing Mikaels mail, I did not convert the computation in > > g1IHOPControl.cpp:145 ff. > > OK. I'll file an RFE for that. > > > I changed though the computations in gcTraceSend.cpp. > > Please check whether I should move the division to > > be performed before the multiplication. > > I checked these, and they are ok in your latest version. > > > > > See more comments inline below. > > > > New webrev: > > http://cr.openjdk.java.net/~goetz/webrevs/8143215- > gcc412/webrev.03/index.html > > Looks good. > > >> get_new_size_prediction? get_predicted_size? Let the bikeshedding > >> begin! > > I introduced get_new_size_prediction() as Mikael said. > > Mikael => Thomas. From david.lindholm at oracle.com Fri Dec 11 12:16:45 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 11 Dec 2015 13:16:45 +0100 Subject: RFR: 8144996: Replace the HeapRegionSetCount class with an uint In-Reply-To: <5669AC1D.5010805@oracle.com> References: <5669AC1D.5010805@oracle.com> Message-ID: <566ABEAD.6070506@oracle.com> Hi, After offline discussions with Bengt we decided that HeapRegionSetBase::total_capacity_bytes() also can be removed. New webrev: http://cr.openjdk.java.net/~david/JDK-8144996/webrev.01/ Thanks, David On 2015-12-10 17:45, David Lindholm wrote: > Hi, > > Please review this cleanup patch that removes the HeapRegionSetCount > class and replaces it with an uint. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8144996 > Webrev: http://cr.openjdk.java.net/~david/JDK-8144996/webrev.00/ > > Testing: JPRT and running jmap executing the heapsummary command > verifying that it still print correct values. > > > Thanks, > David From bengt.rutisson at oracle.com Fri Dec 11 12:39:55 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 11 Dec 2015 13:39:55 +0100 Subject: RFR: 8144996: Replace the HeapRegionSetCount class with an uint In-Reply-To: <566ABEAD.6070506@oracle.com> References: <5669AC1D.5010805@oracle.com> <566ABEAD.6070506@oracle.com> Message-ID: <566AC41B.7060105@oracle.com> Hi David, On 2015-12-11 13:16, David Lindholm wrote: > Hi, > > After offline discussions with Bengt we decided that > HeapRegionSetBase::total_capacity_bytes() also can be removed. > > New webrev: > > http://cr.openjdk.java.net/~david/JDK-8144996/webrev.01/ Looks good to me. Bengt > > Thanks, > David > > On 2015-12-10 17:45, David Lindholm wrote: >> Hi, >> >> Please review this cleanup patch that removes the HeapRegionSetCount >> class and replaces it with an uint. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8144996 >> Webrev: http://cr.openjdk.java.net/~david/JDK-8144996/webrev.00/ >> >> Testing: JPRT and running jmap executing the heapsummary command >> verifying that it still print correct values. >> >> >> Thanks, >> David > From jesper.wilhelmsson at oracle.com Fri Dec 11 13:08:39 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 11 Dec 2015 14:08:39 +0100 Subject: RFR: 8144996: Replace the HeapRegionSetCount class with an uint In-Reply-To: <566AC41B.7060105@oracle.com> References: <5669AC1D.5010805@oracle.com> <566ABEAD.6070506@oracle.com> <566AC41B.7060105@oracle.com> Message-ID: <566ACAD7.7020902@oracle.com> Looks good! /Jesper Den 11/12/15 kl. 13:39, skrev Bengt Rutisson: > > Hi David, > > On 2015-12-11 13:16, David Lindholm wrote: >> Hi, >> >> After offline discussions with Bengt we decided that >> HeapRegionSetBase::total_capacity_bytes() also can be removed. >> >> New webrev: >> >> http://cr.openjdk.java.net/~david/JDK-8144996/webrev.01/ > > Looks good to me. > > Bengt > >> >> Thanks, >> David >> >> On 2015-12-10 17:45, David Lindholm wrote: >>> Hi, >>> >>> Please review this cleanup patch that removes the HeapRegionSetCount class >>> and replaces it with an uint. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144996 >>> Webrev: http://cr.openjdk.java.net/~david/JDK-8144996/webrev.00/ >>> >>> Testing: JPRT and running jmap executing the heapsummary command verifying >>> that it still print correct values. >>> >>> >>> Thanks, >>> David >> > From david.lindholm at oracle.com Fri Dec 11 13:03:51 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 11 Dec 2015 14:03:51 +0100 Subject: RFR: 8144996: Replace the HeapRegionSetCount class with an uint In-Reply-To: <566AC41B.7060105@oracle.com> References: <5669AC1D.5010805@oracle.com> <566ABEAD.6070506@oracle.com> <566AC41B.7060105@oracle.com> Message-ID: <566AC9B7.1070908@oracle.com> Bengt, Thanks for the review! /David On 2015-12-11 13:39, Bengt Rutisson wrote: > > Hi David, > > On 2015-12-11 13:16, David Lindholm wrote: >> Hi, >> >> After offline discussions with Bengt we decided that >> HeapRegionSetBase::total_capacity_bytes() also can be removed. >> >> New webrev: >> >> http://cr.openjdk.java.net/~david/JDK-8144996/webrev.01/ > > Looks good to me. > > Bengt > >> >> Thanks, >> David >> >> On 2015-12-10 17:45, David Lindholm wrote: >>> Hi, >>> >>> Please review this cleanup patch that removes the HeapRegionSetCount >>> class and replaces it with an uint. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144996 >>> Webrev: http://cr.openjdk.java.net/~david/JDK-8144996/webrev.00/ >>> >>> Testing: JPRT and running jmap executing the heapsummary command >>> verifying that it still print correct values. >>> >>> >>> Thanks, >>> David >> > From david.lindholm at oracle.com Fri Dec 11 13:04:12 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 11 Dec 2015 14:04:12 +0100 Subject: RFR: 8144996: Replace the HeapRegionSetCount class with an uint In-Reply-To: <566ACAD7.7020902@oracle.com> References: <5669AC1D.5010805@oracle.com> <566ABEAD.6070506@oracle.com> <566AC41B.7060105@oracle.com> <566ACAD7.7020902@oracle.com> Message-ID: <566AC9CC.3070907@oracle.com> Jesper, Thanks for the review! /David On 2015-12-11 14:08, Jesper Wilhelmsson wrote: > Looks good! > /Jesper > > Den 11/12/15 kl. 13:39, skrev Bengt Rutisson: >> >> Hi David, >> >> On 2015-12-11 13:16, David Lindholm wrote: >>> Hi, >>> >>> After offline discussions with Bengt we decided that >>> HeapRegionSetBase::total_capacity_bytes() also can be removed. >>> >>> New webrev: >>> >>> http://cr.openjdk.java.net/~david/JDK-8144996/webrev.01/ >> >> Looks good to me. >> >> Bengt >> >>> >>> Thanks, >>> David >>> >>> On 2015-12-10 17:45, David Lindholm wrote: >>>> Hi, >>>> >>>> Please review this cleanup patch that removes the >>>> HeapRegionSetCount class >>>> and replaces it with an uint. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144996 >>>> Webrev: http://cr.openjdk.java.net/~david/JDK-8144996/webrev.00/ >>>> >>>> Testing: JPRT and running jmap executing the heapsummary command >>>> verifying >>>> that it still print correct values. >>>> >>>> >>>> Thanks, >>>> David >>> >> From thomas.stuefe at gmail.com Sat Dec 12 06:12:29 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 12 Dec 2015 07:12:29 +0100 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EDDF76@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDDF76@DEWDFEMB12A.global.corp.sap> Message-ID: Hi all, > > > I corrected this in this new webrev, I hope this doesn't cause another long > round of reviews (please!). > http://cr.openjdk.java.net/~goetz/webrevs/8143215-gcc412/webrev.04/ > > Just wanted to second Goetz on this one. This is a very annoying issue and I will be very thankful when this is resolved. Kind Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Sat Dec 12 23:02:31 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 12 Dec 2015 18:02:31 -0500 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EDDF76@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDDF76@DEWDFEMB12A.global.corp.sap> Message-ID: <77BA861E-BEF9-4E61-B46E-84E4612B72E3@oracle.com> On Dec 11, 2015, at 5:52 AM, Lindenmaier, Goetz wrote: > > diff -r 73e267ddd93d src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp > --- a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Wed Nov 18 11:31:59 2015 +0100 > +++ b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Fri Dec 11 11:42:52 2015 +0100 > @@ -2731,7 +2731,7 @@ > // Not MT-safe; so do not pass around these StackObj's > // where they may be accessed by other threads. > jlong wallclock_millis() { > - return TimeHelper::counter_to_millis(os::elapsed_counter() - _trace_time.start_time()); > + return (jlong)TimeHelper::counter_to_millis(os::elapsed_counter() - _trace_time.start_time()); > } > }; This conversion was introduced by the recently pushed 8145092: Use Unified Logging for the GC logging. The only caller of wallclock_millis compares the result with CMSMaxAbortablePrecleanTime (an intx). So I think we?ve always had a bit of a type mismatch here. I?m not sure what to do about this one yet, but adding a cast doesn?t seem like the right solution to me. > diff -r 73e267ddd93d src/share/vm/gc/g1/g1CollectedHeap.cpp > --- a/src/share/vm/gc/g1/g1CollectedHeap.cpp Wed Nov 18 11:31:59 2015 +0100 > +++ b/src/share/vm/gc/g1/g1CollectedHeap.cpp Fri Dec 11 11:42:52 2015 +0100 > @@ -3621,7 +3621,7 @@ > log_info(gc)("To-space exhausted"); > } > > - double pause_time_sec = TimeHelper::counter_to_seconds(pause_time_counter); > + double pause_time_sec = TimeHelper::counter_to_seconds((jlong)pause_time_counter); > g1_policy()->print_phases(pause_time_sec); > > g1_policy()->print_detailed_heap_transition(); Adding a cast is not the proper fix here. The problem is that log_gc_footer?s double pause_time_counter argument ought to itself be a jlong. The caller (do_collection_pause_at_safepoint) contains double pause_start_counter = os::elapsed_counter(); ? log_gc_footer(os::elapsed_counter() - pause_start_counter); elapsed_counter returns a jlong. So pause_start_counter ought to be a jlong too, and fixing the parameter type for log_gc_footer would then make everything work out. This appears to be a mistake introduced by the recently pushed 8145092: Use Unified Logging for the GC logging. From sky1young at gmail.com Mon Dec 14 07:55:23 2015 From: sky1young at gmail.com (ray alex) Date: Mon, 14 Dec 2015 15:55:23 +0800 Subject: [PATCH] enhancement to ParallelScavenge Full GC Message-ID: Hi all, Can I have reviews for the following enhancement? Description: The change addresses the inefficiency in the live_words_in_range() routine in ParallelScavenge Full GC, which generally costs most of the time during the compacting phase. Our idea records last query information of live_words_in_range as well as the query result. Our approach reuses last query result so that can reduce much computation of bitmap searching. Patch: as attached. Testing: Manual testing of full GC intensive applications including JOlden, Dacapo, SPECjvm2008 benchmarks. Results show that our enhancement can reduce much full GC time by 20~50%, depending on application scenarios. -- Lei Tianyang Institute of Parallel and Distributed System (IPADS) Shanghai Jiao Tong University -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: parallelScavenge.patch Type: application/octet-stream Size: 4787 bytes Desc: not available URL: From goetz.lindenmaier at sap.com Mon Dec 14 08:06:54 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Dec 2015 08:06:54 +0000 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDDF76@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC41EDE5E3@DEWDFEMB12A.global.corp.sap> Thanks Thomas! Goetz. From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Samstag, 12. Dezember 2015 07:12 To: Lindenmaier, Goetz Cc: Kim Barrett ; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. Hi all, I corrected this in this new webrev, I hope this doesn't cause another long round of reviews (please!). http://cr.openjdk.java.net/~goetz/webrevs/8143215-gcc412/webrev.04/ Just wanted to second Goetz on this one. This is a very annoying issue and I will be very thankful when this is resolved. Kind Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Mon Dec 14 08:11:07 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Dec 2015 08:11:07 +0000 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <77BA861E-BEF9-4E61-B46E-84E4612B72E3@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDDF76@DEWDFEMB12A.global.corp.sap> <77BA861E-BEF9-4E61-B46E-84E4612B72E3@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EDE645@DEWDFEMB12A.global.corp.sap> Hi, I would call for an extra change if you want to change this. I think it's strange a flag specifying a time span depends on the platform in it's presicion (intx). So I think the type of the Flag should be changed to uint64_t or the like. This would be out of the scope of a 'fix the build' change. Best regards, Goetz. > -----Original Message----- > From: Kim Barrett [mailto:kim.barrett at oracle.com] > Sent: Sonntag, 13. Dezember 2015 00:03 > To: Lindenmaier, Goetz > Cc: hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. > > On Dec 11, 2015, at 5:52 AM, Lindenmaier, Goetz > wrote: > > > > diff -r 73e267ddd93d > src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp > > --- a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Wed > Nov 18 11:31:59 2015 +0100 > > +++ b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Fri > Dec 11 11:42:52 2015 +0100 > > @@ -2731,7 +2731,7 @@ > > // Not MT-safe; so do not pass around these StackObj's > > // where they may be accessed by other threads. > > jlong wallclock_millis() { > > - return TimeHelper::counter_to_millis(os::elapsed_counter() - > _trace_time.start_time()); > > + return (jlong)TimeHelper::counter_to_millis(os::elapsed_counter() - > _trace_time.start_time()); > > } > > }; > > This conversion was introduced by the recently pushed 8145092: Use Unified > Logging for the GC logging. > > The only caller of wallclock_millis compares the result with > CMSMaxAbortablePrecleanTime (an intx). > > So I think we've always had a bit of a type mismatch here. > > I'm not sure what to do about this one yet, but adding a cast doesn't seem > like the right solution to me. > > > diff -r 73e267ddd93d src/share/vm/gc/g1/g1CollectedHeap.cpp > > --- a/src/share/vm/gc/g1/g1CollectedHeap.cpp Wed Nov 18 11:31:59 2015 > +0100 > > +++ b/src/share/vm/gc/g1/g1CollectedHeap.cpp Fri Dec 11 11:42:52 2015 > +0100 > > @@ -3621,7 +3621,7 @@ > > log_info(gc)("To-space exhausted"); > > } > > > > - double pause_time_sec = > TimeHelper::counter_to_seconds(pause_time_counter); > > + double pause_time_sec = > TimeHelper::counter_to_seconds((jlong)pause_time_counter); > > g1_policy()->print_phases(pause_time_sec); > > > > g1_policy()->print_detailed_heap_transition(); > > Adding a cast is not the proper fix here. > > The problem is that log_gc_footer's double pause_time_counter argument > ought to itself be a jlong. > The caller (do_collection_pause_at_safepoint) contains > > double pause_start_counter = os::elapsed_counter(); > ... > log_gc_footer(os::elapsed_counter() - pause_start_counter); > > elapsed_counter returns a jlong. So pause_start_counter ought to be a jlong > too, and fixing the > parameter type for log_gc_footer would then make everything work out. > > This appears to be a mistake introduced by the recently pushed 8145092: Use > Unified Logging for the GC logging. From david.lindholm at oracle.com Mon Dec 14 09:35:00 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Mon, 14 Dec 2015 10:35:00 +0100 Subject: RFR: Improve and unify the printout format for the g1HRPrinter. Message-ID: <566E8D44.4070709@oracle.com> Hi, Please review this patch that unifies the format of the printouts printed by the g1HRPrinter. It also gets the typestring of the HeapRegion from the HeapRegion itself. Bug: https://bugs.openjdk.java.net/browse/JDK-8145301 Webrev: http://cr.openjdk.java.net/~david/JDK-8145301/webrev.00/ Testing: JPRT Thanks, David From bengt.rutisson at oracle.com Mon Dec 14 09:42:18 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 14 Dec 2015 10:42:18 +0100 Subject: RFR: JDK-8145303: Clean up the units for log_gc_footer Message-ID: <566E8EFA.1060506@oracle.com> Hi everyone, Could I have a couple of reviews for this small patch? http://cr.openjdk.java.net/~brutisso/8145303/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8145303 The log_gc_footer() method takes one parameter of type double. But it should be jlong. It also converts to seconds but farther down the call chain we convert to milliseconds. Thanks, Bengt From david.lindholm at oracle.com Mon Dec 14 09:37:53 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Mon, 14 Dec 2015 10:37:53 +0100 Subject: RFR: 8145301: Improve and unify the printout format for the g1HRPrinter. In-Reply-To: <566E8D44.4070709@oracle.com> References: <566E8D44.4070709@oracle.com> Message-ID: <566E8DF1.4070508@oracle.com> Hi, Please review this patch that unifies the format of the printouts printed by the g1HRPrinter. It also gets the typestring of the HeapRegion from the HeapRegion itself. Bug: https://bugs.openjdk.java.net/browse/JDK-8145301 Webrev: http://cr.openjdk.java.net/~david/JDK-8145301/webrev.00/ Testing: JPRT Thanks, David From bengt.rutisson at oracle.com Mon Dec 14 09:43:50 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 14 Dec 2015 10:43:50 +0100 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <77BA861E-BEF9-4E61-B46E-84E4612B72E3@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDDF76@DEWDFEMB12A.global.corp.sap> <77BA861E-BEF9-4E61-B46E-84E4612B72E3@oracle.com> Message-ID: <566E8F56.1020400@oracle.com> Hi Kim and Goetz, On 2015-12-13 00:02, Kim Barrett wrote: > On Dec 11, 2015, at 5:52 AM, Lindenmaier, Goetz wrote: >> diff -r 73e267ddd93d src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp >> --- a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Wed Nov 18 11:31:59 2015 +0100 >> +++ b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Fri Dec 11 11:42:52 2015 +0100 >> @@ -2731,7 +2731,7 @@ >> // Not MT-safe; so do not pass around these StackObj's >> // where they may be accessed by other threads. >> jlong wallclock_millis() { >> - return TimeHelper::counter_to_millis(os::elapsed_counter() - _trace_time.start_time()); >> + return (jlong)TimeHelper::counter_to_millis(os::elapsed_counter() - _trace_time.start_time()); >> } >> }; > This conversion was introduced by the recently pushed 8145092: Use Unified Logging for the GC logging. > > The only caller of wallclock_millis compares the result with CMSMaxAbortablePrecleanTime (an intx). > > So I think we?ve always had a bit of a type mismatch here. > > I?m not sure what to do about this one yet, but adding a cast doesn?t seem like the right solution to me. I would suggest changing CMSMaxAbortablePrecleanTime to a double. It may not be the cleanest way to handle the flag but having it as an intx is also not very clean. Negative values won't make sense. Changing it to a double won't make the situation much worse than it is now and it will simplify the code. So, I would suggest: diff --git a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp --- a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp +++ b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp @@ -2733,1 +2733,1 @@ - jlong wallclock_millis() { + double wallclock_millis() { diff --git a/src/share/vm/runtime/globals.hpp b/src/share/vm/runtime/globals.hpp --- a/src/share/vm/runtime/globals.hpp +++ b/src/share/vm/runtime/globals.hpp @@ -1836,1 +1836,1 @@ - product(intx, CMSMaxAbortablePrecleanTime, 5000, \ + product(double, CMSMaxAbortablePrecleanTime, 5000, \ > >> diff -r 73e267ddd93d src/share/vm/gc/g1/g1CollectedHeap.cpp >> --- a/src/share/vm/gc/g1/g1CollectedHeap.cpp Wed Nov 18 11:31:59 2015 +0100 >> +++ b/src/share/vm/gc/g1/g1CollectedHeap.cpp Fri Dec 11 11:42:52 2015 +0100 >> @@ -3621,7 +3621,7 @@ >> log_info(gc)("To-space exhausted"); >> } >> >> - double pause_time_sec = TimeHelper::counter_to_seconds(pause_time_counter); >> + double pause_time_sec = TimeHelper::counter_to_seconds((jlong)pause_time_counter); >> g1_policy()->print_phases(pause_time_sec); >> >> g1_policy()->print_detailed_heap_transition(); > Adding a cast is not the proper fix here. > > The problem is that log_gc_footer?s double pause_time_counter argument ought to itself be a jlong. > The caller (do_collection_pause_at_safepoint) contains > > double pause_start_counter = os::elapsed_counter(); > ? > log_gc_footer(os::elapsed_counter() - pause_start_counter); > > elapsed_counter returns a jlong. So pause_start_counter ought to be a jlong too, and fixing the > parameter type for log_gc_footer would then make everything work out. > > This appears to be a mistake introduced by the recently pushed 8145092: Use Unified Logging for the GC logging. > Yes, this is a mistake in the push for the unified logging work. I created a patch and sent out a new review request to fix it. RFR: JDK-8145303: Clean up the units for log_gc_footer http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-December/015903.html http://cr.openjdk.java.net/~brutisso/8145303/webrev.00/ Thanks, Bengt From bengt.rutisson at oracle.com Mon Dec 14 09:52:40 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 14 Dec 2015 10:52:40 +0100 Subject: RFR: 8145301: Improve and unify the printout format for the g1HRPrinter. In-Reply-To: <566E8DF1.4070508@oracle.com> References: <566E8D44.4070709@oracle.com> <566E8DF1.4070508@oracle.com> Message-ID: <566E9168.7080807@oracle.com> Hi David, On 2015-12-14 10:37, David Lindholm wrote: > Hi, > > Please review this patch that unifies the format of the printouts > printed by the g1HRPrinter. It also gets the typestring of the > HeapRegion from the HeapRegion itself. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145301 > Webrev: http://cr.openjdk.java.net/~david/JDK-8145301/webrev.00/ Looks good. Bengt > > Testing: JPRT > > > Thanks, > David From david.lindholm at oracle.com Mon Dec 14 09:49:44 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Mon, 14 Dec 2015 10:49:44 +0100 Subject: RFR: JDK-8145303: Clean up the units for log_gc_footer In-Reply-To: <566E8EFA.1060506@oracle.com> References: <566E8EFA.1060506@oracle.com> Message-ID: <566E90B8.3030804@oracle.com> Bengt, The change looks good! /David On 2015-12-14 10:42, Bengt Rutisson wrote: > > Hi everyone, > > Could I have a couple of reviews for this small patch? > > http://cr.openjdk.java.net/~brutisso/8145303/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8145303 > > The log_gc_footer() method takes one parameter of type double. But it > should be jlong. It also converts to seconds but farther down the call > chain we convert to milliseconds. > > Thanks, > Bengt From bengt.rutisson at oracle.com Mon Dec 14 10:28:16 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 14 Dec 2015 11:28:16 +0100 Subject: RFR: JDK-8145303: Clean up the units for log_gc_footer In-Reply-To: <566E90B8.3030804@oracle.com> References: <566E8EFA.1060506@oracle.com> <566E90B8.3030804@oracle.com> Message-ID: <566E99C0.5060602@oracle.com> Thanks, David! Bengt On 2015-12-14 10:49, David Lindholm wrote: > Bengt, > > The change looks good! > > /David > > On 2015-12-14 10:42, Bengt Rutisson wrote: >> >> Hi everyone, >> >> Could I have a couple of reviews for this small patch? >> >> http://cr.openjdk.java.net/~brutisso/8145303/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8145303 >> >> The log_gc_footer() method takes one parameter of type double. But it >> should be jlong. It also converts to seconds but farther down the >> call chain we convert to milliseconds. >> >> Thanks, >> Bengt > From thomas.schatzl at oracle.com Mon Dec 14 10:51:19 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 14 Dec 2015 11:51:19 +0100 Subject: RFR: JDK-8145303: Clean up the units for log_gc_footer In-Reply-To: <566E8EFA.1060506@oracle.com> References: <566E8EFA.1060506@oracle.com> Message-ID: <1450090279.2316.1.camel@oracle.com> Hi Bengt, On Mon, 2015-12-14 at 10:42 +0100, Bengt Rutisson wrote: > Hi everyone, > > Could I have a couple of reviews for this small patch? > > http://cr.openjdk.java.net/~brutisso/8145303/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8145303 > > The log_gc_footer() method takes one parameter of type double. But it > should be jlong. It also converts to seconds but farther down the call > chain we convert to milliseconds. do you mind removing the line "double pause_start_sec = os::elapsedTime()" in g1CollectedHeap.cpp:3717 just above that change in 3718. It's dead code. Do not need another review for that. Thanks, Thomas From bengt.rutisson at oracle.com Mon Dec 14 10:56:30 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 14 Dec 2015 11:56:30 +0100 Subject: RFR: JDK-8145303: Clean up the units for log_gc_footer In-Reply-To: <1450090279.2316.1.camel@oracle.com> References: <566E8EFA.1060506@oracle.com> <1450090279.2316.1.camel@oracle.com> Message-ID: <566EA05E.6050004@oracle.com> Hi Thomas, On 2015-12-14 11:51, Thomas Schatzl wrote: > Hi Bengt, > > On Mon, 2015-12-14 at 10:42 +0100, Bengt Rutisson wrote: >> Hi everyone, >> >> Could I have a couple of reviews for this small patch? >> >> http://cr.openjdk.java.net/~brutisso/8145303/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8145303 >> >> The log_gc_footer() method takes one parameter of type double. But it >> should be jlong. It also converts to seconds but farther down the call >> chain we convert to milliseconds. > do you mind removing the line "double pause_start_sec = > os::elapsedTime()" in g1CollectedHeap.cpp:3717 just above that change in > 3718. It's dead code. > > Do not need another review for that. Good catch. I'll fix that. Thanks for looking at this! Bengt > > Thanks, > Thomas > > From goetz.lindenmaier at sap.com Mon Dec 14 10:57:12 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Dec 2015 10:57:12 +0000 Subject: JDK-8145303: Clean up the units for log_gc_footer In-Reply-To: <566E8EFA.1060506@oracle.com> References: <566E8EFA.1060506@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EDE75A@DEWDFEMB12A.global.corp.sap> Hi Bengt, thanks for doing a real fix for this. Looks good (and works with gcc 4.1.2). I'll remove my patch for g1CollectedHeap.cpp from my webrev for 8143215: gcc 4.1.2: fix three issues breaking the build. Thanks a lot! Goetz. > -----Original Message----- > From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] > On Behalf Of Bengt Rutisson > Sent: Montag, 14. Dezember 2015 10:42 > To: hotspot-gc-dev at openjdk.java.net > Subject: RFR: JDK-8145303: Clean up the units for log_gc_footer > > > Hi everyone, > > Could I have a couple of reviews for this small patch? > > http://cr.openjdk.java.net/~brutisso/8145303/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8145303 > > The log_gc_footer() method takes one parameter of type double. But it > should be jlong. It also converts to seconds but farther down the call > chain we convert to milliseconds. > > Thanks, > Bengt From thomas.schatzl at oracle.com Mon Dec 14 10:58:08 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 14 Dec 2015 11:58:08 +0100 Subject: RFR: 8145301: Improve and unify the printout format for the g1HRPrinter. In-Reply-To: <566E8DF1.4070508@oracle.com> References: <566E8D44.4070709@oracle.com> <566E8DF1.4070508@oracle.com> Message-ID: <1450090688.2316.2.camel@oracle.com> Hi, On Mon, 2015-12-14 at 10:37 +0100, David Lindholm wrote: > Hi, > > Please review this patch that unifies the format of the printouts > printed by the g1HRPrinter. It also gets the typestring of the > HeapRegion from the HeapRegion itself. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145301 > Webrev: http://cr.openjdk.java.net/~david/JDK-8145301/webrev.00/ > > Testing: JPRT > looks good. Thomas From goetz.lindenmaier at sap.com Mon Dec 14 11:19:35 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Dec 2015 11:19:35 +0000 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <566E8F56.1020400@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDDF76@DEWDFEMB12A.global.corp.sap> <77BA861E-BEF9-4E61-B46E-84E4612B72E3@oracle.com> <566E8F56.1020400@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EDE79B@DEWDFEMB12A.global.corp.sap> Hi, I removed the change to g1CollectedHeap.cpp ("8145303: Clean up the units for log_gc_footer" will fix this) and changed the flag to 'double'. New webrev: http://cr.openjdk.java.net/~goetz/webrevs/8143215-gcc412/webrev.05/ Best regards, Goetz. > -----Original Message----- > From: Bengt Rutisson [mailto:bengt.rutisson at oracle.com] > Sent: Montag, 14. Dezember 2015 10:44 > To: Kim Barrett ; Lindenmaier, Goetz > > Cc: hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. > > > Hi Kim and Goetz, > > On 2015-12-13 00:02, Kim Barrett wrote: > > On Dec 11, 2015, at 5:52 AM, Lindenmaier, Goetz > wrote: > >> diff -r 73e267ddd93d > src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp > >> --- a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Wed > Nov 18 11:31:59 2015 +0100 > >> +++ b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Fri > Dec 11 11:42:52 2015 +0100 > >> @@ -2731,7 +2731,7 @@ > >> // Not MT-safe; so do not pass around these StackObj's > >> // where they may be accessed by other threads. > >> jlong wallclock_millis() { > >> - return TimeHelper::counter_to_millis(os::elapsed_counter() - > _trace_time.start_time()); > >> + return (jlong)TimeHelper::counter_to_millis(os::elapsed_counter() - > _trace_time.start_time()); > >> } > >> }; > > This conversion was introduced by the recently pushed 8145092: Use > Unified Logging for the GC logging. > > > > The only caller of wallclock_millis compares the result with > CMSMaxAbortablePrecleanTime (an intx). > > > > So I think we've always had a bit of a type mismatch here. > > > > I'm not sure what to do about this one yet, but adding a cast doesn't seem > like the right solution to me. > > I would suggest changing CMSMaxAbortablePrecleanTime to a double. It > may > not be the cleanest way to handle the flag but having it as an intx is > also not very clean. Negative values won't make sense. Changing it to a > double won't make the situation much worse than it is now and it will > simplify the code. > > So, I would suggest: > > diff --git a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp > b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp > --- a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp > +++ b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp > @@ -2733,1 +2733,1 @@ > - jlong wallclock_millis() { > + double wallclock_millis() { > diff --git a/src/share/vm/runtime/globals.hpp > b/src/share/vm/runtime/globals.hpp > --- a/src/share/vm/runtime/globals.hpp > +++ b/src/share/vm/runtime/globals.hpp > @@ -1836,1 +1836,1 @@ > - product(intx, CMSMaxAbortablePrecleanTime, > 5000, \ > + product(double, CMSMaxAbortablePrecleanTime, > 5000, \ > > > > > >> diff -r 73e267ddd93d src/share/vm/gc/g1/g1CollectedHeap.cpp > >> --- a/src/share/vm/gc/g1/g1CollectedHeap.cpp Wed Nov 18 11:31:59 > 2015 +0100 > >> +++ b/src/share/vm/gc/g1/g1CollectedHeap.cpp Fri Dec 11 11:42:52 2015 > +0100 > >> @@ -3621,7 +3621,7 @@ > >> log_info(gc)("To-space exhausted"); > >> } > >> > >> - double pause_time_sec = > TimeHelper::counter_to_seconds(pause_time_counter); > >> + double pause_time_sec = > TimeHelper::counter_to_seconds((jlong)pause_time_counter); > >> g1_policy()->print_phases(pause_time_sec); > >> > >> g1_policy()->print_detailed_heap_transition(); > > Adding a cast is not the proper fix here. > > > > The problem is that log_gc_footer's double pause_time_counter argument > ought to itself be a jlong. > > The caller (do_collection_pause_at_safepoint) contains > > > > double pause_start_counter = os::elapsed_counter(); > > ... > > log_gc_footer(os::elapsed_counter() - pause_start_counter); > > > > elapsed_counter returns a jlong. So pause_start_counter ought to be a > jlong too, and fixing the > > parameter type for log_gc_footer would then make everything work out. > > > > This appears to be a mistake introduced by the recently pushed 8145092: > Use Unified Logging for the GC logging. > > > > Yes, this is a mistake in the push for the unified logging work. I > created a patch and sent out a new review request to fix it. > > RFR: JDK-8145303: Clean up the units for log_gc_footer > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015- > December/015903.html > > http://cr.openjdk.java.net/~brutisso/8145303/webrev.00/ > > Thanks, > Bengt From bengt.rutisson at oracle.com Mon Dec 14 12:02:06 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 14 Dec 2015 13:02:06 +0100 Subject: JDK-8145303: Clean up the units for log_gc_footer In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EDE75A@DEWDFEMB12A.global.corp.sap> References: <566E8EFA.1060506@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDE75A@DEWDFEMB12A.global.corp.sap> Message-ID: <566EAFBE.5060807@oracle.com> Hi Goetz, Thanks for looking at this so quickly! On 2015-12-14 11:57, Lindenmaier, Goetz wrote: > Hi Bengt, > > thanks for doing a real fix for this. Looks good (and works with gcc 4.1.2). Great! Thanks for verifying it on gcc 4.1.2. > I'll remove my patch for g1CollectedHeap.cpp from my > webrev for 8143215: gcc 4.1.2: fix three issues breaking the build. Sounds good. Bengt > > Thanks a lot! > Goetz. > >> -----Original Message----- >> From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] >> On Behalf Of Bengt Rutisson >> Sent: Montag, 14. Dezember 2015 10:42 >> To: hotspot-gc-dev at openjdk.java.net >> Subject: RFR: JDK-8145303: Clean up the units for log_gc_footer >> >> >> Hi everyone, >> >> Could I have a couple of reviews for this small patch? >> >> http://cr.openjdk.java.net/~brutisso/8145303/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8145303 >> >> The log_gc_footer() method takes one parameter of type double. But it >> should be jlong. It also converts to seconds but farther down the call >> chain we convert to milliseconds. >> >> Thanks, >> Bengt From bengt.rutisson at oracle.com Mon Dec 14 12:03:51 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 14 Dec 2015 13:03:51 +0100 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EDE79B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDDF76@DEWDFEMB12A.global.corp.sap> <77BA861E-BEF9-4E61-B46E-84E4612B72E3@oracle.com> <566E8F56.1020400@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDE79B@DEWDFEMB12A.global.corp.sap> Message-ID: <566EB027.2010403@oracle.com> Hi Goetz, On 2015-12-14 12:19, Lindenmaier, Goetz wrote: > Hi, > > I removed the change to g1CollectedHeap.cpp > ("8145303: Clean up the units for log_gc_footer" will fix this) > and changed the flag to 'double'. New webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8143215-gcc412/webrev.05/ This looks good to me, but I haven't been following this thread closely so it would be good if Kim and Thomas take a look too. Thanks, Bengt > > Best regards, > Goetz. > > >> -----Original Message----- >> From: Bengt Rutisson [mailto:bengt.rutisson at oracle.com] >> Sent: Montag, 14. Dezember 2015 10:44 >> To: Kim Barrett ; Lindenmaier, Goetz >> >> Cc: hotspot-gc-dev at openjdk.java.net >> Subject: Re: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. >> >> >> Hi Kim and Goetz, >> >> On 2015-12-13 00:02, Kim Barrett wrote: >>> On Dec 11, 2015, at 5:52 AM, Lindenmaier, Goetz >> wrote: >>>> diff -r 73e267ddd93d >> src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp >>>> --- a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Wed >> Nov 18 11:31:59 2015 +0100 >>>> +++ b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Fri >> Dec 11 11:42:52 2015 +0100 >>>> @@ -2731,7 +2731,7 @@ >>>> // Not MT-safe; so do not pass around these StackObj's >>>> // where they may be accessed by other threads. >>>> jlong wallclock_millis() { >>>> - return TimeHelper::counter_to_millis(os::elapsed_counter() - >> _trace_time.start_time()); >>>> + return (jlong)TimeHelper::counter_to_millis(os::elapsed_counter() - >> _trace_time.start_time()); >>>> } >>>> }; >>> This conversion was introduced by the recently pushed 8145092: Use >> Unified Logging for the GC logging. >>> The only caller of wallclock_millis compares the result with >> CMSMaxAbortablePrecleanTime (an intx). >>> So I think we've always had a bit of a type mismatch here. >>> >>> I'm not sure what to do about this one yet, but adding a cast doesn't seem >> like the right solution to me. >> >> I would suggest changing CMSMaxAbortablePrecleanTime to a double. It >> may >> not be the cleanest way to handle the flag but having it as an intx is >> also not very clean. Negative values won't make sense. Changing it to a >> double won't make the situation much worse than it is now and it will >> simplify the code. >> >> So, I would suggest: >> >> diff --git a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp >> b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp >> --- a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp >> +++ b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp >> @@ -2733,1 +2733,1 @@ >> - jlong wallclock_millis() { >> + double wallclock_millis() { >> diff --git a/src/share/vm/runtime/globals.hpp >> b/src/share/vm/runtime/globals.hpp >> --- a/src/share/vm/runtime/globals.hpp >> +++ b/src/share/vm/runtime/globals.hpp >> @@ -1836,1 +1836,1 @@ >> - product(intx, CMSMaxAbortablePrecleanTime, >> 5000, \ >> + product(double, CMSMaxAbortablePrecleanTime, >> 5000, \ >> >> >>>> diff -r 73e267ddd93d src/share/vm/gc/g1/g1CollectedHeap.cpp >>>> --- a/src/share/vm/gc/g1/g1CollectedHeap.cpp Wed Nov 18 11:31:59 >> 2015 +0100 >>>> +++ b/src/share/vm/gc/g1/g1CollectedHeap.cpp Fri Dec 11 11:42:52 2015 >> +0100 >>>> @@ -3621,7 +3621,7 @@ >>>> log_info(gc)("To-space exhausted"); >>>> } >>>> >>>> - double pause_time_sec = >> TimeHelper::counter_to_seconds(pause_time_counter); >>>> + double pause_time_sec = >> TimeHelper::counter_to_seconds((jlong)pause_time_counter); >>>> g1_policy()->print_phases(pause_time_sec); >>>> >>>> g1_policy()->print_detailed_heap_transition(); >>> Adding a cast is not the proper fix here. >>> >>> The problem is that log_gc_footer's double pause_time_counter argument >> ought to itself be a jlong. >>> The caller (do_collection_pause_at_safepoint) contains >>> >>> double pause_start_counter = os::elapsed_counter(); >>> ... >>> log_gc_footer(os::elapsed_counter() - pause_start_counter); >>> >>> elapsed_counter returns a jlong. So pause_start_counter ought to be a >> jlong too, and fixing the >>> parameter type for log_gc_footer would then make everything work out. >>> >>> This appears to be a mistake introduced by the recently pushed 8145092: >> Use Unified Logging for the GC logging. >> Yes, this is a mistake in the push for the unified logging work. I >> created a patch and sent out a new review request to fix it. >> >> RFR: JDK-8145303: Clean up the units for log_gc_footer >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015- >> December/015903.html >> >> http://cr.openjdk.java.net/~brutisso/8145303/webrev.00/ >> >> Thanks, >> Bengt From thomas.schatzl at oracle.com Mon Dec 14 12:36:24 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 14 Dec 2015 13:36:24 +0100 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <566EB027.2010403@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDDF76@DEWDFEMB12A.global.corp.sap> <77BA861E-BEF9-4E61-B46E-84E4612B72E3@oracle.com> <566E8F56.1020400@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDE79B@DEWDFEMB12A.global.corp.sap> <566EB027.2010403@oracle.com> Message-ID: <1450096584.2316.14.camel@oracle.com> Hi, On Mon, 2015-12-14 at 13:03 +0100, Bengt Rutisson wrote: > Hi Goetz, > > On 2015-12-14 12:19, Lindenmaier, Goetz wrote: > > Hi, > > > > I removed the change to g1CollectedHeap.cpp > > ("8145303: Clean up the units for log_gc_footer" will fix this) > > and changed the flag to 'double'. New webrev: > > http://cr.openjdk.java.net/~goetz/webrevs/8143215-gcc412/webrev.05/ > > This looks good to me, but I haven't been following this thread closely > so it would be good if Kim and Thomas take a look too. > - I would prefer to keep CMSMaxAbortablePrecleanTime an integer value (uintx/size_t) and then just cast for now. If we keep it a double, it is imo a good idea to keep its max range to max_intx anyway. Using MAX_DOUBLE will just cause grief for no gain. One option would be to change the return value of CMSPhaseAccounting::wallclock_millis() to an integer value (size_t?), make CMSMaxAbortablePrecleanTime a size_t too, and cast in that method. I do not see a problem with slight comparison result differences due to truncating the double. Kim might have some other preference. - in G1AdaptiveIHOPControl::get_conc_mark_start_threshold(), the comment for the calculation of predicted_needed_bytes_during_marking should be moved back closer to _last_unrestrained_young. Maybe something like size_t predicted_needed_bytes_during_marking = pred_promotion_size + // comment here _last_unrestrained_young_size; The second cast in that same method could be avoided by making _initial_ihop_percent an integer value. I am okay with the current way too though. Thanks, Thomas From thomas.schatzl at oracle.com Mon Dec 14 14:48:06 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 14 Dec 2015 15:48:06 +0100 Subject: [PATCH] enhancement to ParallelScavenge Full GC In-Reply-To: References: Message-ID: <1450104486.2316.46.camel@oracle.com> Hi Tianyang, On Mon, 2015-12-14 at 15:55 +0800, ray alex wrote: > Hi all, > > Can I have reviews for the following enhancement? > Thanks for contributing :) Here is a quick review. Note that I am typically not working on Parallel GC, so I am not very proficient in this code and did not take the time to look into it in more detail yet. Also, I did not do any performance testing, so I am mostly criticizing coding style :) - please remove obvious debug code, like most of the code in psParallelCompact.cpp. Also, for whatever reason the TraceTime constructor gets passed a print_phases() method that does not exist. - I am not sure why the VM thread needs to have the cached live-words-in-range information. For that matter, I think that putting new members into the Thread class is a no-go because these members are only used by the GC threads, penalizing everyone else. I think the correct way of putting GC task thread specific data is adding these members to the GCTaskThread class. Since for worker threads Thread::current() is a GCTaskThread(), you can still use it to retrieve the values (and add a Thread::as_gctask_thread() method like as_worker_thread() to retrieve it). Also, please create appropriate getters and/or setters for the variables, taking into account below comments. - in the new ParMarkBitMap::live_words_in_range() method, please do not use l-value references. Hotspot code does not use them, and it does not seem worth to change this "do as the surrounding code does" rule. Following comments are for ParMarkBitMap::live_words_in_range(): - I do not see a point in opening extra scopes for straight-line code (like in parMarkBitMap.cpp:161) - the second part of the new live_words_in_range() looks like a verbatim copy of (the now) live_words_in_range_helper(). Please refactor the code appropriately. E.g. I would prefer if the code looked like the following (actual naming up to debate, I think you will find better names): live_words_in_range() { if (live_words_in_range_in_cache()) { return cached-values(); } return live_words_in_range_helper(); } or something similar. That would be a lot better to read and maintain instead of the copy&paste. - use of uint64_t for casting addresses/comparisons is wrong and just unnecessary type conversion on 32 bit. The type the language provides for this purpose is (u)intptr_t. Also, you probably want to use the pointer_delta function to calculate pointer deltas without overflow. > Description: > The change addresses the inefficiency in the live_words_in_range() > routine in ParallelScavenge Full GC, > which generally costs most of the time during the compacting phase. > >Our idea records last query information of live_words_in_range as well >as the query result. > Our approach reuses last query result so that can reduce much > computation of bitmap searching. :) > > Patch: as attached. > > Testing: > Manual testing of full GC intensive applications including JOlden, > Dacapo, SPECjvm2008 benchmarks. > > Results show that our enhancement can reduce much full GC time by > 20~50%, depending on application scenarios. I am not sure if JOlden (benchmark from '95), or Dacapo (from '09) is representative of today's workloads (or specjvm2008), but the idea sounds timeless :) I will run (a slightly modified version, see pointer_delta() comment above) through some basic testing, and then some benchmarks. > Lei Tianyang > Institute of Parallel and Distributed System (IPADS) > Shanghai Jiao Tong University Another procedural comment, you do not seem to have signed an Oracle's Contributor agreement. We need that to be able to take your patch, unless you are covered by some companies' OCA (but then we would need you to use an email address from that company I think). Please see http://www.oracle.com/technetwork/community/oca-486395.html#l for more information. Thanks, Thomas > From thomas.schatzl at oracle.com Mon Dec 14 14:49:29 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 14 Dec 2015 15:49:29 +0100 Subject: [PATCH] enhancement to ParallelScavenge Full GC In-Reply-To: <1450104486.2316.46.camel@oracle.com> References: <1450104486.2316.46.camel@oracle.com> Message-ID: <1450104569.2316.47.camel@oracle.com> Hi again, I filed https://bugs.openjdk.java.net/browse/JDK-8145318 for work on it. Thanks, Thomas On Mon, 2015-12-14 at 15:48 +0100, Thomas Schatzl wrote: > Hi Tianyang, > > On Mon, 2015-12-14 at 15:55 +0800, ray alex wrote: > > Hi all, > > > > Can I have reviews for the following enhancement? > > > > Thanks for contributing :) Here is a quick review. > > Note that I am typically not working on Parallel GC, so I am not very > proficient in this code and did not take the time to look into it in > more detail yet. Also, I did not do any performance testing, so I am > mostly criticizing coding style :) > > - please remove obvious debug code, like most of the code in > psParallelCompact.cpp. Also, for whatever reason the TraceTime > constructor gets passed a print_phases() method that does not exist. > > - I am not sure why the VM thread needs to have the cached > live-words-in-range information. For that matter, I think that putting > new members into the Thread class is a no-go because these members are > only used by the GC threads, penalizing everyone else. I think the > correct way of putting GC task thread specific data is adding these > members to the GCTaskThread class. > > Since for worker threads Thread::current() is a GCTaskThread(), you can > still use it to retrieve the values (and add a > Thread::as_gctask_thread() method like as_worker_thread() to retrieve > it). > > Also, please create appropriate getters and/or setters for the > variables, taking into account below comments. > > - in the new ParMarkBitMap::live_words_in_range() method, please do not > use l-value references. Hotspot code does not use them, and it does not > seem worth to change this "do as the surrounding code does" rule. > > Following comments are for ParMarkBitMap::live_words_in_range(): > > - I do not see a point in opening extra scopes for straight-line code > (like in parMarkBitMap.cpp:161) > > - the second part of the new live_words_in_range() looks like a verbatim > copy of (the now) live_words_in_range_helper(). Please refactor the code > appropriately. > > E.g. I would prefer if the code looked like the following (actual naming > up to debate, I think you will find better names): > > live_words_in_range() { > if (live_words_in_range_in_cache()) { > return cached-values(); > } > return live_words_in_range_helper(); > } > > or something similar. That would be a lot better to read and maintain > instead of the copy&paste. > > - use of uint64_t for casting addresses/comparisons is wrong and just > unnecessary type conversion on 32 bit. The type the language provides > for this purpose is (u)intptr_t. > > Also, you probably want to use the pointer_delta function to calculate > pointer deltas without overflow. > > > Description: > > The change addresses the inefficiency in the live_words_in_range() > > routine in ParallelScavenge Full GC, > > which generally costs most of the time during the compacting phase. > > > >Our idea records last query information of live_words_in_range as well > >as the query result. > > Our approach reuses last query result so that can reduce much > > computation of bitmap searching. > > :) > > > > > Patch: as attached. > > > > Testing: > > Manual testing of full GC intensive applications including JOlden, > > Dacapo, SPECjvm2008 benchmarks. > > > > Results show that our enhancement can reduce much full GC time by > > 20~50%, depending on application scenarios. > > I am not sure if JOlden (benchmark from '95), or Dacapo (from '09) is > representative of today's workloads (or specjvm2008), but the idea > sounds timeless :) > > I will run (a slightly modified version, see pointer_delta() comment > above) through some basic testing, and then some benchmarks. > > > Lei Tianyang > > Institute of Parallel and Distributed System (IPADS) > > Shanghai Jiao Tong University > > Another procedural comment, you do not seem to have signed an Oracle's > Contributor agreement. We need that to be able to take your patch, > unless you are covered by some companies' OCA (but then we would need > you to use an email address from that company I think). > > Please see http://www.oracle.com/technetwork/community/oca-486395.html#l > for more information. > > Thanks, > Thomas > > > > > From sky1young at gmail.com Mon Dec 14 15:57:43 2015 From: sky1young at gmail.com (ray alex) Date: Mon, 14 Dec 2015 23:57:43 +0800 Subject: [PATCH] enhancement to ParallelScavenge Full GC In-Reply-To: <1450104486.2316.46.camel@oracle.com> References: <1450104486.2316.46.camel@oracle.com> Message-ID: Thanks, Thomas! I will refine my code carefully according to your suggestions as soon as possible. Since I'm new in contributing to OpenJDK, actually I'm not sure how to upload when my new code is ready? Just upload an attach of diffs as I did, or some other ways? Besides, I'm currently processing my signed OCA for the committer rights, I'm not sure how long it will take, does it matter? As for the VM Thread, it does a serial adjust_roots() within the current thread (VM thread) during PSParallelCompact::invoke_no_policy(). I think psCompactionManager.cpp:117 and the surrounding comments confirm the use of VMThread in full GC. Do you agree with my above understanding of the use of VMThread? Sincerely, Tianyang 2015-12-14 22:48 GMT+08:00 Thomas Schatzl : > Hi Tianyang, > > On Mon, 2015-12-14 at 15:55 +0800, ray alex wrote: > > Hi all, > > > > Can I have reviews for the following enhancement? > > > > Thanks for contributing :) Here is a quick review. > > Note that I am typically not working on Parallel GC, so I am not very > proficient in this code and did not take the time to look into it in > more detail yet. Also, I did not do any performance testing, so I am > mostly criticizing coding style :) > > - please remove obvious debug code, like most of the code in > psParallelCompact.cpp. Also, for whatever reason the TraceTime > constructor gets passed a print_phases() method that does not exist. > > - I am not sure why the VM thread needs to have the cached > live-words-in-range information. For that matter, I think that putting > new members into the Thread class is a no-go because these members are > only used by the GC threads, penalizing everyone else. I think the > correct way of putting GC task thread specific data is adding these > members to the GCTaskThread class. > > Since for worker threads Thread::current() is a GCTaskThread(), you can > still use it to retrieve the values (and add a > Thread::as_gctask_thread() method like as_worker_thread() to retrieve > it). > > Also, please create appropriate getters and/or setters for the > variables, taking into account below comments. > > - in the new ParMarkBitMap::live_words_in_range() method, please do not > use l-value references. Hotspot code does not use them, and it does not > seem worth to change this "do as the surrounding code does" rule. > > Following comments are for ParMarkBitMap::live_words_in_range(): > > - I do not see a point in opening extra scopes for straight-line code > (like in parMarkBitMap.cpp:161) > > - the second part of the new live_words_in_range() looks like a verbatim > copy of (the now) live_words_in_range_helper(). Please refactor the code > appropriately. > > E.g. I would prefer if the code looked like the following (actual naming > up to debate, I think you will find better names): > > live_words_in_range() { > if (live_words_in_range_in_cache()) { > return cached-values(); > } > return live_words_in_range_helper(); > } > > or something similar. That would be a lot better to read and maintain > instead of the copy&paste. > > - use of uint64_t for casting addresses/comparisons is wrong and just > unnecessary type conversion on 32 bit. The type the language provides > for this purpose is (u)intptr_t. > > Also, you probably want to use the pointer_delta function to calculate > pointer deltas without overflow. > > > Description: > > The change addresses the inefficiency in the live_words_in_range() > > routine in ParallelScavenge Full GC, > > which generally costs most of the time during the compacting phase. > > > >Our idea records last query information of live_words_in_range as well > >as the query result. > > Our approach reuses last query result so that can reduce much > > computation of bitmap searching. > > :) > > > > > Patch: as attached. > > > > Testing: > > Manual testing of full GC intensive applications including JOlden, > > Dacapo, SPECjvm2008 benchmarks. > > > > Results show that our enhancement can reduce much full GC time by > > 20~50%, depending on application scenarios. > > I am not sure if JOlden (benchmark from '95), or Dacapo (from '09) is > representative of today's workloads (or specjvm2008), but the idea > sounds timeless :) > > I will run (a slightly modified version, see pointer_delta() comment > above) through some basic testing, and then some benchmarks. > > > Lei Tianyang > > Institute of Parallel and Distributed System (IPADS) > > Shanghai Jiao Tong University > > Another procedural comment, you do not seem to have signed an Oracle's > Contributor agreement. We need that to be able to take your patch, > unless you are covered by some companies' OCA (but then we would need > you to use an email address from that company I think). > > Please see http://www.oracle.com/technetwork/community/oca-486395.html#l > for more information. > > Thanks, > Thomas > > > > > > -- Lei Tianyang -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Mon Dec 14 16:49:46 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 14 Dec 2015 17:49:46 +0100 Subject: [PATCH] enhancement to ParallelScavenge Full GC In-Reply-To: References: <1450104486.2316.46.camel@oracle.com> Message-ID: <1450111786.11162.34.camel@oracle.com> Hi, On Mon, 2015-12-14 at 23:57 +0800, ray alex wrote: > Thanks, Thomas! > > I will refine my code carefully according to your suggestions as soon > as possible. Thanks. > > Since I'm new in contributing to OpenJDK, actually I'm not sure how to > upload when my new code is ready? > Just upload an attach of diffs as I did, or some other ways? The best way as long as we have no confirmation about the OCA signing, is to attach a patch (or a webrev, see http://openjdk.java.net/contribute/) and send it to this list. Later it will be more convenient to send me a patch that I will convert into a webrev and put on cr.openjdk.java.net. As soon as you have two contributions, you can upload patches yourselves onto your own account on cr.openjdk.java.net. > > Besides, I'm currently processing my signed OCA for the committer > rights, > I'm not sure how long it will take, does it matter? The OCA is only for us to be able to accept your patch in Hotspot. The various levels of contributor status are a different matter, and signify your level of expertise within the community. See also http://openjdk.java.net/contribute/ for more information. > As for the VM Thread, it does a serial adjust_roots() within the > current thread (VM thread) during > PSParallelCompact::invoke_no_policy(). > I think psCompactionManager.cpp:117 and the surrounding comments > confirm the use of VMThread in full GC. > Do you agree with my above understanding of the use of VMThread? > You are right :( There are multiple options to provide an additional per-thread context: - passing around some context. Looks like lots of work. - change the code so that even that serial portion is performed by some GCTaskThread (which actually sounds best to me) - Another would be to add a field to both GCTaskThread and VMThread, and via a virtual method in Thread get the necessary values. - make VMThread a WorkerThread (that has an id that can be used to query an extra data structure for this cache) - others Let's see if other people have a better idea. Thanks, Thomas From alexander.harlap at oracle.com Mon Dec 14 19:39:06 2015 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Mon, 14 Dec 2015 14:39:06 -0500 Subject: Request for code review - 8145037 Clean up FreeIdSet usage Message-ID: <566F1ADA.30608@oracle.com> JDK-8145037 - Clean up FreeIdSet usage Proposed change: http://cr.openjdk.java.net/~aharlap/8145037/webrev.00/ Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Mon Dec 14 20:02:58 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 14 Dec 2015 15:02:58 -0500 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <566E8F56.1020400@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDDF76@DEWDFEMB12A.global.corp.sap> <77BA861E-BEF9-4E61-B46E-84E4612B72E3@oracle.com> <566E8F56.1020400@oracle.com> Message-ID: <308DDB4A-38AD-41FC-B4BA-850006F760A2@oracle.com> On Dec 14, 2015, at 4:43 AM, Bengt Rutisson wrote: > > > Hi Kim and Goetz, > > On 2015-12-13 00:02, Kim Barrett wrote: >> On Dec 11, 2015, at 5:52 AM, Lindenmaier, Goetz wrote: >>> diff -r 73e267ddd93d src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp >>> --- a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Wed Nov 18 11:31:59 2015 +0100 >>> +++ b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Fri Dec 11 11:42:52 2015 +0100 >>> @@ -2731,7 +2731,7 @@ >>> // Not MT-safe; so do not pass around these StackObj's >>> // where they may be accessed by other threads. >>> jlong wallclock_millis() { >>> - return TimeHelper::counter_to_millis(os::elapsed_counter() - _trace_time.start_time()); >>> + return (jlong)TimeHelper::counter_to_millis(os::elapsed_counter() - _trace_time.start_time()); >>> } >>> }; >> This conversion was introduced by the recently pushed 8145092: Use Unified Logging for the GC logging. >> >> The only caller of wallclock_millis compares the result with CMSMaxAbortablePrecleanTime (an intx). >> >> So I think we?ve always had a bit of a type mismatch here. >> >> I?m not sure what to do about this one yet, but adding a cast doesn?t seem like the right solution to me. > > I would suggest changing CMSMaxAbortablePrecleanTime to a double. It may not be the cleanest way to handle the flag but having it as an intx is also not very clean. Negative values won't make sense. Changing it to a double won't make the situation much worse than it is now and it will simplify the code. Unfortunately, the syntax for floating point options requires the decimal point and fraction part; integer syntax is rejected. So existing uses of that option would be broken by changing its type. CMSMaxAbortablePrecleanTime is a product option, making it not so easy to make such a change. >>> diff -r 73e267ddd93d src/share/vm/gc/g1/g1CollectedHeap.cpp >>> --- a/src/share/vm/gc/g1/g1CollectedHeap.cpp Wed Nov 18 11:31:59 2015 +0100 >>> +++ b/src/share/vm/gc/g1/g1CollectedHeap.cpp Fri Dec 11 11:42:52 2015 +0100 >>> @@ -3621,7 +3621,7 @@ >>> log_info(gc)("To-space exhausted"); >>> } >>> >>> - double pause_time_sec = TimeHelper::counter_to_seconds(pause_time_counter); >>> + double pause_time_sec = TimeHelper::counter_to_seconds((jlong)pause_time_counter); >>> g1_policy()->print_phases(pause_time_sec); >>> >>> g1_policy()->print_detailed_heap_transition(); >> Adding a cast is not the proper fix here. >> >> The problem is that log_gc_footer?s double pause_time_counter argument ought to itself be a jlong. >> The caller (do_collection_pause_at_safepoint) contains >> >> double pause_start_counter = os::elapsed_counter(); >> ? >> log_gc_footer(os::elapsed_counter() - pause_start_counter); >> >> elapsed_counter returns a jlong. So pause_start_counter ought to be a jlong too, and fixing the >> parameter type for log_gc_footer would then make everything work out. >> >> This appears to be a mistake introduced by the recently pushed 8145092: Use Unified Logging for the GC logging. >> > > Yes, this is a mistake in the push for the unified logging work. I created a patch and sent out a new review request to fix it. > > RFR: JDK-8145303: Clean up the units for log_gc_footer > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-December/015903.html > > http://cr.openjdk.java.net/~brutisso/8145303/webrev.00/ Thanks for taking care of this. From kim.barrett at oracle.com Mon Dec 14 20:35:19 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 14 Dec 2015 15:35:19 -0500 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <1450096584.2316.14.camel@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDDF76@DEWDFEMB12A.global.corp.sap> <77BA861E-BEF9-4E61-B46E-84E4612B72E3@oracle.com> <566E8F56.1020400@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDE79B@DEWDFEMB12A.global.corp.sap> <566EB027.2010403@oracle.com> <1450096584.2316.14.camel@oracle.com> Message-ID: <2B1E7A10-0698-4CF5-92A6-3935BAADAFF5@oracle.com> On Dec 14, 2015, at 7:36 AM, Thomas Schatzl wrote: > > Hi, > > On Mon, 2015-12-14 at 13:03 +0100, Bengt Rutisson wrote: >> Hi Goetz, >> >> On 2015-12-14 12:19, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I removed the change to g1CollectedHeap.cpp >>> ("8145303: Clean up the units for log_gc_footer" will fix this) >>> and changed the flag to 'double'. New webrev: >>> http://cr.openjdk.java.net/~goetz/webrevs/8143215-gcc412/webrev.05/ >> >> This looks good to me, but I haven't been following this thread closely >> so it would be good if Kim and Thomas take a look too. >> > > - I would prefer to keep CMSMaxAbortablePrecleanTime an integer value > (uintx/size_t) and then just cast for now. If we keep it a double, it is > imo a good idea to keep its max range to max_intx anyway. Using > MAX_DOUBLE will just cause grief for no gain. > > One option would be to change the return value of > CMSPhaseAccounting::wallclock_millis() to an integer value (size_t?), > make CMSMaxAbortablePrecleanTime a size_t too, and cast in that method. > I do not see a problem with slight comparison result differences due to > truncating the double. > > Kim might have some other preference. I *think* the simplest change is to make the return type for wallclock_millis be double. Then it matches type of the value it obtains from TimeHelper::counter_to_millis. This will lead to a comparison between that double value and the integral CMSMaxAbortablePrecleanTime, but that shouldn't be a problem. Aside: I wish we had a decent framework for time value manipulation, rather than various combinations of counters, seconds, millis (and maybe others?) represented by doubles or various integer types. The C++11 facilities would be nice to have. From kim.barrett at oracle.com Mon Dec 14 22:38:56 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 14 Dec 2015 17:38:56 -0500 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <2B1E7A10-0698-4CF5-92A6-3935BAADAFF5@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDDF76@DEWDFEMB12A.global.corp.sap> <77BA861E-BEF9-4E61-B46E-84E4612B72E3@oracle.com> <566E8F56.1020400@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDE79B@DEWDFEMB12A.global.corp.sap> <566EB027.2010403@oracle.com> <1450096584.2316.14.camel@oracle.com> <2B1E7A10-0698-4CF5-92A6-3935BAADAFF5@oracle.com> Message-ID: On Dec 14, 2015, at 3:35 PM, Kim Barrett wrote: > >>> On 2015-12-14 12:19, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I removed the change to g1CollectedHeap.cpp >>>> ("8145303: Clean up the units for log_gc_footer" will fix this) >>>> and changed the flag to 'double'. New webrev: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8143215-gcc412/webrev.05/ > > I *think* the simplest change is to make the return type for > wallclock_millis be double. Then it matches type of the value it > obtains from TimeHelper::counter_to_millis. This will lead to a > comparison between that double value and the integral > CMSMaxAbortablePrecleanTime, but that shouldn't be a problem. To be specific, webrev.05 looks good to me if the change to the type of CMSMaxAbortablePrecleanTime is backed out. From kim.barrett at oracle.com Tue Dec 15 01:31:58 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 14 Dec 2015 20:31:58 -0500 Subject: Request for code review - 8145037 Clean up FreeIdSet usage In-Reply-To: <566F1ADA.30608@oracle.com> References: <566F1ADA.30608@oracle.com> Message-ID: <0257E2D1-B0CF-45AC-8A94-F9BF5C89BB8C@oracle.com> On Dec 14, 2015, at 2:39 PM, Alexander Harlap wrote: > > JDK-8145037 - Clean up FreeIdSet usage > > Proposed change: > > http://cr.openjdk.java.net/~aharlap/8145037/webrev.00/ > > Alex "JDK-8145037 - Clean up FreeIdSet usage? is a different problem. This is a fix for https://bugs.openjdk.java.net/browse/JDK-8145038 "Simplify mut_process_buffer worker id management?. I think it?s a good fix for that. From sangheon.kim at oracle.com Tue Dec 15 06:27:06 2015 From: sangheon.kim at oracle.com (sangheon) Date: Mon, 14 Dec 2015 22:27:06 -0800 Subject: RFR (M): JDK-8068394: Trace event for concurrent GC phases In-Reply-To: <565FF761.30200@oracle.com> References: <56282271.5090108@oracle.com> <56546233.20006@oracle.com> <5654B10E.1060701@oracle.com> <565EB318.8060607@oracle.com> <565F33A8.6060608@oracle.com> <565FF761.30200@oracle.com> Message-ID: <566FB2BA.5020408@oracle.com> Hi Bengt and all, Here's a next webrev. Bengt and I had a discussion on other thread and he and Stefan Karlsson suggested simpler design. http://cr.openjdk.java.net/~sangheki/8068394/webrev.01 http://cr.openjdk.java.net/~sangheki/8068394/webrev.01_to_00 This webrev includes: 1. Moving concurrent phase measurement into CMSPhaseAccounting class. So we can check all concurrent phases from CMS. 2. Renamed a new flag introduced from webrev.00 for general use, _concurrent_phase_started. 3. Added helper class for concurrent phase measurement, GCConcPhaseTimer. And used this class for all concurrent phases. 4. Flag checking is moved from G1CollectedHeap::register_concurrent_cycle_end() to ConcurrentMark::abort(). 5. Changed switch() to if else statement at gcTraceSend. Many thanks to Bengt and Stefan Karlsson for the discussion. Thanks, Sangheon On 12/03/2015 12:03 AM, Bengt Rutisson wrote: > > Hi Sangheon, > > This all sounds good. Looking forward to the next webrev. > > Thanks, > Bengt > > On 2015-12-02 19:08, sangheon.kim wrote: >> Hi Bengt, >> >> >> On 12/02/2015 01:00 AM, Bengt Rutisson wrote: >>> >>> Hi Sangheon, >>> >>> Sorry again for the late reply. Comments inline. >> No not at all. >> Thank you for taking time for this review! >> >>> >>> On 2015-11-24 19:48, sangheon.kim wrote: >>>> Hi Bengt, >>>> >>>> Thank you so much for reviewing this patch! >>>> >>>> On 11/24/2015 05:12 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi Sangheon, >>>>> >>>>> Sorry for the very late reply to this review request. >>>>> >>>>> On 2015-10-22 01:40, sangheon.kim wrote: >>>>>> Hi all, >>>>>> >>>>>> Can I get some reviews for this change of adding a trace event >>>>>> for concurrent phases on CMS and G1? >>>>>> >>>>>> Currently we only measure pause times for major phases. >>>>>> But I want to add 'concurrent mark' and 'concurrent sweep' phases >>>>>> for CMS and 'concurrent mark' phase for G1. >>>>>> To achieve this, I had to change ConcurrentGCTimer and related >>>>>> classes. >>>>>> >>>>>> This patch includes: >>>>>> 1) A concurrent phase can be measured only from ConcurrentGCTimer >>>>>> and measuring an overlap between concurrent and pause is not >>>>>> allowed as currently we don't have that use case. And >>>>>> TimePartitions class(or related classes) will be simpler than an >>>>>> overlap allowed case. >>>>>> 2) I removed PausePhase and ConcurrentPhase which are derived >>>>>> from GCPhase because I wanted to avoid heap allocation when >>>>>> adding to GrowableArray. Instead introduced 'type' member >>>>>> variable at GCPhase. >>>>>> >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8068394 >>>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8068394/webrev.00/ >>>>> >>>>> Nice work! It is great to get some timing information for the >>>>> concurrent phases. >>>> Thanks! >>>> >>>>> >>>>> A few questions/comments: >>>>> >>>>> CMS. >>>>> >>>>> You have added timing events for the concurrent phases mark and >>>>> sweep, but not for other concurrent phases (preclean, >>>>> abortable_preclean and reset_concurrent). I think that if you >>>>> moved your calls to _gc_timer_cm->register_gc_concurrent_start() >>>>> and _gc_timer_cm->register_gc_concurrent_end() into the >>>>> constructor and destructor of CMSPhaseAccounting you would >>>>> automatically get timing events for all concurrent phases. >>>> I also considered about this idea but I was not clear whether it is >>>> good measurement especially for 'sweep'. >>>> We are using CMSPhaseAccounting for 5 cases. >>>> I think for 'mark' and 'preclean' they are okay. (there are >>>> non-product functions call before CMSPhaseAccounting. But they are >>>> okay). >>>> For 'abortable-preclean' and 'reset', they are good to have that. >>>> But when it comes to 'sweep', there are timer and >>>> CMSTokenSyncWithLocks related codes and I was not sure about these. >>>> If you think they are also okay, I will change as you suggested. >>> >>> I think it is fine for the sweep part as well. If the >>> CMSPhaseAccounting instance is not measuring the correct part of the >>> work I think we should change it to measure what we want. That way >>> we improve the existing measurements too. >>> >>> But as you stated in your follow up email, I think the sweep code is >>> actually pretty much ok from this perspective. >>> >>> So, I would prefer to go with the CMSPhaseAccounting approach. >> Okay, I already changed as you suggested. :) >> >>> >>> >>>> >>>>> >>>>> >>>>> G1. >>>>> >>>>> I think the use of _concurrent_marking_from_roots is unfortunate. >>>>> It would be much cleaner if >>>>> ConcurrentMark::register_mark_from_roots_phase_end() called >>>>> register_gc_concurrent_end() directly. >>>> I wanted to avoid introducing the new flag but the reason of it >>>> was, as you know, to handle 'abort'. >>>> When 'abort' happens we do need to end all timers before calling >>>> 'GCTracer::report_gc_end()'. >>>> And at this point we need a way to know whether concurrent timer is >>>> started or not. >>> >>> As I tried to describe I think you can extend the scope of the >>> timing to cover the part until the marking thread discovers that the >>> marking was aborted. Basically moving the timing in to >>> ConcurrentMarkThread::run_service(). >> Oh, I mis-understood your point. Sorry. >> I will try your recommendation. >> >>> >>>> >>>>> I realize that this would change the timing for when a concurrent >>>>> marking is aborted. The whole time for a full GC (or even several >>>>> full GCs) would be included in the concurrent marking phase. But >>>>> from a code perspective that is what happens, so maybe that is the >>>>> correct time to report? Also, I think the logging is reported that >>>>> way so if we want to make it easy to match the timing events with >>>>> the logging we might want to use about the same scope for timing. >>>>> >>>>> Why do we only measure the concurrent mark phase for G1? >>>> This is good question. :) >>>> I was comparing CMS and G1 for major concurrent phases. >>>> And the candidates were 'concurrent mark/sweep (CMS)' and >>>> 'concurrent mark(G1)'. >>>> >>>>> Wouldn't it be good to measure all concurrent phases? >>>> Okay, Stefan Karlsson also pointed to have them as well so I filed >>>> a separate CR for this. >>>> https://bugs.openjdk.java.net/browse/JDK-8143951 >>> >>> Ok. Is there a reason why we want to split this up into two changes? >>> Why not add all the concurrent timing events at once? >>> >>> I'm ok with splitting it up into two changes, but then maybe the >>> title for JDK-8068394 should be changed to indicate that it only >>> adds events for the marking phase. Also, if we go with the >>> CMSPhaseAccounting approach for CMS, you get events for all phases >>> there. So, it will be a bit odd to have all concurrent phases >>> handled for CMS but only concurrent mark for G1. >> You are correct and I agree with you. >> The only reason of split was due to limited time for FC. >> But as we have enough time, let me close JDK-8143951 and include >> concurrent mark for G1 as well. >> >>> >>>> >>>>> >>>>> gcTraceSend.cpp >>>>> >>>>> 389 void visit(GCPhase* phase) { >>>>> 390 switch (phase->type()) { >>>>> 391 case GCPhase::PausePhaseType: >>>>> 392 assert(phase->level() < PhasesStack::PHASE_LEVELS, >>>>> "Need more event types for PausePhase"); >>>>> 393 >>>>> 394 switch (phase->level()) { >>>>> 395 case 0: send_phase(phase); break; >>>>> 396 case 1: send_phase(phase); >>>>> break; >>>>> 397 case 2: send_phase(phase); >>>>> break; >>>>> 398 case 3: send_phase(phase); >>>>> break; >>>>> 399 default: /* Ignore sending this phase */ break; >>>>> 400 } >>>>> 401 break; >>>>> 402 >>>>> 403 case GCPhase::ConcurrentPhaseType: >>>>> 404 assert(phase->level() < 1, "There's only one level >>>>> for ConcurrentPhase"); >>>>> 405 >>>>> 406 switch (phase->level()) { >>>>> 407 case 0: send_phase(phase); >>>>> break; >>>>> 408 default: /* Ignore sending this phase */ break; >>>>> 409 } >>>>> 410 break; >>>>> 411 } >>>>> 412 } >>>>> 413 }; >>>>> >>>>> Since there are only two values for GCPhase::PhaseType it seems a >>>>> bit odd to use a switch statement. I think I would prefer to >>>>> factor out the code for the different types a bit too. So, maybe >>>>> something like: >>>>> >>>>> void visit(GCPhase* phase) { >>>>> if (phase->type() == GCPhase::PausePhaseType) { >>>>> visit_pause(phase); >>>>> } else { >>>>> assert(phase->type() == GCPhase::ConcurrentPhaseType, ""); >>>>> visit_concurrent(phase); >>>>> } >>>>> } >>>> This seems better. I will fix. >>> >>> Good. Thanks! >> :) >> >> I will post next webrev when I'm ready, including JDK-8143951 part as >> well. >> >> Thanks, >> Sangheon >> >> >>> >>> Bengt >>> >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>>> Testing: JPRT >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>> >>>> >>> >> > From goetz.lindenmaier at sap.com Tue Dec 15 08:35:07 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 15 Dec 2015 08:35:07 +0000 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDDF76@DEWDFEMB12A.global.corp.sap> <77BA861E-BEF9-4E61-B46E-84E4612B72E3@oracle.com> <566E8F56.1020400@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDE79B@DEWDFEMB12A.global.corp.sap> <566EB027.2010403@oracle.com> <1450096584.2316.14.camel@oracle.com> <2B1E7A10-0698-4CF5-92A6-3935BAADAFF5@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EDEC1F@DEWDFEMB12A.global.corp.sap> Hi Kim, I removed the change to the flag: http://cr.openjdk.java.net/~goetz/webrevs/8143215-gcc412/webrev.06 I also moved the comment as Thomas asked for. Would you sponsor this? Thanks, Goetz. > -----Original Message----- > From: Kim Barrett [mailto:kim.barrett at oracle.com] > Sent: Montag, 14. Dezember 2015 23:39 > To: Lindenmaier, Goetz > Cc: Thomas Schatzl ; Bengt Rutisson > ; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. > > On Dec 14, 2015, at 3:35 PM, Kim Barrett wrote: > > > >>> On 2015-12-14 12:19, Lindenmaier, Goetz wrote: > >>>> Hi, > >>>> > >>>> I removed the change to g1CollectedHeap.cpp > >>>> ("8145303: Clean up the units for log_gc_footer" will fix this) > >>>> and changed the flag to 'double'. New webrev: > >>>> http://cr.openjdk.java.net/~goetz/webrevs/8143215- > gcc412/webrev.05/ > > > > I *think* the simplest change is to make the return type for > > wallclock_millis be double. Then it matches type of the value it > > obtains from TimeHelper::counter_to_millis. This will lead to a > > comparison between that double value and the integral > > CMSMaxAbortablePrecleanTime, but that shouldn't be a problem. > > To be specific, webrev.05 looks good to me if the change to the type of > CMSMaxAbortablePrecleanTime is backed out. From stefan.karlsson at oracle.com Tue Dec 15 08:58:31 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 15 Dec 2015 09:58:31 +0100 Subject: RFR (M): JDK-8068394: Trace event for concurrent GC phases In-Reply-To: <566FB2BA.5020408@oracle.com> References: <56282271.5090108@oracle.com> <56546233.20006@oracle.com> <5654B10E.1060701@oracle.com> <565EB318.8060607@oracle.com> <565F33A8.6060608@oracle.com> <565FF761.30200@oracle.com> <566FB2BA.5020408@oracle.com> Message-ID: <566FD637.4060909@oracle.com> Hi Sangheon, On 2015-12-15 07:27, sangheon wrote: > Hi Bengt and all, > > Here's a next webrev. > Bengt and I had a discussion on other thread and he and Stefan > Karlsson suggested simpler design. > > http://cr.openjdk.java.net/~sangheki/8068394/webrev.01 > http://cr.openjdk.java.net/~sangheki/8068394/webrev.01_to_00 Thanks for doing the simplifications of the patch. I have a couple of comments: Could you replace NOT_PRODUCT with DEBUG_ONLY, and #ifndef PRODUCT with #ifdef ASSERT. Otherwise, you'll get inconsistencies when building with optimized builds where neither PRODUCT nor ASSERT is defined. 81 void ConcurrentGCTimer::register_gc_concurrent_start(const char* name, const Ticks& time) { 82 assert(!_is_concurrent_phase_active, "A concurrent phase is already active."); 83 _time_partitions.report_gc_phase_start(name, time, GCPhase::ConcurrentPhaseType); 84 NOT_PRODUCT(_is_concurrent_phase_active = true;) 85 } 162 class ConcurrentGCTimer : public GCTimer { 163 // ConcurrentGCTimer can't be used if there is an overlap between a pause phase and a concurrent phase. 164 // _is_concurrent_phase_active is used to find above case. 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) 166 167 public: 168 #ifndef PRODUCT 169 ConcurrentGCTimer(): GCTimer(), _is_concurrent_phase_active(false) {}; 170 #endif Is it really worth optimizing away the boolean? The code would be cleaner without these macros. Why are you using volatile here? I don't see why that should be needed. 162 class ConcurrentGCTimer : public GCTimer { 163 // ConcurrentGCTimer can't be used if there is an overlap between a pause phase and a concurrent phase. 164 // _is_concurrent_phase_active is used to find above case. 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) Thanks, StefanK > > This webrev includes: > 1. Moving concurrent phase measurement into CMSPhaseAccounting class. > So we can check all concurrent phases from CMS. > > 2. Renamed a new flag introduced from webrev.00 for general use, > _concurrent_phase_started. > > 3. Added helper class for concurrent phase measurement, > GCConcPhaseTimer. And used this class for all concurrent phases. > > 4. Flag checking is moved from > G1CollectedHeap::register_concurrent_cycle_end() to > ConcurrentMark::abort(). > > 5. Changed switch() to if else statement at gcTraceSend. > > Many thanks to Bengt and Stefan Karlsson for the discussion. > > Thanks, > Sangheon > > > On 12/03/2015 12:03 AM, Bengt Rutisson wrote: >> >> Hi Sangheon, >> >> This all sounds good. Looking forward to the next webrev. >> >> Thanks, >> Bengt >> >> On 2015-12-02 19:08, sangheon.kim wrote: >>> Hi Bengt, >>> >>> >>> On 12/02/2015 01:00 AM, Bengt Rutisson wrote: >>>> >>>> Hi Sangheon, >>>> >>>> Sorry again for the late reply. Comments inline. >>> No not at all. >>> Thank you for taking time for this review! >>> >>>> >>>> On 2015-11-24 19:48, sangheon.kim wrote: >>>>> Hi Bengt, >>>>> >>>>> Thank you so much for reviewing this patch! >>>>> >>>>> On 11/24/2015 05:12 AM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi Sangheon, >>>>>> >>>>>> Sorry for the very late reply to this review request. >>>>>> >>>>>> On 2015-10-22 01:40, sangheon.kim wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Can I get some reviews for this change of adding a trace event >>>>>>> for concurrent phases on CMS and G1? >>>>>>> >>>>>>> Currently we only measure pause times for major phases. >>>>>>> But I want to add 'concurrent mark' and 'concurrent sweep' >>>>>>> phases for CMS and 'concurrent mark' phase for G1. >>>>>>> To achieve this, I had to change ConcurrentGCTimer and related >>>>>>> classes. >>>>>>> >>>>>>> This patch includes: >>>>>>> 1) A concurrent phase can be measured only from >>>>>>> ConcurrentGCTimer and measuring an overlap between concurrent >>>>>>> and pause is not allowed as currently we don't have that use >>>>>>> case. And TimePartitions class(or related classes) will be >>>>>>> simpler than an overlap allowed case. >>>>>>> 2) I removed PausePhase and ConcurrentPhase which are derived >>>>>>> from GCPhase because I wanted to avoid heap allocation when >>>>>>> adding to GrowableArray. Instead introduced 'type' member >>>>>>> variable at GCPhase. >>>>>>> >>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8068394 >>>>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8068394/webrev.00/ >>>>>> >>>>>> Nice work! It is great to get some timing information for the >>>>>> concurrent phases. >>>>> Thanks! >>>>> >>>>>> >>>>>> A few questions/comments: >>>>>> >>>>>> CMS. >>>>>> >>>>>> You have added timing events for the concurrent phases mark and >>>>>> sweep, but not for other concurrent phases (preclean, >>>>>> abortable_preclean and reset_concurrent). I think that if you >>>>>> moved your calls to _gc_timer_cm->register_gc_concurrent_start() >>>>>> and _gc_timer_cm->register_gc_concurrent_end() into the >>>>>> constructor and destructor of CMSPhaseAccounting you would >>>>>> automatically get timing events for all concurrent phases. >>>>> I also considered about this idea but I was not clear whether it >>>>> is good measurement especially for 'sweep'. >>>>> We are using CMSPhaseAccounting for 5 cases. >>>>> I think for 'mark' and 'preclean' they are okay. (there are >>>>> non-product functions call before CMSPhaseAccounting. But they are >>>>> okay). >>>>> For 'abortable-preclean' and 'reset', they are good to have that. >>>>> But when it comes to 'sweep', there are timer and >>>>> CMSTokenSyncWithLocks related codes and I was not sure about these. >>>>> If you think they are also okay, I will change as you suggested. >>>> >>>> I think it is fine for the sweep part as well. If the >>>> CMSPhaseAccounting instance is not measuring the correct part of >>>> the work I think we should change it to measure what we want. That >>>> way we improve the existing measurements too. >>>> >>>> But as you stated in your follow up email, I think the sweep code >>>> is actually pretty much ok from this perspective. >>>> >>>> So, I would prefer to go with the CMSPhaseAccounting approach. >>> Okay, I already changed as you suggested. :) >>> >>>> >>>> >>>>> >>>>>> >>>>>> >>>>>> G1. >>>>>> >>>>>> I think the use of _concurrent_marking_from_roots is unfortunate. >>>>>> It would be much cleaner if >>>>>> ConcurrentMark::register_mark_from_roots_phase_end() called >>>>>> register_gc_concurrent_end() directly. >>>>> I wanted to avoid introducing the new flag but the reason of it >>>>> was, as you know, to handle 'abort'. >>>>> When 'abort' happens we do need to end all timers before calling >>>>> 'GCTracer::report_gc_end()'. >>>>> And at this point we need a way to know whether concurrent timer >>>>> is started or not. >>>> >>>> As I tried to describe I think you can extend the scope of the >>>> timing to cover the part until the marking thread discovers that >>>> the marking was aborted. Basically moving the timing in to >>>> ConcurrentMarkThread::run_service(). >>> Oh, I mis-understood your point. Sorry. >>> I will try your recommendation. >>> >>>> >>>>> >>>>>> I realize that this would change the timing for when a concurrent >>>>>> marking is aborted. The whole time for a full GC (or even several >>>>>> full GCs) would be included in the concurrent marking phase. But >>>>>> from a code perspective that is what happens, so maybe that is >>>>>> the correct time to report? Also, I think the logging is reported >>>>>> that way so if we want to make it easy to match the timing events >>>>>> with the logging we might want to use about the same scope for >>>>>> timing. >>>>>> >>>>>> Why do we only measure the concurrent mark phase for G1? >>>>> This is good question. :) >>>>> I was comparing CMS and G1 for major concurrent phases. >>>>> And the candidates were 'concurrent mark/sweep (CMS)' and >>>>> 'concurrent mark(G1)'. >>>>> >>>>>> Wouldn't it be good to measure all concurrent phases? >>>>> Okay, Stefan Karlsson also pointed to have them as well so I filed >>>>> a separate CR for this. >>>>> https://bugs.openjdk.java.net/browse/JDK-8143951 >>>> >>>> Ok. Is there a reason why we want to split this up into two >>>> changes? Why not add all the concurrent timing events at once? >>>> >>>> I'm ok with splitting it up into two changes, but then maybe the >>>> title for JDK-8068394 should be changed to indicate that it only >>>> adds events for the marking phase. Also, if we go with the >>>> CMSPhaseAccounting approach for CMS, you get events for all phases >>>> there. So, it will be a bit odd to have all concurrent phases >>>> handled for CMS but only concurrent mark for G1. >>> You are correct and I agree with you. >>> The only reason of split was due to limited time for FC. >>> But as we have enough time, let me close JDK-8143951 and include >>> concurrent mark for G1 as well. >>> >>>> >>>>> >>>>>> >>>>>> gcTraceSend.cpp >>>>>> >>>>>> 389 void visit(GCPhase* phase) { >>>>>> 390 switch (phase->type()) { >>>>>> 391 case GCPhase::PausePhaseType: >>>>>> 392 assert(phase->level() < PhasesStack::PHASE_LEVELS, >>>>>> "Need more event types for PausePhase"); >>>>>> 393 >>>>>> 394 switch (phase->level()) { >>>>>> 395 case 0: send_phase(phase); break; >>>>>> 396 case 1: >>>>>> send_phase(phase); break; >>>>>> 397 case 2: >>>>>> send_phase(phase); break; >>>>>> 398 case 3: >>>>>> send_phase(phase); break; >>>>>> 399 default: /* Ignore sending this phase */ break; >>>>>> 400 } >>>>>> 401 break; >>>>>> 402 >>>>>> 403 case GCPhase::ConcurrentPhaseType: >>>>>> 404 assert(phase->level() < 1, "There's only one level >>>>>> for ConcurrentPhase"); >>>>>> 405 >>>>>> 406 switch (phase->level()) { >>>>>> 407 case 0: send_phase(phase); >>>>>> break; >>>>>> 408 default: /* Ignore sending this phase */ break; >>>>>> 409 } >>>>>> 410 break; >>>>>> 411 } >>>>>> 412 } >>>>>> 413 }; >>>>>> >>>>>> Since there are only two values for GCPhase::PhaseType it seems a >>>>>> bit odd to use a switch statement. I think I would prefer to >>>>>> factor out the code for the different types a bit too. So, maybe >>>>>> something like: >>>>>> >>>>>> void visit(GCPhase* phase) { >>>>>> if (phase->type() == GCPhase::PausePhaseType) { >>>>>> visit_pause(phase); >>>>>> } else { >>>>>> assert(phase->type() == GCPhase::ConcurrentPhaseType, ""); >>>>>> visit_concurrent(phase); >>>>>> } >>>>>> } >>>>> This seems better. I will fix. >>>> >>>> Good. Thanks! >>> :) >>> >>> I will post next webrev when I'm ready, including JDK-8143951 part >>> as well. >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> Bengt >>>> >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>>> Testing: JPRT >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>> >>>>> >>>> >>> >> > From thomas.schatzl at oracle.com Tue Dec 15 09:23:20 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 15 Dec 2015 10:23:20 +0100 Subject: Request for code review - 8145037 Clean up FreeIdSet usage In-Reply-To: <0257E2D1-B0CF-45AC-8A94-F9BF5C89BB8C@oracle.com> References: <566F1ADA.30608@oracle.com> <0257E2D1-B0CF-45AC-8A94-F9BF5C89BB8C@oracle.com> Message-ID: <1450171400.1979.0.camel@oracle.com> Hi, On Mon, 2015-12-14 at 20:31 -0500, Kim Barrett wrote: > On Dec 14, 2015, at 2:39 PM, Alexander Harlap wrote: > > > > JDK-8145037 - Clean up FreeIdSet usage > > > > Proposed change: > > > > http://cr.openjdk.java.net/~aharlap/8145037/webrev.00/ > > > > Alex > > "JDK-8145037 - Clean up FreeIdSet usage? is a different problem. > > This is a fix for https://bugs.openjdk.java.net/browse/JDK-8145038 "Simplify mut_process_buffer worker id management?. > > I think it?s a good fix for that. > looks good to me as well as fix for JDK-8145038. Thanks, Thomas From bengt.rutisson at oracle.com Tue Dec 15 09:32:27 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 15 Dec 2015 10:32:27 +0100 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <308DDB4A-38AD-41FC-B4BA-850006F760A2@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDDF76@DEWDFEMB12A.global.corp.sap> <77BA861E-BEF9-4E61-B46E-84E4612B72E3@oracle.com> <566E8F56.1020400@oracle.com> <308DDB4A-38AD-41FC-B4BA-850006F760A2@oracle.com> Message-ID: <566FDE2B.1090008@oracle.com> Hi Kim, On 2015-12-14 21:02, Kim Barrett wrote: > On Dec 14, 2015, at 4:43 AM, Bengt Rutisson wrote: >> >> Hi Kim and Goetz, >> >> On 2015-12-13 00:02, Kim Barrett wrote: >>> On Dec 11, 2015, at 5:52 AM, Lindenmaier, Goetz wrote: >>>> diff -r 73e267ddd93d src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp >>>> --- a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Wed Nov 18 11:31:59 2015 +0100 >>>> +++ b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Fri Dec 11 11:42:52 2015 +0100 >>>> @@ -2731,7 +2731,7 @@ >>>> // Not MT-safe; so do not pass around these StackObj's >>>> // where they may be accessed by other threads. >>>> jlong wallclock_millis() { >>>> - return TimeHelper::counter_to_millis(os::elapsed_counter() - _trace_time.start_time()); >>>> + return (jlong)TimeHelper::counter_to_millis(os::elapsed_counter() - _trace_time.start_time()); >>>> } >>>> }; >>> This conversion was introduced by the recently pushed 8145092: Use Unified Logging for the GC logging. >>> >>> The only caller of wallclock_millis compares the result with CMSMaxAbortablePrecleanTime (an intx). >>> >>> So I think we?ve always had a bit of a type mismatch here. >>> >>> I?m not sure what to do about this one yet, but adding a cast doesn?t seem like the right solution to me. >> I would suggest changing CMSMaxAbortablePrecleanTime to a double. It may not be the cleanest way to handle the flag but having it as an intx is also not very clean. Negative values won't make sense. Changing it to a double won't make the situation much worse than it is now and it will simplify the code. > Unfortunately, the syntax for floating point options requires the decimal point and fraction part; integer > syntax is rejected. So existing uses of that option would be broken by changing its type. > CMSMaxAbortablePrecleanTime is a product option, making it not so easy to make such a change. Right. I would never have expected that from the floating point parsing. Seems like a bug to me. But that's a different story. I agree that making CMSMaxAbortablePrecleanTime is not the right solution. Thanks, Bengt > > >>>> diff -r 73e267ddd93d src/share/vm/gc/g1/g1CollectedHeap.cpp >>>> --- a/src/share/vm/gc/g1/g1CollectedHeap.cpp Wed Nov 18 11:31:59 2015 +0100 >>>> +++ b/src/share/vm/gc/g1/g1CollectedHeap.cpp Fri Dec 11 11:42:52 2015 +0100 >>>> @@ -3621,7 +3621,7 @@ >>>> log_info(gc)("To-space exhausted"); >>>> } >>>> >>>> - double pause_time_sec = TimeHelper::counter_to_seconds(pause_time_counter); >>>> + double pause_time_sec = TimeHelper::counter_to_seconds((jlong)pause_time_counter); >>>> g1_policy()->print_phases(pause_time_sec); >>>> >>>> g1_policy()->print_detailed_heap_transition(); >>> Adding a cast is not the proper fix here. >>> >>> The problem is that log_gc_footer?s double pause_time_counter argument ought to itself be a jlong. >>> The caller (do_collection_pause_at_safepoint) contains >>> >>> double pause_start_counter = os::elapsed_counter(); >>> ? >>> log_gc_footer(os::elapsed_counter() - pause_start_counter); >>> >>> elapsed_counter returns a jlong. So pause_start_counter ought to be a jlong too, and fixing the >>> parameter type for log_gc_footer would then make everything work out. >>> >>> This appears to be a mistake introduced by the recently pushed 8145092: Use Unified Logging for the GC logging. >>> >> Yes, this is a mistake in the push for the unified logging work. I created a patch and sent out a new review request to fix it. >> >> RFR: JDK-8145303: Clean up the units for log_gc_footer >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-December/015903.html >> >> http://cr.openjdk.java.net/~brutisso/8145303/webrev.00/ > Thanks for taking care of this. > From thomas.schatzl at oracle.com Tue Dec 15 10:24:39 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 15 Dec 2015 11:24:39 +0100 Subject: Request for review (s) - 8145031: Add regression test for 8133023 In-Reply-To: <5669D7A0.8000201@oracle.com> References: <5669D7A0.8000201@oracle.com> Message-ID: <1450175079.2296.1.camel@oracle.com> Hi Jon, On Thu, 2015-12-10 at 11:50 -0800, Jon Masamitsu wrote: > > The cause of the failure in 8133023 was the calculation of the > ParallelGCThreads using > information that had not yet been initialized. Add a test that checks > that, after full > initialization, the fresh calculation of ParallelGCThreads is > consistent with the value > calculated earlier. > > http://cr.openjdk.java.net/~jmasa/8145031/webrev.00/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8145031 > > Tested with and without the fix for 8133023. > seems okay, with one nit: the indendation of the parameters for the assert in Abstract_VM_Version::FinalParallelGCThreads_test() seems off. Also there is an extra space between the "void" and the method name. I do not need to re-review. Thanks, Thomas From bengt.rutisson at oracle.com Tue Dec 15 11:56:24 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 15 Dec 2015 12:56:24 +0100 Subject: RFR: JDK-8145315: VM crashes in print_task_time_stamps() Message-ID: <566FFFE8.9090309@oracle.com> Hi everyone, Could I have a couple of reviews for this patch? http://cr.openjdk.java.net/~brutisso/8145315/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8145315 The fix will make sure that the VM does not crash. But there is still an issue with that a task may not be printed if we run into the race that exist. This is a separate problem and outside the scope of this bug fix. From the bug report: The crash is due to an existing race condition in the ParallelGC. This race existed even before the new logging was introduced but we did not run with this logging enabled before. The test now runs with -Xlog:gc*=debug, which enables logging that was previously guarded by the PrintGCTaskTimeStamps flag. In the GCTaskThread::run() method we have this code: GCTaskTimeStamp* time_stamp = time_stamp_at(_time_stamp_index++); time_stamp->set_name(name); time_stamp->set_entry_time(entry_time); time_stamp->set_exit_time(timer.ticks()); And in GCTaskThread::print_task_time_stamps() we have this code: for(uint i=0; i<_time_stamp_index; i++) { GCTaskTimeStamp* time_stamp = time_stamp_at(i); log_debug(gc, task, time)("\t[ %s " JLONG_FORMAT " " JLONG_FORMAT " ]", time_stamp->name(), time_stamp->entry_time(), time_stamp->exit_time()); } The code in GCTaskThread::run() increments the _time_stamp_index value before setting the name, entry and exit times, which means that the code in GCTaskThread::print_task_time_stamps() can see the new value of _time_stamp_index before the name, entry and exit times have been set. I can reproduce this on Linux x64 with the following patch that introduces a sleep and an assert: diff --git a/src/share/vm/gc/parallel/gcTaskThread.cpp b/src/share/vm/gc/parallel/gcTaskThread.cpp --- a/src/share/vm/gc/parallel/gcTaskThread.cpp +++ b/src/share/vm/gc/parallel/gcTaskThread.cpp @@ -83,6 +83,7 @@ log_debug(gc, task, time)("GC-Thread %u entries: %d", id(), _time_stamp_index); for(uint i=0; i<_time_stamp_index; i++) { GCTaskTimeStamp* time_stamp = time_stamp_at(i); + assert(time_stamp->name() != NULL, "NULL name"); log_debug(gc, task, time)("\t[ %s " JLONG_FORMAT " " JLONG_FORMAT " ]", time_stamp->name(), time_stamp->entry_time(), @@ -154,6 +155,12 @@ GCTaskTimeStamp* time_stamp = time_stamp_at(_time_stamp_index++); + if (os::random() % 100 == 0) { + time_stamp->set_name(NULL); + tty->print_cr("####### WAITING: %s", name); + sleep(1); + } + time_stamp->set_name(name); time_stamp->set_entry_time(entry_time); time_stamp->set_exit_time(timer.ticks()); By updating the _time_stamp_index after we have set the other values we remove the crash: diff --git a/src/share/vm/gc/parallel/gcTaskThread.cpp b/src/share/vm/gc/parallel/gcTaskThread.cpp --- a/src/share/vm/gc/parallel/gcTaskThread.cpp +++ b/src/share/vm/gc/parallel/gcTaskThread.cpp @@ -153,7 +153,7 @@ if (log_is_enabled(Debug, gc, task, time)) { timer.update(); - GCTaskTimeStamp* time_stamp = time_stamp_at(_time_stamp_index++); + GCTaskTimeStamp* time_stamp = time_stamp_at(_time_stamp_index); if (os::random() % 100 == 0) { time_stamp->set_name(NULL); @@ -164,6 +164,7 @@ time_stamp->set_name(name); time_stamp->set_entry_time(entry_time); time_stamp->set_exit_time(timer.ticks()); + _time_stamp_index++; } } else { // idle tasks complete outside the normal accounting Running with the first patch asserts every time. Adding the second patch does not hit the assert. From jesper.wilhelmsson at oracle.com Tue Dec 15 15:39:59 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 15 Dec 2015 16:39:59 +0100 Subject: RFR: JDK-8145315: VM crashes in print_task_time_stamps() In-Reply-To: <566FFFE8.9090309@oracle.com> References: <566FFFE8.9090309@oracle.com> Message-ID: <5670344F.6060504@oracle.com> Looks good! /Jesper Den 15/12/15 kl. 12:56, skrev Bengt Rutisson: > > Hi everyone, > > Could I have a couple of reviews for this patch? > > http://cr.openjdk.java.net/~brutisso/8145315/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8145315 > > The fix will make sure that the VM does not crash. But there is still an issue > with that a task may not be printed if we run into the race that exist. This is > a separate problem and outside the scope of this bug fix. > > From the bug report: > > The crash is due to an existing race condition in the ParallelGC. This race > existed even before the new logging was introduced but we did not run with this > logging enabled before. > > The test now runs with -Xlog:gc*=debug, which enables logging that was > previously guarded by the PrintGCTaskTimeStamps flag. > > In the GCTaskThread::run() method we have this code: > > GCTaskTimeStamp* time_stamp = time_stamp_at(_time_stamp_index++); > > time_stamp->set_name(name); > time_stamp->set_entry_time(entry_time); > time_stamp->set_exit_time(timer.ticks()); > > > And in GCTaskThread::print_task_time_stamps() we have this code: > > for(uint i=0; i<_time_stamp_index; i++) { > GCTaskTimeStamp* time_stamp = time_stamp_at(i); > log_debug(gc, task, time)("\t[ %s " JLONG_FORMAT " " JLONG_FORMAT " ]", > time_stamp->name(), > time_stamp->entry_time(), > time_stamp->exit_time()); > } > > The code in GCTaskThread::run() increments the _time_stamp_index value before > setting the name, entry and exit times, which means that the code in > GCTaskThread::print_task_time_stamps() can see the new value of > _time_stamp_index before the name, entry and exit times have been set. > > I can reproduce this on Linux x64 with the following patch that introduces a > sleep and an assert: > > diff --git a/src/share/vm/gc/parallel/gcTaskThread.cpp > b/src/share/vm/gc/parallel/gcTaskThread.cpp > --- a/src/share/vm/gc/parallel/gcTaskThread.cpp > +++ b/src/share/vm/gc/parallel/gcTaskThread.cpp > @@ -83,6 +83,7 @@ > log_debug(gc, task, time)("GC-Thread %u entries: %d", id(), _time_stamp_index); > for(uint i=0; i<_time_stamp_index; i++) { > GCTaskTimeStamp* time_stamp = time_stamp_at(i); > + assert(time_stamp->name() != NULL, "NULL name"); > log_debug(gc, task, time)("\t[ %s " JLONG_FORMAT " " JLONG_FORMAT " ]", > time_stamp->name(), > time_stamp->entry_time(), > @@ -154,6 +155,12 @@ > > GCTaskTimeStamp* time_stamp = time_stamp_at(_time_stamp_index++); > > + if (os::random() % 100 == 0) { > + time_stamp->set_name(NULL); > + tty->print_cr("####### WAITING: %s", name); > + sleep(1); > + } > + > time_stamp->set_name(name); > time_stamp->set_entry_time(entry_time); > time_stamp->set_exit_time(timer.ticks()); > > > By updating the _time_stamp_index after we have set the other values we remove > the crash: > > diff --git a/src/share/vm/gc/parallel/gcTaskThread.cpp > b/src/share/vm/gc/parallel/gcTaskThread.cpp > --- a/src/share/vm/gc/parallel/gcTaskThread.cpp > +++ b/src/share/vm/gc/parallel/gcTaskThread.cpp > @@ -153,7 +153,7 @@ > if (log_is_enabled(Debug, gc, task, time)) { > timer.update(); > > - GCTaskTimeStamp* time_stamp = time_stamp_at(_time_stamp_index++); > + GCTaskTimeStamp* time_stamp = time_stamp_at(_time_stamp_index); > > if (os::random() % 100 == 0) { > time_stamp->set_name(NULL); > @@ -164,6 +164,7 @@ > time_stamp->set_name(name); > time_stamp->set_entry_time(entry_time); > time_stamp->set_exit_time(timer.ticks()); > + _time_stamp_index++; > } > } else { > // idle tasks complete outside the normal accounting > > > Running with the first patch asserts every time. Adding the second patch does > not hit the assert. From alexander.harlap at oracle.com Tue Dec 15 15:40:11 2015 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Tue, 15 Dec 2015 10:40:11 -0500 Subject: Request for code review - 8145038 Simplify mut_process_buffer worker id management In-Reply-To: <1450171400.1979.0.camel@oracle.com> References: <566F1ADA.30608@oracle.com> <0257E2D1-B0CF-45AC-8A94-F9BF5C89BB8C@oracle.com> <1450171400.1979.0.camel@oracle.com> Message-ID: <5670345B.9080607@oracle.com> Thomas, It was great catch. Here is correct change: for JDK-8145038 - Simplify mut_process_buffer worker id management http://cr.openjdk.java.net/~aharlap/8145038/webrev.00/ Alex On 12/15/2015 4:23 AM, Thomas Schatzl wrote: > Hi, > > On Mon, 2015-12-14 at 20:31 -0500, Kim Barrett wrote: >> On Dec 14, 2015, at 2:39 PM, Alexander Harlap wrote: >>> JDK-8145037 - Clean up FreeIdSet usage >>> >>> Proposed change: >>> >>> http://cr.openjdk.java.net/~aharlap/8145037/webrev.00/ >>> >>> Alex >> "JDK-8145037 - Clean up FreeIdSet usage? is a different problem. >> >> This is a fix for https://bugs.openjdk.java.net/browse/JDK-8145038 "Simplify mut_process_buffer worker id management?. >> >> I think it?s a good fix for that. >> > looks good to me as well as fix for JDK-8145038. > > Thanks, > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Tue Dec 15 16:15:31 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 15 Dec 2015 17:15:31 +0100 Subject: [PATCH] enhancement to ParallelScavenge Full GC In-Reply-To: <1450111786.11162.34.camel@oracle.com> References: <1450104486.2316.46.camel@oracle.com> <1450111786.11162.34.camel@oracle.com> Message-ID: <56703CA3.9050605@oracle.com> Hi, On 2015-12-14 17:49, Thomas Schatzl wrote: > Hi, > > On Mon, 2015-12-14 at 23:57 +0800, ray alex wrote: >> Thanks, Thomas! >> >> I will refine my code carefully according to your suggestions as soon >> as possible. > > Thanks. >> >> Since I'm new in contributing to OpenJDK, actually I'm not sure how to >> upload when my new code is ready? >> Just upload an attach of diffs as I did, or some other ways? > > The best way as long as we have no confirmation about the OCA signing, > is to attach a patch (or a webrev, see > http://openjdk.java.net/contribute/) and send it to this list. Later it > will be more convenient to send me a patch that I will convert into a > webrev and put on cr.openjdk.java.net. > > As soon as you have two contributions, you can upload patches yourselves > onto your own account on cr.openjdk.java.net. >> >> Besides, I'm currently processing my signed OCA for the committer >> rights, >> I'm not sure how long it will take, does it matter? > > The OCA is only for us to be able to accept your patch in Hotspot. The > various levels of contributor status are a different matter, and signify > your level of expertise within the community. > > See also http://openjdk.java.net/contribute/ for more information. > >> As for the VM Thread, it does a serial adjust_roots() within the >> current thread (VM thread) during >> PSParallelCompact::invoke_no_policy(). >> I think psCompactionManager.cpp:117 and the surrounding comments >> confirm the use of VMThread in full GC. >> Do you agree with my above understanding of the use of VMThread? >> > You are right :( > > There are multiple options to provide an additional per-thread context: > > - passing around some context. Looks like lots of work. I actually think this is the correct way to go. In my mind you would only have to change ParCompactionMangager::update_contents to pass on the ParCompactionManager* through oopDesc::pc_update_contents to *Klass::oop_pc_update_contents It's similar to how the marking phase passes around the current worker's compaction manager. Then the AdjustPointerClosure needs to become a per-ParCompactionManager thing and then it's all set :) /Mikael > - change the code so that even that serial portion is performed by some > GCTaskThread (which actually sounds best to me) > - Another would be to add a field to both GCTaskThread and VMThread, and > via a virtual method in Thread get the necessary values. > - make VMThread a WorkerThread (that has an id that can be used to query > an extra data structure for this cache) > - others > > Let's see if other people have a better idea. > > Thanks, > Thomas > > > From jon.masamitsu at oracle.com Tue Dec 15 19:01:21 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 15 Dec 2015 11:01:21 -0800 Subject: Request for review (s) - 8145031: Add regression test for 8133023 In-Reply-To: <1450175079.2296.1.camel@oracle.com> References: <5669D7A0.8000201@oracle.com> <1450175079.2296.1.camel@oracle.com> Message-ID: <56706381.7050205@oracle.com> On 12/15/2015 2:24 AM, Thomas Schatzl wrote: > Hi Jon, > > On Thu, 2015-12-10 at 11:50 -0800, Jon Masamitsu wrote: >> The cause of the failure in 8133023 was the calculation of the >> ParallelGCThreads using >> information that had not yet been initialized. Add a test that checks >> that, after full >> initialization, the fresh calculation of ParallelGCThreads is >> consistent with the value >> calculated earlier. >> >> http://cr.openjdk.java.net/~jmasa/8145031/webrev.00/ >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8145031 >> >> Tested with and without the fix for 8133023. >> > seems okay, with one nit: the indendation of the parameters for the > assert in Abstract_VM_Version::FinalParallelGCThreads_test() seems off. > > Also there is an extra space between the "void" and the method name. Both fixed. Thanks. Jon > > I do not need to re-review. > > Thanks, > Thomas > > From kim.barrett at oracle.com Tue Dec 15 19:02:28 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 15 Dec 2015 14:02:28 -0500 Subject: RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build. In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EDEC1F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41EBAAF4@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41EBAE11@DEWDFEMB12A.global.corp.sap> <6A61B1AE-73E8-422E-B563-C1A9E48A3631@oracle.com> <4295855A5C1DE049A61835A1887419CC41EBB0A8@DEWDFEMB12A.global.corp.sap> <292EA70E-1FAF-4F3D-AD5D-226EA6DCD885@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDA34E@DEWDFEMB12A.global.corp.sap> <9C23F5AA-2FAE-4683-A63D-A331A914DA37@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDC852@DEWDFEMB12A.global.corp.sap> <4AEA0880-0A53-4DC7-B360-B24511B96B73@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDDF76@DEWDFEMB12A.global.corp.sap> <77BA861E-BEF9-4E61-B46E-84E4612B72E3@oracle.com> <566E8F56.1020400@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDE79B@DEWDFEMB12A.global.corp.sap> <566EB027.2010403@oracle.com> <1450096584.2316.14.camel@oracle.com> <2B1E7A10-0698-4CF5-92A6-3935BAADAFF5@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDEC1F@DEWDFEMB12A.global.corp.sap> Message-ID: <14DC0348-F6BD-4C2D-B5AF-9265DEF65E98@oracle.com> On Dec 15, 2015, at 3:35 AM, Lindenmaier, Goetz wrote: > > Hi Kim, > > I removed the change to the flag: > http://cr.openjdk.java.net/~goetz/webrevs/8143215-gcc412/webrev.06 > I also moved the comment as Thomas asked for. > > Would you sponsor this? This looks good. I will sponsor. From jon.masamitsu at oracle.com Tue Dec 15 19:05:51 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 15 Dec 2015 11:05:51 -0800 Subject: RFR: JDK-8145315: VM crashes in print_task_time_stamps() In-Reply-To: <566FFFE8.9090309@oracle.com> References: <566FFFE8.9090309@oracle.com> Message-ID: <5670648F.3030701@oracle.com> Looks good. Jon On 12/15/2015 3:56 AM, Bengt Rutisson wrote: > > Hi everyone, > > Could I have a couple of reviews for this patch? > > http://cr.openjdk.java.net/~brutisso/8145315/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8145315 > > The fix will make sure that the VM does not crash. But there is still > an issue with that a task may not be printed if we run into the race > that exist. This is a separate problem and outside the scope of this > bug fix. > > From the bug report: > > The crash is due to an existing race condition in the ParallelGC. This > race existed even before the new logging was introduced but we did not > run with this logging enabled before. > > The test now runs with -Xlog:gc*=debug, which enables logging that was > previously guarded by the PrintGCTaskTimeStamps flag. > > In the GCTaskThread::run() method we have this code: > > GCTaskTimeStamp* time_stamp = > time_stamp_at(_time_stamp_index++); > > time_stamp->set_name(name); > time_stamp->set_entry_time(entry_time); > time_stamp->set_exit_time(timer.ticks()); > > > And in GCTaskThread::print_task_time_stamps() we have this code: > > for(uint i=0; i<_time_stamp_index; i++) { > GCTaskTimeStamp* time_stamp = time_stamp_at(i); > log_debug(gc, task, time)("\t[ %s " JLONG_FORMAT " " JLONG_FORMAT > " ]", > time_stamp->name(), > time_stamp->entry_time(), > time_stamp->exit_time()); > } > > The code in GCTaskThread::run() increments the _time_stamp_index value > before setting the name, entry and exit times, which means that the > code in GCTaskThread::print_task_time_stamps() can see the new value > of _time_stamp_index before the name, entry and exit times have been set. > > I can reproduce this on Linux x64 with the following patch that > introduces a sleep and an assert: > > diff --git a/src/share/vm/gc/parallel/gcTaskThread.cpp > b/src/share/vm/gc/parallel/gcTaskThread.cpp > --- a/src/share/vm/gc/parallel/gcTaskThread.cpp > +++ b/src/share/vm/gc/parallel/gcTaskThread.cpp > @@ -83,6 +83,7 @@ > log_debug(gc, task, time)("GC-Thread %u entries: %d", id(), > _time_stamp_index); > for(uint i=0; i<_time_stamp_index; i++) { > GCTaskTimeStamp* time_stamp = time_stamp_at(i); > + assert(time_stamp->name() != NULL, "NULL name"); > log_debug(gc, task, time)("\t[ %s " JLONG_FORMAT " " JLONG_FORMAT > " ]", > time_stamp->name(), > time_stamp->entry_time(), > @@ -154,6 +155,12 @@ > > GCTaskTimeStamp* time_stamp = > time_stamp_at(_time_stamp_index++); > > + if (os::random() % 100 == 0) { > + time_stamp->set_name(NULL); > + tty->print_cr("####### WAITING: %s", name); > + sleep(1); > + } > + > time_stamp->set_name(name); > time_stamp->set_entry_time(entry_time); > time_stamp->set_exit_time(timer.ticks()); > > > By updating the _time_stamp_index after we have set the other values > we remove the crash: > > diff --git a/src/share/vm/gc/parallel/gcTaskThread.cpp > b/src/share/vm/gc/parallel/gcTaskThread.cpp > --- a/src/share/vm/gc/parallel/gcTaskThread.cpp > +++ b/src/share/vm/gc/parallel/gcTaskThread.cpp > @@ -153,7 +153,7 @@ > if (log_is_enabled(Debug, gc, task, time)) { > timer.update(); > > - GCTaskTimeStamp* time_stamp = time_stamp_at(_time_stamp_index++); > + GCTaskTimeStamp* time_stamp = time_stamp_at(_time_stamp_index); > > if (os::random() % 100 == 0) { > time_stamp->set_name(NULL); > @@ -164,6 +164,7 @@ > time_stamp->set_name(name); > time_stamp->set_entry_time(entry_time); > time_stamp->set_exit_time(timer.ticks()); > + _time_stamp_index++; > } > } else { > // idle tasks complete outside the normal accounting > > > Running with the first patch asserts every time. Adding the second > patch does not hit the assert. From sangheon.kim at oracle.com Tue Dec 15 19:29:38 2015 From: sangheon.kim at oracle.com (sangheon) Date: Tue, 15 Dec 2015 11:29:38 -0800 Subject: RFR (M): JDK-8068394: Trace event for concurrent GC phases In-Reply-To: <566FD637.4060909@oracle.com> References: <56282271.5090108@oracle.com> <56546233.20006@oracle.com> <5654B10E.1060701@oracle.com> <565EB318.8060607@oracle.com> <565F33A8.6060608@oracle.com> <565FF761.30200@oracle.com> <566FB2BA.5020408@oracle.com> <566FD637.4060909@oracle.com> Message-ID: <56706A22.9070803@oracle.com> Hi Stefan, Thank you for looking at official RFR as well. On 12/15/2015 12:58 AM, Stefan Karlsson wrote: > Hi Sangheon, > > On 2015-12-15 07:27, sangheon wrote: >> Hi Bengt and all, >> >> Here's a next webrev. >> Bengt and I had a discussion on other thread and he and Stefan >> Karlsson suggested simpler design. >> >> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01 >> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01_to_00 > > Thanks for doing the simplifications of the patch. > > I have a couple of comments: > Could you replace NOT_PRODUCT with DEBUG_ONLY, and #ifndef PRODUCT > with #ifdef ASSERT. Otherwise, you'll get inconsistencies when > building with optimized builds where neither PRODUCT nor ASSERT is > defined. Okay, I will do. But you also pointed that whether this flag is really needed below. > > 81 void ConcurrentGCTimer::register_gc_concurrent_start(const char* > name, const Ticks& time) { > 82 assert(!_is_concurrent_phase_active, "A concurrent phase is already > active."); > 83 _time_partitions.report_gc_phase_start(name, time, > GCPhase::ConcurrentPhaseType); > 84 NOT_PRODUCT(_is_concurrent_phase_active = true;) > 85 } > > 162 class ConcurrentGCTimer : public GCTimer { > 163 // ConcurrentGCTimer can't be used if there is an overlap between > a pause phase and a concurrent phase. > 164 // _is_concurrent_phase_active is used to find above case. > 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) > 166 > 167 public: > 168 #ifndef PRODUCT > 169 ConcurrentGCTimer(): GCTimer(), _is_concurrent_phase_active(false) > {}; > 170 #endif Is it really worth optimizing away the boolean? The code > would be cleaner without these macros. I just wanted to prevent mis-use of concurrent timer for overlapping phase. A pause phase nor another concurrent phase can't be started if a concurrent phase is already started. I think this would be nice to have. But I don't have a strong opinion on this as currently we don't have these situations. > > > Why are you using volatile here? I don't see why that should be needed. > > 162 class ConcurrentGCTimer : public GCTimer { > 163 // ConcurrentGCTimer can't be used if there is an overlap between > a pause phase and a concurrent phase. > 164 // _is_concurrent_phase_active is used to find above case. > 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) You are right, volatile is not needed here. I was thinking register_gc_concurrent_end() would be called from different threads(ConcurrentMarkThread and VMThread), but as it only happens from safepoint, I think volatile should be removed. I will post a new webrev with your opinion about the flag. Thanks, Sangheon > > > Thanks, > StefanK > >> >> This webrev includes: >> 1. Moving concurrent phase measurement into CMSPhaseAccounting class. >> So we can check all concurrent phases from CMS. >> >> 2. Renamed a new flag introduced from webrev.00 for general use, >> _concurrent_phase_started. >> >> 3. Added helper class for concurrent phase measurement, >> GCConcPhaseTimer. And used this class for all concurrent phases. >> >> 4. Flag checking is moved from >> G1CollectedHeap::register_concurrent_cycle_end() to >> ConcurrentMark::abort(). >> >> 5. Changed switch() to if else statement at gcTraceSend. >> >> Many thanks to Bengt and Stefan Karlsson for the discussion. >> >> Thanks, >> Sangheon >> >> >> On 12/03/2015 12:03 AM, Bengt Rutisson wrote: >>> >>> Hi Sangheon, >>> >>> This all sounds good. Looking forward to the next webrev. >>> >>> Thanks, >>> Bengt >>> >>> On 2015-12-02 19:08, sangheon.kim wrote: >>>> Hi Bengt, >>>> >>>> >>>> On 12/02/2015 01:00 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi Sangheon, >>>>> >>>>> Sorry again for the late reply. Comments inline. >>>> No not at all. >>>> Thank you for taking time for this review! >>>> >>>>> >>>>> On 2015-11-24 19:48, sangheon.kim wrote: >>>>>> Hi Bengt, >>>>>> >>>>>> Thank you so much for reviewing this patch! >>>>>> >>>>>> On 11/24/2015 05:12 AM, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> Sorry for the very late reply to this review request. >>>>>>> >>>>>>> On 2015-10-22 01:40, sangheon.kim wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Can I get some reviews for this change of adding a trace event >>>>>>>> for concurrent phases on CMS and G1? >>>>>>>> >>>>>>>> Currently we only measure pause times for major phases. >>>>>>>> But I want to add 'concurrent mark' and 'concurrent sweep' >>>>>>>> phases for CMS and 'concurrent mark' phase for G1. >>>>>>>> To achieve this, I had to change ConcurrentGCTimer and related >>>>>>>> classes. >>>>>>>> >>>>>>>> This patch includes: >>>>>>>> 1) A concurrent phase can be measured only from >>>>>>>> ConcurrentGCTimer and measuring an overlap between concurrent >>>>>>>> and pause is not allowed as currently we don't have that use >>>>>>>> case. And TimePartitions class(or related classes) will be >>>>>>>> simpler than an overlap allowed case. >>>>>>>> 2) I removed PausePhase and ConcurrentPhase which are derived >>>>>>>> from GCPhase because I wanted to avoid heap allocation when >>>>>>>> adding to GrowableArray. Instead introduced 'type' member >>>>>>>> variable at GCPhase. >>>>>>>> >>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8068394 >>>>>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8068394/webrev.00/ >>>>>>> >>>>>>> Nice work! It is great to get some timing information for the >>>>>>> concurrent phases. >>>>>> Thanks! >>>>>> >>>>>>> >>>>>>> A few questions/comments: >>>>>>> >>>>>>> CMS. >>>>>>> >>>>>>> You have added timing events for the concurrent phases mark and >>>>>>> sweep, but not for other concurrent phases (preclean, >>>>>>> abortable_preclean and reset_concurrent). I think that if you >>>>>>> moved your calls to _gc_timer_cm->register_gc_concurrent_start() >>>>>>> and _gc_timer_cm->register_gc_concurrent_end() into the >>>>>>> constructor and destructor of CMSPhaseAccounting you would >>>>>>> automatically get timing events for all concurrent phases. >>>>>> I also considered about this idea but I was not clear whether it >>>>>> is good measurement especially for 'sweep'. >>>>>> We are using CMSPhaseAccounting for 5 cases. >>>>>> I think for 'mark' and 'preclean' they are okay. (there are >>>>>> non-product functions call before CMSPhaseAccounting. But they >>>>>> are okay). >>>>>> For 'abortable-preclean' and 'reset', they are good to have that. >>>>>> But when it comes to 'sweep', there are timer and >>>>>> CMSTokenSyncWithLocks related codes and I was not sure about these. >>>>>> If you think they are also okay, I will change as you suggested. >>>>> >>>>> I think it is fine for the sweep part as well. If the >>>>> CMSPhaseAccounting instance is not measuring the correct part of >>>>> the work I think we should change it to measure what we want. That >>>>> way we improve the existing measurements too. >>>>> >>>>> But as you stated in your follow up email, I think the sweep code >>>>> is actually pretty much ok from this perspective. >>>>> >>>>> So, I would prefer to go with the CMSPhaseAccounting approach. >>>> Okay, I already changed as you suggested. :) >>>> >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> G1. >>>>>>> >>>>>>> I think the use of _concurrent_marking_from_roots is >>>>>>> unfortunate. It would be much cleaner if >>>>>>> ConcurrentMark::register_mark_from_roots_phase_end() called >>>>>>> register_gc_concurrent_end() directly. >>>>>> I wanted to avoid introducing the new flag but the reason of it >>>>>> was, as you know, to handle 'abort'. >>>>>> When 'abort' happens we do need to end all timers before calling >>>>>> 'GCTracer::report_gc_end()'. >>>>>> And at this point we need a way to know whether concurrent timer >>>>>> is started or not. >>>>> >>>>> As I tried to describe I think you can extend the scope of the >>>>> timing to cover the part until the marking thread discovers that >>>>> the marking was aborted. Basically moving the timing in to >>>>> ConcurrentMarkThread::run_service(). >>>> Oh, I mis-understood your point. Sorry. >>>> I will try your recommendation. >>>> >>>>> >>>>>> >>>>>>> I realize that this would change the timing for when a >>>>>>> concurrent marking is aborted. The whole time for a full GC (or >>>>>>> even several full GCs) would be included in the concurrent >>>>>>> marking phase. But from a code perspective that is what happens, >>>>>>> so maybe that is the correct time to report? Also, I think the >>>>>>> logging is reported that way so if we want to make it easy to >>>>>>> match the timing events with the logging we might want to use >>>>>>> about the same scope for timing. >>>>>>> >>>>>>> Why do we only measure the concurrent mark phase for G1? >>>>>> This is good question. :) >>>>>> I was comparing CMS and G1 for major concurrent phases. >>>>>> And the candidates were 'concurrent mark/sweep (CMS)' and >>>>>> 'concurrent mark(G1)'. >>>>>> >>>>>>> Wouldn't it be good to measure all concurrent phases? >>>>>> Okay, Stefan Karlsson also pointed to have them as well so I >>>>>> filed a separate CR for this. >>>>>> https://bugs.openjdk.java.net/browse/JDK-8143951 >>>>> >>>>> Ok. Is there a reason why we want to split this up into two >>>>> changes? Why not add all the concurrent timing events at once? >>>>> >>>>> I'm ok with splitting it up into two changes, but then maybe the >>>>> title for JDK-8068394 should be changed to indicate that it only >>>>> adds events for the marking phase. Also, if we go with the >>>>> CMSPhaseAccounting approach for CMS, you get events for all phases >>>>> there. So, it will be a bit odd to have all concurrent phases >>>>> handled for CMS but only concurrent mark for G1. >>>> You are correct and I agree with you. >>>> The only reason of split was due to limited time for FC. >>>> But as we have enough time, let me close JDK-8143951 and include >>>> concurrent mark for G1 as well. >>>> >>>>> >>>>>> >>>>>>> >>>>>>> gcTraceSend.cpp >>>>>>> >>>>>>> 389 void visit(GCPhase* phase) { >>>>>>> 390 switch (phase->type()) { >>>>>>> 391 case GCPhase::PausePhaseType: >>>>>>> 392 assert(phase->level() < PhasesStack::PHASE_LEVELS, >>>>>>> "Need more event types for PausePhase"); >>>>>>> 393 >>>>>>> 394 switch (phase->level()) { >>>>>>> 395 case 0: send_phase(phase); break; >>>>>>> 396 case 1: >>>>>>> send_phase(phase); break; >>>>>>> 397 case 2: >>>>>>> send_phase(phase); break; >>>>>>> 398 case 3: >>>>>>> send_phase(phase); break; >>>>>>> 399 default: /* Ignore sending this phase */ break; >>>>>>> 400 } >>>>>>> 401 break; >>>>>>> 402 >>>>>>> 403 case GCPhase::ConcurrentPhaseType: >>>>>>> 404 assert(phase->level() < 1, "There's only one level >>>>>>> for ConcurrentPhase"); >>>>>>> 405 >>>>>>> 406 switch (phase->level()) { >>>>>>> 407 case 0: >>>>>>> send_phase(phase); break; >>>>>>> 408 default: /* Ignore sending this phase */ break; >>>>>>> 409 } >>>>>>> 410 break; >>>>>>> 411 } >>>>>>> 412 } >>>>>>> 413 }; >>>>>>> >>>>>>> Since there are only two values for GCPhase::PhaseType it seems >>>>>>> a bit odd to use a switch statement. I think I would prefer to >>>>>>> factor out the code for the different types a bit too. So, maybe >>>>>>> something like: >>>>>>> >>>>>>> void visit(GCPhase* phase) { >>>>>>> if (phase->type() == GCPhase::PausePhaseType) { >>>>>>> visit_pause(phase); >>>>>>> } else { >>>>>>> assert(phase->type() == GCPhase::ConcurrentPhaseType, ""); >>>>>>> visit_concurrent(phase); >>>>>>> } >>>>>>> } >>>>>> This seems better. I will fix. >>>>> >>>>> Good. Thanks! >>>> :) >>>> >>>> I will post next webrev when I'm ready, including JDK-8143951 part >>>> as well. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> Bengt >>>>> >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>>>> >>>>>>>> Testing: JPRT >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>> >>>>>> >>>>> >>>> >>> >> > From stefan.karlsson at oracle.com Tue Dec 15 19:32:23 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 15 Dec 2015 20:32:23 +0100 Subject: RFR (M): JDK-8068394: Trace event for concurrent GC phases In-Reply-To: <56706A22.9070803@oracle.com> References: <56282271.5090108@oracle.com> <56546233.20006@oracle.com> <5654B10E.1060701@oracle.com> <565EB318.8060607@oracle.com> <565F33A8.6060608@oracle.com> <565FF761.30200@oracle.com> <566FB2BA.5020408@oracle.com> <566FD637.4060909@oracle.com> <56706A22.9070803@oracle.com> Message-ID: <56706AC7.1070708@oracle.com> Hi Sangheon, On 2015-12-15 20:29, sangheon wrote: > Hi Stefan, > > Thank you for looking at official RFR as well. > > On 12/15/2015 12:58 AM, Stefan Karlsson wrote: >> Hi Sangheon, >> >> On 2015-12-15 07:27, sangheon wrote: >>> Hi Bengt and all, >>> >>> Here's a next webrev. >>> Bengt and I had a discussion on other thread and he and Stefan >>> Karlsson suggested simpler design. >>> >>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01 >>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01_to_00 >> >> Thanks for doing the simplifications of the patch. >> >> I have a couple of comments: >> Could you replace NOT_PRODUCT with DEBUG_ONLY, and #ifndef PRODUCT >> with #ifdef ASSERT. Otherwise, you'll get inconsistencies when >> building with optimized builds where neither PRODUCT nor ASSERT is >> defined. > Okay, I will do. > But you also pointed that whether this flag is really needed below. > >> >> 81 void ConcurrentGCTimer::register_gc_concurrent_start(const char* >> name, const Ticks& time) { >> 82 assert(!_is_concurrent_phase_active, "A concurrent phase is >> already active."); >> 83 _time_partitions.report_gc_phase_start(name, time, >> GCPhase::ConcurrentPhaseType); >> 84 NOT_PRODUCT(_is_concurrent_phase_active = true;) >> 85 } >> >> 162 class ConcurrentGCTimer : public GCTimer { >> 163 // ConcurrentGCTimer can't be used if there is an overlap between >> a pause phase and a concurrent phase. >> 164 // _is_concurrent_phase_active is used to find above case. >> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >> 166 >> 167 public: >> 168 #ifndef PRODUCT >> 169 ConcurrentGCTimer(): GCTimer(), >> _is_concurrent_phase_active(false) {}; >> 170 #endif Is it really worth optimizing away the boolean? The code >> would be cleaner without these macros. > I just wanted to prevent mis-use of concurrent timer for overlapping > phase. > A pause phase nor another concurrent phase can't be started if a > concurrent phase is already started. > I think this would be nice to have. But I don't have a strong opinion > on this as currently we don't have these situations. I meant that we could keep the the variable in the product builds as well. Just to get rid of the noisy PRODUCT / DEBUG_ONLY macros. It could even be useful for future debugging. ;) > >> >> >> Why are you using volatile here? I don't see why that should be needed. >> >> 162 class ConcurrentGCTimer : public GCTimer { >> 163 // ConcurrentGCTimer can't be used if there is an overlap >> between a pause phase and a concurrent phase. >> 164 // _is_concurrent_phase_active is used to find above case. >> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) > You are right, volatile is not needed here. > I was thinking register_gc_concurrent_end() would be called from > different threads(ConcurrentMarkThread and VMThread), but as it only > happens from safepoint, I think volatile should be removed. > > I will post a new webrev with your opinion about the flag. Great. Thanks, StefanK > > Thanks, > Sangheon > > >> >> >> Thanks, >> StefanK >> >>> >>> This webrev includes: >>> 1. Moving concurrent phase measurement into CMSPhaseAccounting >>> class. So we can check all concurrent phases from CMS. >>> >>> 2. Renamed a new flag introduced from webrev.00 for general use, >>> _concurrent_phase_started. >>> >>> 3. Added helper class for concurrent phase measurement, >>> GCConcPhaseTimer. And used this class for all concurrent phases. >>> >>> 4. Flag checking is moved from >>> G1CollectedHeap::register_concurrent_cycle_end() to >>> ConcurrentMark::abort(). >>> >>> 5. Changed switch() to if else statement at gcTraceSend. >>> >>> Many thanks to Bengt and Stefan Karlsson for the discussion. >>> >>> Thanks, >>> Sangheon >>> >>> >>> On 12/03/2015 12:03 AM, Bengt Rutisson wrote: >>>> >>>> Hi Sangheon, >>>> >>>> This all sounds good. Looking forward to the next webrev. >>>> >>>> Thanks, >>>> Bengt >>>> >>>> On 2015-12-02 19:08, sangheon.kim wrote: >>>>> Hi Bengt, >>>>> >>>>> >>>>> On 12/02/2015 01:00 AM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi Sangheon, >>>>>> >>>>>> Sorry again for the late reply. Comments inline. >>>>> No not at all. >>>>> Thank you for taking time for this review! >>>>> >>>>>> >>>>>> On 2015-11-24 19:48, sangheon.kim wrote: >>>>>>> Hi Bengt, >>>>>>> >>>>>>> Thank you so much for reviewing this patch! >>>>>>> >>>>>>> On 11/24/2015 05:12 AM, Bengt Rutisson wrote: >>>>>>>> >>>>>>>> Hi Sangheon, >>>>>>>> >>>>>>>> Sorry for the very late reply to this review request. >>>>>>>> >>>>>>>> On 2015-10-22 01:40, sangheon.kim wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Can I get some reviews for this change of adding a trace event >>>>>>>>> for concurrent phases on CMS and G1? >>>>>>>>> >>>>>>>>> Currently we only measure pause times for major phases. >>>>>>>>> But I want to add 'concurrent mark' and 'concurrent sweep' >>>>>>>>> phases for CMS and 'concurrent mark' phase for G1. >>>>>>>>> To achieve this, I had to change ConcurrentGCTimer and related >>>>>>>>> classes. >>>>>>>>> >>>>>>>>> This patch includes: >>>>>>>>> 1) A concurrent phase can be measured only from >>>>>>>>> ConcurrentGCTimer and measuring an overlap between concurrent >>>>>>>>> and pause is not allowed as currently we don't have that use >>>>>>>>> case. And TimePartitions class(or related classes) will be >>>>>>>>> simpler than an overlap allowed case. >>>>>>>>> 2) I removed PausePhase and ConcurrentPhase which are derived >>>>>>>>> from GCPhase because I wanted to avoid heap allocation when >>>>>>>>> adding to GrowableArray. Instead introduced 'type' member >>>>>>>>> variable at GCPhase. >>>>>>>>> >>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8068394 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8068394/webrev.00/ >>>>>>>> >>>>>>>> Nice work! It is great to get some timing information for the >>>>>>>> concurrent phases. >>>>>>> Thanks! >>>>>>> >>>>>>>> >>>>>>>> A few questions/comments: >>>>>>>> >>>>>>>> CMS. >>>>>>>> >>>>>>>> You have added timing events for the concurrent phases mark and >>>>>>>> sweep, but not for other concurrent phases (preclean, >>>>>>>> abortable_preclean and reset_concurrent). I think that if you >>>>>>>> moved your calls to >>>>>>>> _gc_timer_cm->register_gc_concurrent_start() and >>>>>>>> _gc_timer_cm->register_gc_concurrent_end() into the constructor >>>>>>>> and destructor of CMSPhaseAccounting you would automatically >>>>>>>> get timing events for all concurrent phases. >>>>>>> I also considered about this idea but I was not clear whether it >>>>>>> is good measurement especially for 'sweep'. >>>>>>> We are using CMSPhaseAccounting for 5 cases. >>>>>>> I think for 'mark' and 'preclean' they are okay. (there are >>>>>>> non-product functions call before CMSPhaseAccounting. But they >>>>>>> are okay). >>>>>>> For 'abortable-preclean' and 'reset', they are good to have that. >>>>>>> But when it comes to 'sweep', there are timer and >>>>>>> CMSTokenSyncWithLocks related codes and I was not sure about these. >>>>>>> If you think they are also okay, I will change as you suggested. >>>>>> >>>>>> I think it is fine for the sweep part as well. If the >>>>>> CMSPhaseAccounting instance is not measuring the correct part of >>>>>> the work I think we should change it to measure what we want. >>>>>> That way we improve the existing measurements too. >>>>>> >>>>>> But as you stated in your follow up email, I think the sweep code >>>>>> is actually pretty much ok from this perspective. >>>>>> >>>>>> So, I would prefer to go with the CMSPhaseAccounting approach. >>>>> Okay, I already changed as you suggested. :) >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> G1. >>>>>>>> >>>>>>>> I think the use of _concurrent_marking_from_roots is >>>>>>>> unfortunate. It would be much cleaner if >>>>>>>> ConcurrentMark::register_mark_from_roots_phase_end() called >>>>>>>> register_gc_concurrent_end() directly. >>>>>>> I wanted to avoid introducing the new flag but the reason of it >>>>>>> was, as you know, to handle 'abort'. >>>>>>> When 'abort' happens we do need to end all timers before calling >>>>>>> 'GCTracer::report_gc_end()'. >>>>>>> And at this point we need a way to know whether concurrent timer >>>>>>> is started or not. >>>>>> >>>>>> As I tried to describe I think you can extend the scope of the >>>>>> timing to cover the part until the marking thread discovers that >>>>>> the marking was aborted. Basically moving the timing in to >>>>>> ConcurrentMarkThread::run_service(). >>>>> Oh, I mis-understood your point. Sorry. >>>>> I will try your recommendation. >>>>> >>>>>> >>>>>>> >>>>>>>> I realize that this would change the timing for when a >>>>>>>> concurrent marking is aborted. The whole time for a full GC (or >>>>>>>> even several full GCs) would be included in the concurrent >>>>>>>> marking phase. But from a code perspective that is what >>>>>>>> happens, so maybe that is the correct time to report? Also, I >>>>>>>> think the logging is reported that way so if we want to make it >>>>>>>> easy to match the timing events with the logging we might want >>>>>>>> to use about the same scope for timing. >>>>>>>> >>>>>>>> Why do we only measure the concurrent mark phase for G1? >>>>>>> This is good question. :) >>>>>>> I was comparing CMS and G1 for major concurrent phases. >>>>>>> And the candidates were 'concurrent mark/sweep (CMS)' and >>>>>>> 'concurrent mark(G1)'. >>>>>>> >>>>>>>> Wouldn't it be good to measure all concurrent phases? >>>>>>> Okay, Stefan Karlsson also pointed to have them as well so I >>>>>>> filed a separate CR for this. >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8143951 >>>>>> >>>>>> Ok. Is there a reason why we want to split this up into two >>>>>> changes? Why not add all the concurrent timing events at once? >>>>>> >>>>>> I'm ok with splitting it up into two changes, but then maybe the >>>>>> title for JDK-8068394 should be changed to indicate that it only >>>>>> adds events for the marking phase. Also, if we go with the >>>>>> CMSPhaseAccounting approach for CMS, you get events for all >>>>>> phases there. So, it will be a bit odd to have all concurrent >>>>>> phases handled for CMS but only concurrent mark for G1. >>>>> You are correct and I agree with you. >>>>> The only reason of split was due to limited time for FC. >>>>> But as we have enough time, let me close JDK-8143951 and include >>>>> concurrent mark for G1 as well. >>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> gcTraceSend.cpp >>>>>>>> >>>>>>>> 389 void visit(GCPhase* phase) { >>>>>>>> 390 switch (phase->type()) { >>>>>>>> 391 case GCPhase::PausePhaseType: >>>>>>>> 392 assert(phase->level() < PhasesStack::PHASE_LEVELS, >>>>>>>> "Need more event types for PausePhase"); >>>>>>>> 393 >>>>>>>> 394 switch (phase->level()) { >>>>>>>> 395 case 0: send_phase(phase); >>>>>>>> break; >>>>>>>> 396 case 1: >>>>>>>> send_phase(phase); break; >>>>>>>> 397 case 2: >>>>>>>> send_phase(phase); break; >>>>>>>> 398 case 3: >>>>>>>> send_phase(phase); break; >>>>>>>> 399 default: /* Ignore sending this phase */ break; >>>>>>>> 400 } >>>>>>>> 401 break; >>>>>>>> 402 >>>>>>>> 403 case GCPhase::ConcurrentPhaseType: >>>>>>>> 404 assert(phase->level() < 1, "There's only one level >>>>>>>> for ConcurrentPhase"); >>>>>>>> 405 >>>>>>>> 406 switch (phase->level()) { >>>>>>>> 407 case 0: >>>>>>>> send_phase(phase); break; >>>>>>>> 408 default: /* Ignore sending this phase */ break; >>>>>>>> 409 } >>>>>>>> 410 break; >>>>>>>> 411 } >>>>>>>> 412 } >>>>>>>> 413 }; >>>>>>>> >>>>>>>> Since there are only two values for GCPhase::PhaseType it seems >>>>>>>> a bit odd to use a switch statement. I think I would prefer to >>>>>>>> factor out the code for the different types a bit too. So, >>>>>>>> maybe something like: >>>>>>>> >>>>>>>> void visit(GCPhase* phase) { >>>>>>>> if (phase->type() == GCPhase::PausePhaseType) { >>>>>>>> visit_pause(phase); >>>>>>>> } else { >>>>>>>> assert(phase->type() == GCPhase::ConcurrentPhaseType, ""); >>>>>>>> visit_concurrent(phase); >>>>>>>> } >>>>>>>> } >>>>>>> This seems better. I will fix. >>>>>> >>>>>> Good. Thanks! >>>>> :) >>>>> >>>>> I will post next webrev when I'm ready, including JDK-8143951 part >>>>> as well. >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>>> >>>>>> Bengt >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bengt >>>>>>>> >>>>>>>>> Testing: JPRT >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sangheon >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From sangheon.kim at oracle.com Tue Dec 15 19:37:28 2015 From: sangheon.kim at oracle.com (sangheon) Date: Tue, 15 Dec 2015 11:37:28 -0800 Subject: RFR (M): JDK-8068394: Trace event for concurrent GC phases In-Reply-To: <56706AC7.1070708@oracle.com> References: <56282271.5090108@oracle.com> <56546233.20006@oracle.com> <5654B10E.1060701@oracle.com> <565EB318.8060607@oracle.com> <565F33A8.6060608@oracle.com> <565FF761.30200@oracle.com> <566FB2BA.5020408@oracle.com> <566FD637.4060909@oracle.com> <56706A22.9070803@oracle.com> <56706AC7.1070708@oracle.com> Message-ID: <56706BF8.6030604@oracle.com> Hi Stefan, On 12/15/2015 11:32 AM, Stefan Karlsson wrote: > Hi Sangheon, > > On 2015-12-15 20:29, sangheon wrote: >> Hi Stefan, >> >> Thank you for looking at official RFR as well. >> >> On 12/15/2015 12:58 AM, Stefan Karlsson wrote: >>> Hi Sangheon, >>> >>> On 2015-12-15 07:27, sangheon wrote: >>>> Hi Bengt and all, >>>> >>>> Here's a next webrev. >>>> Bengt and I had a discussion on other thread and he and Stefan >>>> Karlsson suggested simpler design. >>>> >>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01 >>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01_to_00 >>> >>> Thanks for doing the simplifications of the patch. >>> >>> I have a couple of comments: >>> Could you replace NOT_PRODUCT with DEBUG_ONLY, and #ifndef PRODUCT >>> with #ifdef ASSERT. Otherwise, you'll get inconsistencies when >>> building with optimized builds where neither PRODUCT nor ASSERT is >>> defined. >> Okay, I will do. >> But you also pointed that whether this flag is really needed below. >> >>> >>> 81 void ConcurrentGCTimer::register_gc_concurrent_start(const char* >>> name, const Ticks& time) { >>> 82 assert(!_is_concurrent_phase_active, "A concurrent phase is >>> already active."); >>> 83 _time_partitions.report_gc_phase_start(name, time, >>> GCPhase::ConcurrentPhaseType); >>> 84 NOT_PRODUCT(_is_concurrent_phase_active = true;) >>> 85 } >>> >>> 162 class ConcurrentGCTimer : public GCTimer { >>> 163 // ConcurrentGCTimer can't be used if there is an overlap >>> between a pause phase and a concurrent phase. >>> 164 // _is_concurrent_phase_active is used to find above case. >>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >>> 166 >>> 167 public: >>> 168 #ifndef PRODUCT >>> 169 ConcurrentGCTimer(): GCTimer(), >>> _is_concurrent_phase_active(false) {}; >>> 170 #endif Is it really worth optimizing away the boolean? The code >>> would be cleaner without these macros. >> I just wanted to prevent mis-use of concurrent timer for overlapping >> phase. >> A pause phase nor another concurrent phase can't be started if a >> concurrent phase is already started. >> I think this would be nice to have. But I don't have a strong opinion >> on this as currently we don't have these situations. > > I meant that we could keep the the variable in the product builds as > well. Just to get rid of the noisy PRODUCT / DEBUG_ONLY macros. It > could even be useful for future debugging. ;) Oops! I am okay with removing this macro. Let me post a new webrev soon. Thank you for the real time answer! Sangheon >> >>> >>> >>> Why are you using volatile here? I don't see why that should be needed. >>> >>> 162 class ConcurrentGCTimer : public GCTimer { >>> 163 // ConcurrentGCTimer can't be used if there is an overlap >>> between a pause phase and a concurrent phase. >>> 164 // _is_concurrent_phase_active is used to find above case. >>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >> You are right, volatile is not needed here. >> I was thinking register_gc_concurrent_end() would be called from >> different threads(ConcurrentMarkThread and VMThread), but as it only >> happens from safepoint, I think volatile should be removed. >> >> I will post a new webrev with your opinion about the flag. > > Great. > > Thanks, > StefanK > >> >> Thanks, >> Sangheon >> >> >>> >>> >>> Thanks, >>> StefanK >>> >>>> >>>> This webrev includes: >>>> 1. Moving concurrent phase measurement into CMSPhaseAccounting >>>> class. So we can check all concurrent phases from CMS. >>>> >>>> 2. Renamed a new flag introduced from webrev.00 for general use, >>>> _concurrent_phase_started. >>>> >>>> 3. Added helper class for concurrent phase measurement, >>>> GCConcPhaseTimer. And used this class for all concurrent phases. >>>> >>>> 4. Flag checking is moved from >>>> G1CollectedHeap::register_concurrent_cycle_end() to >>>> ConcurrentMark::abort(). >>>> >>>> 5. Changed switch() to if else statement at gcTraceSend. >>>> >>>> Many thanks to Bengt and Stefan Karlsson for the discussion. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> On 12/03/2015 12:03 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi Sangheon, >>>>> >>>>> This all sounds good. Looking forward to the next webrev. >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> On 2015-12-02 19:08, sangheon.kim wrote: >>>>>> Hi Bengt, >>>>>> >>>>>> >>>>>> On 12/02/2015 01:00 AM, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> Sorry again for the late reply. Comments inline. >>>>>> No not at all. >>>>>> Thank you for taking time for this review! >>>>>> >>>>>>> >>>>>>> On 2015-11-24 19:48, sangheon.kim wrote: >>>>>>>> Hi Bengt, >>>>>>>> >>>>>>>> Thank you so much for reviewing this patch! >>>>>>>> >>>>>>>> On 11/24/2015 05:12 AM, Bengt Rutisson wrote: >>>>>>>>> >>>>>>>>> Hi Sangheon, >>>>>>>>> >>>>>>>>> Sorry for the very late reply to this review request. >>>>>>>>> >>>>>>>>> On 2015-10-22 01:40, sangheon.kim wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Can I get some reviews for this change of adding a trace >>>>>>>>>> event for concurrent phases on CMS and G1? >>>>>>>>>> >>>>>>>>>> Currently we only measure pause times for major phases. >>>>>>>>>> But I want to add 'concurrent mark' and 'concurrent sweep' >>>>>>>>>> phases for CMS and 'concurrent mark' phase for G1. >>>>>>>>>> To achieve this, I had to change ConcurrentGCTimer and >>>>>>>>>> related classes. >>>>>>>>>> >>>>>>>>>> This patch includes: >>>>>>>>>> 1) A concurrent phase can be measured only from >>>>>>>>>> ConcurrentGCTimer and measuring an overlap between concurrent >>>>>>>>>> and pause is not allowed as currently we don't have that use >>>>>>>>>> case. And TimePartitions class(or related classes) will be >>>>>>>>>> simpler than an overlap allowed case. >>>>>>>>>> 2) I removed PausePhase and ConcurrentPhase which are derived >>>>>>>>>> from GCPhase because I wanted to avoid heap allocation when >>>>>>>>>> adding to GrowableArray. Instead introduced 'type' member >>>>>>>>>> variable at GCPhase. >>>>>>>>>> >>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8068394 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8068394/webrev.00/ >>>>>>>>> >>>>>>>>> Nice work! It is great to get some timing information for the >>>>>>>>> concurrent phases. >>>>>>>> Thanks! >>>>>>>> >>>>>>>>> >>>>>>>>> A few questions/comments: >>>>>>>>> >>>>>>>>> CMS. >>>>>>>>> >>>>>>>>> You have added timing events for the concurrent phases mark >>>>>>>>> and sweep, but not for other concurrent phases (preclean, >>>>>>>>> abortable_preclean and reset_concurrent). I think that if you >>>>>>>>> moved your calls to >>>>>>>>> _gc_timer_cm->register_gc_concurrent_start() and >>>>>>>>> _gc_timer_cm->register_gc_concurrent_end() into the >>>>>>>>> constructor and destructor of CMSPhaseAccounting you would >>>>>>>>> automatically get timing events for all concurrent phases. >>>>>>>> I also considered about this idea but I was not clear whether >>>>>>>> it is good measurement especially for 'sweep'. >>>>>>>> We are using CMSPhaseAccounting for 5 cases. >>>>>>>> I think for 'mark' and 'preclean' they are okay. (there are >>>>>>>> non-product functions call before CMSPhaseAccounting. But they >>>>>>>> are okay). >>>>>>>> For 'abortable-preclean' and 'reset', they are good to have that. >>>>>>>> But when it comes to 'sweep', there are timer and >>>>>>>> CMSTokenSyncWithLocks related codes and I was not sure about >>>>>>>> these. >>>>>>>> If you think they are also okay, I will change as you suggested. >>>>>>> >>>>>>> I think it is fine for the sweep part as well. If the >>>>>>> CMSPhaseAccounting instance is not measuring the correct part of >>>>>>> the work I think we should change it to measure what we want. >>>>>>> That way we improve the existing measurements too. >>>>>>> >>>>>>> But as you stated in your follow up email, I think the sweep >>>>>>> code is actually pretty much ok from this perspective. >>>>>>> >>>>>>> So, I would prefer to go with the CMSPhaseAccounting approach. >>>>>> Okay, I already changed as you suggested. :) >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> G1. >>>>>>>>> >>>>>>>>> I think the use of _concurrent_marking_from_roots is >>>>>>>>> unfortunate. It would be much cleaner if >>>>>>>>> ConcurrentMark::register_mark_from_roots_phase_end() called >>>>>>>>> register_gc_concurrent_end() directly. >>>>>>>> I wanted to avoid introducing the new flag but the reason of it >>>>>>>> was, as you know, to handle 'abort'. >>>>>>>> When 'abort' happens we do need to end all timers before >>>>>>>> calling 'GCTracer::report_gc_end()'. >>>>>>>> And at this point we need a way to know whether concurrent >>>>>>>> timer is started or not. >>>>>>> >>>>>>> As I tried to describe I think you can extend the scope of the >>>>>>> timing to cover the part until the marking thread discovers that >>>>>>> the marking was aborted. Basically moving the timing in to >>>>>>> ConcurrentMarkThread::run_service(). >>>>>> Oh, I mis-understood your point. Sorry. >>>>>> I will try your recommendation. >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> I realize that this would change the timing for when a >>>>>>>>> concurrent marking is aborted. The whole time for a full GC >>>>>>>>> (or even several full GCs) would be included in the concurrent >>>>>>>>> marking phase. But from a code perspective that is what >>>>>>>>> happens, so maybe that is the correct time to report? Also, I >>>>>>>>> think the logging is reported that way so if we want to make >>>>>>>>> it easy to match the timing events with the logging we might >>>>>>>>> want to use about the same scope for timing. >>>>>>>>> >>>>>>>>> Why do we only measure the concurrent mark phase for G1? >>>>>>>> This is good question. :) >>>>>>>> I was comparing CMS and G1 for major concurrent phases. >>>>>>>> And the candidates were 'concurrent mark/sweep (CMS)' and >>>>>>>> 'concurrent mark(G1)'. >>>>>>>> >>>>>>>>> Wouldn't it be good to measure all concurrent phases? >>>>>>>> Okay, Stefan Karlsson also pointed to have them as well so I >>>>>>>> filed a separate CR for this. >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8143951 >>>>>>> >>>>>>> Ok. Is there a reason why we want to split this up into two >>>>>>> changes? Why not add all the concurrent timing events at once? >>>>>>> >>>>>>> I'm ok with splitting it up into two changes, but then maybe the >>>>>>> title for JDK-8068394 should be changed to indicate that it only >>>>>>> adds events for the marking phase. Also, if we go with the >>>>>>> CMSPhaseAccounting approach for CMS, you get events for all >>>>>>> phases there. So, it will be a bit odd to have all concurrent >>>>>>> phases handled for CMS but only concurrent mark for G1. >>>>>> You are correct and I agree with you. >>>>>> The only reason of split was due to limited time for FC. >>>>>> But as we have enough time, let me close JDK-8143951 and include >>>>>> concurrent mark for G1 as well. >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> gcTraceSend.cpp >>>>>>>>> >>>>>>>>> 389 void visit(GCPhase* phase) { >>>>>>>>> 390 switch (phase->type()) { >>>>>>>>> 391 case GCPhase::PausePhaseType: >>>>>>>>> 392 assert(phase->level() < >>>>>>>>> PhasesStack::PHASE_LEVELS, "Need more event types for >>>>>>>>> PausePhase"); >>>>>>>>> 393 >>>>>>>>> 394 switch (phase->level()) { >>>>>>>>> 395 case 0: send_phase(phase); >>>>>>>>> break; >>>>>>>>> 396 case 1: >>>>>>>>> send_phase(phase); break; >>>>>>>>> 397 case 2: >>>>>>>>> send_phase(phase); break; >>>>>>>>> 398 case 3: >>>>>>>>> send_phase(phase); break; >>>>>>>>> 399 default: /* Ignore sending this phase */ break; >>>>>>>>> 400 } >>>>>>>>> 401 break; >>>>>>>>> 402 >>>>>>>>> 403 case GCPhase::ConcurrentPhaseType: >>>>>>>>> 404 assert(phase->level() < 1, "There's only one >>>>>>>>> level for ConcurrentPhase"); >>>>>>>>> 405 >>>>>>>>> 406 switch (phase->level()) { >>>>>>>>> 407 case 0: >>>>>>>>> send_phase(phase); break; >>>>>>>>> 408 default: /* Ignore sending this phase */ break; >>>>>>>>> 409 } >>>>>>>>> 410 break; >>>>>>>>> 411 } >>>>>>>>> 412 } >>>>>>>>> 413 }; >>>>>>>>> >>>>>>>>> Since there are only two values for GCPhase::PhaseType it >>>>>>>>> seems a bit odd to use a switch statement. I think I would >>>>>>>>> prefer to factor out the code for the different types a bit >>>>>>>>> too. So, maybe something like: >>>>>>>>> >>>>>>>>> void visit(GCPhase* phase) { >>>>>>>>> if (phase->type() == GCPhase::PausePhaseType) { >>>>>>>>> visit_pause(phase); >>>>>>>>> } else { >>>>>>>>> assert(phase->type() == GCPhase::ConcurrentPhaseType, ""); >>>>>>>>> visit_concurrent(phase); >>>>>>>>> } >>>>>>>>> } >>>>>>>> This seems better. I will fix. >>>>>>> >>>>>>> Good. Thanks! >>>>>> :) >>>>>> >>>>>> I will post next webrev when I'm ready, including JDK-8143951 >>>>>> part as well. >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>>> >>>>>>> Bengt >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Bengt >>>>>>>>> >>>>>>>>>> Testing: JPRT >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Sangheon >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From poonam.bajaj at oracle.com Tue Dec 15 21:32:17 2015 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Tue, 15 Dec 2015 13:32:17 -0800 Subject: RFR: JDK-8145442: Add an option to verify remembered sets for G1 Message-ID: <567086E1.7080501@oracle.com> Hello, Please review these changes that add a diagnostic VM option 'G1VerifyRSetsAfterEvacuationPause' that when turned on enables the verification of Rem Sets of heap regions. Bug: JDK-8145442: Add an option to verify remembered sets for G1 Webrev: http://cr.openjdk.java.net/~poonam/8145442/webrev.00/ Testing: JPRT, GCBasher Thanks, Poonam From sangheon.kim at oracle.com Tue Dec 15 22:18:09 2015 From: sangheon.kim at oracle.com (sangheon) Date: Tue, 15 Dec 2015 14:18:09 -0800 Subject: RFR (M): JDK-8068394: Trace event for concurrent GC phases In-Reply-To: <56706BF8.6030604@oracle.com> References: <56282271.5090108@oracle.com> <56546233.20006@oracle.com> <5654B10E.1060701@oracle.com> <565EB318.8060607@oracle.com> <565F33A8.6060608@oracle.com> <565FF761.30200@oracle.com> <566FB2BA.5020408@oracle.com> <566FD637.4060909@oracle.com> <56706A22.9070803@oracle.com> <56706AC7.1070708@oracle.com> <56706BF8.6030604@oracle.com> Message-ID: <567091A1.1050105@oracle.com> Hi Stefan, Here's the next webrev which includes your suggestion. - Removed 'NOT_PRODUCT' and '#ifndef PRODUCT'. (Stefan) - Removed volatile keyword at ConcurrentGCTimer::_is_concurrent_phase_active. (Stefan) - Removed volatile keyword at ConcurrentMark::_concurrent_phase_started. This should be removed as well. http://cr.openjdk.java.net/~sangheki/8068394/webrev.02 http://cr.openjdk.java.net/~sangheki/8068394/webrev.02_to_01/ Thanks, Sangheon On 12/15/2015 11:37 AM, sangheon wrote: > Hi Stefan, > > On 12/15/2015 11:32 AM, Stefan Karlsson wrote: >> Hi Sangheon, >> >> On 2015-12-15 20:29, sangheon wrote: >>> Hi Stefan, >>> >>> Thank you for looking at official RFR as well. >>> >>> On 12/15/2015 12:58 AM, Stefan Karlsson wrote: >>>> Hi Sangheon, >>>> >>>> On 2015-12-15 07:27, sangheon wrote: >>>>> Hi Bengt and all, >>>>> >>>>> Here's a next webrev. >>>>> Bengt and I had a discussion on other thread and he and Stefan >>>>> Karlsson suggested simpler design. >>>>> >>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01 >>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01_to_00 >>>> >>>> Thanks for doing the simplifications of the patch. >>>> >>>> I have a couple of comments: >>>> Could you replace NOT_PRODUCT with DEBUG_ONLY, and #ifndef PRODUCT >>>> with #ifdef ASSERT. Otherwise, you'll get inconsistencies when >>>> building with optimized builds where neither PRODUCT nor ASSERT is >>>> defined. >>> Okay, I will do. >>> But you also pointed that whether this flag is really needed below. >>> >>>> >>>> 81 void ConcurrentGCTimer::register_gc_concurrent_start(const char* >>>> name, const Ticks& time) { >>>> 82 assert(!_is_concurrent_phase_active, "A concurrent phase is >>>> already active."); >>>> 83 _time_partitions.report_gc_phase_start(name, time, >>>> GCPhase::ConcurrentPhaseType); >>>> 84 NOT_PRODUCT(_is_concurrent_phase_active = true;) >>>> 85 } >>>> >>>> 162 class ConcurrentGCTimer : public GCTimer { >>>> 163 // ConcurrentGCTimer can't be used if there is an overlap >>>> between a pause phase and a concurrent phase. >>>> 164 // _is_concurrent_phase_active is used to find above case. >>>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >>>> 166 >>>> 167 public: >>>> 168 #ifndef PRODUCT >>>> 169 ConcurrentGCTimer(): GCTimer(), >>>> _is_concurrent_phase_active(false) {}; >>>> 170 #endif Is it really worth optimizing away the boolean? The code >>>> would be cleaner without these macros. >>> I just wanted to prevent mis-use of concurrent timer for overlapping >>> phase. >>> A pause phase nor another concurrent phase can't be started if a >>> concurrent phase is already started. >>> I think this would be nice to have. But I don't have a strong >>> opinion on this as currently we don't have these situations. >> >> I meant that we could keep the the variable in the product builds as >> well. Just to get rid of the noisy PRODUCT / DEBUG_ONLY macros. It >> could even be useful for future debugging. ;) > Oops! > I am okay with removing this macro. > > Let me post a new webrev soon. > Thank you for the real time answer! > > Sangheon > > >>> >>>> >>>> >>>> Why are you using volatile here? I don't see why that should be >>>> needed. >>>> >>>> 162 class ConcurrentGCTimer : public GCTimer { >>>> 163 // ConcurrentGCTimer can't be used if there is an overlap >>>> between a pause phase and a concurrent phase. >>>> 164 // _is_concurrent_phase_active is used to find above case. >>>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >>> You are right, volatile is not needed here. >>> I was thinking register_gc_concurrent_end() would be called from >>> different threads(ConcurrentMarkThread and VMThread), but as it only >>> happens from safepoint, I think volatile should be removed. >>> >>> I will post a new webrev with your opinion about the flag. >> >> Great. >> >> Thanks, >> StefanK >> >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> >>>> Thanks, >>>> StefanK >>>> >>>>> >>>>> This webrev includes: >>>>> 1. Moving concurrent phase measurement into CMSPhaseAccounting >>>>> class. So we can check all concurrent phases from CMS. >>>>> >>>>> 2. Renamed a new flag introduced from webrev.00 for general use, >>>>> _concurrent_phase_started. >>>>> >>>>> 3. Added helper class for concurrent phase measurement, >>>>> GCConcPhaseTimer. And used this class for all concurrent phases. >>>>> >>>>> 4. Flag checking is moved from >>>>> G1CollectedHeap::register_concurrent_cycle_end() to >>>>> ConcurrentMark::abort(). >>>>> >>>>> 5. Changed switch() to if else statement at gcTraceSend. >>>>> >>>>> Many thanks to Bengt and Stefan Karlsson for the discussion. >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>> On 12/03/2015 12:03 AM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi Sangheon, >>>>>> >>>>>> This all sounds good. Looking forward to the next webrev. >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>> On 2015-12-02 19:08, sangheon.kim wrote: >>>>>>> Hi Bengt, >>>>>>> >>>>>>> >>>>>>> On 12/02/2015 01:00 AM, Bengt Rutisson wrote: >>>>>>>> >>>>>>>> Hi Sangheon, >>>>>>>> >>>>>>>> Sorry again for the late reply. Comments inline. >>>>>>> No not at all. >>>>>>> Thank you for taking time for this review! >>>>>>> >>>>>>>> >>>>>>>> On 2015-11-24 19:48, sangheon.kim wrote: >>>>>>>>> Hi Bengt, >>>>>>>>> >>>>>>>>> Thank you so much for reviewing this patch! >>>>>>>>> >>>>>>>>> On 11/24/2015 05:12 AM, Bengt Rutisson wrote: >>>>>>>>>> >>>>>>>>>> Hi Sangheon, >>>>>>>>>> >>>>>>>>>> Sorry for the very late reply to this review request. >>>>>>>>>> >>>>>>>>>> On 2015-10-22 01:40, sangheon.kim wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Can I get some reviews for this change of adding a trace >>>>>>>>>>> event for concurrent phases on CMS and G1? >>>>>>>>>>> >>>>>>>>>>> Currently we only measure pause times for major phases. >>>>>>>>>>> But I want to add 'concurrent mark' and 'concurrent sweep' >>>>>>>>>>> phases for CMS and 'concurrent mark' phase for G1. >>>>>>>>>>> To achieve this, I had to change ConcurrentGCTimer and >>>>>>>>>>> related classes. >>>>>>>>>>> >>>>>>>>>>> This patch includes: >>>>>>>>>>> 1) A concurrent phase can be measured only from >>>>>>>>>>> ConcurrentGCTimer and measuring an overlap between >>>>>>>>>>> concurrent and pause is not allowed as currently we don't >>>>>>>>>>> have that use case. And TimePartitions class(or related >>>>>>>>>>> classes) will be simpler than an overlap allowed case. >>>>>>>>>>> 2) I removed PausePhase and ConcurrentPhase which are >>>>>>>>>>> derived from GCPhase because I wanted to avoid heap >>>>>>>>>>> allocation when adding to GrowableArray. Instead introduced >>>>>>>>>>> 'type' member variable at GCPhase. >>>>>>>>>>> >>>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8068394 >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8068394/webrev.00/ >>>>>>>>>> >>>>>>>>>> Nice work! It is great to get some timing information for the >>>>>>>>>> concurrent phases. >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>>> >>>>>>>>>> A few questions/comments: >>>>>>>>>> >>>>>>>>>> CMS. >>>>>>>>>> >>>>>>>>>> You have added timing events for the concurrent phases mark >>>>>>>>>> and sweep, but not for other concurrent phases (preclean, >>>>>>>>>> abortable_preclean and reset_concurrent). I think that if you >>>>>>>>>> moved your calls to >>>>>>>>>> _gc_timer_cm->register_gc_concurrent_start() and >>>>>>>>>> _gc_timer_cm->register_gc_concurrent_end() into the >>>>>>>>>> constructor and destructor of CMSPhaseAccounting you would >>>>>>>>>> automatically get timing events for all concurrent phases. >>>>>>>>> I also considered about this idea but I was not clear whether >>>>>>>>> it is good measurement especially for 'sweep'. >>>>>>>>> We are using CMSPhaseAccounting for 5 cases. >>>>>>>>> I think for 'mark' and 'preclean' they are okay. (there are >>>>>>>>> non-product functions call before CMSPhaseAccounting. But they >>>>>>>>> are okay). >>>>>>>>> For 'abortable-preclean' and 'reset', they are good to have that. >>>>>>>>> But when it comes to 'sweep', there are timer and >>>>>>>>> CMSTokenSyncWithLocks related codes and I was not sure about >>>>>>>>> these. >>>>>>>>> If you think they are also okay, I will change as you suggested. >>>>>>>> >>>>>>>> I think it is fine for the sweep part as well. If the >>>>>>>> CMSPhaseAccounting instance is not measuring the correct part >>>>>>>> of the work I think we should change it to measure what we >>>>>>>> want. That way we improve the existing measurements too. >>>>>>>> >>>>>>>> But as you stated in your follow up email, I think the sweep >>>>>>>> code is actually pretty much ok from this perspective. >>>>>>>> >>>>>>>> So, I would prefer to go with the CMSPhaseAccounting approach. >>>>>>> Okay, I already changed as you suggested. :) >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> G1. >>>>>>>>>> >>>>>>>>>> I think the use of _concurrent_marking_from_roots is >>>>>>>>>> unfortunate. It would be much cleaner if >>>>>>>>>> ConcurrentMark::register_mark_from_roots_phase_end() called >>>>>>>>>> register_gc_concurrent_end() directly. >>>>>>>>> I wanted to avoid introducing the new flag but the reason of >>>>>>>>> it was, as you know, to handle 'abort'. >>>>>>>>> When 'abort' happens we do need to end all timers before >>>>>>>>> calling 'GCTracer::report_gc_end()'. >>>>>>>>> And at this point we need a way to know whether concurrent >>>>>>>>> timer is started or not. >>>>>>>> >>>>>>>> As I tried to describe I think you can extend the scope of the >>>>>>>> timing to cover the part until the marking thread discovers >>>>>>>> that the marking was aborted. Basically moving the timing in to >>>>>>>> ConcurrentMarkThread::run_service(). >>>>>>> Oh, I mis-understood your point. Sorry. >>>>>>> I will try your recommendation. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> I realize that this would change the timing for when a >>>>>>>>>> concurrent marking is aborted. The whole time for a full GC >>>>>>>>>> (or even several full GCs) would be included in the >>>>>>>>>> concurrent marking phase. But from a code perspective that is >>>>>>>>>> what happens, so maybe that is the correct time to report? >>>>>>>>>> Also, I think the logging is reported that way so if we want >>>>>>>>>> to make it easy to match the timing events with the logging >>>>>>>>>> we might want to use about the same scope for timing. >>>>>>>>>> >>>>>>>>>> Why do we only measure the concurrent mark phase for G1? >>>>>>>>> This is good question. :) >>>>>>>>> I was comparing CMS and G1 for major concurrent phases. >>>>>>>>> And the candidates were 'concurrent mark/sweep (CMS)' and >>>>>>>>> 'concurrent mark(G1)'. >>>>>>>>> >>>>>>>>>> Wouldn't it be good to measure all concurrent phases? >>>>>>>>> Okay, Stefan Karlsson also pointed to have them as well so I >>>>>>>>> filed a separate CR for this. >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8143951 >>>>>>>> >>>>>>>> Ok. Is there a reason why we want to split this up into two >>>>>>>> changes? Why not add all the concurrent timing events at once? >>>>>>>> >>>>>>>> I'm ok with splitting it up into two changes, but then maybe >>>>>>>> the title for JDK-8068394 should be changed to indicate that it >>>>>>>> only adds events for the marking phase. Also, if we go with the >>>>>>>> CMSPhaseAccounting approach for CMS, you get events for all >>>>>>>> phases there. So, it will be a bit odd to have all concurrent >>>>>>>> phases handled for CMS but only concurrent mark for G1. >>>>>>> You are correct and I agree with you. >>>>>>> The only reason of split was due to limited time for FC. >>>>>>> But as we have enough time, let me close JDK-8143951 and include >>>>>>> concurrent mark for G1 as well. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> gcTraceSend.cpp >>>>>>>>>> >>>>>>>>>> 389 void visit(GCPhase* phase) { >>>>>>>>>> 390 switch (phase->type()) { >>>>>>>>>> 391 case GCPhase::PausePhaseType: >>>>>>>>>> 392 assert(phase->level() < >>>>>>>>>> PhasesStack::PHASE_LEVELS, "Need more event types for >>>>>>>>>> PausePhase"); >>>>>>>>>> 393 >>>>>>>>>> 394 switch (phase->level()) { >>>>>>>>>> 395 case 0: send_phase(phase); >>>>>>>>>> break; >>>>>>>>>> 396 case 1: >>>>>>>>>> send_phase(phase); break; >>>>>>>>>> 397 case 2: >>>>>>>>>> send_phase(phase); break; >>>>>>>>>> 398 case 3: >>>>>>>>>> send_phase(phase); break; >>>>>>>>>> 399 default: /* Ignore sending this phase */ break; >>>>>>>>>> 400 } >>>>>>>>>> 401 break; >>>>>>>>>> 402 >>>>>>>>>> 403 case GCPhase::ConcurrentPhaseType: >>>>>>>>>> 404 assert(phase->level() < 1, "There's only one >>>>>>>>>> level for ConcurrentPhase"); >>>>>>>>>> 405 >>>>>>>>>> 406 switch (phase->level()) { >>>>>>>>>> 407 case 0: >>>>>>>>>> send_phase(phase); break; >>>>>>>>>> 408 default: /* Ignore sending this phase */ break; >>>>>>>>>> 409 } >>>>>>>>>> 410 break; >>>>>>>>>> 411 } >>>>>>>>>> 412 } >>>>>>>>>> 413 }; >>>>>>>>>> >>>>>>>>>> Since there are only two values for GCPhase::PhaseType it >>>>>>>>>> seems a bit odd to use a switch statement. I think I would >>>>>>>>>> prefer to factor out the code for the different types a bit >>>>>>>>>> too. So, maybe something like: >>>>>>>>>> >>>>>>>>>> void visit(GCPhase* phase) { >>>>>>>>>> if (phase->type() == GCPhase::PausePhaseType) { >>>>>>>>>> visit_pause(phase); >>>>>>>>>> } else { >>>>>>>>>> assert(phase->type() == GCPhase::ConcurrentPhaseType, ""); >>>>>>>>>> visit_concurrent(phase); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>> This seems better. I will fix. >>>>>>>> >>>>>>>> Good. Thanks! >>>>>>> :) >>>>>>> >>>>>>> I will post next webrev when I'm ready, including JDK-8143951 >>>>>>> part as well. >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Bengt >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sangheon >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Bengt >>>>>>>>>> >>>>>>>>>>> Testing: JPRT >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Sangheon >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From sangheon.kim at oracle.com Tue Dec 15 23:10:08 2015 From: sangheon.kim at oracle.com (sangheon) Date: Tue, 15 Dec 2015 15:10:08 -0800 Subject: RFR(s): 8144949: TestOptionsWithRanges -XX:NUMAInterleaveGranularity=2147483648 crashes VM Message-ID: <56709DD0.80808@oracle.com> Hi all, Could I get some reviews for this change? Current 32bit binary with NUMAInterleavingGranularity=2g on server mode fires an assert on Windows as we are proceeding without memory allocation failure check at CodeCache::reserve_heap_memory. I think the constraint function can be removed with maximum range of 2G/8192G. These are the maximum available memory on Windows and smaller values can be used but I wanted to avoid adding artificial limit. With this limitation, current constraint function for overflow check is not needed. And we need to check allocation failure. This issue is not reproducible with client mode as the different default value of ReservedCodeCacheSize sets SegmentedCodeCache to false. And CodeCache::reserve_heap_memory() is called only when SegmentedCodeCache is enabled. Skipped adding a test as TestOptionsWithRanges.java is enough when this is combined with nightly vm option rotation. CR: https://bugs.openjdk.java.net/browse/JDK-8144949 Webrev: http://cr.openjdk.java.net/~sangheki/8144949/webrev.00 Testing: JPRT (with TestOptionsWithRanges.java enabled), manual tests on Windows machine(to test several option combination). Thanks, Sangheon From poonam.bajaj at oracle.com Tue Dec 15 23:15:03 2015 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Tue, 15 Dec 2015 15:15:03 -0800 Subject: RFR: JDK-8072725: Provide more granular levels for GC verification Message-ID: <56709EF7.9020003@oracle.com> Hello, Please review these changes that split up the work done under Verify*GC options. This will be very useful in debugging GC issues/crashes where verifying the whole memory system with Verify*GC options slows down the process and makes it impossible to reproduce the problem. The changes introduce a new option /VerifySubSet///that can be used to specify the specific memory sub-systems that one wants to verify. It can be one or more of the sub-systems from these: threads, heap, symbol_table, string_table, codecache, dictionary, classloader_data_graph, metaspace, jni_handles, c-heap and codecache_oops. If nothing is specified with /VerifySubSet/ then whole of the memory system is verified with Verify*GC options. Bug:JDK-8072725: Provide more granular levels for GC verification Webrev: http://cr.openjdk.java.net/~poonam/8072725/webrev.00/ Testing: JPRT, tested the changes with a simple test program. Thanks, Poonam -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.wilhelmsson at oracle.com Tue Dec 15 23:33:25 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 16 Dec 2015 00:33:25 +0100 Subject: RFR(s): 8144949: TestOptionsWithRanges -XX:NUMAInterleaveGranularity=2147483648 crashes VM In-Reply-To: <56709DD0.80808@oracle.com> References: <56709DD0.80808@oracle.com> Message-ID: <5670A345.6030200@oracle.com> Looks good! /Jesper Den 16/12/15 kl. 00:10, skrev sangheon: > Hi all, > > Could I get some reviews for this change? > > Current 32bit binary with NUMAInterleavingGranularity=2g on server mode fires an > assert on Windows as we are proceeding without memory allocation failure check > at CodeCache::reserve_heap_memory. > > I think the constraint function can be removed with maximum range of 2G/8192G. > These are the maximum available memory on Windows and smaller values can be used > but I wanted to avoid adding artificial limit. With this limitation, current > constraint function for overflow check is not needed. > And we need to check allocation failure. > > This issue is not reproducible with client mode as the different default value > of ReservedCodeCacheSize sets SegmentedCodeCache to false. And > CodeCache::reserve_heap_memory() is called only when SegmentedCodeCache is enabled. > > Skipped adding a test as TestOptionsWithRanges.java is enough when this is > combined with nightly vm option rotation. > > CR: https://bugs.openjdk.java.net/browse/JDK-8144949 > Webrev: http://cr.openjdk.java.net/~sangheki/8144949/webrev.00 > Testing: JPRT (with TestOptionsWithRanges.java enabled), manual tests on Windows > machine(to test several option combination). > > Thanks, > Sangheon > From sangheon.kim at oracle.com Tue Dec 15 23:47:44 2015 From: sangheon.kim at oracle.com (sangheon) Date: Tue, 15 Dec 2015 15:47:44 -0800 Subject: RFR(s): 8144949: TestOptionsWithRanges -XX:NUMAInterleaveGranularity=2147483648 crashes VM In-Reply-To: <5670A345.6030200@oracle.com> References: <56709DD0.80808@oracle.com> <5670A345.6030200@oracle.com> Message-ID: <5670A6A0.6010000@oracle.com> Hi Jesper, Thanks for the review! Sangheon On 12/15/2015 03:33 PM, Jesper Wilhelmsson wrote: > Looks good! > /Jesper > > Den 16/12/15 kl. 00:10, skrev sangheon: >> Hi all, >> >> Could I get some reviews for this change? >> >> Current 32bit binary with NUMAInterleavingGranularity=2g on server >> mode fires an >> assert on Windows as we are proceeding without memory allocation >> failure check >> at CodeCache::reserve_heap_memory. >> >> I think the constraint function can be removed with maximum range of >> 2G/8192G. >> These are the maximum available memory on Windows and smaller values >> can be used >> but I wanted to avoid adding artificial limit. With this limitation, >> current >> constraint function for overflow check is not needed. >> And we need to check allocation failure. >> >> This issue is not reproducible with client mode as the different >> default value >> of ReservedCodeCacheSize sets SegmentedCodeCache to false. And >> CodeCache::reserve_heap_memory() is called only when >> SegmentedCodeCache is enabled. >> >> Skipped adding a test as TestOptionsWithRanges.java is enough when >> this is >> combined with nightly vm option rotation. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8144949 >> Webrev: http://cr.openjdk.java.net/~sangheki/8144949/webrev.00 >> Testing: JPRT (with TestOptionsWithRanges.java enabled), manual tests >> on Windows >> machine(to test several option combination). >> >> Thanks, >> Sangheon >> From jon.masamitsu at oracle.com Wed Dec 16 00:38:21 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 15 Dec 2015 16:38:21 -0800 Subject: RFR(s): 8144949: TestOptionsWithRanges -XX:NUMAInterleaveGranularity=2147483648 crashes VM In-Reply-To: <5670A6A0.6010000@oracle.com> References: <56709DD0.80808@oracle.com> <5670A345.6030200@oracle.com> <5670A6A0.6010000@oracle.com> Message-ID: <5670B27D.6080202@oracle.com> On 12/15/2015 3:47 PM, sangheon wrote: > Hi Jesper, > > Thanks for the review! > > Sangheon > > > On 12/15/2015 03:33 PM, Jesper Wilhelmsson wrote: >> Looks good! >> /Jesper >> >> Den 16/12/15 kl. 00:10, skrev sangheon: >>> Hi all, >>> >>> Could I get some reviews for this change? >>> >>> Current 32bit binary with NUMAInterleavingGranularity=2g on server >>> mode fires an >>> assert on Windows as we are proceeding without memory allocation >>> failure check >>> at CodeCache::reserve_heap_memory. >>> >>> I think the constraint function can be removed with maximum range of >>> 2G/8192G. >>> These are the maximum available memory on Windows and smaller values >>> can be used >>> but I wanted to avoid adding artificial limit. With this limitation, >>> current >>> constraint function for overflow check is not needed. >>> And we need to check allocation failure. >>> >>> This issue is not reproducible with client mode as the different >>> default value >>> of ReservedCodeCacheSize sets SegmentedCodeCache to false. And >>> CodeCache::reserve_heap_memory() is called only when >>> SegmentedCodeCache is enabled. >>> >>> Skipped adding a test as TestOptionsWithRanges.java is enough when >>> this is >>> combined with nightly vm option rotation. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8144949 >>> Webrev: http://cr.openjdk.java.net/~sangheki/8144949/webrev.00 >>> Testing: JPRT (with TestOptionsWithRanges.java enabled), manual >>> tests on Windows >>> machine(to test several option combination). Sangheon, Could you check if the changes in globals.hpp can be put in "os/windows/vm/globals_windows.hpp" Since this is a windows specific flag, it should work to go in windows.hpp. On 32bit upper limit is 2G. Is that the largest value that can be used without having to check for arithmetic overflow? Jon >>> >>> Thanks, >>> Sangheon >>> > From sangheon.kim at oracle.com Wed Dec 16 00:50:00 2015 From: sangheon.kim at oracle.com (sangheon) Date: Tue, 15 Dec 2015 16:50:00 -0800 Subject: RFR(s): 8144949: TestOptionsWithRanges -XX:NUMAInterleaveGranularity=2147483648 crashes VM In-Reply-To: <5670B27D.6080202@oracle.com> References: <56709DD0.80808@oracle.com> <5670A345.6030200@oracle.com> <5670A6A0.6010000@oracle.com> <5670B27D.6080202@oracle.com> Message-ID: <5670B538.6090404@oracle.com> Hi Jon, Thank you for reviewing this. On 12/15/2015 04:38 PM, Jon Masamitsu wrote: > > > On 12/15/2015 3:47 PM, sangheon wrote: >> Hi Jesper, >> >> Thanks for the review! >> >> Sangheon >> >> >> On 12/15/2015 03:33 PM, Jesper Wilhelmsson wrote: >>> Looks good! >>> /Jesper >>> >>> Den 16/12/15 kl. 00:10, skrev sangheon: >>>> Hi all, >>>> >>>> Could I get some reviews for this change? >>>> >>>> Current 32bit binary with NUMAInterleavingGranularity=2g on server >>>> mode fires an >>>> assert on Windows as we are proceeding without memory allocation >>>> failure check >>>> at CodeCache::reserve_heap_memory. >>>> >>>> I think the constraint function can be removed with maximum range >>>> of 2G/8192G. >>>> These are the maximum available memory on Windows and smaller >>>> values can be used >>>> but I wanted to avoid adding artificial limit. With this >>>> limitation, current >>>> constraint function for overflow check is not needed. >>>> And we need to check allocation failure. >>>> >>>> This issue is not reproducible with client mode as the different >>>> default value >>>> of ReservedCodeCacheSize sets SegmentedCodeCache to false. And >>>> CodeCache::reserve_heap_memory() is called only when >>>> SegmentedCodeCache is enabled. >>>> >>>> Skipped adding a test as TestOptionsWithRanges.java is enough when >>>> this is >>>> combined with nightly vm option rotation. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8144949 >>>> Webrev: http://cr.openjdk.java.net/~sangheki/8144949/webrev.00 >>>> Testing: JPRT (with TestOptionsWithRanges.java enabled), manual >>>> tests on Windows >>>> machine(to test several option combination). > > Sangheon, > > Could you check if the changes in globals.hpp can be put in > > "os/windows/vm/globals_windows.hpp" > > Since this is a windows specific flag, it should work to > go in windows.hpp. This flag is only used for Windows (as its description says), so I am not sure whether we need to move it to windows.hpp. > > On 32bit upper limit is 2G. Is that the largest value that can be used > without having to check for arithmetic overflow? No. That is Windows OS limitation that each process would use. And within this range we don't need to check arithmetic overflow as it will never happen. Thanks, Sangheon > > Jon >>>> >>>> Thanks, >>>> Sangheon >>>> >> > From sangheon.kim at oracle.com Wed Dec 16 00:53:05 2015 From: sangheon.kim at oracle.com (sangheon) Date: Tue, 15 Dec 2015 16:53:05 -0800 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 Message-ID: <5670B5F1.7010505@oracle.com> Hi all, Could I get a couple of reviews for Windows NUMAInterleaveGranularity change? Current Windows implementation can't handle correctly when we reserve a heap with disjoint heap base mode with NUMAInterleaveGranularity. Windows, os::protect_memory fails in above case, as we are trying to protect the whole reserved heap at one time. But we reserved that area with separate/contiguous chunks based on NUMAInterleaveGranularity size. MSDN describes to call the API separately. I changed protect API to be called multiple times if needed. Skipped adding a test as TestOptionsWithRanges.java is enough. 'java -XX:+UseNUMA -XX:+UseNUMAInterleaving' is enough to reproduce on large memory Windows machine. However we need to specify heap size if the machine doesn't have large memory. e.g. -Xms30g -Xmx30g This patch is based on the patch for JDK-8144949 which includes the change of the max range of NUMAInterleaveGranularity to 2G(32bit), 8192G(64bit). CR: https://bugs.openjdk.java.net/browse/JDK-8145000 Webrev: http://cr.openjdk.java.net/~sangheki/8145000/webrev.00 Testing: JPRT (with TestOptionsWithRanges.java enabled), manual tests on Windows machine(to test on large memory). Thanks, Sangheon From sangheon.kim at oracle.com Wed Dec 16 01:42:45 2015 From: sangheon.kim at oracle.com (sangheon) Date: Tue, 15 Dec 2015 17:42:45 -0800 Subject: RFR(s): 8144949: TestOptionsWithRanges -XX:NUMAInterleaveGranularity=2147483648 crashes VM In-Reply-To: <5670B538.6090404@oracle.com> References: <56709DD0.80808@oracle.com> <5670A345.6030200@oracle.com> <5670A6A0.6010000@oracle.com> <5670B27D.6080202@oracle.com> <5670B538.6090404@oracle.com> Message-ID: <5670C195.2010607@oracle.com> Hi Jon again, On 12/15/2015 04:50 PM, sangheon wrote: > Hi Jon, > > Thank you for reviewing this. > > On 12/15/2015 04:38 PM, Jon Masamitsu wrote: >> >> >> On 12/15/2015 3:47 PM, sangheon wrote: >>> Hi Jesper, >>> >>> Thanks for the review! >>> >>> Sangheon >>> >>> >>> On 12/15/2015 03:33 PM, Jesper Wilhelmsson wrote: >>>> Looks good! >>>> /Jesper >>>> >>>> Den 16/12/15 kl. 00:10, skrev sangheon: >>>>> Hi all, >>>>> >>>>> Could I get some reviews for this change? >>>>> >>>>> Current 32bit binary with NUMAInterleavingGranularity=2g on server >>>>> mode fires an >>>>> assert on Windows as we are proceeding without memory allocation >>>>> failure check >>>>> at CodeCache::reserve_heap_memory. >>>>> >>>>> I think the constraint function can be removed with maximum range >>>>> of 2G/8192G. >>>>> These are the maximum available memory on Windows and smaller >>>>> values can be used >>>>> but I wanted to avoid adding artificial limit. With this >>>>> limitation, current >>>>> constraint function for overflow check is not needed. >>>>> And we need to check allocation failure. >>>>> >>>>> This issue is not reproducible with client mode as the different >>>>> default value >>>>> of ReservedCodeCacheSize sets SegmentedCodeCache to false. And >>>>> CodeCache::reserve_heap_memory() is called only when >>>>> SegmentedCodeCache is enabled. >>>>> >>>>> Skipped adding a test as TestOptionsWithRanges.java is enough when >>>>> this is >>>>> combined with nightly vm option rotation. >>>>> >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8144949 >>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8144949/webrev.00 >>>>> Testing: JPRT (with TestOptionsWithRanges.java enabled), manual >>>>> tests on Windows >>>>> machine(to test several option combination). >> >> Sangheon, >> >> Could you check if the changes in globals.hpp can be put in >> >> "os/windows/vm/globals_windows.hpp" >> >> Since this is a windows specific flag, it should work to >> go in windows.hpp. > This flag is only used for Windows (as its description says), so I am > not sure whether we need to move it to windows.hpp. I understood your comment to move my changes(range and constraint) to globals_windows.hpp. i.e. making the flag as product_pd. Since this flag is only used on Windows, I am not sure it is a good idea. If you are suggesting to move the whole definition of the flag into globals_windows.hpp, let me consider it. I'm not sure whether it's feasible or not. Thanks, Sangheon > >> >> On 32bit upper limit is 2G. Is that the largest value that can be used >> without having to check for arithmetic overflow? > No. > That is Windows OS limitation that each process would use. And within > this range we don't need to check arithmetic overflow as it will never > happen. > > Thanks, > Sangheon > > >> >> Jon >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>> >> > From bengt.rutisson at oracle.com Wed Dec 16 08:42:41 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 16 Dec 2015 09:42:41 +0100 Subject: RFR: JDK-8145315: VM crashes in print_task_time_stamps() In-Reply-To: <5670648F.3030701@oracle.com> References: <566FFFE8.9090309@oracle.com> <5670648F.3030701@oracle.com> Message-ID: <56712401.1050703@oracle.com> Thanks for the reviews, Jon and Jesper! Bengt On 2015-12-15 20:05, Jon Masamitsu wrote: > Looks good. > > Jon > > On 12/15/2015 3:56 AM, Bengt Rutisson wrote: >> >> Hi everyone, >> >> Could I have a couple of reviews for this patch? >> >> http://cr.openjdk.java.net/~brutisso/8145315/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8145315 >> >> The fix will make sure that the VM does not crash. But there is still >> an issue with that a task may not be printed if we run into the race >> that exist. This is a separate problem and outside the scope of this >> bug fix. >> >> From the bug report: >> >> The crash is due to an existing race condition in the ParallelGC. >> This race existed even before the new logging was introduced but we >> did not run with this logging enabled before. >> >> The test now runs with -Xlog:gc*=debug, which enables logging that >> was previously guarded by the PrintGCTaskTimeStamps flag. >> >> In the GCTaskThread::run() method we have this code: >> >> GCTaskTimeStamp* time_stamp = >> time_stamp_at(_time_stamp_index++); >> >> time_stamp->set_name(name); >> time_stamp->set_entry_time(entry_time); >> time_stamp->set_exit_time(timer.ticks()); >> >> >> And in GCTaskThread::print_task_time_stamps() we have this code: >> >> for(uint i=0; i<_time_stamp_index; i++) { >> GCTaskTimeStamp* time_stamp = time_stamp_at(i); >> log_debug(gc, task, time)("\t[ %s " JLONG_FORMAT " " JLONG_FORMAT >> " ]", >> time_stamp->name(), >> time_stamp->entry_time(), >> time_stamp->exit_time()); >> } >> >> The code in GCTaskThread::run() increments the _time_stamp_index >> value before setting the name, entry and exit times, which means that >> the code in GCTaskThread::print_task_time_stamps() can see the new >> value of _time_stamp_index before the name, entry and exit times have >> been set. >> >> I can reproduce this on Linux x64 with the following patch that >> introduces a sleep and an assert: >> >> diff --git a/src/share/vm/gc/parallel/gcTaskThread.cpp >> b/src/share/vm/gc/parallel/gcTaskThread.cpp >> --- a/src/share/vm/gc/parallel/gcTaskThread.cpp >> +++ b/src/share/vm/gc/parallel/gcTaskThread.cpp >> @@ -83,6 +83,7 @@ >> log_debug(gc, task, time)("GC-Thread %u entries: %d", id(), >> _time_stamp_index); >> for(uint i=0; i<_time_stamp_index; i++) { >> GCTaskTimeStamp* time_stamp = time_stamp_at(i); >> + assert(time_stamp->name() != NULL, "NULL name"); >> log_debug(gc, task, time)("\t[ %s " JLONG_FORMAT " " >> JLONG_FORMAT " ]", >> time_stamp->name(), >> time_stamp->entry_time(), >> @@ -154,6 +155,12 @@ >> >> GCTaskTimeStamp* time_stamp = >> time_stamp_at(_time_stamp_index++); >> >> + if (os::random() % 100 == 0) { >> + time_stamp->set_name(NULL); >> + tty->print_cr("####### WAITING: %s", name); >> + sleep(1); >> + } >> + >> time_stamp->set_name(name); >> time_stamp->set_entry_time(entry_time); >> time_stamp->set_exit_time(timer.ticks()); >> >> >> By updating the _time_stamp_index after we have set the other values >> we remove the crash: >> >> diff --git a/src/share/vm/gc/parallel/gcTaskThread.cpp >> b/src/share/vm/gc/parallel/gcTaskThread.cpp >> --- a/src/share/vm/gc/parallel/gcTaskThread.cpp >> +++ b/src/share/vm/gc/parallel/gcTaskThread.cpp >> @@ -153,7 +153,7 @@ >> if (log_is_enabled(Debug, gc, task, time)) { >> timer.update(); >> >> - GCTaskTimeStamp* time_stamp = time_stamp_at(_time_stamp_index++); >> + GCTaskTimeStamp* time_stamp = time_stamp_at(_time_stamp_index); >> >> if (os::random() % 100 == 0) { >> time_stamp->set_name(NULL); >> @@ -164,6 +164,7 @@ >> time_stamp->set_name(name); >> time_stamp->set_entry_time(entry_time); >> time_stamp->set_exit_time(timer.ticks()); >> + _time_stamp_index++; >> } >> } else { >> // idle tasks complete outside the normal accounting >> >> >> Running with the first patch asserts every time. Adding the second >> patch does not hit the assert. > From jesper.wilhelmsson at oracle.com Wed Dec 16 12:50:07 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 16 Dec 2015 13:50:07 +0100 Subject: RFR(s): 8144949: TestOptionsWithRanges -XX:NUMAInterleaveGranularity=2147483648 crashes VM In-Reply-To: <5670C195.2010607@oracle.com> References: <56709DD0.80808@oracle.com> <5670A345.6030200@oracle.com> <5670A6A0.6010000@oracle.com> <5670B27D.6080202@oracle.com> <5670B538.6090404@oracle.com> <5670C195.2010607@oracle.com> Message-ID: <56715DFF.40009@oracle.com> Den 16/12/15 kl. 02:42, skrev sangheon: > Hi Jon again, > > On 12/15/2015 04:50 PM, sangheon wrote: >> Hi Jon, >> >> Thank you for reviewing this. >> >> On 12/15/2015 04:38 PM, Jon Masamitsu wrote: >>> >>> >>> On 12/15/2015 3:47 PM, sangheon wrote: >>>> Hi Jesper, >>>> >>>> Thanks for the review! >>>> >>>> Sangheon >>>> >>>> >>>> On 12/15/2015 03:33 PM, Jesper Wilhelmsson wrote: >>>>> Looks good! >>>>> /Jesper >>>>> >>>>> Den 16/12/15 kl. 00:10, skrev sangheon: >>>>>> Hi all, >>>>>> >>>>>> Could I get some reviews for this change? >>>>>> >>>>>> Current 32bit binary with NUMAInterleavingGranularity=2g on server mode >>>>>> fires an >>>>>> assert on Windows as we are proceeding without memory allocation failure >>>>>> check >>>>>> at CodeCache::reserve_heap_memory. >>>>>> >>>>>> I think the constraint function can be removed with maximum range of >>>>>> 2G/8192G. >>>>>> These are the maximum available memory on Windows and smaller values can >>>>>> be used >>>>>> but I wanted to avoid adding artificial limit. With this limitation, current >>>>>> constraint function for overflow check is not needed. >>>>>> And we need to check allocation failure. >>>>>> >>>>>> This issue is not reproducible with client mode as the different default >>>>>> value >>>>>> of ReservedCodeCacheSize sets SegmentedCodeCache to false. And >>>>>> CodeCache::reserve_heap_memory() is called only when SegmentedCodeCache is >>>>>> enabled. >>>>>> >>>>>> Skipped adding a test as TestOptionsWithRanges.java is enough when this is >>>>>> combined with nightly vm option rotation. >>>>>> >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8144949 >>>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8144949/webrev.00 >>>>>> Testing: JPRT (with TestOptionsWithRanges.java enabled), manual tests on >>>>>> Windows >>>>>> machine(to test several option combination). >>> >>> Sangheon, >>> >>> Could you check if the changes in globals.hpp can be put in >>> >>> "os/windows/vm/globals_windows.hpp" >>> >>> Since this is a windows specific flag, it should work to >>> go in windows.hpp. >> This flag is only used for Windows (as its description says), so I am not sure >> whether we need to move it to windows.hpp. > I understood your comment to move my changes(range and constraint) to > globals_windows.hpp. i.e. making the flag as product_pd. Since this flag is only > used on Windows, I am not sure it is a good idea. > If you are suggesting to move the whole definition of the flag into > globals_windows.hpp, let me consider it. I'm not sure whether it's feasible or not. The description of the flag kind of mentions that this is a Windows specific flag, but it's not fool prof. It's possible that this flag is used on non-Windows set ups as well. For instance applications could use the same set of flags on multiple platforms. Removing this flag on non-Windows platforms would be a breaking change in this case and will most likely require a CCC. /Jesper > > Thanks, > Sangheon > > >> >>> >>> On 32bit upper limit is 2G. Is that the largest value that can be used >>> without having to check for arithmetic overflow? >> No. >> That is Windows OS limitation that each process would use. And within this >> range we don't need to check arithmetic overflow as it will never happen. >> >> Thanks, >> Sangheon >> >> >>> >>> Jon >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>> >>> >> > From marcus.larsson at oracle.com Wed Dec 16 13:30:27 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 16 Dec 2015 14:30:27 +0100 Subject: [PING] Re: RFR (XS): Forward port of 8065331: Add trace events for failed allocations In-Reply-To: <56681744.4030907@oracle.com> References: <55DACA18.2070605@oracle.com> <55DD8F43.7070003@oracle.com> <5665511F.8000509@oracle.com> <56681744.4030907@oracle.com> Message-ID: <56716773.1050408@oracle.com> Need one more review for this. Thanks, Marcus On 2015-12-09 12:57, Marcus Larsson wrote: > Hi, > > After offline discussions with Bengt, I've decided to omit the Pending > GCId from the event. The ID used previously was never guaranteed to be > correct, since it came from the peek() method. Sometimes a GCId would > be skipped which then caused some of the events to have an "invalid" > GCId. Grouping these events together with some GC will now instead > have to be done by the event timestamps. > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.02/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.01-02/ > > Thanks, > Marcus > > On 2015-12-07 10:27, Marcus Larsson wrote: >> Hi all, >> >> Still need approval for this forward port. >> >> New webrev due to changes in how GCId works: >> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.01/ >> >> Had to add a peek method in order to find the pending GC id for the >> event. >> This and the changes to includes should be the only things differing >> from the original patch. >> >> Thanks, >> Marcus >> >> On 2015-08-26 12:04, Marcus Larsson wrote: >>> Ping! >>> >>> On 2015-08-24 09:39, Marcus Larsson wrote: >>>> Hi, >>>> >>>> Please review the following patch to forward port the JEP-242 event >>>> to JDK9. The patch was originally reviewed in April/March [1], but >>>> was only integrated in 8u60. The original patch no longer applies >>>> cleanly to 9, due to directory restructuring and changes to >>>> includes, so I need a quick re-review for this. >>>> >>>> The new patch has updated #includes for the new directory structure >>>> but should otherwise be identical to the previous patch. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.00/ >>>> >>>> Original webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8065331/webrev.02/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8065331 >>>> >>>> Thanks, >>>> Marcus >>>> >>>> [1]: >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-March/012408.html >>> >> > From jesper.wilhelmsson at oracle.com Wed Dec 16 14:46:28 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 16 Dec 2015 15:46:28 +0100 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <5670B5F1.7010505@oracle.com> References: <5670B5F1.7010505@oracle.com> Message-ID: <56717944.1030402@oracle.com> Hi Sangheon, * It seems to me that protect_pages_individually() can only be called if UseLargePages is false. Still it looks at UseLargePages to decide page_size. I would prefer if there was an assert(!UseLargePages) at the start of protect_pages_individually() to emphasize that this code has not been used or tested with large pages. * I'm not sure if this matters, but it seems to me that if the size of the area is not an even multiple of pages, you will start protecting the smaller part, and then continue with page sized areas. E.g. If page size is 4k and we want to protect a 10k area, we will start with a 2k block and then take two 4k blocks. This has the effect that if we pass in a page aligned address, the areas we protect will not cover one page at a time. This may be a non-issue though. It depends on if we usually get page aligned addresses and if it matters if we protect one page at a time or not. * You use UINT32_FORMAT to print an uint. %u is the recommended way to print an uint. * if (!ret) return false; We should always use { } Thanks, /Jesper Den 16/12/15 kl. 01:53, skrev sangheon: > Hi all, > > Could I get a couple of reviews for Windows NUMAInterleaveGranularity change? > > Current Windows implementation can't handle correctly when we reserve a heap > with disjoint heap base mode with NUMAInterleaveGranularity. > > Windows, os::protect_memory fails in above case, as we are trying to protect the > whole reserved heap at one time. But we reserved that area with > separate/contiguous chunks based on NUMAInterleaveGranularity size. MSDN > describes to call the API separately. > I changed protect API to be called multiple times if needed. > > Skipped adding a test as TestOptionsWithRanges.java is enough. > 'java -XX:+UseNUMA -XX:+UseNUMAInterleaving' is enough to reproduce on large > memory Windows machine. However we need to specify heap size if the machine > doesn't have large memory. e.g. -Xms30g -Xmx30g > > This patch is based on the patch for JDK-8144949 which includes the change of > the max range of NUMAInterleaveGranularity to 2G(32bit), 8192G(64bit). > > CR: https://bugs.openjdk.java.net/browse/JDK-8145000 > Webrev: http://cr.openjdk.java.net/~sangheki/8145000/webrev.00 > Testing: JPRT (with TestOptionsWithRanges.java enabled), manual tests on Windows > machine(to test on large memory). > > Thanks, > Sangheon > > From dmitry.dmitriev at oracle.com Wed Dec 16 14:51:00 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 16 Dec 2015 17:51:00 +0300 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <5670B5F1.7010505@oracle.com> References: <5670B5F1.7010505@oracle.com> Message-ID: <56717A54.5080402@oracle.com> Hi Sangheon, Are you planning to remove excluding of "NUMAInterleaveGranularity" from testing in TestOptionsWithRanges? Thanks, Dmtry On 16.12.2015 3:53, sangheon wrote: > Hi all, > > Could I get a couple of reviews for Windows NUMAInterleaveGranularity > change? > > Current Windows implementation can't handle correctly when we reserve > a heap with disjoint heap base mode with NUMAInterleaveGranularity. > > Windows, os::protect_memory fails in above case, as we are trying to > protect the whole reserved heap at one time. But we reserved that area > with separate/contiguous chunks based on NUMAInterleaveGranularity > size. MSDN describes to call the API separately. > I changed protect API to be called multiple times if needed. > > Skipped adding a test as TestOptionsWithRanges.java is enough. > 'java -XX:+UseNUMA -XX:+UseNUMAInterleaving' is enough to reproduce on > large memory Windows machine. However we need to specify heap size if > the machine doesn't have large memory. e.g. -Xms30g -Xmx30g > > This patch is based on the patch for JDK-8144949 which includes the > change of the max range of NUMAInterleaveGranularity to 2G(32bit), > 8192G(64bit). > > CR: https://bugs.openjdk.java.net/browse/JDK-8145000 > Webrev: http://cr.openjdk.java.net/~sangheki/8145000/webrev.00 > Testing: JPRT (with TestOptionsWithRanges.java enabled), manual tests > on Windows machine(to test on large memory). > > Thanks, > Sangheon > > From tom.benson at oracle.com Wed Dec 16 15:45:56 2015 From: tom.benson at oracle.com (Tom Benson) Date: Wed, 16 Dec 2015 10:45:56 -0500 Subject: Request for review (s) - 8145031: Add regression test for 8133023 In-Reply-To: <56706381.7050205@oracle.com> References: <5669D7A0.8000201@oracle.com> <1450175079.2296.1.camel@oracle.com> <56706381.7050205@oracle.com> Message-ID: <56718734.3080003@oracle.com> Hi Jon, This looks OK to me (modulo Thomas' comments), but it's not clear to me why a unit test is needed for this case, rather than a simple assert somewhere, such as when the threads are created. Thanks, Tom On 12/15/2015 2:01 PM, Jon Masamitsu wrote: > > > On 12/15/2015 2:24 AM, Thomas Schatzl wrote: >> Hi Jon, >> >> On Thu, 2015-12-10 at 11:50 -0800, Jon Masamitsu wrote: >>> The cause of the failure in 8133023 was the calculation of the >>> ParallelGCThreads using >>> information that had not yet been initialized. Add a test that checks >>> that, after full >>> initialization, the fresh calculation of ParallelGCThreads is >>> consistent with the value >>> calculated earlier. >>> >>> http://cr.openjdk.java.net/~jmasa/8145031/webrev.00/ >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8145031 >>> >>> Tested with and without the fix for 8133023. >>> >> seems okay, with one nit: the indendation of the parameters for the >> assert in Abstract_VM_Version::FinalParallelGCThreads_test() seems off. >> >> Also there is an extra space between the "void" and the method name. > > Both fixed. Thanks. > > Jon > >> >> I do not need to re-review. >> >> Thanks, >> Thomas >> >> > From sangheon.kim at oracle.com Wed Dec 16 16:55:18 2015 From: sangheon.kim at oracle.com (sangheon) Date: Wed, 16 Dec 2015 08:55:18 -0800 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <56717A54.5080402@oracle.com> References: <5670B5F1.7010505@oracle.com> <56717A54.5080402@oracle.com> Message-ID: <56719776.2000208@oracle.com> Hi Dmitry, On 12/16/2015 06:51 AM, Dmitry Dmitriev wrote: > Hi Sangheon, > > Are you planning to remove excluding of "NUMAInterleaveGranularity" > from testing in TestOptionsWithRanges? No, sorry for the confusion. I forgot to add that part on my webrev. When I ran JPRT, I added "NUMAInterleaveGranularity" and enabled TestOptionsWithRanges.java. Let me include this on next webrev. Thanks, Sangheon > > Thanks, > Dmtry > > > On 16.12.2015 3:53, sangheon wrote: >> Hi all, >> >> Could I get a couple of reviews for Windows NUMAInterleaveGranularity >> change? >> >> Current Windows implementation can't handle correctly when we reserve >> a heap with disjoint heap base mode with NUMAInterleaveGranularity. >> >> Windows, os::protect_memory fails in above case, as we are trying to >> protect the whole reserved heap at one time. But we reserved that >> area with separate/contiguous chunks based on >> NUMAInterleaveGranularity size. MSDN describes to call the API >> separately. >> I changed protect API to be called multiple times if needed. >> >> Skipped adding a test as TestOptionsWithRanges.java is enough. >> 'java -XX:+UseNUMA -XX:+UseNUMAInterleaving' is enough to reproduce >> on large memory Windows machine. However we need to specify heap size >> if the machine doesn't have large memory. e.g. -Xms30g -Xmx30g >> >> This patch is based on the patch for JDK-8144949 which includes the >> change of the max range of NUMAInterleaveGranularity to 2G(32bit), >> 8192G(64bit). >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8145000 >> Webrev: http://cr.openjdk.java.net/~sangheki/8145000/webrev.00 >> Testing: JPRT (with TestOptionsWithRanges.java enabled), manual tests >> on Windows machine(to test on large memory). >> >> Thanks, >> Sangheon >> >> > From thomas.schatzl at oracle.com Wed Dec 16 17:18:03 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 16 Dec 2015 18:18:03 +0100 Subject: RFR (S): 8145534: TestRemsetLogging.java takes a long time Message-ID: <1450286283.2322.49.camel@oracle.com> Hi all, can I have reviews for the following changes to gc/g1/TestRemset* tests that decrease its runtime significantly? Most of the runtime improvements come from using WhiteBox methods to start gcs (instead of allocating objects and waiting for it to happen), then forcing that test to use the interpreter (because starting up the compilers only slows it down), and some measures to improve startup. In total all this decreases fastdebug VM runtime from 100s to 17s on my local machine. The changes also add @requires tags and deletes equivalent java code. CR: https://bugs.openjdk.java.net/browse/JDK-8145534 Webrev: http://cr.openjdk.java.net/~tschatzl/8145534/webrev/ Testing: looking at run times of jprt jobs which are much better now. There is still some variation, but they are in the same range as other tests now. Thanks, Thomas From dmitry.dmitriev at oracle.com Wed Dec 16 17:20:43 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 16 Dec 2015 20:20:43 +0300 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <56719776.2000208@oracle.com> References: <5670B5F1.7010505@oracle.com> <56717A54.5080402@oracle.com> <56719776.2000208@oracle.com> Message-ID: <56719D6B.9020100@oracle.com> Sangheon, thank you for clarification! Dmitry On 16.12.2015 19:55, sangheon wrote: > Hi Dmitry, > > On 12/16/2015 06:51 AM, Dmitry Dmitriev wrote: >> Hi Sangheon, >> >> Are you planning to remove excluding of "NUMAInterleaveGranularity" >> from testing in TestOptionsWithRanges? > No, sorry for the confusion. > I forgot to add that part on my webrev. When I ran JPRT, I added > "NUMAInterleaveGranularity" and enabled TestOptionsWithRanges.java. > Let me include this on next webrev. > > Thanks, > Sangheon > > >> >> Thanks, >> Dmtry >> >> >> On 16.12.2015 3:53, sangheon wrote: >>> Hi all, >>> >>> Could I get a couple of reviews for Windows >>> NUMAInterleaveGranularity change? >>> >>> Current Windows implementation can't handle correctly when we >>> reserve a heap with disjoint heap base mode with >>> NUMAInterleaveGranularity. >>> >>> Windows, os::protect_memory fails in above case, as we are trying to >>> protect the whole reserved heap at one time. But we reserved that >>> area with separate/contiguous chunks based on >>> NUMAInterleaveGranularity size. MSDN describes to call the API >>> separately. >>> I changed protect API to be called multiple times if needed. >>> >>> Skipped adding a test as TestOptionsWithRanges.java is enough. >>> 'java -XX:+UseNUMA -XX:+UseNUMAInterleaving' is enough to reproduce >>> on large memory Windows machine. However we need to specify heap >>> size if the machine doesn't have large memory. e.g. -Xms30g -Xmx30g >>> >>> This patch is based on the patch for JDK-8144949 which includes the >>> change of the max range of NUMAInterleaveGranularity to 2G(32bit), >>> 8192G(64bit). >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8145000 >>> Webrev: http://cr.openjdk.java.net/~sangheki/8145000/webrev.00 >>> Testing: JPRT (with TestOptionsWithRanges.java enabled), manual >>> tests on Windows machine(to test on large memory). >>> >>> Thanks, >>> Sangheon >>> >>> >> > From jon.masamitsu at oracle.com Wed Dec 16 18:00:41 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 16 Dec 2015 10:00:41 -0800 Subject: RFR(s): 8144949: TestOptionsWithRanges -XX:NUMAInterleaveGranularity=2147483648 crashes VM In-Reply-To: <56715DFF.40009@oracle.com> References: <56709DD0.80808@oracle.com> <5670A345.6030200@oracle.com> <5670A6A0.6010000@oracle.com> <5670B27D.6080202@oracle.com> <5670B538.6090404@oracle.com> <5670C195.2010607@oracle.com> <56715DFF.40009@oracle.com> Message-ID: <5671A6C9.9070705@oracle.com> On 12/16/2015 04:50 AM, Jesper Wilhelmsson wrote: > Den 16/12/15 kl. 02:42, skrev sangheon: >> Hi Jon again, >> >> On 12/15/2015 04:50 PM, sangheon wrote: >>> Hi Jon, >>> >>> Thank you for reviewing this. >>> >>> On 12/15/2015 04:38 PM, Jon Masamitsu wrote: >>>> >>>> >>>> On 12/15/2015 3:47 PM, sangheon wrote: >>>>> Hi Jesper, >>>>> >>>>> Thanks for the review! >>>>> >>>>> Sangheon >>>>> >>>>> >>>>> On 12/15/2015 03:33 PM, Jesper Wilhelmsson wrote: >>>>>> Looks good! >>>>>> /Jesper >>>>>> >>>>>> Den 16/12/15 kl. 00:10, skrev sangheon: >>>>>>> Hi all, >>>>>>> >>>>>>> Could I get some reviews for this change? >>>>>>> >>>>>>> Current 32bit binary with NUMAInterleavingGranularity=2g on >>>>>>> server mode >>>>>>> fires an >>>>>>> assert on Windows as we are proceeding without memory allocation >>>>>>> failure >>>>>>> check >>>>>>> at CodeCache::reserve_heap_memory. >>>>>>> >>>>>>> I think the constraint function can be removed with maximum >>>>>>> range of >>>>>>> 2G/8192G. >>>>>>> These are the maximum available memory on Windows and smaller >>>>>>> values can >>>>>>> be used >>>>>>> but I wanted to avoid adding artificial limit. With this >>>>>>> limitation, current >>>>>>> constraint function for overflow check is not needed. >>>>>>> And we need to check allocation failure. >>>>>>> >>>>>>> This issue is not reproducible with client mode as the different >>>>>>> default >>>>>>> value >>>>>>> of ReservedCodeCacheSize sets SegmentedCodeCache to false. And >>>>>>> CodeCache::reserve_heap_memory() is called only when >>>>>>> SegmentedCodeCache is >>>>>>> enabled. >>>>>>> >>>>>>> Skipped adding a test as TestOptionsWithRanges.java is enough >>>>>>> when this is >>>>>>> combined with nightly vm option rotation. >>>>>>> >>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8144949 >>>>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8144949/webrev.00 >>>>>>> Testing: JPRT (with TestOptionsWithRanges.java enabled), manual >>>>>>> tests on >>>>>>> Windows >>>>>>> machine(to test several option combination). >>>> >>>> Sangheon, >>>> >>>> Could you check if the changes in globals.hpp can be put in >>>> >>>> "os/windows/vm/globals_windows.hpp" >>>> >>>> Since this is a windows specific flag, it should work to >>>> go in windows.hpp. >>> This flag is only used for Windows (as its description says), so I >>> am not sure >>> whether we need to move it to windows.hpp. >> I understood your comment to move my changes(range and constraint) to >> globals_windows.hpp. i.e. making the flag as product_pd. Since this >> flag is only >> used on Windows, I am not sure it is a good idea. >> If you are suggesting to move the whole definition of the flag into >> globals_windows.hpp, let me consider it. I'm not sure whether it's >> feasible or not. > > The description of the flag kind of mentions that this is a Windows > specific flag, but it's not fool prof. It's possible that this flag is > used on non-Windows set ups as well. For instance applications could > use the same set of flags on multiple platforms. Removing this flag on > non-Windows platforms would be a breaking change in this case and will > most likely require a CCC. > /Jesper Jesper, you're right about the side effects of moving the code to the globals_windows.hpp. Sangheon, forget about that suggestion. Changes look good. Jon > >> >> Thanks, >> Sangheon >> >> >>> >>>> >>>> On 32bit upper limit is 2G. Is that the largest value that can be >>>> used >>>> without having to check for arithmetic overflow? >>> No. >>> That is Windows OS limitation that each process would use. And >>> within this >>> range we don't need to check arithmetic overflow as it will never >>> happen. >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> Jon >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>> >>>> >>> >> From dmitry.fazunenko at oracle.com Wed Dec 16 18:12:46 2015 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 16 Dec 2015 21:12:46 +0300 Subject: RFR (S): 8145534: TestRemsetLogging.java takes a long time In-Reply-To: <1450286283.2322.49.camel@oracle.com> References: <1450286283.2322.49.camel@oracle.com> Message-ID: <5671A99E.3040606@oracle.com> Hi Thomas, 1) TestRemsetLoggingPerRegion.java there are unused imports, you can remove them 2) TestRemsetLoggingThreads.java it doesn't use TestRemsetLoggingTools, just -version. So, you don't need WB here and you don't need to build TestRemsetLoggingTools TestRemsetLoggingThreads 3) TestRemsetLoggingTools.java You changed the logic of the test: - replaced "1 young GC + N full GC" with "N young GC + 1 full GC" - removed all object allocations So, now VerifySummaryOutput just invokes serveral GC. Did you do this intentionally or by mistake? Thanks, Dima On 16.12.2015 20:18, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the following changes to gc/g1/TestRemset* > tests that decrease its runtime significantly? > > Most of the runtime improvements come from using WhiteBox methods to > start gcs (instead of allocating objects and waiting for it to happen), > then forcing that test to use the interpreter (because starting up the > compilers only slows it down), and some measures to improve startup. > > In total all this decreases fastdebug VM runtime from 100s to 17s on my > local machine. > > The changes also add @requires tags and deletes equivalent java code. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8145534 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8145534/webrev/ > Testing: > looking at run times of jprt jobs which are much better now. There is > still some variation, but they are in the same range as other tests now. > > Thanks, > Thomas > > From sangheon.kim at oracle.com Wed Dec 16 18:14:19 2015 From: sangheon.kim at oracle.com (sangheon) Date: Wed, 16 Dec 2015 10:14:19 -0800 Subject: RFR(s): 8144949: TestOptionsWithRanges -XX:NUMAInterleaveGranularity=2147483648 crashes VM In-Reply-To: <5671A6C9.9070705@oracle.com> References: <56709DD0.80808@oracle.com> <5670A345.6030200@oracle.com> <5670A6A0.6010000@oracle.com> <5670B27D.6080202@oracle.com> <5670B538.6090404@oracle.com> <5670C195.2010607@oracle.com> <56715DFF.40009@oracle.com> <5671A6C9.9070705@oracle.com> Message-ID: <5671A9FB.2010705@oracle.com> Hi Jon and Jesper, On 12/16/2015 10:00 AM, Jon Masamitsu wrote: > > > On 12/16/2015 04:50 AM, Jesper Wilhelmsson wrote: >> Den 16/12/15 kl. 02:42, skrev sangheon: >>> Hi Jon again, >>> >>> On 12/15/2015 04:50 PM, sangheon wrote: >>>> Hi Jon, >>>> >>>> Thank you for reviewing this. >>>> >>>> On 12/15/2015 04:38 PM, Jon Masamitsu wrote: >>>>> >>>>> >>>>> On 12/15/2015 3:47 PM, sangheon wrote: >>>>>> Hi Jesper, >>>>>> >>>>>> Thanks for the review! >>>>>> >>>>>> Sangheon >>>>>> >>>>>> >>>>>> On 12/15/2015 03:33 PM, Jesper Wilhelmsson wrote: >>>>>>> Looks good! >>>>>>> /Jesper >>>>>>> >>>>>>> Den 16/12/15 kl. 00:10, skrev sangheon: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Could I get some reviews for this change? >>>>>>>> >>>>>>>> Current 32bit binary with NUMAInterleavingGranularity=2g on >>>>>>>> server mode >>>>>>>> fires an >>>>>>>> assert on Windows as we are proceeding without memory >>>>>>>> allocation failure >>>>>>>> check >>>>>>>> at CodeCache::reserve_heap_memory. >>>>>>>> >>>>>>>> I think the constraint function can be removed with maximum >>>>>>>> range of >>>>>>>> 2G/8192G. >>>>>>>> These are the maximum available memory on Windows and smaller >>>>>>>> values can >>>>>>>> be used >>>>>>>> but I wanted to avoid adding artificial limit. With this >>>>>>>> limitation, current >>>>>>>> constraint function for overflow check is not needed. >>>>>>>> And we need to check allocation failure. >>>>>>>> >>>>>>>> This issue is not reproducible with client mode as the >>>>>>>> different default >>>>>>>> value >>>>>>>> of ReservedCodeCacheSize sets SegmentedCodeCache to false. And >>>>>>>> CodeCache::reserve_heap_memory() is called only when >>>>>>>> SegmentedCodeCache is >>>>>>>> enabled. >>>>>>>> >>>>>>>> Skipped adding a test as TestOptionsWithRanges.java is enough >>>>>>>> when this is >>>>>>>> combined with nightly vm option rotation. >>>>>>>> >>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8144949 >>>>>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8144949/webrev.00 >>>>>>>> Testing: JPRT (with TestOptionsWithRanges.java enabled), manual >>>>>>>> tests on >>>>>>>> Windows >>>>>>>> machine(to test several option combination). >>>>> >>>>> Sangheon, >>>>> >>>>> Could you check if the changes in globals.hpp can be put in >>>>> >>>>> "os/windows/vm/globals_windows.hpp" >>>>> >>>>> Since this is a windows specific flag, it should work to >>>>> go in windows.hpp. >>>> This flag is only used for Windows (as its description says), so I >>>> am not sure >>>> whether we need to move it to windows.hpp. >>> I understood your comment to move my changes(range and constraint) to >>> globals_windows.hpp. i.e. making the flag as product_pd. Since this >>> flag is only >>> used on Windows, I am not sure it is a good idea. >>> If you are suggesting to move the whole definition of the flag into >>> globals_windows.hpp, let me consider it. I'm not sure whether it's >>> feasible or not. >> >> The description of the flag kind of mentions that this is a Windows >> specific flag, but it's not fool prof. It's possible that this flag >> is used on non-Windows set ups as well. For instance applications >> could use the same set of flags on multiple platforms. Removing this >> flag on non-Windows platforms would be a breaking change in this case >> and will most likely require a CCC. >> /Jesper > > Jesper, you're right about the side effects of moving the code to > the globals_windows.hpp. Thank you Jesper, I didn't know about this. > > Sangheon, forget about that suggestion. Okay, Jon. I will proceed as is. Thanks, Sangheon > > Changes look good. > > Jon > >> >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>>> >>>>> On 32bit upper limit is 2G. Is that the largest value that can be >>>>> used >>>>> without having to check for arithmetic overflow? >>>> No. >>>> That is Windows OS limitation that each process would use. And >>>> within this >>>> range we don't need to check arithmetic overflow as it will never >>>> happen. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> Jon >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>> >>>>> >>>> >>> > From jon.masamitsu at oracle.com Wed Dec 16 22:45:38 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 16 Dec 2015 14:45:38 -0800 Subject: Request for review (s) - 8145031: Add regression test for 8133023 In-Reply-To: <56718734.3080003@oracle.com> References: <5669D7A0.8000201@oracle.com> <1450175079.2296.1.camel@oracle.com> <56706381.7050205@oracle.com> <56718734.3080003@oracle.com> Message-ID: <5671E992.9070306@oracle.com> Tom, Thanks for looking at this. On 12/16/2015 07:45 AM, Tom Benson wrote: > Hi Jon, > This looks OK to me (modulo Thomas' comments), but it's not clear to > me why a unit test is needed for this case, rather than a simple > assert somewhere, such as when the threads are created. Thanks, Do you mean add an assertion when each GC thread is created? I think that would add checks to 2 places (one for ParallelGC and one for the other GC's - ignoring the concurrent threads). Adding the check at one place seemed better. Or maybe you meant someplace else? Jon > Tom > > On 12/15/2015 2:01 PM, Jon Masamitsu wrote: >> >> >> On 12/15/2015 2:24 AM, Thomas Schatzl wrote: >>> Hi Jon, >>> >>> On Thu, 2015-12-10 at 11:50 -0800, Jon Masamitsu wrote: >>>> The cause of the failure in 8133023 was the calculation of the >>>> ParallelGCThreads using >>>> information that had not yet been initialized. Add a test that checks >>>> that, after full >>>> initialization, the fresh calculation of ParallelGCThreads is >>>> consistent with the value >>>> calculated earlier. >>>> >>>> http://cr.openjdk.java.net/~jmasa/8145031/webrev.00/ >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8145031 >>>> >>>> Tested with and without the fix for 8133023. >>>> >>> seems okay, with one nit: the indendation of the parameters for the >>> assert in Abstract_VM_Version::FinalParallelGCThreads_test() seems off. >>> >>> Also there is an extra space between the "void" and the method name. >> >> Both fixed. Thanks. >> >> Jon >> >>> >>> I do not need to re-review. >>> >>> Thanks, >>> Thomas >>> >>> >> > From jon.masamitsu at oracle.com Wed Dec 16 23:15:58 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 16 Dec 2015 15:15:58 -0800 Subject: RFR (S): 8145534: TestRemsetLogging.java takes a long time In-Reply-To: <1450286283.2322.49.camel@oracle.com> References: <1450286283.2322.49.camel@oracle.com> Message-ID: <5671F0AE.6020705@oracle.com> Thomas, http://cr.openjdk.java.net/~tschatzl/8145534/webrev/test/gc/g1/TestRemsetLoggingThreads.java.frames.html Did you consider adding the -Xint to the execution line above? http://cr.openjdk.java.net/~tschatzl/8145534/webrev/test/gc/g1/TestRemsetLoggingPerRegion.java.frames.html Why is the @requires needed above? It's telling jtreg that TestRemsetLoggingPerRegion needs to be run with G1, right. Is that really the case? Rest looks good. Jon On 12/16/2015 09:18 AM, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the following changes to gc/g1/TestRemset* > tests that decrease its runtime significantly? > > Most of the runtime improvements come from using WhiteBox methods to > start gcs (instead of allocating objects and waiting for it to happen), > then forcing that test to use the interpreter (because starting up the > compilers only slows it down), and some measures to improve startup. > > In total all this decreases fastdebug VM runtime from 100s to 17s on my > local machine. > > The changes also add @requires tags and deletes equivalent java code. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8145534 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8145534/webrev/ > Testing: > looking at run times of jprt jobs which are much better now. There is > still some variation, but they are in the same range as other tests now. > > Thanks, > Thomas > > From sangheon.kim at oracle.com Thu Dec 17 05:34:43 2015 From: sangheon.kim at oracle.com (sangheon) Date: Wed, 16 Dec 2015 21:34:43 -0800 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <56717944.1030402@oracle.com> References: <5670B5F1.7010505@oracle.com> <56717944.1030402@oracle.com> Message-ID: <56724973.4060405@oracle.com> Hi Jesper, Thank you for looking at this! On 12/16/2015 06:46 AM, Jesper Wilhelmsson wrote: > Hi Sangheon, > > * It seems to me that protect_pages_individually() can only be called > if UseLargePages is false. Still it looks at UseLargePages to decide > page_size. I would prefer if there was an assert(!UseLargePages) at > the start of protect_pages_individually() to emphasize that this code > has not been used or tested with large pages. > > * I'm not sure if this matters, but it seems to me that if the size of > the area is not an even multiple of pages, you will start protecting > the smaller part, and then continue with page sized areas. E.g. If > page size is 4k and we want to protect a 10k area, we will start with > a 2k block and then take two 4k blocks. This has the effect that if we > pass in a page aligned address, the areas we protect will not cover > one page at a time. This may be a non-issue though. It depends on if > we usually get page aligned addresses and if it matters if we protect > one page at a time or not. Your second comment made me to change the function which maybe doesn't need an assert now and removed potential alignment problem. Currently protect_pages_individually() is only called when "UseNUMAInterleaving && !UseLargePages" and protect_pages_indivisually() will always have aligned size as allocate_pages_individually() allocate aligned size. This means, as you pointed, we need an assert to prevent wrong use and would have alignment issue. So I changed the function to read currently allocated chunk size(via Windows API) rather than calculating chunk size and then try to protect the chunk. With this change, we don't need to care about the flags neither align matter. > > * You use UINT32_FORMAT to print an uint. %u is the recommended way to > print an uint. Fixed. > > * if (!ret) return false; We should always use { } Fixed. Here's a next webrev. http://cr.openjdk.java.net/~sangheki/8145000/webrev.01/ http://cr.openjdk.java.net/~sangheki/8145000/webrev.01_to_00/ Testing: JPRT (TestOptionsWithRanges.java), RBT (hotspot_all,testlist,noncolo.testlist for Windows only) * Added more tests. Thanks, Sangheon > > Thanks, > /Jesper > > > > Den 16/12/15 kl. 01:53, skrev sangheon: >> Hi all, >> >> Could I get a couple of reviews for Windows NUMAInterleaveGranularity >> change? >> >> Current Windows implementation can't handle correctly when we reserve >> a heap >> with disjoint heap base mode with NUMAInterleaveGranularity. >> >> Windows, os::protect_memory fails in above case, as we are trying to >> protect the >> whole reserved heap at one time. But we reserved that area with >> separate/contiguous chunks based on NUMAInterleaveGranularity size. MSDN >> describes to call the API separately. >> I changed protect API to be called multiple times if needed. >> >> Skipped adding a test as TestOptionsWithRanges.java is enough. >> 'java -XX:+UseNUMA -XX:+UseNUMAInterleaving' is enough to reproduce >> on large >> memory Windows machine. However we need to specify heap size if the >> machine >> doesn't have large memory. e.g. -Xms30g -Xmx30g >> >> This patch is based on the patch for JDK-8144949 which includes the >> change of >> the max range of NUMAInterleaveGranularity to 2G(32bit), 8192G(64bit). >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8145000 >> Webrev: http://cr.openjdk.java.net/~sangheki/8145000/webrev.00 >> Testing: JPRT (with TestOptionsWithRanges.java enabled), manual tests >> on Windows >> machine(to test on large memory). >> >> Thanks, >> Sangheon >> >> From bengt.rutisson at oracle.com Thu Dec 17 07:28:25 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 17 Dec 2015 08:28:25 +0100 Subject: RFR (S): 8145534: TestRemsetLogging.java takes a long time In-Reply-To: <1450286283.2322.49.camel@oracle.com> References: <1450286283.2322.49.camel@oracle.com> Message-ID: <56726419.40804@oracle.com> Hi Thomas, Thanks for fixing this! Changes look good except that I think TestRemsetLogging.java should have the same @requires tag as the other tests. @requires vm.gc=="G1" | vm.gc =="null" Also, I think the 100 seconds runtime that you got may be related to the fastdebug/slowdebug issue that the changes to the configure scripts introduced. The numbers I reported in the bug report (18 seconds) are from my workstation without the slowdebug problem. If I run with your changes I get: elapsed time (seconds): 4.391 Which is a great improvement and an acceptable execution time I think. Thanks, Bengt On 2015-12-16 18:18, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the following changes to gc/g1/TestRemset* > tests that decrease its runtime significantly? > > Most of the runtime improvements come from using WhiteBox methods to > start gcs (instead of allocating objects and waiting for it to happen), > then forcing that test to use the interpreter (because starting up the > compilers only slows it down), and some measures to improve startup. > > In total all this decreases fastdebug VM runtime from 100s to 17s on my > local machine. > > The changes also add @requires tags and deletes equivalent java code. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8145534 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8145534/webrev/ > Testing: > looking at run times of jprt jobs which are much better now. There is > still some variation, but they are in the same range as other tests now. > > Thanks, > Thomas > > From bengt.rutisson at oracle.com Thu Dec 17 08:34:10 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 17 Dec 2015 09:34:10 +0100 Subject: RFR (M): JDK-8068394: Trace event for concurrent GC phases In-Reply-To: <567091A1.1050105@oracle.com> References: <56282271.5090108@oracle.com> <56546233.20006@oracle.com> <5654B10E.1060701@oracle.com> <565EB318.8060607@oracle.com> <565F33A8.6060608@oracle.com> <565FF761.30200@oracle.com> <566FB2BA.5020408@oracle.com> <566FD637.4060909@oracle.com> <56706A22.9070803@oracle.com> <56706AC7.1070708@oracle.com> <56706BF8.6030604@oracle.com> <567091A1.1050105@oracle.com> Message-ID: <56727382.4030800@oracle.com> Hi Sangheon, On 2015-12-15 23:18, sangheon wrote: > Hi Stefan, > > Here's the next webrev which includes your suggestion. > - Removed 'NOT_PRODUCT' and '#ifndef PRODUCT'. (Stefan) > - Removed volatile keyword at > ConcurrentGCTimer::_is_concurrent_phase_active. (Stefan) > - Removed volatile keyword at > ConcurrentMark::_concurrent_phase_started. This should be removed as > well. > > http://cr.openjdk.java.net/~sangheki/8068394/webrev.02 > http://cr.openjdk.java.net/~sangheki/8068394/webrev.02_to_01/ This looks good to me. Thanks, Bengt > > Thanks, > Sangheon > > > On 12/15/2015 11:37 AM, sangheon wrote: >> Hi Stefan, >> >> On 12/15/2015 11:32 AM, Stefan Karlsson wrote: >>> Hi Sangheon, >>> >>> On 2015-12-15 20:29, sangheon wrote: >>>> Hi Stefan, >>>> >>>> Thank you for looking at official RFR as well. >>>> >>>> On 12/15/2015 12:58 AM, Stefan Karlsson wrote: >>>>> Hi Sangheon, >>>>> >>>>> On 2015-12-15 07:27, sangheon wrote: >>>>>> Hi Bengt and all, >>>>>> >>>>>> Here's a next webrev. >>>>>> Bengt and I had a discussion on other thread and he and Stefan >>>>>> Karlsson suggested simpler design. >>>>>> >>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01 >>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01_to_00 >>>>> >>>>> Thanks for doing the simplifications of the patch. >>>>> >>>>> I have a couple of comments: >>>>> Could you replace NOT_PRODUCT with DEBUG_ONLY, and #ifndef PRODUCT >>>>> with #ifdef ASSERT. Otherwise, you'll get inconsistencies when >>>>> building with optimized builds where neither PRODUCT nor ASSERT is >>>>> defined. >>>> Okay, I will do. >>>> But you also pointed that whether this flag is really needed below. >>>> >>>>> >>>>> 81 void ConcurrentGCTimer::register_gc_concurrent_start(const >>>>> char* name, const Ticks& time) { >>>>> 82 assert(!_is_concurrent_phase_active, "A concurrent phase is >>>>> already active."); >>>>> 83 _time_partitions.report_gc_phase_start(name, time, >>>>> GCPhase::ConcurrentPhaseType); >>>>> 84 NOT_PRODUCT(_is_concurrent_phase_active = true;) >>>>> 85 } >>>>> >>>>> 162 class ConcurrentGCTimer : public GCTimer { >>>>> 163 // ConcurrentGCTimer can't be used if there is an overlap >>>>> between a pause phase and a concurrent phase. >>>>> 164 // _is_concurrent_phase_active is used to find above case. >>>>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >>>>> 166 >>>>> 167 public: >>>>> 168 #ifndef PRODUCT >>>>> 169 ConcurrentGCTimer(): GCTimer(), >>>>> _is_concurrent_phase_active(false) {}; >>>>> 170 #endif Is it really worth optimizing away the boolean? The >>>>> code would be cleaner without these macros. >>>> I just wanted to prevent mis-use of concurrent timer for >>>> overlapping phase. >>>> A pause phase nor another concurrent phase can't be started if a >>>> concurrent phase is already started. >>>> I think this would be nice to have. But I don't have a strong >>>> opinion on this as currently we don't have these situations. >>> >>> I meant that we could keep the the variable in the product builds as >>> well. Just to get rid of the noisy PRODUCT / DEBUG_ONLY macros. It >>> could even be useful for future debugging. ;) >> Oops! >> I am okay with removing this macro. >> >> Let me post a new webrev soon. >> Thank you for the real time answer! >> >> Sangheon >> >> >>>> >>>>> >>>>> >>>>> Why are you using volatile here? I don't see why that should be >>>>> needed. >>>>> >>>>> 162 class ConcurrentGCTimer : public GCTimer { >>>>> 163 // ConcurrentGCTimer can't be used if there is an overlap >>>>> between a pause phase and a concurrent phase. >>>>> 164 // _is_concurrent_phase_active is used to find above case. >>>>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >>>> You are right, volatile is not needed here. >>>> I was thinking register_gc_concurrent_end() would be called from >>>> different threads(ConcurrentMarkThread and VMThread), but as it >>>> only happens from safepoint, I think volatile should be removed. >>>> >>>> I will post a new webrev with your opinion about the flag. >>> >>> Great. >>> >>> Thanks, >>> StefanK >>> >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>>> >>>>>> This webrev includes: >>>>>> 1. Moving concurrent phase measurement into CMSPhaseAccounting >>>>>> class. So we can check all concurrent phases from CMS. >>>>>> >>>>>> 2. Renamed a new flag introduced from webrev.00 for general use, >>>>>> _concurrent_phase_started. >>>>>> >>>>>> 3. Added helper class for concurrent phase measurement, >>>>>> GCConcPhaseTimer. And used this class for all concurrent phases. >>>>>> >>>>>> 4. Flag checking is moved from >>>>>> G1CollectedHeap::register_concurrent_cycle_end() to >>>>>> ConcurrentMark::abort(). >>>>>> >>>>>> 5. Changed switch() to if else statement at gcTraceSend. >>>>>> >>>>>> Many thanks to Bengt and Stefan Karlsson for the discussion. >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>> On 12/03/2015 12:03 AM, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> This all sounds good. Looking forward to the next webrev. >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>>>> >>>>>>> On 2015-12-02 19:08, sangheon.kim wrote: >>>>>>>> Hi Bengt, >>>>>>>> >>>>>>>> >>>>>>>> On 12/02/2015 01:00 AM, Bengt Rutisson wrote: >>>>>>>>> >>>>>>>>> Hi Sangheon, >>>>>>>>> >>>>>>>>> Sorry again for the late reply. Comments inline. >>>>>>>> No not at all. >>>>>>>> Thank you for taking time for this review! >>>>>>>> >>>>>>>>> >>>>>>>>> On 2015-11-24 19:48, sangheon.kim wrote: >>>>>>>>>> Hi Bengt, >>>>>>>>>> >>>>>>>>>> Thank you so much for reviewing this patch! >>>>>>>>>> >>>>>>>>>> On 11/24/2015 05:12 AM, Bengt Rutisson wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Sangheon, >>>>>>>>>>> >>>>>>>>>>> Sorry for the very late reply to this review request. >>>>>>>>>>> >>>>>>>>>>> On 2015-10-22 01:40, sangheon.kim wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Can I get some reviews for this change of adding a trace >>>>>>>>>>>> event for concurrent phases on CMS and G1? >>>>>>>>>>>> >>>>>>>>>>>> Currently we only measure pause times for major phases. >>>>>>>>>>>> But I want to add 'concurrent mark' and 'concurrent sweep' >>>>>>>>>>>> phases for CMS and 'concurrent mark' phase for G1. >>>>>>>>>>>> To achieve this, I had to change ConcurrentGCTimer and >>>>>>>>>>>> related classes. >>>>>>>>>>>> >>>>>>>>>>>> This patch includes: >>>>>>>>>>>> 1) A concurrent phase can be measured only from >>>>>>>>>>>> ConcurrentGCTimer and measuring an overlap between >>>>>>>>>>>> concurrent and pause is not allowed as currently we don't >>>>>>>>>>>> have that use case. And TimePartitions class(or related >>>>>>>>>>>> classes) will be simpler than an overlap allowed case. >>>>>>>>>>>> 2) I removed PausePhase and ConcurrentPhase which are >>>>>>>>>>>> derived from GCPhase because I wanted to avoid heap >>>>>>>>>>>> allocation when adding to GrowableArray. Instead introduced >>>>>>>>>>>> 'type' member variable at GCPhase. >>>>>>>>>>>> >>>>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8068394 >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Nice work! It is great to get some timing information for >>>>>>>>>>> the concurrent phases. >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> A few questions/comments: >>>>>>>>>>> >>>>>>>>>>> CMS. >>>>>>>>>>> >>>>>>>>>>> You have added timing events for the concurrent phases mark >>>>>>>>>>> and sweep, but not for other concurrent phases (preclean, >>>>>>>>>>> abortable_preclean and reset_concurrent). I think that if >>>>>>>>>>> you moved your calls to >>>>>>>>>>> _gc_timer_cm->register_gc_concurrent_start() and >>>>>>>>>>> _gc_timer_cm->register_gc_concurrent_end() into the >>>>>>>>>>> constructor and destructor of CMSPhaseAccounting you would >>>>>>>>>>> automatically get timing events for all concurrent phases. >>>>>>>>>> I also considered about this idea but I was not clear whether >>>>>>>>>> it is good measurement especially for 'sweep'. >>>>>>>>>> We are using CMSPhaseAccounting for 5 cases. >>>>>>>>>> I think for 'mark' and 'preclean' they are okay. (there are >>>>>>>>>> non-product functions call before CMSPhaseAccounting. But >>>>>>>>>> they are okay). >>>>>>>>>> For 'abortable-preclean' and 'reset', they are good to have >>>>>>>>>> that. >>>>>>>>>> But when it comes to 'sweep', there are timer and >>>>>>>>>> CMSTokenSyncWithLocks related codes and I was not sure about >>>>>>>>>> these. >>>>>>>>>> If you think they are also okay, I will change as you suggested. >>>>>>>>> >>>>>>>>> I think it is fine for the sweep part as well. If the >>>>>>>>> CMSPhaseAccounting instance is not measuring the correct part >>>>>>>>> of the work I think we should change it to measure what we >>>>>>>>> want. That way we improve the existing measurements too. >>>>>>>>> >>>>>>>>> But as you stated in your follow up email, I think the sweep >>>>>>>>> code is actually pretty much ok from this perspective. >>>>>>>>> >>>>>>>>> So, I would prefer to go with the CMSPhaseAccounting approach. >>>>>>>> Okay, I already changed as you suggested. :) >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> G1. >>>>>>>>>>> >>>>>>>>>>> I think the use of _concurrent_marking_from_roots is >>>>>>>>>>> unfortunate. It would be much cleaner if >>>>>>>>>>> ConcurrentMark::register_mark_from_roots_phase_end() called >>>>>>>>>>> register_gc_concurrent_end() directly. >>>>>>>>>> I wanted to avoid introducing the new flag but the reason of >>>>>>>>>> it was, as you know, to handle 'abort'. >>>>>>>>>> When 'abort' happens we do need to end all timers before >>>>>>>>>> calling 'GCTracer::report_gc_end()'. >>>>>>>>>> And at this point we need a way to know whether concurrent >>>>>>>>>> timer is started or not. >>>>>>>>> >>>>>>>>> As I tried to describe I think you can extend the scope of the >>>>>>>>> timing to cover the part until the marking thread discovers >>>>>>>>> that the marking was aborted. Basically moving the timing in >>>>>>>>> to ConcurrentMarkThread::run_service(). >>>>>>>> Oh, I mis-understood your point. Sorry. >>>>>>>> I will try your recommendation. >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I realize that this would change the timing for when a >>>>>>>>>>> concurrent marking is aborted. The whole time for a full GC >>>>>>>>>>> (or even several full GCs) would be included in the >>>>>>>>>>> concurrent marking phase. But from a code perspective that >>>>>>>>>>> is what happens, so maybe that is the correct time to >>>>>>>>>>> report? Also, I think the logging is reported that way so if >>>>>>>>>>> we want to make it easy to match the timing events with the >>>>>>>>>>> logging we might want to use about the same scope for timing. >>>>>>>>>>> >>>>>>>>>>> Why do we only measure the concurrent mark phase for G1? >>>>>>>>>> This is good question. :) >>>>>>>>>> I was comparing CMS and G1 for major concurrent phases. >>>>>>>>>> And the candidates were 'concurrent mark/sweep (CMS)' and >>>>>>>>>> 'concurrent mark(G1)'. >>>>>>>>>> >>>>>>>>>>> Wouldn't it be good to measure all concurrent phases? >>>>>>>>>> Okay, Stefan Karlsson also pointed to have them as well so I >>>>>>>>>> filed a separate CR for this. >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8143951 >>>>>>>>> >>>>>>>>> Ok. Is there a reason why we want to split this up into two >>>>>>>>> changes? Why not add all the concurrent timing events at once? >>>>>>>>> >>>>>>>>> I'm ok with splitting it up into two changes, but then maybe >>>>>>>>> the title for JDK-8068394 should be changed to indicate that >>>>>>>>> it only adds events for the marking phase. Also, if we go with >>>>>>>>> the CMSPhaseAccounting approach for CMS, you get events for >>>>>>>>> all phases there. So, it will be a bit odd to have all >>>>>>>>> concurrent phases handled for CMS but only concurrent mark for >>>>>>>>> G1. >>>>>>>> You are correct and I agree with you. >>>>>>>> The only reason of split was due to limited time for FC. >>>>>>>> But as we have enough time, let me close JDK-8143951 and >>>>>>>> include concurrent mark for G1 as well. >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> gcTraceSend.cpp >>>>>>>>>>> >>>>>>>>>>> 389 void visit(GCPhase* phase) { >>>>>>>>>>> 390 switch (phase->type()) { >>>>>>>>>>> 391 case GCPhase::PausePhaseType: >>>>>>>>>>> 392 assert(phase->level() < >>>>>>>>>>> PhasesStack::PHASE_LEVELS, "Need more event types for >>>>>>>>>>> PausePhase"); >>>>>>>>>>> 393 >>>>>>>>>>> 394 switch (phase->level()) { >>>>>>>>>>> 395 case 0: send_phase(phase); >>>>>>>>>>> break; >>>>>>>>>>> 396 case 1: >>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>> 397 case 2: >>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>> 398 case 3: >>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>> 399 default: /* Ignore sending this phase */ break; >>>>>>>>>>> 400 } >>>>>>>>>>> 401 break; >>>>>>>>>>> 402 >>>>>>>>>>> 403 case GCPhase::ConcurrentPhaseType: >>>>>>>>>>> 404 assert(phase->level() < 1, "There's only one >>>>>>>>>>> level for ConcurrentPhase"); >>>>>>>>>>> 405 >>>>>>>>>>> 406 switch (phase->level()) { >>>>>>>>>>> 407 case 0: >>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>> 408 default: /* Ignore sending this phase */ break; >>>>>>>>>>> 409 } >>>>>>>>>>> 410 break; >>>>>>>>>>> 411 } >>>>>>>>>>> 412 } >>>>>>>>>>> 413 }; >>>>>>>>>>> >>>>>>>>>>> Since there are only two values for GCPhase::PhaseType it >>>>>>>>>>> seems a bit odd to use a switch statement. I think I would >>>>>>>>>>> prefer to factor out the code for the different types a bit >>>>>>>>>>> too. So, maybe something like: >>>>>>>>>>> >>>>>>>>>>> void visit(GCPhase* phase) { >>>>>>>>>>> if (phase->type() == GCPhase::PausePhaseType) { >>>>>>>>>>> visit_pause(phase); >>>>>>>>>>> } else { >>>>>>>>>>> assert(phase->type() == GCPhase::ConcurrentPhaseType, ""); >>>>>>>>>>> visit_concurrent(phase); >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>> This seems better. I will fix. >>>>>>>>> >>>>>>>>> Good. Thanks! >>>>>>>> :) >>>>>>>> >>>>>>>> I will post next webrev when I'm ready, including JDK-8143951 >>>>>>>> part as well. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Bengt >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Sangheon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Bengt >>>>>>>>>>> >>>>>>>>>>>> Testing: JPRT >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Sangheon >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From stefan.karlsson at oracle.com Thu Dec 17 08:41:29 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 17 Dec 2015 09:41:29 +0100 Subject: RFR (M): JDK-8068394: Trace event for concurrent GC phases In-Reply-To: <567091A1.1050105@oracle.com> References: <56282271.5090108@oracle.com> <56546233.20006@oracle.com> <5654B10E.1060701@oracle.com> <565EB318.8060607@oracle.com> <565F33A8.6060608@oracle.com> <565FF761.30200@oracle.com> <566FB2BA.5020408@oracle.com> <566FD637.4060909@oracle.com> <56706A22.9070803@oracle.com> <56706AC7.1070708@oracle.com> <56706BF8.6030604@oracle.com> <567091A1.1050105@oracle.com> Message-ID: <56727539.2040802@oracle.com> Hi Sangheon, On 2015-12-15 23:18, sangheon wrote: > Hi Stefan, > > Here's the next webrev which includes your suggestion. > - Removed 'NOT_PRODUCT' and '#ifndef PRODUCT'. (Stefan) > - Removed volatile keyword at > ConcurrentGCTimer::_is_concurrent_phase_active. (Stefan) > - Removed volatile keyword at > ConcurrentMark::_concurrent_phase_started. This should be removed as > well. > > http://cr.openjdk.java.net/~sangheki/8068394/webrev.02 > http://cr.openjdk.java.net/~sangheki/8068394/webrev.02_to_01/ Looks good. Thanks, StefanK > > Thanks, > Sangheon > > > On 12/15/2015 11:37 AM, sangheon wrote: >> Hi Stefan, >> >> On 12/15/2015 11:32 AM, Stefan Karlsson wrote: >>> Hi Sangheon, >>> >>> On 2015-12-15 20:29, sangheon wrote: >>>> Hi Stefan, >>>> >>>> Thank you for looking at official RFR as well. >>>> >>>> On 12/15/2015 12:58 AM, Stefan Karlsson wrote: >>>>> Hi Sangheon, >>>>> >>>>> On 2015-12-15 07:27, sangheon wrote: >>>>>> Hi Bengt and all, >>>>>> >>>>>> Here's a next webrev. >>>>>> Bengt and I had a discussion on other thread and he and Stefan >>>>>> Karlsson suggested simpler design. >>>>>> >>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01 >>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01_to_00 >>>>> >>>>> Thanks for doing the simplifications of the patch. >>>>> >>>>> I have a couple of comments: >>>>> Could you replace NOT_PRODUCT with DEBUG_ONLY, and #ifndef PRODUCT >>>>> with #ifdef ASSERT. Otherwise, you'll get inconsistencies when >>>>> building with optimized builds where neither PRODUCT nor ASSERT is >>>>> defined. >>>> Okay, I will do. >>>> But you also pointed that whether this flag is really needed below. >>>> >>>>> >>>>> 81 void ConcurrentGCTimer::register_gc_concurrent_start(const >>>>> char* name, const Ticks& time) { >>>>> 82 assert(!_is_concurrent_phase_active, "A concurrent phase is >>>>> already active."); >>>>> 83 _time_partitions.report_gc_phase_start(name, time, >>>>> GCPhase::ConcurrentPhaseType); >>>>> 84 NOT_PRODUCT(_is_concurrent_phase_active = true;) >>>>> 85 } >>>>> >>>>> 162 class ConcurrentGCTimer : public GCTimer { >>>>> 163 // ConcurrentGCTimer can't be used if there is an overlap >>>>> between a pause phase and a concurrent phase. >>>>> 164 // _is_concurrent_phase_active is used to find above case. >>>>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >>>>> 166 >>>>> 167 public: >>>>> 168 #ifndef PRODUCT >>>>> 169 ConcurrentGCTimer(): GCTimer(), >>>>> _is_concurrent_phase_active(false) {}; >>>>> 170 #endif Is it really worth optimizing away the boolean? The >>>>> code would be cleaner without these macros. >>>> I just wanted to prevent mis-use of concurrent timer for >>>> overlapping phase. >>>> A pause phase nor another concurrent phase can't be started if a >>>> concurrent phase is already started. >>>> I think this would be nice to have. But I don't have a strong >>>> opinion on this as currently we don't have these situations. >>> >>> I meant that we could keep the the variable in the product builds as >>> well. Just to get rid of the noisy PRODUCT / DEBUG_ONLY macros. It >>> could even be useful for future debugging. ;) >> Oops! >> I am okay with removing this macro. >> >> Let me post a new webrev soon. >> Thank you for the real time answer! >> >> Sangheon >> >> >>>> >>>>> >>>>> >>>>> Why are you using volatile here? I don't see why that should be >>>>> needed. >>>>> >>>>> 162 class ConcurrentGCTimer : public GCTimer { >>>>> 163 // ConcurrentGCTimer can't be used if there is an overlap >>>>> between a pause phase and a concurrent phase. >>>>> 164 // _is_concurrent_phase_active is used to find above case. >>>>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >>>> You are right, volatile is not needed here. >>>> I was thinking register_gc_concurrent_end() would be called from >>>> different threads(ConcurrentMarkThread and VMThread), but as it >>>> only happens from safepoint, I think volatile should be removed. >>>> >>>> I will post a new webrev with your opinion about the flag. >>> >>> Great. >>> >>> Thanks, >>> StefanK >>> >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>>> >>>>>> This webrev includes: >>>>>> 1. Moving concurrent phase measurement into CMSPhaseAccounting >>>>>> class. So we can check all concurrent phases from CMS. >>>>>> >>>>>> 2. Renamed a new flag introduced from webrev.00 for general use, >>>>>> _concurrent_phase_started. >>>>>> >>>>>> 3. Added helper class for concurrent phase measurement, >>>>>> GCConcPhaseTimer. And used this class for all concurrent phases. >>>>>> >>>>>> 4. Flag checking is moved from >>>>>> G1CollectedHeap::register_concurrent_cycle_end() to >>>>>> ConcurrentMark::abort(). >>>>>> >>>>>> 5. Changed switch() to if else statement at gcTraceSend. >>>>>> >>>>>> Many thanks to Bengt and Stefan Karlsson for the discussion. >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>> On 12/03/2015 12:03 AM, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> This all sounds good. Looking forward to the next webrev. >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>>>> >>>>>>> On 2015-12-02 19:08, sangheon.kim wrote: >>>>>>>> Hi Bengt, >>>>>>>> >>>>>>>> >>>>>>>> On 12/02/2015 01:00 AM, Bengt Rutisson wrote: >>>>>>>>> >>>>>>>>> Hi Sangheon, >>>>>>>>> >>>>>>>>> Sorry again for the late reply. Comments inline. >>>>>>>> No not at all. >>>>>>>> Thank you for taking time for this review! >>>>>>>> >>>>>>>>> >>>>>>>>> On 2015-11-24 19:48, sangheon.kim wrote: >>>>>>>>>> Hi Bengt, >>>>>>>>>> >>>>>>>>>> Thank you so much for reviewing this patch! >>>>>>>>>> >>>>>>>>>> On 11/24/2015 05:12 AM, Bengt Rutisson wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Sangheon, >>>>>>>>>>> >>>>>>>>>>> Sorry for the very late reply to this review request. >>>>>>>>>>> >>>>>>>>>>> On 2015-10-22 01:40, sangheon.kim wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Can I get some reviews for this change of adding a trace >>>>>>>>>>>> event for concurrent phases on CMS and G1? >>>>>>>>>>>> >>>>>>>>>>>> Currently we only measure pause times for major phases. >>>>>>>>>>>> But I want to add 'concurrent mark' and 'concurrent sweep' >>>>>>>>>>>> phases for CMS and 'concurrent mark' phase for G1. >>>>>>>>>>>> To achieve this, I had to change ConcurrentGCTimer and >>>>>>>>>>>> related classes. >>>>>>>>>>>> >>>>>>>>>>>> This patch includes: >>>>>>>>>>>> 1) A concurrent phase can be measured only from >>>>>>>>>>>> ConcurrentGCTimer and measuring an overlap between >>>>>>>>>>>> concurrent and pause is not allowed as currently we don't >>>>>>>>>>>> have that use case. And TimePartitions class(or related >>>>>>>>>>>> classes) will be simpler than an overlap allowed case. >>>>>>>>>>>> 2) I removed PausePhase and ConcurrentPhase which are >>>>>>>>>>>> derived from GCPhase because I wanted to avoid heap >>>>>>>>>>>> allocation when adding to GrowableArray. Instead introduced >>>>>>>>>>>> 'type' member variable at GCPhase. >>>>>>>>>>>> >>>>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8068394 >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Nice work! It is great to get some timing information for >>>>>>>>>>> the concurrent phases. >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> A few questions/comments: >>>>>>>>>>> >>>>>>>>>>> CMS. >>>>>>>>>>> >>>>>>>>>>> You have added timing events for the concurrent phases mark >>>>>>>>>>> and sweep, but not for other concurrent phases (preclean, >>>>>>>>>>> abortable_preclean and reset_concurrent). I think that if >>>>>>>>>>> you moved your calls to >>>>>>>>>>> _gc_timer_cm->register_gc_concurrent_start() and >>>>>>>>>>> _gc_timer_cm->register_gc_concurrent_end() into the >>>>>>>>>>> constructor and destructor of CMSPhaseAccounting you would >>>>>>>>>>> automatically get timing events for all concurrent phases. >>>>>>>>>> I also considered about this idea but I was not clear whether >>>>>>>>>> it is good measurement especially for 'sweep'. >>>>>>>>>> We are using CMSPhaseAccounting for 5 cases. >>>>>>>>>> I think for 'mark' and 'preclean' they are okay. (there are >>>>>>>>>> non-product functions call before CMSPhaseAccounting. But >>>>>>>>>> they are okay). >>>>>>>>>> For 'abortable-preclean' and 'reset', they are good to have >>>>>>>>>> that. >>>>>>>>>> But when it comes to 'sweep', there are timer and >>>>>>>>>> CMSTokenSyncWithLocks related codes and I was not sure about >>>>>>>>>> these. >>>>>>>>>> If you think they are also okay, I will change as you suggested. >>>>>>>>> >>>>>>>>> I think it is fine for the sweep part as well. If the >>>>>>>>> CMSPhaseAccounting instance is not measuring the correct part >>>>>>>>> of the work I think we should change it to measure what we >>>>>>>>> want. That way we improve the existing measurements too. >>>>>>>>> >>>>>>>>> But as you stated in your follow up email, I think the sweep >>>>>>>>> code is actually pretty much ok from this perspective. >>>>>>>>> >>>>>>>>> So, I would prefer to go with the CMSPhaseAccounting approach. >>>>>>>> Okay, I already changed as you suggested. :) >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> G1. >>>>>>>>>>> >>>>>>>>>>> I think the use of _concurrent_marking_from_roots is >>>>>>>>>>> unfortunate. It would be much cleaner if >>>>>>>>>>> ConcurrentMark::register_mark_from_roots_phase_end() called >>>>>>>>>>> register_gc_concurrent_end() directly. >>>>>>>>>> I wanted to avoid introducing the new flag but the reason of >>>>>>>>>> it was, as you know, to handle 'abort'. >>>>>>>>>> When 'abort' happens we do need to end all timers before >>>>>>>>>> calling 'GCTracer::report_gc_end()'. >>>>>>>>>> And at this point we need a way to know whether concurrent >>>>>>>>>> timer is started or not. >>>>>>>>> >>>>>>>>> As I tried to describe I think you can extend the scope of the >>>>>>>>> timing to cover the part until the marking thread discovers >>>>>>>>> that the marking was aborted. Basically moving the timing in >>>>>>>>> to ConcurrentMarkThread::run_service(). >>>>>>>> Oh, I mis-understood your point. Sorry. >>>>>>>> I will try your recommendation. >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I realize that this would change the timing for when a >>>>>>>>>>> concurrent marking is aborted. The whole time for a full GC >>>>>>>>>>> (or even several full GCs) would be included in the >>>>>>>>>>> concurrent marking phase. But from a code perspective that >>>>>>>>>>> is what happens, so maybe that is the correct time to >>>>>>>>>>> report? Also, I think the logging is reported that way so if >>>>>>>>>>> we want to make it easy to match the timing events with the >>>>>>>>>>> logging we might want to use about the same scope for timing. >>>>>>>>>>> >>>>>>>>>>> Why do we only measure the concurrent mark phase for G1? >>>>>>>>>> This is good question. :) >>>>>>>>>> I was comparing CMS and G1 for major concurrent phases. >>>>>>>>>> And the candidates were 'concurrent mark/sweep (CMS)' and >>>>>>>>>> 'concurrent mark(G1)'. >>>>>>>>>> >>>>>>>>>>> Wouldn't it be good to measure all concurrent phases? >>>>>>>>>> Okay, Stefan Karlsson also pointed to have them as well so I >>>>>>>>>> filed a separate CR for this. >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8143951 >>>>>>>>> >>>>>>>>> Ok. Is there a reason why we want to split this up into two >>>>>>>>> changes? Why not add all the concurrent timing events at once? >>>>>>>>> >>>>>>>>> I'm ok with splitting it up into two changes, but then maybe >>>>>>>>> the title for JDK-8068394 should be changed to indicate that >>>>>>>>> it only adds events for the marking phase. Also, if we go with >>>>>>>>> the CMSPhaseAccounting approach for CMS, you get events for >>>>>>>>> all phases there. So, it will be a bit odd to have all >>>>>>>>> concurrent phases handled for CMS but only concurrent mark for >>>>>>>>> G1. >>>>>>>> You are correct and I agree with you. >>>>>>>> The only reason of split was due to limited time for FC. >>>>>>>> But as we have enough time, let me close JDK-8143951 and >>>>>>>> include concurrent mark for G1 as well. >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> gcTraceSend.cpp >>>>>>>>>>> >>>>>>>>>>> 389 void visit(GCPhase* phase) { >>>>>>>>>>> 390 switch (phase->type()) { >>>>>>>>>>> 391 case GCPhase::PausePhaseType: >>>>>>>>>>> 392 assert(phase->level() < >>>>>>>>>>> PhasesStack::PHASE_LEVELS, "Need more event types for >>>>>>>>>>> PausePhase"); >>>>>>>>>>> 393 >>>>>>>>>>> 394 switch (phase->level()) { >>>>>>>>>>> 395 case 0: send_phase(phase); >>>>>>>>>>> break; >>>>>>>>>>> 396 case 1: >>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>> 397 case 2: >>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>> 398 case 3: >>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>> 399 default: /* Ignore sending this phase */ break; >>>>>>>>>>> 400 } >>>>>>>>>>> 401 break; >>>>>>>>>>> 402 >>>>>>>>>>> 403 case GCPhase::ConcurrentPhaseType: >>>>>>>>>>> 404 assert(phase->level() < 1, "There's only one >>>>>>>>>>> level for ConcurrentPhase"); >>>>>>>>>>> 405 >>>>>>>>>>> 406 switch (phase->level()) { >>>>>>>>>>> 407 case 0: >>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>> 408 default: /* Ignore sending this phase */ break; >>>>>>>>>>> 409 } >>>>>>>>>>> 410 break; >>>>>>>>>>> 411 } >>>>>>>>>>> 412 } >>>>>>>>>>> 413 }; >>>>>>>>>>> >>>>>>>>>>> Since there are only two values for GCPhase::PhaseType it >>>>>>>>>>> seems a bit odd to use a switch statement. I think I would >>>>>>>>>>> prefer to factor out the code for the different types a bit >>>>>>>>>>> too. So, maybe something like: >>>>>>>>>>> >>>>>>>>>>> void visit(GCPhase* phase) { >>>>>>>>>>> if (phase->type() == GCPhase::PausePhaseType) { >>>>>>>>>>> visit_pause(phase); >>>>>>>>>>> } else { >>>>>>>>>>> assert(phase->type() == GCPhase::ConcurrentPhaseType, ""); >>>>>>>>>>> visit_concurrent(phase); >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>> This seems better. I will fix. >>>>>>>>> >>>>>>>>> Good. Thanks! >>>>>>>> :) >>>>>>>> >>>>>>>> I will post next webrev when I'm ready, including JDK-8143951 >>>>>>>> part as well. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Bengt >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Sangheon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Bengt >>>>>>>>>>> >>>>>>>>>>>> Testing: JPRT >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Sangheon >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From thomas.schatzl at oracle.com Thu Dec 17 11:03:48 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 17 Dec 2015 12:03:48 +0100 Subject: RFR (S): 8145534: TestRemsetLogging.java takes a long time In-Reply-To: <56726419.40804@oracle.com> References: <1450286283.2322.49.camel@oracle.com> <56726419.40804@oracle.com> Message-ID: <1450350228.2137.3.camel@oracle.com> Hi Bengt, thanks for your review, On Thu, 2015-12-17 at 08:28 +0100, Bengt Rutisson wrote: > Hi Thomas, > > Thanks for fixing this! > > Changes look good except that I think TestRemsetLogging.java should have > the same @requires tag as the other tests. > > @requires vm.gc=="G1" | vm.gc =="null" > Fixed. > > Also, I think the 100 seconds runtime that you got may be related to the > fastdebug/slowdebug issue that the changes to the configure scripts > introduced. > > The numbers I reported in the bug report (18 seconds) are from my > workstation without the slowdebug problem. > > If I run with your changes I get: > > elapsed time (seconds): 4.391 > > Which is a great improvement and an acceptable execution time I think. :) New webrev at http://cr.openjdk.java.net/~tschatzl/8145534/webrev.1 (sorry no diff, I messed up) Thanks, Thomas From thomas.schatzl at oracle.com Thu Dec 17 11:05:24 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 17 Dec 2015 12:05:24 +0100 Subject: RFR (S): 8145534: TestRemsetLogging.java takes a long time In-Reply-To: <5671F0AE.6020705@oracle.com> References: <1450286283.2322.49.camel@oracle.com> <5671F0AE.6020705@oracle.com> Message-ID: <1450350324.2137.5.camel@oracle.com> Hi Jon, thanks for your review. On Wed, 2015-12-16 at 15:15 -0800, Jon Masamitsu wrote: > Thomas, > > http://cr.openjdk.java.net/~tschatzl/8145534/webrev/test/gc/g1/TestRemsetLoggingThreads.java.frames.html > > Did you consider adding the -Xint to the execution line above? The test only runs the VM with -version. No java code is executed. > > http://cr.openjdk.java.net/~tschatzl/8145534/webrev/test/gc/g1/TestRemsetLoggingPerRegion.java.frames.html > > Why is the @requires needed above? It's telling jtreg that > TestRemsetLoggingPerRegion > needs to be run with G1, right. Is that really the case? > > Rest looks good. Yes. The option and log message is G1 only. New webrev at http://cr.openjdk.java.net/~tschatzl/8145534/webrev.1 (sorry no diff, I messed up) Thanks, Thomas From thomas.schatzl at oracle.com Thu Dec 17 11:08:48 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 17 Dec 2015 12:08:48 +0100 Subject: RFR (S): 8145534: TestRemsetLogging.java takes a long time In-Reply-To: <5671A99E.3040606@oracle.com> References: <1450286283.2322.49.camel@oracle.com> <5671A99E.3040606@oracle.com> Message-ID: <1450350528.2137.9.camel@oracle.com> Hi Dima, On Wed, 2015-12-16 at 21:12 +0300, Dmitry Fazunenko wrote: > Hi Thomas, > > 1) TestRemsetLoggingPerRegion.java > there are unused imports, you can remove them > Fixed. > 2) TestRemsetLoggingThreads.java > it doesn't use TestRemsetLoggingTools, just -version. > So, you don't need WB here and you don't need to build > TestRemsetLoggingTools TestRemsetLoggingThreads > Fixed. > 3) TestRemsetLoggingTools.java > You changed the logic of the test: > - replaced "1 young GC + N full GC" with "N young GC + 1 full GC" > - removed all object allocations > > So, now VerifySummaryOutput just invokes serveral GC. > Did you do this intentionally or by mistake? > Intentionally. The idea is to run one gc of every kind. If the user specified to run only one gc, it does not matter. The expected messages are printed for any kind of gc. Young gcs on an empty heap are just slightly faster than full gcs. The test also does not check particular object allocation, just that some messages exist. Previously the allocations with the goal to run young gcs only. There is no difference on whether there are actually any kind of survivors. New webrev at http://cr.openjdk.java.net/~tschatzl/8145534/webrev.1 (sorry no diff, I messed up) Thanks, Thomas From dmitry.fazunenko at oracle.com Thu Dec 17 11:33:14 2015 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 17 Dec 2015 14:33:14 +0300 Subject: RFR (S): 8145534: TestRemsetLogging.java takes a long time In-Reply-To: <1450350528.2137.9.camel@oracle.com> References: <1450286283.2322.49.camel@oracle.com> <5671A99E.3040606@oracle.com> <1450350528.2137.9.camel@oracle.com> Message-ID: <56729D7A.9060900@oracle.com> Hi Thomas, Thanks for explanation. New version looks good to me. One a very tiny comment about TestRemsetLoggingThreads.java * @library /testlibrary /test/lib --> * @library /testlibrary I don't need a new webrev for that. Thanks, Dima On 17.12.2015 14:08, Thomas Schatzl wrote: > Hi Dima, > > On Wed, 2015-12-16 at 21:12 +0300, Dmitry Fazunenko wrote: >> Hi Thomas, >> >> 1) TestRemsetLoggingPerRegion.java >> there are unused imports, you can remove them >> > Fixed. > >> 2) TestRemsetLoggingThreads.java >> it doesn't use TestRemsetLoggingTools, just -version. >> So, you don't need WB here and you don't need to build >> TestRemsetLoggingTools TestRemsetLoggingThreads >> > Fixed. > >> 3) TestRemsetLoggingTools.java >> You changed the logic of the test: >> - replaced "1 young GC + N full GC" with "N young GC + 1 full GC" >> - removed all object allocations >> >> So, now VerifySummaryOutput just invokes serveral GC. >> Did you do this intentionally or by mistake? >> > Intentionally. The idea is to run one gc of every kind. If the user > specified to run only one gc, it does not matter. > The expected messages are printed for any kind of gc. > > Young gcs on an empty heap are just slightly faster than full gcs. > > The test also does not check particular object allocation, just that > some messages exist. Previously the allocations with the goal to run > young gcs only. There is no difference on whether there are actually any > kind of survivors. > > New webrev at http://cr.openjdk.java.net/~tschatzl/8145534/webrev.1 > (sorry no diff, I messed up) > > Thanks, > Thomas > > From bengt.rutisson at oracle.com Thu Dec 17 11:37:54 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 17 Dec 2015 12:37:54 +0100 Subject: RFR (S): 8145534: TestRemsetLogging.java takes a long time In-Reply-To: <1450350228.2137.3.camel@oracle.com> References: <1450286283.2322.49.camel@oracle.com> <56726419.40804@oracle.com> <1450350228.2137.3.camel@oracle.com> Message-ID: <56729E92.5030902@oracle.com> Hi Thomas, Latest webrev looks good. Thanks for fixing this! Bengt On 2015-12-17 12:03, Thomas Schatzl wrote: > Hi Bengt, > > thanks for your review, > > On Thu, 2015-12-17 at 08:28 +0100, Bengt Rutisson wrote: >> Hi Thomas, >> >> Thanks for fixing this! >> >> Changes look good except that I think TestRemsetLogging.java should have >> the same @requires tag as the other tests. >> >> @requires vm.gc=="G1" | vm.gc =="null" >> > Fixed. > >> Also, I think the 100 seconds runtime that you got may be related to the >> fastdebug/slowdebug issue that the changes to the configure scripts >> introduced. >> >> The numbers I reported in the bug report (18 seconds) are from my >> workstation without the slowdebug problem. >> >> If I run with your changes I get: >> >> elapsed time (seconds): 4.391 >> >> Which is a great improvement and an acceptable execution time I think. > :) > > New webrev at http://cr.openjdk.java.net/~tschatzl/8145534/webrev.1 > (sorry no diff, I messed up) > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Thu Dec 17 12:51:25 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 17 Dec 2015 13:51:25 +0100 Subject: RFR (S): 8145534: TestRemsetLogging.java takes a long time In-Reply-To: <56729D7A.9060900@oracle.com> References: <1450286283.2322.49.camel@oracle.com> <5671A99E.3040606@oracle.com> <1450350528.2137.9.camel@oracle.com> <56729D7A.9060900@oracle.com> Message-ID: <1450356685.2137.18.camel@oracle.com> Hi Dima, On Thu, 2015-12-17 at 14:33 +0300, Dmitry Fazunenko wrote: > Hi Thomas, > > Thanks for explanation. New version looks good to me. > > One a very tiny comment about TestRemsetLoggingThreads.java > * @library /testlibrary /test/lib > --> > * @library /testlibrary > I don't need a new webrev for that. > thanks for the review. I will fix the problem before pushing. Thanks, Thomas From thomas.schatzl at oracle.com Thu Dec 17 12:51:45 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 17 Dec 2015 13:51:45 +0100 Subject: RFR (S): 8145534: TestRemsetLogging.java takes a long time In-Reply-To: <56729E92.5030902@oracle.com> References: <1450286283.2322.49.camel@oracle.com> <56726419.40804@oracle.com> <1450350228.2137.3.camel@oracle.com> <56729E92.5030902@oracle.com> Message-ID: <1450356705.2137.19.camel@oracle.com> Hi Bengt, On Thu, 2015-12-17 at 12:37 +0100, Bengt Rutisson wrote: > Hi Thomas, > > Latest webrev looks good. > > Thanks for fixing this! > thanks for the review. Thomas From jon.masamitsu at oracle.com Thu Dec 17 15:52:17 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 17 Dec 2015 07:52:17 -0800 Subject: Request for review (s) - 8145031: Add regression test for 8133023 In-Reply-To: <5671E992.9070306@oracle.com> References: <5669D7A0.8000201@oracle.com> <1450175079.2296.1.camel@oracle.com> <56706381.7050205@oracle.com> <56718734.3080003@oracle.com> <5671E992.9070306@oracle.com> Message-ID: <5672DA31.7050307@oracle.com> Tom, The other reason I wanted to add the test was that I was surprised by the failure. The order of initialization was moved around at some point in jdk8 and created this failure. I could have done some assertion checking when the GC threads were created but that would have been during JVM initialization and I wanted to get completely past initialization and then do the checking. I don't expect initialization to be moved around so much that GC thread initialization would be done before cpu identification but I didn't expect the first bug could happen either. Jon On 12/16/2015 02:45 PM, Jon Masamitsu wrote: > Tom, > > Thanks for looking at this. > > On 12/16/2015 07:45 AM, Tom Benson wrote: >> Hi Jon, >> This looks OK to me (modulo Thomas' comments), but it's not clear to >> me why a unit test is needed for this case, rather than a simple >> assert somewhere, such as when the threads are created. Thanks, > > Do you mean add an assertion when each GC thread is created? > > I think that would add checks to 2 places (one for ParallelGC and > one for the other GC's - ignoring the concurrent threads). Adding > the check at one place seemed better. > > Or maybe you meant someplace else? > > Jon > >> Tom >> >> On 12/15/2015 2:01 PM, Jon Masamitsu wrote: >>> >>> >>> On 12/15/2015 2:24 AM, Thomas Schatzl wrote: >>>> Hi Jon, >>>> >>>> On Thu, 2015-12-10 at 11:50 -0800, Jon Masamitsu wrote: >>>>> The cause of the failure in 8133023 was the calculation of the >>>>> ParallelGCThreads using >>>>> information that had not yet been initialized. Add a test that checks >>>>> that, after full >>>>> initialization, the fresh calculation of ParallelGCThreads is >>>>> consistent with the value >>>>> calculated earlier. >>>>> >>>>> http://cr.openjdk.java.net/~jmasa/8145031/webrev.00/ >>>>> >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8145031 >>>>> >>>>> Tested with and without the fix for 8133023. >>>>> >>>> seems okay, with one nit: the indendation of the parameters for the >>>> assert in Abstract_VM_Version::FinalParallelGCThreads_test() seems >>>> off. >>>> >>>> Also there is an extra space between the "void" and the method name. >>> >>> Both fixed. Thanks. >>> >>> Jon >>> >>>> >>>> I do not need to re-review. >>>> >>>> Thanks, >>>> Thomas >>>> >>>> >>> >> > From jon.masamitsu at oracle.com Thu Dec 17 16:35:30 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 17 Dec 2015 08:35:30 -0800 Subject: RFR (S): 8145534: TestRemsetLogging.java takes a long time In-Reply-To: <1450350324.2137.5.camel@oracle.com> References: <1450286283.2322.49.camel@oracle.com> <5671F0AE.6020705@oracle.com> <1450350324.2137.5.camel@oracle.com> Message-ID: <5672E452.8020101@oracle.com> On 12/17/2015 03:05 AM, Thomas Schatzl wrote: > Hi Jon, > > thanks for your review. > > On Wed, 2015-12-16 at 15:15 -0800, Jon Masamitsu wrote: >> Thomas, >> >> http://cr.openjdk.java.net/~tschatzl/8145534/webrev/test/gc/g1/TestRemsetLoggingThreads.java.frames.html >> >> Did you consider adding the -Xint to the execution line above? > The test only runs the VM with -version. No java code is executed. > >> http://cr.openjdk.java.net/~tschatzl/8145534/webrev/test/gc/g1/TestRemsetLoggingPerRegion.java.frames.html >> >> Why is the @requires needed above? It's telling jtreg that >> TestRemsetLoggingPerRegion >> needs to be run with G1, right. Is that really the case? >> >> Rest looks good. > Yes. The option and log message is G1 only. > > New webrev at http://cr.openjdk.java.net/~tschatzl/8145534/webrev.1 Looks good. Jon > (sorry no diff, I messed up) > > Thanks, > Thomas > From tom.benson at oracle.com Thu Dec 17 17:13:39 2015 From: tom.benson at oracle.com (Tom Benson) Date: Thu, 17 Dec 2015 12:13:39 -0500 Subject: Request for review (s) - 8145031: Add regression test for 8133023 In-Reply-To: <5672DA31.7050307@oracle.com> References: <5669D7A0.8000201@oracle.com> <1450175079.2296.1.camel@oracle.com> <56706381.7050205@oracle.com> <56718734.3080003@oracle.com> <5671E992.9070306@oracle.com> <5672DA31.7050307@oracle.com> Message-ID: <5672ED43.9050102@oracle.com> Hi Jon, OK, I don't object strongly... It just seemed like extra overhead for what is ultimately an assert. I did notice that there is some GC-specific code in an 'ifdef ASSERT' at the end of Universe::genesis, at the end of init. It does some setup for FullGCAlot, apparently. So that would be a possible place to put it, but I bet you'd rather get rid of the code that's already there. 8^) Tom On 12/17/2015 10:52 AM, Jon Masamitsu wrote: > Tom, > > The other reason I wanted to add the test was that I was surprised > by the failure. The order of initialization was moved around at > some point in jdk8 and created this failure. I could have > done some assertion checking when the GC threads were > created but that would have been during JVM initialization > and I wanted to get completely past initialization and then > do the checking. I don't expect initialization to be moved > around so much that GC thread initialization would be done > before cpu identification but I didn't expect the first bug > could happen either. > > Jon > > > On 12/16/2015 02:45 PM, Jon Masamitsu wrote: >> Tom, >> >> Thanks for looking at this. >> >> On 12/16/2015 07:45 AM, Tom Benson wrote: >>> Hi Jon, >>> This looks OK to me (modulo Thomas' comments), but it's not clear to >>> me why a unit test is needed for this case, rather than a simple >>> assert somewhere, such as when the threads are created. Thanks, >> >> Do you mean add an assertion when each GC thread is created? >> >> I think that would add checks to 2 places (one for ParallelGC and >> one for the other GC's - ignoring the concurrent threads). Adding >> the check at one place seemed better. >> >> Or maybe you meant someplace else? >> >> Jon >> >>> Tom >>> >>> On 12/15/2015 2:01 PM, Jon Masamitsu wrote: >>>> >>>> >>>> On 12/15/2015 2:24 AM, Thomas Schatzl wrote: >>>>> Hi Jon, >>>>> >>>>> On Thu, 2015-12-10 at 11:50 -0800, Jon Masamitsu wrote: >>>>>> The cause of the failure in 8133023 was the calculation of the >>>>>> ParallelGCThreads using >>>>>> information that had not yet been initialized. Add a test that >>>>>> checks >>>>>> that, after full >>>>>> initialization, the fresh calculation of ParallelGCThreads is >>>>>> consistent with the value >>>>>> calculated earlier. >>>>>> >>>>>> http://cr.openjdk.java.net/~jmasa/8145031/webrev.00/ >>>>>> >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8145031 >>>>>> >>>>>> Tested with and without the fix for 8133023. >>>>>> >>>>> seems okay, with one nit: the indendation of the parameters for >>>>> the >>>>> assert in Abstract_VM_Version::FinalParallelGCThreads_test() seems >>>>> off. >>>>> >>>>> Also there is an extra space between the "void" and the method name. >>>> >>>> Both fixed. Thanks. >>>> >>>> Jon >>>> >>>>> >>>>> I do not need to re-review. >>>>> >>>>> Thanks, >>>>> Thomas >>>>> >>>>> >>>> >>> >> > From jon.masamitsu at oracle.com Thu Dec 17 17:55:21 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 17 Dec 2015 09:55:21 -0800 Subject: Request for review (s) - 8145031: Add regression test for 8133023 In-Reply-To: <5672ED43.9050102@oracle.com> References: <5669D7A0.8000201@oracle.com> <1450175079.2296.1.camel@oracle.com> <56706381.7050205@oracle.com> <56718734.3080003@oracle.com> <5671E992.9070306@oracle.com> <5672DA31.7050307@oracle.com> <5672ED43.9050102@oracle.com> Message-ID: <5672F709.9060800@oracle.com> On 12/17/2015 09:13 AM, Tom Benson wrote: > Hi Jon, > OK, I don't object strongly... It just seemed like extra overhead for > what is ultimately an assert. It is just an assert but the question is where do you put it. Having the test means I don't have to think about where to put it (genesis() is fine but I had to go look through the code to see that it was late enough during initialization). But I don't need to push this change and can add the assert when I'm doing some work in GC thread initialization. Let's drop it. Jon > > I did notice that there is some GC-specific code in an 'ifdef ASSERT' > at the end of Universe::genesis, at the end of init. It does some > setup for FullGCAlot, apparently. So that would be a possible place > to put it, but I bet you'd rather get rid of the code that's already > there. 8^) > Tom > > > On 12/17/2015 10:52 AM, Jon Masamitsu wrote: >> Tom, >> >> The other reason I wanted to add the test was that I was surprised >> by the failure. The order of initialization was moved around at >> some point in jdk8 and created this failure. I could have >> done some assertion checking when the GC threads were >> created but that would have been during JVM initialization >> and I wanted to get completely past initialization and then >> do the checking. I don't expect initialization to be moved >> around so much that GC thread initialization would be done >> before cpu identification but I didn't expect the first bug >> could happen either. >> >> Jon >> >> >> On 12/16/2015 02:45 PM, Jon Masamitsu wrote: >>> Tom, >>> >>> Thanks for looking at this. >>> >>> On 12/16/2015 07:45 AM, Tom Benson wrote: >>>> Hi Jon, >>>> This looks OK to me (modulo Thomas' comments), but it's not clear >>>> to me why a unit test is needed for this case, rather than a simple >>>> assert somewhere, such as when the threads are created. Thanks, >>> >>> Do you mean add an assertion when each GC thread is created? >>> >>> I think that would add checks to 2 places (one for ParallelGC and >>> one for the other GC's - ignoring the concurrent threads). Adding >>> the check at one place seemed better. >>> >>> Or maybe you meant someplace else? >>> >>> Jon >>> >>>> Tom >>>> >>>> On 12/15/2015 2:01 PM, Jon Masamitsu wrote: >>>>> >>>>> >>>>> On 12/15/2015 2:24 AM, Thomas Schatzl wrote: >>>>>> Hi Jon, >>>>>> >>>>>> On Thu, 2015-12-10 at 11:50 -0800, Jon Masamitsu wrote: >>>>>>> The cause of the failure in 8133023 was the calculation of the >>>>>>> ParallelGCThreads using >>>>>>> information that had not yet been initialized. Add a test that >>>>>>> checks >>>>>>> that, after full >>>>>>> initialization, the fresh calculation of ParallelGCThreads is >>>>>>> consistent with the value >>>>>>> calculated earlier. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~jmasa/8145031/webrev.00/ >>>>>>> >>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8145031 >>>>>>> >>>>>>> Tested with and without the fix for 8133023. >>>>>>> >>>>>> seems okay, with one nit: the indendation of the parameters >>>>>> for the >>>>>> assert in Abstract_VM_Version::FinalParallelGCThreads_test() >>>>>> seems off. >>>>>> >>>>>> Also there is an extra space between the "void" and the method name. >>>>> >>>>> Both fixed. Thanks. >>>>> >>>>> Jon >>>>> >>>>>> >>>>>> I do not need to re-review. >>>>>> >>>>>> Thanks, >>>>>> Thomas >>>>>> >>>>>> >>>>> >>>> >>> >> > From sangheon.kim at oracle.com Thu Dec 17 18:27:12 2015 From: sangheon.kim at oracle.com (sangheon) Date: Thu, 17 Dec 2015 10:27:12 -0800 Subject: RFR (M): JDK-8068394: Trace event for concurrent GC phases In-Reply-To: <56727382.4030800@oracle.com> References: <56282271.5090108@oracle.com> <56546233.20006@oracle.com> <5654B10E.1060701@oracle.com> <565EB318.8060607@oracle.com> <565F33A8.6060608@oracle.com> <565FF761.30200@oracle.com> <566FB2BA.5020408@oracle.com> <566FD637.4060909@oracle.com> <56706A22.9070803@oracle.com> <56706AC7.1070708@oracle.com> <56706BF8.6030604@oracle.com> <567091A1.1050105@oracle.com> <56727382.4030800@oracle.com> Message-ID: <5672FE80.6070100@oracle.com> Hi Bengt and Stefan, Thank you for reviewing this. And all the suggestions and advices. I will a sponsor this patch, anyone could help me? Thanks, Sangheon On 12/17/2015 12:34 AM, Bengt Rutisson wrote: > > Hi Sangheon, > > On 2015-12-15 23:18, sangheon wrote: >> Hi Stefan, >> >> Here's the next webrev which includes your suggestion. >> - Removed 'NOT_PRODUCT' and '#ifndef PRODUCT'. (Stefan) >> - Removed volatile keyword at >> ConcurrentGCTimer::_is_concurrent_phase_active. (Stefan) >> - Removed volatile keyword at >> ConcurrentMark::_concurrent_phase_started. This should be removed as >> well. >> >> http://cr.openjdk.java.net/~sangheki/8068394/webrev.02 >> http://cr.openjdk.java.net/~sangheki/8068394/webrev.02_to_01/ > > This looks good to me. > > Thanks, > Bengt > >> >> Thanks, >> Sangheon >> >> >> On 12/15/2015 11:37 AM, sangheon wrote: >>> Hi Stefan, >>> >>> On 12/15/2015 11:32 AM, Stefan Karlsson wrote: >>>> Hi Sangheon, >>>> >>>> On 2015-12-15 20:29, sangheon wrote: >>>>> Hi Stefan, >>>>> >>>>> Thank you for looking at official RFR as well. >>>>> >>>>> On 12/15/2015 12:58 AM, Stefan Karlsson wrote: >>>>>> Hi Sangheon, >>>>>> >>>>>> On 2015-12-15 07:27, sangheon wrote: >>>>>>> Hi Bengt and all, >>>>>>> >>>>>>> Here's a next webrev. >>>>>>> Bengt and I had a discussion on other thread and he and Stefan >>>>>>> Karlsson suggested simpler design. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01 >>>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01_to_00 >>>>>> >>>>>> Thanks for doing the simplifications of the patch. >>>>>> >>>>>> I have a couple of comments: >>>>>> Could you replace NOT_PRODUCT with DEBUG_ONLY, and #ifndef >>>>>> PRODUCT with #ifdef ASSERT. Otherwise, you'll get inconsistencies >>>>>> when building with optimized builds where neither PRODUCT nor >>>>>> ASSERT is defined. >>>>> Okay, I will do. >>>>> But you also pointed that whether this flag is really needed below. >>>>> >>>>>> >>>>>> 81 void ConcurrentGCTimer::register_gc_concurrent_start(const >>>>>> char* name, const Ticks& time) { >>>>>> 82 assert(!_is_concurrent_phase_active, "A concurrent phase is >>>>>> already active."); >>>>>> 83 _time_partitions.report_gc_phase_start(name, time, >>>>>> GCPhase::ConcurrentPhaseType); >>>>>> 84 NOT_PRODUCT(_is_concurrent_phase_active = true;) >>>>>> 85 } >>>>>> >>>>>> 162 class ConcurrentGCTimer : public GCTimer { >>>>>> 163 // ConcurrentGCTimer can't be used if there is an overlap >>>>>> between a pause phase and a concurrent phase. >>>>>> 164 // _is_concurrent_phase_active is used to find above case. >>>>>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >>>>>> 166 >>>>>> 167 public: >>>>>> 168 #ifndef PRODUCT >>>>>> 169 ConcurrentGCTimer(): GCTimer(), >>>>>> _is_concurrent_phase_active(false) {}; >>>>>> 170 #endif Is it really worth optimizing away the boolean? The >>>>>> code would be cleaner without these macros. >>>>> I just wanted to prevent mis-use of concurrent timer for >>>>> overlapping phase. >>>>> A pause phase nor another concurrent phase can't be started if a >>>>> concurrent phase is already started. >>>>> I think this would be nice to have. But I don't have a strong >>>>> opinion on this as currently we don't have these situations. >>>> >>>> I meant that we could keep the the variable in the product builds >>>> as well. Just to get rid of the noisy PRODUCT / DEBUG_ONLY macros. >>>> It could even be useful for future debugging. ;) >>> Oops! >>> I am okay with removing this macro. >>> >>> Let me post a new webrev soon. >>> Thank you for the real time answer! >>> >>> Sangheon >>> >>> >>>>> >>>>>> >>>>>> >>>>>> Why are you using volatile here? I don't see why that should be >>>>>> needed. >>>>>> >>>>>> 162 class ConcurrentGCTimer : public GCTimer { >>>>>> 163 // ConcurrentGCTimer can't be used if there is an overlap >>>>>> between a pause phase and a concurrent phase. >>>>>> 164 // _is_concurrent_phase_active is used to find above case. >>>>>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >>>>> You are right, volatile is not needed here. >>>>> I was thinking register_gc_concurrent_end() would be called from >>>>> different threads(ConcurrentMarkThread and VMThread), but as it >>>>> only happens from safepoint, I think volatile should be removed. >>>>> >>>>> I will post a new webrev with your opinion about the flag. >>>> >>>> Great. >>>> >>>> Thanks, >>>> StefanK >>>> >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> StefanK >>>>>> >>>>>>> >>>>>>> This webrev includes: >>>>>>> 1. Moving concurrent phase measurement into CMSPhaseAccounting >>>>>>> class. So we can check all concurrent phases from CMS. >>>>>>> >>>>>>> 2. Renamed a new flag introduced from webrev.00 for general use, >>>>>>> _concurrent_phase_started. >>>>>>> >>>>>>> 3. Added helper class for concurrent phase measurement, >>>>>>> GCConcPhaseTimer. And used this class for all concurrent phases. >>>>>>> >>>>>>> 4. Flag checking is moved from >>>>>>> G1CollectedHeap::register_concurrent_cycle_end() to >>>>>>> ConcurrentMark::abort(). >>>>>>> >>>>>>> 5. Changed switch() to if else statement at gcTraceSend. >>>>>>> >>>>>>> Many thanks to Bengt and Stefan Karlsson for the discussion. >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>> On 12/03/2015 12:03 AM, Bengt Rutisson wrote: >>>>>>>> >>>>>>>> Hi Sangheon, >>>>>>>> >>>>>>>> This all sounds good. Looking forward to the next webrev. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bengt >>>>>>>> >>>>>>>> On 2015-12-02 19:08, sangheon.kim wrote: >>>>>>>>> Hi Bengt, >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/02/2015 01:00 AM, Bengt Rutisson wrote: >>>>>>>>>> >>>>>>>>>> Hi Sangheon, >>>>>>>>>> >>>>>>>>>> Sorry again for the late reply. Comments inline. >>>>>>>>> No not at all. >>>>>>>>> Thank you for taking time for this review! >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2015-11-24 19:48, sangheon.kim wrote: >>>>>>>>>>> Hi Bengt, >>>>>>>>>>> >>>>>>>>>>> Thank you so much for reviewing this patch! >>>>>>>>>>> >>>>>>>>>>> On 11/24/2015 05:12 AM, Bengt Rutisson wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Sangheon, >>>>>>>>>>>> >>>>>>>>>>>> Sorry for the very late reply to this review request. >>>>>>>>>>>> >>>>>>>>>>>> On 2015-10-22 01:40, sangheon.kim wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> Can I get some reviews for this change of adding a trace >>>>>>>>>>>>> event for concurrent phases on CMS and G1? >>>>>>>>>>>>> >>>>>>>>>>>>> Currently we only measure pause times for major phases. >>>>>>>>>>>>> But I want to add 'concurrent mark' and 'concurrent sweep' >>>>>>>>>>>>> phases for CMS and 'concurrent mark' phase for G1. >>>>>>>>>>>>> To achieve this, I had to change ConcurrentGCTimer and >>>>>>>>>>>>> related classes. >>>>>>>>>>>>> >>>>>>>>>>>>> This patch includes: >>>>>>>>>>>>> 1) A concurrent phase can be measured only from >>>>>>>>>>>>> ConcurrentGCTimer and measuring an overlap between >>>>>>>>>>>>> concurrent and pause is not allowed as currently we don't >>>>>>>>>>>>> have that use case. And TimePartitions class(or related >>>>>>>>>>>>> classes) will be simpler than an overlap allowed case. >>>>>>>>>>>>> 2) I removed PausePhase and ConcurrentPhase which are >>>>>>>>>>>>> derived from GCPhase because I wanted to avoid heap >>>>>>>>>>>>> allocation when adding to GrowableArray. Instead >>>>>>>>>>>>> introduced 'type' member variable at GCPhase. >>>>>>>>>>>>> >>>>>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8068394 >>>>>>>>>>>>> Webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Nice work! It is great to get some timing information for >>>>>>>>>>>> the concurrent phases. >>>>>>>>>>> Thanks! >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> A few questions/comments: >>>>>>>>>>>> >>>>>>>>>>>> CMS. >>>>>>>>>>>> >>>>>>>>>>>> You have added timing events for the concurrent phases mark >>>>>>>>>>>> and sweep, but not for other concurrent phases (preclean, >>>>>>>>>>>> abortable_preclean and reset_concurrent). I think that if >>>>>>>>>>>> you moved your calls to >>>>>>>>>>>> _gc_timer_cm->register_gc_concurrent_start() and >>>>>>>>>>>> _gc_timer_cm->register_gc_concurrent_end() into the >>>>>>>>>>>> constructor and destructor of CMSPhaseAccounting you would >>>>>>>>>>>> automatically get timing events for all concurrent phases. >>>>>>>>>>> I also considered about this idea but I was not clear >>>>>>>>>>> whether it is good measurement especially for 'sweep'. >>>>>>>>>>> We are using CMSPhaseAccounting for 5 cases. >>>>>>>>>>> I think for 'mark' and 'preclean' they are okay. (there are >>>>>>>>>>> non-product functions call before CMSPhaseAccounting. But >>>>>>>>>>> they are okay). >>>>>>>>>>> For 'abortable-preclean' and 'reset', they are good to have >>>>>>>>>>> that. >>>>>>>>>>> But when it comes to 'sweep', there are timer and >>>>>>>>>>> CMSTokenSyncWithLocks related codes and I was not sure about >>>>>>>>>>> these. >>>>>>>>>>> If you think they are also okay, I will change as you >>>>>>>>>>> suggested. >>>>>>>>>> >>>>>>>>>> I think it is fine for the sweep part as well. If the >>>>>>>>>> CMSPhaseAccounting instance is not measuring the correct part >>>>>>>>>> of the work I think we should change it to measure what we >>>>>>>>>> want. That way we improve the existing measurements too. >>>>>>>>>> >>>>>>>>>> But as you stated in your follow up email, I think the sweep >>>>>>>>>> code is actually pretty much ok from this perspective. >>>>>>>>>> >>>>>>>>>> So, I would prefer to go with the CMSPhaseAccounting approach. >>>>>>>>> Okay, I already changed as you suggested. :) >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> G1. >>>>>>>>>>>> >>>>>>>>>>>> I think the use of _concurrent_marking_from_roots is >>>>>>>>>>>> unfortunate. It would be much cleaner if >>>>>>>>>>>> ConcurrentMark::register_mark_from_roots_phase_end() called >>>>>>>>>>>> register_gc_concurrent_end() directly. >>>>>>>>>>> I wanted to avoid introducing the new flag but the reason of >>>>>>>>>>> it was, as you know, to handle 'abort'. >>>>>>>>>>> When 'abort' happens we do need to end all timers before >>>>>>>>>>> calling 'GCTracer::report_gc_end()'. >>>>>>>>>>> And at this point we need a way to know whether concurrent >>>>>>>>>>> timer is started or not. >>>>>>>>>> >>>>>>>>>> As I tried to describe I think you can extend the scope of >>>>>>>>>> the timing to cover the part until the marking thread >>>>>>>>>> discovers that the marking was aborted. Basically moving the >>>>>>>>>> timing in to ConcurrentMarkThread::run_service(). >>>>>>>>> Oh, I mis-understood your point. Sorry. >>>>>>>>> I will try your recommendation. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I realize that this would change the timing for when a >>>>>>>>>>>> concurrent marking is aborted. The whole time for a full GC >>>>>>>>>>>> (or even several full GCs) would be included in the >>>>>>>>>>>> concurrent marking phase. But from a code perspective that >>>>>>>>>>>> is what happens, so maybe that is the correct time to >>>>>>>>>>>> report? Also, I think the logging is reported that way so >>>>>>>>>>>> if we want to make it easy to match the timing events with >>>>>>>>>>>> the logging we might want to use about the same scope for >>>>>>>>>>>> timing. >>>>>>>>>>>> >>>>>>>>>>>> Why do we only measure the concurrent mark phase for G1? >>>>>>>>>>> This is good question. :) >>>>>>>>>>> I was comparing CMS and G1 for major concurrent phases. >>>>>>>>>>> And the candidates were 'concurrent mark/sweep (CMS)' and >>>>>>>>>>> 'concurrent mark(G1)'. >>>>>>>>>>> >>>>>>>>>>>> Wouldn't it be good to measure all concurrent phases? >>>>>>>>>>> Okay, Stefan Karlsson also pointed to have them as well so I >>>>>>>>>>> filed a separate CR for this. >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8143951 >>>>>>>>>> >>>>>>>>>> Ok. Is there a reason why we want to split this up into two >>>>>>>>>> changes? Why not add all the concurrent timing events at once? >>>>>>>>>> >>>>>>>>>> I'm ok with splitting it up into two changes, but then maybe >>>>>>>>>> the title for JDK-8068394 should be changed to indicate that >>>>>>>>>> it only adds events for the marking phase. Also, if we go >>>>>>>>>> with the CMSPhaseAccounting approach for CMS, you get events >>>>>>>>>> for all phases there. So, it will be a bit odd to have all >>>>>>>>>> concurrent phases handled for CMS but only concurrent mark >>>>>>>>>> for G1. >>>>>>>>> You are correct and I agree with you. >>>>>>>>> The only reason of split was due to limited time for FC. >>>>>>>>> But as we have enough time, let me close JDK-8143951 and >>>>>>>>> include concurrent mark for G1 as well. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> gcTraceSend.cpp >>>>>>>>>>>> >>>>>>>>>>>> 389 void visit(GCPhase* phase) { >>>>>>>>>>>> 390 switch (phase->type()) { >>>>>>>>>>>> 391 case GCPhase::PausePhaseType: >>>>>>>>>>>> 392 assert(phase->level() < >>>>>>>>>>>> PhasesStack::PHASE_LEVELS, "Need more event types for >>>>>>>>>>>> PausePhase"); >>>>>>>>>>>> 393 >>>>>>>>>>>> 394 switch (phase->level()) { >>>>>>>>>>>> 395 case 0: >>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>> 396 case 1: >>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>> 397 case 2: >>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>> 398 case 3: >>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>> 399 default: /* Ignore sending this phase */ break; >>>>>>>>>>>> 400 } >>>>>>>>>>>> 401 break; >>>>>>>>>>>> 402 >>>>>>>>>>>> 403 case GCPhase::ConcurrentPhaseType: >>>>>>>>>>>> 404 assert(phase->level() < 1, "There's only one >>>>>>>>>>>> level for ConcurrentPhase"); >>>>>>>>>>>> 405 >>>>>>>>>>>> 406 switch (phase->level()) { >>>>>>>>>>>> 407 case 0: >>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>> 408 default: /* Ignore sending this phase */ break; >>>>>>>>>>>> 409 } >>>>>>>>>>>> 410 break; >>>>>>>>>>>> 411 } >>>>>>>>>>>> 412 } >>>>>>>>>>>> 413 }; >>>>>>>>>>>> >>>>>>>>>>>> Since there are only two values for GCPhase::PhaseType it >>>>>>>>>>>> seems a bit odd to use a switch statement. I think I would >>>>>>>>>>>> prefer to factor out the code for the different types a bit >>>>>>>>>>>> too. So, maybe something like: >>>>>>>>>>>> >>>>>>>>>>>> void visit(GCPhase* phase) { >>>>>>>>>>>> if (phase->type() == GCPhase::PausePhaseType) { >>>>>>>>>>>> visit_pause(phase); >>>>>>>>>>>> } else { >>>>>>>>>>>> assert(phase->type() == GCPhase::ConcurrentPhaseType, ""); >>>>>>>>>>>> visit_concurrent(phase); >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>> This seems better. I will fix. >>>>>>>>>> >>>>>>>>>> Good. Thanks! >>>>>>>>> :) >>>>>>>>> >>>>>>>>> I will post next webrev when I'm ready, including JDK-8143951 >>>>>>>>> part as well. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sangheon >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Bengt >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Sangheon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Bengt >>>>>>>>>>>> >>>>>>>>>>>>> Testing: JPRT >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Sangheon >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From poonam.bajaj at oracle.com Thu Dec 17 18:29:42 2015 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Thu, 17 Dec 2015 10:29:42 -0800 Subject: RFR: JDK-8145442: Add an option to verify remembered sets for G1 In-Reply-To: <567086E1.7080501@oracle.com> References: <567086E1.7080501@oracle.com> Message-ID: <5672FF16.7050904@oracle.com> Hello, Could I have reviews for this change? Thanks, Poonam On 12/15/2015 1:32 PM, Poonam Bajaj Parhar wrote: > Hello, > > Please review these changes that add a diagnostic VM option > 'G1VerifyRSetsAfterEvacuationPause' that when turned on enables the > verification of Rem Sets of heap regions. > > Bug: JDK-8145442: Add an option to verify remembered sets for G1 > Webrev: http://cr.openjdk.java.net/~poonam/8145442/webrev.00/ > Testing: JPRT, GCBasher > > Thanks, > Poonam > From poonam.bajaj at oracle.com Thu Dec 17 18:32:00 2015 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Thu, 17 Dec 2015 10:32:00 -0800 Subject: RFR: JDK-8072725: Provide more granular levels for GC verification In-Reply-To: <56709EF7.9020003@oracle.com> References: <56709EF7.9020003@oracle.com> Message-ID: <5672FFA0.3020805@oracle.com> Friendly reminder, please take a look at these changes and let me know your feedback. Thanks, Poonam On 12/15/2015 3:15 PM, Poonam Bajaj Parhar wrote: > Hello, > > Please review these changes that split up the work done under > Verify*GC options. This will be very useful in debugging GC > issues/crashes where verifying the whole memory system with Verify*GC > options slows down the process and makes it impossible to reproduce > the problem. > > The changes introduce a new option /VerifySubSet///that can be used to > specify the specific memory sub-systems that one wants to verify. It > can be one or more of the sub-systems from these: threads, heap, > symbol_table, string_table, codecache, dictionary, > classloader_data_graph, metaspace, jni_handles, c-heap and > codecache_oops. If nothing is specified with /VerifySubSet/ then whole > of the memory system is verified with Verify*GC options. > > Bug:JDK-8072725: > Provide more granular levels for GC verification > Webrev: http://cr.openjdk.java.net/~poonam/8072725/webrev.00/ > Testing: JPRT, tested the changes with a simple test program. > > Thanks, > Poonam > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.harlap at oracle.com Thu Dec 17 20:35:15 2015 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Thu, 17 Dec 2015 15:35:15 -0500 Subject: Request for code review - 8145037 Clean up FreeIdSet usage In-Reply-To: <566F1ADA.30608@oracle.com> References: <566F1ADA.30608@oracle.com> Message-ID: <56731C83.6050507@oracle.com> JDK-8145037 - Clean up FreeIdSet usage Proposed change: http://cr.openjdk.java.net/~aharlap/8145037/webrev.00/ Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.benson at oracle.com Thu Dec 17 21:28:46 2015 From: tom.benson at oracle.com (Tom Benson) Date: Thu, 17 Dec 2015 16:28:46 -0500 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <56724973.4060405@oracle.com> References: <5670B5F1.7010505@oracle.com> <56717944.1030402@oracle.com> <56724973.4060405@oracle.com> Message-ID: <5673290E.7080106@oracle.com> Hi Sangheon, I like the new approach, but just have a couple of comments. I think you should check the VirtualQuery return status and return false from protect_pages_individually if zero. I don't *think* you need to have the "!UseLargePages" restriction anymore with this approach, do you? Actually, I think you could just always use protect_pages_individually regardless of whether UseNUMAInterleaving was enabled or not, and the right thing would happen. But this way, you save an unnecessary system call plus some overhead. Tom On 12/17/2015 12:34 AM, sangheon wrote: > Hi Jesper, > > Thank you for looking at this! > > On 12/16/2015 06:46 AM, Jesper Wilhelmsson wrote: >> Hi Sangheon, >> >> * It seems to me that protect_pages_individually() can only be called >> if UseLargePages is false. Still it looks at UseLargePages to decide >> page_size. I would prefer if there was an assert(!UseLargePages) at >> the start of protect_pages_individually() to emphasize that this code >> has not been used or tested with large pages. >> >> * I'm not sure if this matters, but it seems to me that if the size >> of the area is not an even multiple of pages, you will start >> protecting the smaller part, and then continue with page sized areas. >> E.g. If page size is 4k and we want to protect a 10k area, we will >> start with a 2k block and then take two 4k blocks. This has the >> effect that if we pass in a page aligned address, the areas we >> protect will not cover one page at a time. This may be a non-issue >> though. It depends on if we usually get page aligned addresses and if >> it matters if we protect one page at a time or not. > Your second comment made me to change the function which maybe doesn't > need an assert now and removed potential alignment problem. > Currently protect_pages_individually() is only called when > "UseNUMAInterleaving && !UseLargePages" and > protect_pages_indivisually() will always have aligned size as > allocate_pages_individually() allocate aligned size. This means, as > you pointed, we need an assert to prevent wrong use and would have > alignment issue. > > So I changed the function to read currently allocated chunk size(via > Windows API) rather than calculating chunk size and then try to > protect the chunk. > With this change, we don't need to care about the flags neither align > matter. > >> >> * You use UINT32_FORMAT to print an uint. %u is the recommended way >> to print an uint. > Fixed. > >> >> * if (!ret) return false; We should always use { } > Fixed. > > Here's a next webrev. > http://cr.openjdk.java.net/~sangheki/8145000/webrev.01/ > http://cr.openjdk.java.net/~sangheki/8145000/webrev.01_to_00/ > > Testing: JPRT (TestOptionsWithRanges.java), RBT > (hotspot_all,testlist,noncolo.testlist for Windows only) > > * Added more tests. > > Thanks, > Sangheon > > >> >> Thanks, >> /Jesper >> >> >> >> Den 16/12/15 kl. 01:53, skrev sangheon: >>> Hi all, >>> >>> Could I get a couple of reviews for Windows >>> NUMAInterleaveGranularity change? >>> >>> Current Windows implementation can't handle correctly when we >>> reserve a heap >>> with disjoint heap base mode with NUMAInterleaveGranularity. >>> >>> Windows, os::protect_memory fails in above case, as we are trying to >>> protect the >>> whole reserved heap at one time. But we reserved that area with >>> separate/contiguous chunks based on NUMAInterleaveGranularity size. >>> MSDN >>> describes to call the API separately. >>> I changed protect API to be called multiple times if needed. >>> >>> Skipped adding a test as TestOptionsWithRanges.java is enough. >>> 'java -XX:+UseNUMA -XX:+UseNUMAInterleaving' is enough to reproduce >>> on large >>> memory Windows machine. However we need to specify heap size if the >>> machine >>> doesn't have large memory. e.g. -Xms30g -Xmx30g >>> >>> This patch is based on the patch for JDK-8144949 which includes the >>> change of >>> the max range of NUMAInterleaveGranularity to 2G(32bit), 8192G(64bit). >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8145000 >>> Webrev: http://cr.openjdk.java.net/~sangheki/8145000/webrev.00 >>> Testing: JPRT (with TestOptionsWithRanges.java enabled), manual >>> tests on Windows >>> machine(to test on large memory). >>> >>> Thanks, >>> Sangheon >>> >>> > From kim.barrett at oracle.com Thu Dec 17 21:30:55 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 17 Dec 2015 16:30:55 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> Message-ID: On Dec 4, 2015, at 1:07 PM, Kim Barrett wrote: > > On Dec 3, 2015, at 6:04 PM, Mandy Chung wrote: >> >>> [Indeed, this whole section isn't strictly necessary; all of it can be >>> inferred from information in other places.] >> >> Agree. This section is no longer necessary and maybe just remove it: > > I wasn't actually intending to suggest removal. It seems like there > is useful overview information to be had here, rather than requiring > readers to make not necessarily obvious inferences. My impression is > that readability is valued more highly than terseness in Java > documentation. Sorry for the long gap in the discussion. Mandy and I have been talking about what to do about the "Automatically-cleared references" section that was the topic of some debate. We've decided to eliminate it, which led us to some additional modifications. Here's the latest set of webrevs: http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06/ http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.06/ They've been rebased to hs-rt tip, which required resolving a minor merge conflict with a nearby change to logging in referenceProcessor.cpp. Other than that, there are only specification wording changes. Here's the incremental change from the previous version: http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06.inc/ We are treating the discussions around changing PhantomReference to forbid a null queue as out of scope for this change. As Mandy said earlier, she might propose a separate change for that in the future. From sangheon.kim at oracle.com Fri Dec 18 00:23:05 2015 From: sangheon.kim at oracle.com (sangheon) Date: Thu, 17 Dec 2015 16:23:05 -0800 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <5673290E.7080106@oracle.com> References: <5670B5F1.7010505@oracle.com> <56717944.1030402@oracle.com> <56724973.4060405@oracle.com> <5673290E.7080106@oracle.com> Message-ID: <567351E9.40109@oracle.com> Hi Tom, Thank you for reviewing this! On 12/17/2015 01:28 PM, Tom Benson wrote: > Hi Sangheon, > I like the new approach, but just have a couple of comments. Thanks. > > I think you should check the VirtualQuery return status and return > false from protect_pages_individually if zero. Right. I will fix this. > > I don't *think* you need to have the "!UseLargePages" restriction > anymore with this approach, do you? protect_pages_individually() doesn't have previous restriction on its usage. However I wanted to remain the caller(os::protect_memory) as is because, as you already mentioned below, I didn't want to have an additional call of VirtualQuery() for simpler code. I don't have strong opinion on this. Let me post next webrev after concluding this. Thanks, Sangheon > > Actually, I think you could just always use protect_pages_individually > regardless of whether UseNUMAInterleaving was enabled or not, and the > right thing would happen. But this way, you save an unnecessary > system call plus some overhead. > Tom > > > On 12/17/2015 12:34 AM, sangheon wrote: >> Hi Jesper, >> >> Thank you for looking at this! >> >> On 12/16/2015 06:46 AM, Jesper Wilhelmsson wrote: >>> Hi Sangheon, >>> >>> * It seems to me that protect_pages_individually() can only be >>> called if UseLargePages is false. Still it looks at UseLargePages to >>> decide page_size. I would prefer if there was an >>> assert(!UseLargePages) at the start of protect_pages_individually() >>> to emphasize that this code has not been used or tested with large >>> pages. >>> >>> * I'm not sure if this matters, but it seems to me that if the size >>> of the area is not an even multiple of pages, you will start >>> protecting the smaller part, and then continue with page sized >>> areas. E.g. If page size is 4k and we want to protect a 10k area, we >>> will start with a 2k block and then take two 4k blocks. This has the >>> effect that if we pass in a page aligned address, the areas we >>> protect will not cover one page at a time. This may be a non-issue >>> though. It depends on if we usually get page aligned addresses and >>> if it matters if we protect one page at a time or not. >> Your second comment made me to change the function which maybe >> doesn't need an assert now and removed potential alignment problem. >> Currently protect_pages_individually() is only called when >> "UseNUMAInterleaving && !UseLargePages" and >> protect_pages_indivisually() will always have aligned size as >> allocate_pages_individually() allocate aligned size. This means, as >> you pointed, we need an assert to prevent wrong use and would have >> alignment issue. >> >> So I changed the function to read currently allocated chunk size(via >> Windows API) rather than calculating chunk size and then try to >> protect the chunk. >> With this change, we don't need to care about the flags neither align >> matter. >> >>> >>> * You use UINT32_FORMAT to print an uint. %u is the recommended way >>> to print an uint. >> Fixed. >> >>> >>> * if (!ret) return false; We should always use { } >> Fixed. >> >> Here's a next webrev. >> http://cr.openjdk.java.net/~sangheki/8145000/webrev.01/ >> http://cr.openjdk.java.net/~sangheki/8145000/webrev.01_to_00/ >> >> Testing: JPRT (TestOptionsWithRanges.java), RBT >> (hotspot_all,testlist,noncolo.testlist for Windows only) >> >> * Added more tests. >> >> Thanks, >> Sangheon >> >> >>> >>> Thanks, >>> /Jesper >>> >>> >>> >>> Den 16/12/15 kl. 01:53, skrev sangheon: >>>> Hi all, >>>> >>>> Could I get a couple of reviews for Windows >>>> NUMAInterleaveGranularity change? >>>> >>>> Current Windows implementation can't handle correctly when we >>>> reserve a heap >>>> with disjoint heap base mode with NUMAInterleaveGranularity. >>>> >>>> Windows, os::protect_memory fails in above case, as we are trying >>>> to protect the >>>> whole reserved heap at one time. But we reserved that area with >>>> separate/contiguous chunks based on NUMAInterleaveGranularity size. >>>> MSDN >>>> describes to call the API separately. >>>> I changed protect API to be called multiple times if needed. >>>> >>>> Skipped adding a test as TestOptionsWithRanges.java is enough. >>>> 'java -XX:+UseNUMA -XX:+UseNUMAInterleaving' is enough to reproduce >>>> on large >>>> memory Windows machine. However we need to specify heap size if the >>>> machine >>>> doesn't have large memory. e.g. -Xms30g -Xmx30g >>>> >>>> This patch is based on the patch for JDK-8144949 which includes the >>>> change of >>>> the max range of NUMAInterleaveGranularity to 2G(32bit), 8192G(64bit). >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8145000 >>>> Webrev: http://cr.openjdk.java.net/~sangheki/8145000/webrev.00 >>>> Testing: JPRT (with TestOptionsWithRanges.java enabled), manual >>>> tests on Windows >>>> machine(to test on large memory). >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >> > From yiyeguhu at gmail.com Fri Dec 18 02:05:53 2015 From: yiyeguhu at gmail.com (Tao Mao) Date: Thu, 17 Dec 2015 18:05:53 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> Message-ID: Hi Kim, 34 *

Suppose the garbage collector determines at a certain point in time 35 * that an object is 36 * phantom reachable. At that time it will atomically clear 37 * all phantom references to that object and all phantom references to 38 * any other phantom-reachable objects from which that object is reachable. 39 * At the same time or at some later time it will enqueue those newly-cleared 40 * phantom references that are registered with reference queues. XYZRefenrece concept is never being understood too well besides the authors who spend time grinding words. WeakReference ( https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html) states this: "At that time it will atomically clear all weak references to that object and all weak references to any other weakly-reachable objects from which that object is reachable through a chain of strong and soft references." On line 38, can we also add "through a chain of strong, soft, and weak references." to the above, which I think is the case? In addition, in src/java.base/share/classes/java/lang/ref/package-info.java, can we add WeakHashMap ( https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html) as a concrete example of so-called canonicalized mappings to help readers understand its usage? I always need to look up for what "canonicalized mappings" really means and end up with "OK, it's WeakHashMap". Thanks. Tao Mao On Thu, Dec 17, 2015 at 1:30 PM, Kim Barrett wrote: > On Dec 4, 2015, at 1:07 PM, Kim Barrett wrote: > > > > On Dec 3, 2015, at 6:04 PM, Mandy Chung wrote: > >> > >>> [Indeed, this whole section isn't strictly necessary; all of it can be > >>> inferred from information in other places.] > >> > >> Agree. This section is no longer necessary and maybe just remove it: > > > > I wasn't actually intending to suggest removal. It seems like there > > is useful overview information to be had here, rather than requiring > > readers to make not necessarily obvious inferences. My impression is > > that readability is valued more highly than terseness in Java > > documentation. > > Sorry for the long gap in the discussion. Mandy and I have been > talking about what to do about the "Automatically-cleared references" > section that was the topic of some debate. We've decided to eliminate > it, which led us to some additional modifications. > > Here's the latest set of webrevs: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06/ > http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.06/ > > They've been rebased to hs-rt tip, which required resolving a minor > merge conflict with a nearby change to logging in > referenceProcessor.cpp. Other than that, there are only specification > wording changes. Here's the incremental change from the previous > version: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06.inc/ > > We are treating the discussions around changing PhantomReference to > forbid a null queue as out of scope for this change. As Mandy said > earlier, she might propose a separate change for that in the future. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Fri Dec 18 05:34:53 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Dec 2015 21:34:53 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> Message-ID: <84A72B6D-A101-435E-88D5-7D9EE1363EC9@oracle.com> > On Dec 17, 2015, at 6:05 PM, Tao Mao wrote: > > Hi Kim, > > 34 *

Suppose the garbage collector determines at a certain point in time > 35 * that an object is > 36 * phantom reachable. At that time it will atomically clear > 37 * all phantom references to that object and all phantom references to > 38 * any other phantom-reachable objects from which that object is reachable. > 39 * At the same time or at some later time it will enqueue those newly-cleared > 40 * phantom references that are registered with reference queues. > > XYZRefenrece concept is never being understood too well besides the authors who spend time grinding words. WeakReference (https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html) states this: "At that time it will atomically clear all weak references to that object and all weak references to any other weakly-reachable objects from which that object is reachable through a chain of strong and soft references." > > On line 38, can we also add "through a chain of strong, soft, and weak references." to the above, which I think is the case? > Yes it is and this is not strictly needed. For phantom reference case, this can be left ?unqualified? as it?s basically a chain of any reference type. > In addition, in src/java.base/share/classes/java/lang/ref/package-info.java, can we add WeakHashMap (https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html) as a concrete example of so-called canonicalized mappings to help readers understand its usage? I always need to look up for what "canonicalized mappings" really means and end up with "OK, it's WeakHashMap?. In the Notification section, it does reference WeakHashMap (although it might not contain the exact description you are looking at). Mandy > Thanks. > Tao Mao > > > > On Thu, Dec 17, 2015 at 1:30 PM, Kim Barrett wrote: > On Dec 4, 2015, at 1:07 PM, Kim Barrett wrote: > > > > On Dec 3, 2015, at 6:04 PM, Mandy Chung wrote: > >> > >>> [Indeed, this whole section isn't strictly necessary; all of it can be > >>> inferred from information in other places.] > >> > >> Agree. This section is no longer necessary and maybe just remove it: > > > > I wasn't actually intending to suggest removal. It seems like there > > is useful overview information to be had here, rather than requiring > > readers to make not necessarily obvious inferences. My impression is > > that readability is valued more highly than terseness in Java > > documentation. > > Sorry for the long gap in the discussion. Mandy and I have been > talking about what to do about the "Automatically-cleared references" > section that was the topic of some debate. We've decided to eliminate > it, which led us to some additional modifications. > > Here's the latest set of webrevs: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06/ > http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.06/ > > They've been rebased to hs-rt tip, which required resolving a minor > merge conflict with a nearby change to logging in > referenceProcessor.cpp. Other than that, there are only specification > wording changes. Here's the incremental change from the previous > version: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06.inc/ > > We are treating the discussions around changing PhantomReference to > forbid a null queue as out of scope for this change. As Mandy said > earlier, she might propose a separate change for that in the future. > > From yiyeguhu at gmail.com Fri Dec 18 05:46:40 2015 From: yiyeguhu at gmail.com (Tao Mao) Date: Thu, 17 Dec 2015 21:46:40 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <84A72B6D-A101-435E-88D5-7D9EE1363EC9@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> <84A72B6D-A101-435E-88D5-7D9EE1363EC9@oracle.com> Message-ID: On Thu, Dec 17, 2015 at 9:34 PM, Mandy Chung wrote: > > > On Dec 17, 2015, at 6:05 PM, Tao Mao wrote: > > > > Hi Kim, > > > > 34 *

Suppose the garbage collector determines at a certain point in > time > > 35 * that an object is > > 36 * phantom reachable. At that time it will atomically clear > > 37 * all phantom references to that object and all phantom references > to > > 38 * any other phantom-reachable objects from which that object is > reachable. > > 39 * At the same time or at some later time it will enqueue those > newly-cleared > > 40 * phantom references that are registered with reference queues. > > > > XYZRefenrece concept is never being understood too well besides the > authors who spend time grinding words. WeakReference ( > https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html) > states this: "At that time it will atomically clear all weak references to > that object and all weak references to any other weakly-reachable objects > from which that object is reachable through a chain of strong and soft > references." > > > > On line 38, can we also add "through a chain of strong, soft, and weak > references." to the above, which I think is the case? > > > > Yes it is and this is not strictly needed. For phantom reference case, > this can be left ?unqualified? as it?s basically a chain of any reference > type. > Strictly speaking, any reference type but phantom reference. > > > In addition, in > src/java.base/share/classes/java/lang/ref/package-info.java, can we add > WeakHashMap ( > https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html) as > a concrete example of so-called canonicalized mappings to help readers > understand its usage? I always need to look up for what "canonicalized > mappings" really means and end up with "OK, it's WeakHashMap?. > > In the Notification section, it does reference WeakHashMap (although it > might not contain the exact description you are looking at). > Good, I see it. > > Mandy > > > Thanks. > > Tao Mao > > > > > > > > On Thu, Dec 17, 2015 at 1:30 PM, Kim Barrett > wrote: > > On Dec 4, 2015, at 1:07 PM, Kim Barrett wrote: > > > > > > On Dec 3, 2015, at 6:04 PM, Mandy Chung > wrote: > > >> > > >>> [Indeed, this whole section isn't strictly necessary; all of it can > be > > >>> inferred from information in other places.] > > >> > > >> Agree. This section is no longer necessary and maybe just remove it: > > > > > > I wasn't actually intending to suggest removal. It seems like there > > > is useful overview information to be had here, rather than requiring > > > readers to make not necessarily obvious inferences. My impression is > > > that readability is valued more highly than terseness in Java > > > documentation. > > > > Sorry for the long gap in the discussion. Mandy and I have been > > talking about what to do about the "Automatically-cleared references" > > section that was the topic of some debate. We've decided to eliminate > > it, which led us to some additional modifications. > > > > Here's the latest set of webrevs: > > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06/ > > http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.06/ > > > > They've been rebased to hs-rt tip, which required resolving a minor > > merge conflict with a nearby change to logging in > > referenceProcessor.cpp. Other than that, there are only specification > > wording changes. Here's the incremental change from the previous > > version: > > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06.inc/ > > > > We are treating the discussions around changing PhantomReference to > > forbid a null queue as out of scope for this change. As Mandy said > > earlier, she might propose a separate change for that in the future. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Fri Dec 18 09:54:38 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 18 Dec 2015 10:54:38 +0100 Subject: RFR (M): JDK-8068394: Trace event for concurrent GC phases In-Reply-To: <5672FE80.6070100@oracle.com> References: <56282271.5090108@oracle.com> <56546233.20006@oracle.com> <5654B10E.1060701@oracle.com> <565EB318.8060607@oracle.com> <565F33A8.6060608@oracle.com> <565FF761.30200@oracle.com> <566FB2BA.5020408@oracle.com> <566FD637.4060909@oracle.com> <56706A22.9070803@oracle.com> <56706AC7.1070708@oracle.com> <56706BF8.6030604@oracle.com> <567091A1.1050105@oracle.com> <56727382.4030800@oracle.com> <5672FE80.6070100@oracle.com> Message-ID: <5673D7DE.8000103@oracle.com> Hi Sangheon, On 2015-12-17 19:27, sangheon wrote: > Hi Bengt and Stefan, > > Thank you for reviewing this. > And all the suggestions and advices. > > I will a sponsor this patch, anyone could help me? I'm pushing this now. Thanks, Bengt > > Thanks, > Sangheon > > > On 12/17/2015 12:34 AM, Bengt Rutisson wrote: >> >> Hi Sangheon, >> >> On 2015-12-15 23:18, sangheon wrote: >>> Hi Stefan, >>> >>> Here's the next webrev which includes your suggestion. >>> - Removed 'NOT_PRODUCT' and '#ifndef PRODUCT'. (Stefan) >>> - Removed volatile keyword at >>> ConcurrentGCTimer::_is_concurrent_phase_active. (Stefan) >>> - Removed volatile keyword at >>> ConcurrentMark::_concurrent_phase_started. This should be removed as >>> well. >>> >>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.02 >>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.02_to_01/ >> >> This looks good to me. >> >> Thanks, >> Bengt >> >>> >>> Thanks, >>> Sangheon >>> >>> >>> On 12/15/2015 11:37 AM, sangheon wrote: >>>> Hi Stefan, >>>> >>>> On 12/15/2015 11:32 AM, Stefan Karlsson wrote: >>>>> Hi Sangheon, >>>>> >>>>> On 2015-12-15 20:29, sangheon wrote: >>>>>> Hi Stefan, >>>>>> >>>>>> Thank you for looking at official RFR as well. >>>>>> >>>>>> On 12/15/2015 12:58 AM, Stefan Karlsson wrote: >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> On 2015-12-15 07:27, sangheon wrote: >>>>>>>> Hi Bengt and all, >>>>>>>> >>>>>>>> Here's a next webrev. >>>>>>>> Bengt and I had a discussion on other thread and he and Stefan >>>>>>>> Karlsson suggested simpler design. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01 >>>>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01_to_00 >>>>>>> >>>>>>> Thanks for doing the simplifications of the patch. >>>>>>> >>>>>>> I have a couple of comments: >>>>>>> Could you replace NOT_PRODUCT with DEBUG_ONLY, and #ifndef >>>>>>> PRODUCT with #ifdef ASSERT. Otherwise, you'll get >>>>>>> inconsistencies when building with optimized builds where >>>>>>> neither PRODUCT nor ASSERT is defined. >>>>>> Okay, I will do. >>>>>> But you also pointed that whether this flag is really needed below. >>>>>> >>>>>>> >>>>>>> 81 void ConcurrentGCTimer::register_gc_concurrent_start(const >>>>>>> char* name, const Ticks& time) { >>>>>>> 82 assert(!_is_concurrent_phase_active, "A concurrent phase is >>>>>>> already active."); >>>>>>> 83 _time_partitions.report_gc_phase_start(name, time, >>>>>>> GCPhase::ConcurrentPhaseType); >>>>>>> 84 NOT_PRODUCT(_is_concurrent_phase_active = true;) >>>>>>> 85 } >>>>>>> >>>>>>> 162 class ConcurrentGCTimer : public GCTimer { >>>>>>> 163 // ConcurrentGCTimer can't be used if there is an overlap >>>>>>> between a pause phase and a concurrent phase. >>>>>>> 164 // _is_concurrent_phase_active is used to find above case. >>>>>>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >>>>>>> 166 >>>>>>> 167 public: >>>>>>> 168 #ifndef PRODUCT >>>>>>> 169 ConcurrentGCTimer(): GCTimer(), >>>>>>> _is_concurrent_phase_active(false) {}; >>>>>>> 170 #endif Is it really worth optimizing away the boolean? The >>>>>>> code would be cleaner without these macros. >>>>>> I just wanted to prevent mis-use of concurrent timer for >>>>>> overlapping phase. >>>>>> A pause phase nor another concurrent phase can't be started if a >>>>>> concurrent phase is already started. >>>>>> I think this would be nice to have. But I don't have a strong >>>>>> opinion on this as currently we don't have these situations. >>>>> >>>>> I meant that we could keep the the variable in the product builds >>>>> as well. Just to get rid of the noisy PRODUCT / DEBUG_ONLY macros. >>>>> It could even be useful for future debugging. ;) >>>> Oops! >>>> I am okay with removing this macro. >>>> >>>> Let me post a new webrev soon. >>>> Thank you for the real time answer! >>>> >>>> Sangheon >>>> >>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Why are you using volatile here? I don't see why that should be >>>>>>> needed. >>>>>>> >>>>>>> 162 class ConcurrentGCTimer : public GCTimer { >>>>>>> 163 // ConcurrentGCTimer can't be used if there is an overlap >>>>>>> between a pause phase and a concurrent phase. >>>>>>> 164 // _is_concurrent_phase_active is used to find above case. >>>>>>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >>>>>> You are right, volatile is not needed here. >>>>>> I was thinking register_gc_concurrent_end() would be called from >>>>>> different threads(ConcurrentMarkThread and VMThread), but as it >>>>>> only happens from safepoint, I think volatile should be removed. >>>>>> >>>>>> I will post a new webrev with your opinion about the flag. >>>>> >>>>> Great. >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> StefanK >>>>>>> >>>>>>>> >>>>>>>> This webrev includes: >>>>>>>> 1. Moving concurrent phase measurement into CMSPhaseAccounting >>>>>>>> class. So we can check all concurrent phases from CMS. >>>>>>>> >>>>>>>> 2. Renamed a new flag introduced from webrev.00 for general >>>>>>>> use, _concurrent_phase_started. >>>>>>>> >>>>>>>> 3. Added helper class for concurrent phase measurement, >>>>>>>> GCConcPhaseTimer. And used this class for all concurrent phases. >>>>>>>> >>>>>>>> 4. Flag checking is moved from >>>>>>>> G1CollectedHeap::register_concurrent_cycle_end() to >>>>>>>> ConcurrentMark::abort(). >>>>>>>> >>>>>>>> 5. Changed switch() to if else statement at gcTraceSend. >>>>>>>> >>>>>>>> Many thanks to Bengt and Stefan Karlsson for the discussion. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>> >>>>>>>> On 12/03/2015 12:03 AM, Bengt Rutisson wrote: >>>>>>>>> >>>>>>>>> Hi Sangheon, >>>>>>>>> >>>>>>>>> This all sounds good. Looking forward to the next webrev. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Bengt >>>>>>>>> >>>>>>>>> On 2015-12-02 19:08, sangheon.kim wrote: >>>>>>>>>> Hi Bengt, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 12/02/2015 01:00 AM, Bengt Rutisson wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Sangheon, >>>>>>>>>>> >>>>>>>>>>> Sorry again for the late reply. Comments inline. >>>>>>>>>> No not at all. >>>>>>>>>> Thank you for taking time for this review! >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2015-11-24 19:48, sangheon.kim wrote: >>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>> >>>>>>>>>>>> Thank you so much for reviewing this patch! >>>>>>>>>>>> >>>>>>>>>>>> On 11/24/2015 05:12 AM, Bengt Rutisson wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Sangheon, >>>>>>>>>>>>> >>>>>>>>>>>>> Sorry for the very late reply to this review request. >>>>>>>>>>>>> >>>>>>>>>>>>> On 2015-10-22 01:40, sangheon.kim wrote: >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can I get some reviews for this change of adding a trace >>>>>>>>>>>>>> event for concurrent phases on CMS and G1? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Currently we only measure pause times for major phases. >>>>>>>>>>>>>> But I want to add 'concurrent mark' and 'concurrent >>>>>>>>>>>>>> sweep' phases for CMS and 'concurrent mark' phase for G1. >>>>>>>>>>>>>> To achieve this, I had to change ConcurrentGCTimer and >>>>>>>>>>>>>> related classes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This patch includes: >>>>>>>>>>>>>> 1) A concurrent phase can be measured only from >>>>>>>>>>>>>> ConcurrentGCTimer and measuring an overlap between >>>>>>>>>>>>>> concurrent and pause is not allowed as currently we don't >>>>>>>>>>>>>> have that use case. And TimePartitions class(or related >>>>>>>>>>>>>> classes) will be simpler than an overlap allowed case. >>>>>>>>>>>>>> 2) I removed PausePhase and ConcurrentPhase which are >>>>>>>>>>>>>> derived from GCPhase because I wanted to avoid heap >>>>>>>>>>>>>> allocation when adding to GrowableArray. Instead >>>>>>>>>>>>>> introduced 'type' member variable at GCPhase. >>>>>>>>>>>>>> >>>>>>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8068394 >>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Nice work! It is great to get some timing information for >>>>>>>>>>>>> the concurrent phases. >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> A few questions/comments: >>>>>>>>>>>>> >>>>>>>>>>>>> CMS. >>>>>>>>>>>>> >>>>>>>>>>>>> You have added timing events for the concurrent phases >>>>>>>>>>>>> mark and sweep, but not for other concurrent phases >>>>>>>>>>>>> (preclean, abortable_preclean and reset_concurrent). I >>>>>>>>>>>>> think that if you moved your calls to >>>>>>>>>>>>> _gc_timer_cm->register_gc_concurrent_start() and >>>>>>>>>>>>> _gc_timer_cm->register_gc_concurrent_end() into the >>>>>>>>>>>>> constructor and destructor of CMSPhaseAccounting you would >>>>>>>>>>>>> automatically get timing events for all concurrent phases. >>>>>>>>>>>> I also considered about this idea but I was not clear >>>>>>>>>>>> whether it is good measurement especially for 'sweep'. >>>>>>>>>>>> We are using CMSPhaseAccounting for 5 cases. >>>>>>>>>>>> I think for 'mark' and 'preclean' they are okay. (there are >>>>>>>>>>>> non-product functions call before CMSPhaseAccounting. But >>>>>>>>>>>> they are okay). >>>>>>>>>>>> For 'abortable-preclean' and 'reset', they are good to have >>>>>>>>>>>> that. >>>>>>>>>>>> But when it comes to 'sweep', there are timer and >>>>>>>>>>>> CMSTokenSyncWithLocks related codes and I was not sure >>>>>>>>>>>> about these. >>>>>>>>>>>> If you think they are also okay, I will change as you >>>>>>>>>>>> suggested. >>>>>>>>>>> >>>>>>>>>>> I think it is fine for the sweep part as well. If the >>>>>>>>>>> CMSPhaseAccounting instance is not measuring the correct >>>>>>>>>>> part of the work I think we should change it to measure what >>>>>>>>>>> we want. That way we improve the existing measurements too. >>>>>>>>>>> >>>>>>>>>>> But as you stated in your follow up email, I think the sweep >>>>>>>>>>> code is actually pretty much ok from this perspective. >>>>>>>>>>> >>>>>>>>>>> So, I would prefer to go with the CMSPhaseAccounting approach. >>>>>>>>>> Okay, I already changed as you suggested. :) >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> G1. >>>>>>>>>>>>> >>>>>>>>>>>>> I think the use of _concurrent_marking_from_roots is >>>>>>>>>>>>> unfortunate. It would be much cleaner if >>>>>>>>>>>>> ConcurrentMark::register_mark_from_roots_phase_end() >>>>>>>>>>>>> called register_gc_concurrent_end() directly. >>>>>>>>>>>> I wanted to avoid introducing the new flag but the reason >>>>>>>>>>>> of it was, as you know, to handle 'abort'. >>>>>>>>>>>> When 'abort' happens we do need to end all timers before >>>>>>>>>>>> calling 'GCTracer::report_gc_end()'. >>>>>>>>>>>> And at this point we need a way to know whether concurrent >>>>>>>>>>>> timer is started or not. >>>>>>>>>>> >>>>>>>>>>> As I tried to describe I think you can extend the scope of >>>>>>>>>>> the timing to cover the part until the marking thread >>>>>>>>>>> discovers that the marking was aborted. Basically moving the >>>>>>>>>>> timing in to ConcurrentMarkThread::run_service(). >>>>>>>>>> Oh, I mis-understood your point. Sorry. >>>>>>>>>> I will try your recommendation. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I realize that this would change the timing for when a >>>>>>>>>>>>> concurrent marking is aborted. The whole time for a full >>>>>>>>>>>>> GC (or even several full GCs) would be included in the >>>>>>>>>>>>> concurrent marking phase. But from a code perspective that >>>>>>>>>>>>> is what happens, so maybe that is the correct time to >>>>>>>>>>>>> report? Also, I think the logging is reported that way so >>>>>>>>>>>>> if we want to make it easy to match the timing events with >>>>>>>>>>>>> the logging we might want to use about the same scope for >>>>>>>>>>>>> timing. >>>>>>>>>>>>> >>>>>>>>>>>>> Why do we only measure the concurrent mark phase for G1? >>>>>>>>>>>> This is good question. :) >>>>>>>>>>>> I was comparing CMS and G1 for major concurrent phases. >>>>>>>>>>>> And the candidates were 'concurrent mark/sweep (CMS)' and >>>>>>>>>>>> 'concurrent mark(G1)'. >>>>>>>>>>>> >>>>>>>>>>>>> Wouldn't it be good to measure all concurrent phases? >>>>>>>>>>>> Okay, Stefan Karlsson also pointed to have them as well so >>>>>>>>>>>> I filed a separate CR for this. >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8143951 >>>>>>>>>>> >>>>>>>>>>> Ok. Is there a reason why we want to split this up into two >>>>>>>>>>> changes? Why not add all the concurrent timing events at once? >>>>>>>>>>> >>>>>>>>>>> I'm ok with splitting it up into two changes, but then maybe >>>>>>>>>>> the title for JDK-8068394 should be changed to indicate that >>>>>>>>>>> it only adds events for the marking phase. Also, if we go >>>>>>>>>>> with the CMSPhaseAccounting approach for CMS, you get events >>>>>>>>>>> for all phases there. So, it will be a bit odd to have all >>>>>>>>>>> concurrent phases handled for CMS but only concurrent mark >>>>>>>>>>> for G1. >>>>>>>>>> You are correct and I agree with you. >>>>>>>>>> The only reason of split was due to limited time for FC. >>>>>>>>>> But as we have enough time, let me close JDK-8143951 and >>>>>>>>>> include concurrent mark for G1 as well. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> gcTraceSend.cpp >>>>>>>>>>>>> >>>>>>>>>>>>> 389 void visit(GCPhase* phase) { >>>>>>>>>>>>> 390 switch (phase->type()) { >>>>>>>>>>>>> 391 case GCPhase::PausePhaseType: >>>>>>>>>>>>> 392 assert(phase->level() < >>>>>>>>>>>>> PhasesStack::PHASE_LEVELS, "Need more event types for >>>>>>>>>>>>> PausePhase"); >>>>>>>>>>>>> 393 >>>>>>>>>>>>> 394 switch (phase->level()) { >>>>>>>>>>>>> 395 case 0: >>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>> 396 case 1: >>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>> 397 case 2: >>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>> 398 case 3: >>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>> 399 default: /* Ignore sending this phase */ >>>>>>>>>>>>> break; >>>>>>>>>>>>> 400 } >>>>>>>>>>>>> 401 break; >>>>>>>>>>>>> 402 >>>>>>>>>>>>> 403 case GCPhase::ConcurrentPhaseType: >>>>>>>>>>>>> 404 assert(phase->level() < 1, "There's only one >>>>>>>>>>>>> level for ConcurrentPhase"); >>>>>>>>>>>>> 405 >>>>>>>>>>>>> 406 switch (phase->level()) { >>>>>>>>>>>>> 407 case 0: >>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>> 408 default: /* Ignore sending this phase */ >>>>>>>>>>>>> break; >>>>>>>>>>>>> 409 } >>>>>>>>>>>>> 410 break; >>>>>>>>>>>>> 411 } >>>>>>>>>>>>> 412 } >>>>>>>>>>>>> 413 }; >>>>>>>>>>>>> >>>>>>>>>>>>> Since there are only two values for GCPhase::PhaseType it >>>>>>>>>>>>> seems a bit odd to use a switch statement. I think I would >>>>>>>>>>>>> prefer to factor out the code for the different types a >>>>>>>>>>>>> bit too. So, maybe something like: >>>>>>>>>>>>> >>>>>>>>>>>>> void visit(GCPhase* phase) { >>>>>>>>>>>>> if (phase->type() == GCPhase::PausePhaseType) { >>>>>>>>>>>>> visit_pause(phase); >>>>>>>>>>>>> } else { >>>>>>>>>>>>> assert(phase->type() == GCPhase::ConcurrentPhaseType, >>>>>>>>>>>>> ""); >>>>>>>>>>>>> visit_concurrent(phase); >>>>>>>>>>>>> } >>>>>>>>>>>>> } >>>>>>>>>>>> This seems better. I will fix. >>>>>>>>>>> >>>>>>>>>>> Good. Thanks! >>>>>>>>>> :) >>>>>>>>>> >>>>>>>>>> I will post next webrev when I'm ready, including JDK-8143951 >>>>>>>>>> part as well. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Sangheon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Bengt >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Sangheon >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Bengt >>>>>>>>>>>>> >>>>>>>>>>>>>> Testing: JPRT >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Sangheon >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From peter.levart at gmail.com Fri Dec 18 10:12:51 2015 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 18 Dec 2015 11:12:51 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> Message-ID: <5673DC23.4050304@gmail.com> Hi, Now that PhantomReference(s) (excluding sun.misc.Cleaner(s)) are treated equally to sun.misc.Cleaner(s), the split between _discoveredPhantomRefs and _discoveredCleanerRefs is not needed any more right? Will this be a separate simplification? Regards, Peter On 12/17/2015 10:30 PM, Kim Barrett wrote: > On Dec 4, 2015, at 1:07 PM, Kim Barrett wrote: >> On Dec 3, 2015, at 6:04 PM, Mandy Chung wrote: >>>> [Indeed, this whole section isn't strictly necessary; all of it can be >>>> inferred from information in other places.] >>> Agree. This section is no longer necessary and maybe just remove it: >> I wasn't actually intending to suggest removal. It seems like there >> is useful overview information to be had here, rather than requiring >> readers to make not necessarily obvious inferences. My impression is >> that readability is valued more highly than terseness in Java >> documentation. > Sorry for the long gap in the discussion. Mandy and I have been > talking about what to do about the "Automatically-cleared references" > section that was the topic of some debate. We've decided to eliminate > it, which led us to some additional modifications. > > Here's the latest set of webrevs: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06/ > http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.06/ > > They've been rebased to hs-rt tip, which required resolving a minor > merge conflict with a nearby change to logging in > referenceProcessor.cpp. Other than that, there are only specification > wording changes. Here's the incremental change from the previous > version: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06.inc/ > > We are treating the discussions around changing PhantomReference to > forbid a null queue as out of scope for this change. As Mandy said > earlier, she might propose a separate change for that in the future. > From thomas.schatzl at oracle.com Fri Dec 18 10:46:07 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 18 Dec 2015 11:46:07 +0100 Subject: RFR (XXS): 8145673: G1RemSetSummary.hpp uses FREE_C_HEAP_ARRAY Message-ID: <1450435567.2496.3.camel@oracle.com> Hi all, can I have reviews for this change that fixes some include problem with G1RemSetSummary? The .hpp file uses FREE_C_HEAP_ARRAY, which is defined in an .inline.hpp file. For some reason, g1RemSetSummary.hpp does not even include that one, but only relies on other code using it doing the right thing (tm). The fix is to move the code into the .cpp file and do the correct includes. CR: https://bugs.openjdk.java.net/browse/JDK-8145673 Webrev: http://cr.openjdk.java.net/~tschatzl/8145673/webrev/ Testing: jprt, build all platforms Thanks, Thomas From thomas.schatzl at oracle.com Fri Dec 18 10:48:24 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 18 Dec 2015 11:48:24 +0100 Subject: RFR (XS): 8145674: Fix includes and forward declarations in g1Remset files Message-ID: <1450435704.2496.5.camel@oracle.com> Hi all, can I have reviews for this change that adds necessary includes and forward declarations in g1RemSet.?pp files? While it compiles right now as is, if something changes in this area, compilation tends to break in interesting ways. CR: https://bugs.openjdk.java.net/browse/JDK-8145674 Webrev: http://cr.openjdk.java.net/~tschatzl/8145674/webrev/ Testing: jprt Thanks, Thomas From thomas.schatzl at oracle.com Fri Dec 18 10:49:40 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 18 Dec 2015 11:49:40 +0100 Subject: RFR (XS): 8145667: Move FromCardCache into separate files Message-ID: <1450435780.2496.7.camel@oracle.com> Hi all, please review this change that moves the FromCardCache into separate files. It is pretty much a "self-sustaining" part of remembered set processing which I think is enough to warrant moving it into a separate file. Also it then does not stay in the way when working on remembered set code. Follow-up CRs will rename it according to naming conventions (->G1FromCardCache, JDK-8145671), and some clean-up to remove dependencies to HeapRegionRemSet (JDK-8145672). So this change is purely moving the class into separate files. CR: https://bugs.openjdk.java.net/browse/JDK-8145667 Webrev: http://cr.openjdk.java.net/~tschatzl/8145667/webrev/ Testing: compilation Thanks, Thomas From thomas.schatzl at oracle.com Fri Dec 18 10:53:17 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 18 Dec 2015 11:53:17 +0100 Subject: RFR (XXS): 8145671: Rename FromCardCache to G1FromCardCache Message-ID: <1450435997.2496.10.camel@oracle.com> Hi all, as the title for this change implies, this code changes the name of the FromCardCache class into G1FromCardCache to adhere to other class names. It is based on 8145667. CR: https://bugs.openjdk.java.net/browse/JDK-8145671 Webrev: http://cr.openjdk.java.net/~tschatzl/8145671/webrev/ Testing: jprt Thanks, Thomas From thomas.schatzl at oracle.com Fri Dec 18 11:02:52 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 18 Dec 2015 12:02:52 +0100 Subject: RFR (S): 8145672: Remove dependency of G1FromCardCache to HeapRegionRemSet Message-ID: <1450436572.2496.17.camel@oracle.com> Hi all, can I have review for the following change that removes the remaining dependency of G1FromCardCache to HeapRegionRemSet? G1FromCardCache references some static method that returns some configuration value for G1FromCardCache. Imo it is better to move that into G1RemSet as it is some value that is used for configuring parts of the entire remembered set. I.e. G1FromCardCache is actually pretty independent of HeapRegionRemSet. I also removed some unnecessary references to (former) HeapRegionRemSet::num_par_rem_sets() across the code. This allows easier hg rm heapRegionRemset* later, or at least adds some explanation for the methods :) CR: https://bugs.openjdk.java.net/browse/JDK-8145672 Webrev: http://cr.openjdk.java.net/~tschatzl/8145672/webrev Testing: jprt Thanks, Thomas From volker.simonis at gmail.com Fri Dec 18 11:22:00 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 18 Dec 2015 12:22:00 +0100 Subject: RFR (XS): 8145674: Fix includes and forward declarations in g1Remset files In-Reply-To: <1450435704.2496.5.camel@oracle.com> References: <1450435704.2496.5.camel@oracle.com> Message-ID: Hi Thomas, I like such kind of changes, nevertheless I have some comments: in g1RemSet.hpp the following classes: G1BlockOffsetSharedArray G1SATBCardTableModRefBS outputStream are not used or referenced, so there's no need to forward declare them. If files which include g1RemSet.hpp need them, than they should forward declare the classes (and only the classes) they really require themselves. There's no need to provide forward declarations in a header file to fulfil requirements of users of that header file. You added an include of "gc/g1/heapRegion.hpp" to g1RemSet.hpp but also a forward declaration for "class HeapRegion". So either the forward declaration of HeapRegion is enough to fulfil all the requirements in heapRegion.hpp in which case you could remove the include or the include is really needed (why?) in which case you can remove the forward declaration because heapRegion.hpp defines HeapReagion. From a first look it seems you are only using HeapRegion pointers in g1RemSet.hpp so you should probably drop the inclusion of heapRegion.hpp. The other extra includes are fine. The inclusion of "gc/g1/heapRegion.inline.hpp" into g1RemSet.cpp is also fine because g1RemSet.cpp uses the inline function HeapRegion::in_collection_set() which is defined in "gc/g1/heapRegion.inline.hpp" Regards, Volker On Fri, Dec 18, 2015 at 11:48 AM, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that adds necessary includes and > forward declarations in g1RemSet.?pp files? While it compiles right now > as is, if something changes in this area, compilation tends to break in > interesting ways. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8145674 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8145674/webrev/ > Testing: > jprt > > Thanks, > Thomas > From thomas.schatzl at oracle.com Fri Dec 18 11:35:32 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 18 Dec 2015 12:35:32 +0100 Subject: RFR (XS): 8145674: Fix includes and forward declarations in g1Remset files In-Reply-To: References: <1450435704.2496.5.camel@oracle.com> Message-ID: <1450438532.2496.26.camel@oracle.com> Hi Volker, thanks for your comments. On Fri, 2015-12-18 at 12:22 +0100, Volker Simonis wrote: > Hi Thomas, > > I like such kind of changes, nevertheless I have some comments: > > in g1RemSet.hpp the following classes: > > G1BlockOffsetSharedArray > G1SATBCardTableModRefBS Both used in the ScanRSClosure class. > outputStream > > are not used or referenced, so there's no need to forward declare them. I will remove that one. Sorry, overlooked that one. > If files which include g1RemSet.hpp need them, than they should > forward declare the classes (and only the classes) they really require > themselves. There's no need to provide forward declarations in a > header file to fulfill requirements of users of that header file. That has not been the intent. > You added an include of "gc/g1/heapRegion.hpp" to g1RemSet.hpp but > also a forward declaration for "class HeapRegion". So either the > forward declaration of HeapRegion is enough to fulfil all the > requirements in heapRegion.hpp in which case you could remove the > include or the include is really needed (why?) in which case you can > remove the forward declaration because heapRegion.hpp defines > HeapReagion. From a first look it seems you are only using HeapRegion > pointers in g1RemSet.hpp so you should probably drop the inclusion of > heapRegion.hpp. The file has ScanRSClosure that inherits from HeapRegionClosure that is also in heapRegion.hpp. I would assume that inheriting from something needs its definition (i.e. a forward declaration is not sufficient), no? I did not remove the HeapRegion* forward declarations after adding heapRegion.hpp. > The other extra includes are fine. > > The inclusion of "gc/g1/heapRegion.inline.hpp" into g1RemSet.cpp is > also fine because g1RemSet.cpp uses the inline function > HeapRegion::in_collection_set() which is defined in > "gc/g1/heapRegion.inline.hpp" > > Regards, > Volker > > > On Fri, Dec 18, 2015 at 11:48 AM, Thomas Schatzl > wrote: > > Hi all, > > > > can I have reviews for this change that adds necessary includes and > > forward declarations in g1RemSet.?pp files? While it compiles right now > > as is, if something changes in this area, compilation tends to break in > > interesting ways. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8145674 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8145674/webrev/ > > Testing: > > jprt New webrevs (pending another jprt run): http://cr.openjdk.java.net/~tschatzl/8145674/webrev.1 (full) http://cr.openjdk.java.net/~tschatzl/8145674/webrev.0_to_1 (diff) Thanks, Thomas From stefan.karlsson at oracle.com Fri Dec 18 11:37:14 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 18 Dec 2015 12:37:14 +0100 Subject: RFR (XXS): 8145673: G1RemSetSummary.hpp uses FREE_C_HEAP_ARRAY In-Reply-To: <1450435567.2496.3.camel@oracle.com> References: <1450435567.2496.3.camel@oracle.com> Message-ID: <5673EFEA.5080900@oracle.com> Looks good. Thanks, StefanK On 2015-12-18 11:46, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that fixes some include problem > with G1RemSetSummary? > > The .hpp file uses FREE_C_HEAP_ARRAY, which is defined in an .inline.hpp > file. For some reason, g1RemSetSummary.hpp does not even include that > one, but only relies on other code using it doing the right thing (tm). > > The fix is to move the code into the .cpp file and do the correct > includes. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8145673 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8145673/webrev/ > Testing: > jprt, build all platforms > > Thanks, > Thomas > > From mikael.gerdin at oracle.com Fri Dec 18 11:37:23 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 18 Dec 2015 12:37:23 +0100 Subject: RFR (XXS): 8145673: G1RemSetSummary.hpp uses FREE_C_HEAP_ARRAY In-Reply-To: <1450435567.2496.3.camel@oracle.com> References: <1450435567.2496.3.camel@oracle.com> Message-ID: <5673EFF3.4010203@oracle.com> Hi Thomas, On 2015-12-18 11:46, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that fixes some include problem > with G1RemSetSummary? > > The .hpp file uses FREE_C_HEAP_ARRAY, which is defined in an .inline.hpp > file. For some reason, g1RemSetSummary.hpp does not even include that > one, but only relies on other code using it doing the right thing (tm). > > The fix is to move the code into the .cpp file and do the correct > includes. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8145673 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8145673/webrev/ Looks good. /Mikael > Testing: > jprt, build all platforms > > Thanks, > Thomas > > From stefan.karlsson at oracle.com Fri Dec 18 11:42:55 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 18 Dec 2015 12:42:55 +0100 Subject: RFR (XS): 8145667: Move FromCardCache into separate files In-Reply-To: <1450435780.2496.7.camel@oracle.com> References: <1450435780.2496.7.camel@oracle.com> Message-ID: <5673F13F.4080805@oracle.com> Hi Thomas, On 2015-12-18 11:49, Thomas Schatzl wrote: > Hi all, > > please review this change that moves the FromCardCache into separate > files. It is pretty much a "self-sustaining" part of remembered set > processing which I think is enough to warrant moving it into a separate > file. > Also it then does not stay in the way when working on remembered set code. > > Follow-up CRs will rename it according to naming conventions > (->G1FromCardCache, JDK-8145671), and some clean-up to remove > dependencies to HeapRegionRemSet (JDK-8145672). > > So this change is purely moving the class into separate files. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8145667 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8145667/webrev/ Looks good, except that you are introducing a new way to end the include guards: #endif /* SHARE_VM_GC_G1_G1FROMCARDCACHE_HPP */ The file you moved the code from uses: #endif // SHARE_VM_GC_G1_HEAPREGIONREMSET_HPP which is the format that was used when the include guards were introduced. Thanks, StefanK > Testing: > compilation > > Thanks, > Thomas > > > From thomas.schatzl at oracle.com Fri Dec 18 11:48:01 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 18 Dec 2015 12:48:01 +0100 Subject: RFR (XS): 8145667: Move FromCardCache into separate files In-Reply-To: <5673F13F.4080805@oracle.com> References: <1450435780.2496.7.camel@oracle.com> <5673F13F.4080805@oracle.com> Message-ID: <1450439281.2496.28.camel@oracle.com> Hi, On Fri, 2015-12-18 at 12:42 +0100, Stefan Karlsson wrote: > Hi Thomas, > > On 2015-12-18 11:49, Thomas Schatzl wrote: > > Hi all, > > > > please review this change that moves the FromCardCache into separate > > files. It is pretty much a "self-sustaining" part of remembered set > > processing which I think is enough to warrant moving it into a separate > > file. > > Also it then does not stay in the way when working on remembered set code. > > > > Follow-up CRs will rename it according to naming conventions > > (->G1FromCardCache, JDK-8145671), and some clean-up to remove > > dependencies to HeapRegionRemSet (JDK-8145672). > > > > So this change is purely moving the class into separate files. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8145667 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8145667/webrev/ > > Looks good, except that you are introducing a new way to end the include > guards: > > #endif /* SHARE_VM_GC_G1_G1FROMCARDCACHE_HPP */ > > The file you moved the code from uses: > > #endif // SHARE_VM_GC_G1_HEAPREGIONREMSET_HPP > > > which is the format that was used when the include guards were introduced. Thanks for the review. Copy and past from the wrong file then :( I will fix it in the other G1 files too in another change. I updated the webrev in place. Thanks, Thomas From mikael.gerdin at oracle.com Fri Dec 18 11:51:53 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 18 Dec 2015 12:51:53 +0100 Subject: RFR (XS): 8145667: Move FromCardCache into separate files In-Reply-To: <1450439281.2496.28.camel@oracle.com> References: <1450435780.2496.7.camel@oracle.com> <5673F13F.4080805@oracle.com> <1450439281.2496.28.camel@oracle.com> Message-ID: <5673F359.2040807@oracle.com> Thomas, On 2015-12-18 12:48, Thomas Schatzl wrote: > Hi, > > On Fri, 2015-12-18 at 12:42 +0100, Stefan Karlsson wrote: >> Hi Thomas, >> >> On 2015-12-18 11:49, Thomas Schatzl wrote: >>> Hi all, >>> >>> please review this change that moves the FromCardCache into separate >>> files. It is pretty much a "self-sustaining" part of remembered set >>> processing which I think is enough to warrant moving it into a separate >>> file. >>> Also it then does not stay in the way when working on remembered set code. >>> >>> Follow-up CRs will rename it according to naming conventions >>> (->G1FromCardCache, JDK-8145671), and some clean-up to remove >>> dependencies to HeapRegionRemSet (JDK-8145672). >>> >>> So this change is purely moving the class into separate files. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8145667 >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8145667/webrev/ >> >> Looks good, except that you are introducing a new way to end the include >> guards: >> >> #endif /* SHARE_VM_GC_G1_G1FROMCARDCACHE_HPP */ >> >> The file you moved the code from uses: >> >> #endif // SHARE_VM_GC_G1_HEAPREGIONREMSET_HPP >> >> >> which is the format that was used when the include guards were introduced. > > Thanks for the review. Copy and past from the wrong file then :( I will > fix it in the other G1 files too in another change. > > I updated the webrev in place. Looks good to me. /Mikael > > Thanks, > Thomas > From stefan.karlsson at oracle.com Fri Dec 18 11:53:54 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 18 Dec 2015 12:53:54 +0100 Subject: RFR (XS): 8145674: Fix includes and forward declarations in g1Remset files In-Reply-To: <1450435704.2496.5.camel@oracle.com> References: <1450435704.2496.5.camel@oracle.com> Message-ID: <5673F3D2.6070002@oracle.com> Hi Thomas, On 2015-12-18 11:48, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that adds necessary includes and > forward declarations in g1RemSet.?pp files? While it compiles right now > as is, if something changes in this area, compilation tends to break in > interesting ways. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8145674 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8145674/webrev/ Looks good. It's a bit unfortunate that you have to include heapRegion.hpp. Maybe we should break out HeapRegionClosure out of heapRegion.hpp? Thanks, StefanK > Testing: > jprt > > Thanks, > Thomas > From stefan.karlsson at oracle.com Fri Dec 18 11:56:05 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 18 Dec 2015 12:56:05 +0100 Subject: RFR (XS): 8145667: Move FromCardCache into separate files In-Reply-To: <1450439281.2496.28.camel@oracle.com> References: <1450435780.2496.7.camel@oracle.com> <5673F13F.4080805@oracle.com> <1450439281.2496.28.camel@oracle.com> Message-ID: <5673F455.4040601@oracle.com> Looks good. StefanK On 2015-12-18 12:48, Thomas Schatzl wrote: > Hi, > > On Fri, 2015-12-18 at 12:42 +0100, Stefan Karlsson wrote: >> Hi Thomas, >> >> On 2015-12-18 11:49, Thomas Schatzl wrote: >>> Hi all, >>> >>> please review this change that moves the FromCardCache into separate >>> files. It is pretty much a "self-sustaining" part of remembered set >>> processing which I think is enough to warrant moving it into a separate >>> file. >>> Also it then does not stay in the way when working on remembered set code. >>> >>> Follow-up CRs will rename it according to naming conventions >>> (->G1FromCardCache, JDK-8145671), and some clean-up to remove >>> dependencies to HeapRegionRemSet (JDK-8145672). >>> >>> So this change is purely moving the class into separate files. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8145667 >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8145667/webrev/ >> Looks good, except that you are introducing a new way to end the include >> guards: >> >> #endif /* SHARE_VM_GC_G1_G1FROMCARDCACHE_HPP */ >> >> The file you moved the code from uses: >> >> #endif // SHARE_VM_GC_G1_HEAPREGIONREMSET_HPP >> >> >> which is the format that was used when the include guards were introduced. > Thanks for the review. Copy and past from the wrong file then :( I will > fix it in the other G1 files too in another change. > > I updated the webrev in place. > > Thanks, > Thomas > From thomas.schatzl at oracle.com Fri Dec 18 12:00:12 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 18 Dec 2015 13:00:12 +0100 Subject: RFR (XXXS): 8145752: Fix include guards in GC code Message-ID: <1450440012.2496.31.camel@oracle.com> Hi all, can I have reviews for this change that fixes include guards in GC code? In the review for 8145667 StefanK noticed that some include guards are #endif /* SHARE_VM_GC_G1_G1FROMCARDCACHE_HPP */ while they should be #endif // SHARE_VM_GC_G1_HEAPREGIONREMSET_HPP CR: https://bugs.openjdk.java.net/browse/JDK-8145752 Webrev: http://cr.openjdk.java.net/~tschatzl/8145752/webrev/ Testing: local compilation Thanks, Thomas From stefan.karlsson at oracle.com Fri Dec 18 12:02:26 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 18 Dec 2015 13:02:26 +0100 Subject: RFR (XXXS): 8145752: Fix include guards in GC code In-Reply-To: <1450440012.2496.31.camel@oracle.com> References: <1450440012.2496.31.camel@oracle.com> Message-ID: <5673F5D2.3060500@oracle.com> Looks good. Thanks, StefanK On 2015-12-18 13:00, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that fixes include guards in GC > code? > > In the review for 8145667 StefanK noticed that some include guards are > > #endif /* SHARE_VM_GC_G1_G1FROMCARDCACHE_HPP */ > > while they should be > > #endif // SHARE_VM_GC_G1_HEAPREGIONREMSET_HPP > > CR: > https://bugs.openjdk.java.net/browse/JDK-8145752 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8145752/webrev/ > Testing: > local compilation > > Thanks, > Thomas > > From mikael.gerdin at oracle.com Fri Dec 18 12:03:02 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 18 Dec 2015 13:03:02 +0100 Subject: RFR (XXXS): 8145752: Fix include guards in GC code In-Reply-To: <1450440012.2496.31.camel@oracle.com> References: <1450440012.2496.31.camel@oracle.com> Message-ID: <5673F5F6.3030109@oracle.com> Thomas, On 2015-12-18 13:00, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that fixes include guards in GC > code? > > In the review for 8145667 StefanK noticed that some include guards are > > #endif /* SHARE_VM_GC_G1_G1FROMCARDCACHE_HPP */ > > while they should be > > #endif // SHARE_VM_GC_G1_HEAPREGIONREMSET_HPP > > CR: > https://bugs.openjdk.java.net/browse/JDK-8145752 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8145752/webrev/ Looks good :) /Mikael > Testing: > local compilation > > Thanks, > Thomas > > From mikael.gerdin at oracle.com Fri Dec 18 12:05:00 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 18 Dec 2015 13:05:00 +0100 Subject: RFR (XXS): 8145671: Rename FromCardCache to G1FromCardCache In-Reply-To: <1450435997.2496.10.camel@oracle.com> References: <1450435997.2496.10.camel@oracle.com> Message-ID: <5673F66C.6080605@oracle.com> Hi Thomas, On 2015-12-18 11:53, Thomas Schatzl wrote: > Hi all, > > as the title for this change implies, this code changes the name of > the FromCardCache class into G1FromCardCache to adhere to other class > names. > > It is based on 8145667. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8145671 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8145671/webrev/ Looks good. /Mikael > Testing: > jprt > > Thanks, > Thomas > > > From bengt.rutisson at oracle.com Fri Dec 18 12:41:40 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 18 Dec 2015 13:41:40 +0100 Subject: RFR (M): JDK-8068394: Trace event for concurrent GC phases In-Reply-To: <5673D7DE.8000103@oracle.com> References: <56282271.5090108@oracle.com> <56546233.20006@oracle.com> <5654B10E.1060701@oracle.com> <565EB318.8060607@oracle.com> <565F33A8.6060608@oracle.com> <565FF761.30200@oracle.com> <566FB2BA.5020408@oracle.com> <566FD637.4060909@oracle.com> <56706A22.9070803@oracle.com> <56706AC7.1070708@oracle.com> <56706BF8.6030604@oracle.com> <567091A1.1050105@oracle.com> <56727382.4030800@oracle.com> <5672FE80.6070100@oracle.com> <5673D7DE.8000103@oracle.com> Message-ID: <5673FF04.9020905@oracle.com> Hi Sangheon, There was a test failure when I ran JPRT: http://sthjprt.uk.oracle.com/archives/2015/12/2015-12-18-095536.brutisso.8068394/logs/macosx_x64_10.9-fastdebug-c2-jdk_svc_sanity.log.FAILED.log ACTION: main -- Failed. Execution failed: `main' threw exception: java.lang.Exception: Preset 'Continuous' doesn't configure event 'http://www.oracle.com/hotspot/jvm/vm/gc/phases/concurrent' Preset 'Profiling' doesn't configure event 'http://www.oracle.com/hotspot/jvm/vm/gc/phases/concurrent' I think you need to add your new event to: jdk/test/closed/com/oracle/jfr/api/ConfigurationTest/TestDefaultPresets.java I'll be on vacation next week. Not sure if I will check email. If you get the TestDefaultPresets test to pass you can still list me as a reviewer. But someone else needs to sponsor the push. Thanks, Bengt On 2015-12-18 10:54, Bengt Rutisson wrote: > > Hi Sangheon, > > On 2015-12-17 19:27, sangheon wrote: >> Hi Bengt and Stefan, >> >> Thank you for reviewing this. >> And all the suggestions and advices. >> >> I will a sponsor this patch, anyone could help me? > > I'm pushing this now. > > Thanks, > Bengt > >> >> Thanks, >> Sangheon >> >> >> On 12/17/2015 12:34 AM, Bengt Rutisson wrote: >>> >>> Hi Sangheon, >>> >>> On 2015-12-15 23:18, sangheon wrote: >>>> Hi Stefan, >>>> >>>> Here's the next webrev which includes your suggestion. >>>> - Removed 'NOT_PRODUCT' and '#ifndef PRODUCT'. (Stefan) >>>> - Removed volatile keyword at >>>> ConcurrentGCTimer::_is_concurrent_phase_active. (Stefan) >>>> - Removed volatile keyword at >>>> ConcurrentMark::_concurrent_phase_started. This should be removed >>>> as well. >>>> >>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.02 >>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.02_to_01/ >>> >>> This looks good to me. >>> >>> Thanks, >>> Bengt >>> >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> On 12/15/2015 11:37 AM, sangheon wrote: >>>>> Hi Stefan, >>>>> >>>>> On 12/15/2015 11:32 AM, Stefan Karlsson wrote: >>>>>> Hi Sangheon, >>>>>> >>>>>> On 2015-12-15 20:29, sangheon wrote: >>>>>>> Hi Stefan, >>>>>>> >>>>>>> Thank you for looking at official RFR as well. >>>>>>> >>>>>>> On 12/15/2015 12:58 AM, Stefan Karlsson wrote: >>>>>>>> Hi Sangheon, >>>>>>>> >>>>>>>> On 2015-12-15 07:27, sangheon wrote: >>>>>>>>> Hi Bengt and all, >>>>>>>>> >>>>>>>>> Here's a next webrev. >>>>>>>>> Bengt and I had a discussion on other thread and he and Stefan >>>>>>>>> Karlsson suggested simpler design. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01 >>>>>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01_to_00 >>>>>>>> >>>>>>>> Thanks for doing the simplifications of the patch. >>>>>>>> >>>>>>>> I have a couple of comments: >>>>>>>> Could you replace NOT_PRODUCT with DEBUG_ONLY, and #ifndef >>>>>>>> PRODUCT with #ifdef ASSERT. Otherwise, you'll get >>>>>>>> inconsistencies when building with optimized builds where >>>>>>>> neither PRODUCT nor ASSERT is defined. >>>>>>> Okay, I will do. >>>>>>> But you also pointed that whether this flag is really needed below. >>>>>>> >>>>>>>> >>>>>>>> 81 void ConcurrentGCTimer::register_gc_concurrent_start(const >>>>>>>> char* name, const Ticks& time) { >>>>>>>> 82 assert(!_is_concurrent_phase_active, "A concurrent phase is >>>>>>>> already active."); >>>>>>>> 83 _time_partitions.report_gc_phase_start(name, time, >>>>>>>> GCPhase::ConcurrentPhaseType); >>>>>>>> 84 NOT_PRODUCT(_is_concurrent_phase_active = true;) >>>>>>>> 85 } >>>>>>>> >>>>>>>> 162 class ConcurrentGCTimer : public GCTimer { >>>>>>>> 163 // ConcurrentGCTimer can't be used if there is an overlap >>>>>>>> between a pause phase and a concurrent phase. >>>>>>>> 164 // _is_concurrent_phase_active is used to find above case. >>>>>>>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >>>>>>>> 166 >>>>>>>> 167 public: >>>>>>>> 168 #ifndef PRODUCT >>>>>>>> 169 ConcurrentGCTimer(): GCTimer(), >>>>>>>> _is_concurrent_phase_active(false) {}; >>>>>>>> 170 #endif Is it really worth optimizing away the boolean? The >>>>>>>> code would be cleaner without these macros. >>>>>>> I just wanted to prevent mis-use of concurrent timer for >>>>>>> overlapping phase. >>>>>>> A pause phase nor another concurrent phase can't be started if a >>>>>>> concurrent phase is already started. >>>>>>> I think this would be nice to have. But I don't have a strong >>>>>>> opinion on this as currently we don't have these situations. >>>>>> >>>>>> I meant that we could keep the the variable in the product builds >>>>>> as well. Just to get rid of the noisy PRODUCT / DEBUG_ONLY >>>>>> macros. It could even be useful for future debugging. ;) >>>>> Oops! >>>>> I am okay with removing this macro. >>>>> >>>>> Let me post a new webrev soon. >>>>> Thank you for the real time answer! >>>>> >>>>> Sangheon >>>>> >>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Why are you using volatile here? I don't see why that should be >>>>>>>> needed. >>>>>>>> >>>>>>>> 162 class ConcurrentGCTimer : public GCTimer { >>>>>>>> 163 // ConcurrentGCTimer can't be used if there is an overlap >>>>>>>> between a pause phase and a concurrent phase. >>>>>>>> 164 // _is_concurrent_phase_active is used to find above case. >>>>>>>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >>>>>>> You are right, volatile is not needed here. >>>>>>> I was thinking register_gc_concurrent_end() would be called from >>>>>>> different threads(ConcurrentMarkThread and VMThread), but as it >>>>>>> only happens from safepoint, I think volatile should be removed. >>>>>>> >>>>>>> I will post a new webrev with your opinion about the flag. >>>>>> >>>>>> Great. >>>>>> >>>>>> Thanks, >>>>>> StefanK >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> StefanK >>>>>>>> >>>>>>>>> >>>>>>>>> This webrev includes: >>>>>>>>> 1. Moving concurrent phase measurement into CMSPhaseAccounting >>>>>>>>> class. So we can check all concurrent phases from CMS. >>>>>>>>> >>>>>>>>> 2. Renamed a new flag introduced from webrev.00 for general >>>>>>>>> use, _concurrent_phase_started. >>>>>>>>> >>>>>>>>> 3. Added helper class for concurrent phase measurement, >>>>>>>>> GCConcPhaseTimer. And used this class for all concurrent phases. >>>>>>>>> >>>>>>>>> 4. Flag checking is moved from >>>>>>>>> G1CollectedHeap::register_concurrent_cycle_end() to >>>>>>>>> ConcurrentMark::abort(). >>>>>>>>> >>>>>>>>> 5. Changed switch() to if else statement at gcTraceSend. >>>>>>>>> >>>>>>>>> Many thanks to Bengt and Stefan Karlsson for the discussion. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sangheon >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/03/2015 12:03 AM, Bengt Rutisson wrote: >>>>>>>>>> >>>>>>>>>> Hi Sangheon, >>>>>>>>>> >>>>>>>>>> This all sounds good. Looking forward to the next webrev. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Bengt >>>>>>>>>> >>>>>>>>>> On 2015-12-02 19:08, sangheon.kim wrote: >>>>>>>>>>> Hi Bengt, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 12/02/2015 01:00 AM, Bengt Rutisson wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Sangheon, >>>>>>>>>>>> >>>>>>>>>>>> Sorry again for the late reply. Comments inline. >>>>>>>>>>> No not at all. >>>>>>>>>>> Thank you for taking time for this review! >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2015-11-24 19:48, sangheon.kim wrote: >>>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you so much for reviewing this patch! >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/24/2015 05:12 AM, Bengt Rutisson wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Sangheon, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sorry for the very late reply to this review request. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2015-10-22 01:40, sangheon.kim wrote: >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can I get some reviews for this change of adding a trace >>>>>>>>>>>>>>> event for concurrent phases on CMS and G1? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Currently we only measure pause times for major phases. >>>>>>>>>>>>>>> But I want to add 'concurrent mark' and 'concurrent >>>>>>>>>>>>>>> sweep' phases for CMS and 'concurrent mark' phase for G1. >>>>>>>>>>>>>>> To achieve this, I had to change ConcurrentGCTimer and >>>>>>>>>>>>>>> related classes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This patch includes: >>>>>>>>>>>>>>> 1) A concurrent phase can be measured only from >>>>>>>>>>>>>>> ConcurrentGCTimer and measuring an overlap between >>>>>>>>>>>>>>> concurrent and pause is not allowed as currently we >>>>>>>>>>>>>>> don't have that use case. And TimePartitions class(or >>>>>>>>>>>>>>> related classes) will be simpler than an overlap allowed >>>>>>>>>>>>>>> case. >>>>>>>>>>>>>>> 2) I removed PausePhase and ConcurrentPhase which are >>>>>>>>>>>>>>> derived from GCPhase because I wanted to avoid heap >>>>>>>>>>>>>>> allocation when adding to GrowableArray. Instead >>>>>>>>>>>>>>> introduced 'type' member variable at GCPhase. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8068394 >>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Nice work! It is great to get some timing information for >>>>>>>>>>>>>> the concurrent phases. >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> A few questions/comments: >>>>>>>>>>>>>> >>>>>>>>>>>>>> CMS. >>>>>>>>>>>>>> >>>>>>>>>>>>>> You have added timing events for the concurrent phases >>>>>>>>>>>>>> mark and sweep, but not for other concurrent phases >>>>>>>>>>>>>> (preclean, abortable_preclean and reset_concurrent). I >>>>>>>>>>>>>> think that if you moved your calls to >>>>>>>>>>>>>> _gc_timer_cm->register_gc_concurrent_start() and >>>>>>>>>>>>>> _gc_timer_cm->register_gc_concurrent_end() into the >>>>>>>>>>>>>> constructor and destructor of CMSPhaseAccounting you >>>>>>>>>>>>>> would automatically get timing events for all concurrent >>>>>>>>>>>>>> phases. >>>>>>>>>>>>> I also considered about this idea but I was not clear >>>>>>>>>>>>> whether it is good measurement especially for 'sweep'. >>>>>>>>>>>>> We are using CMSPhaseAccounting for 5 cases. >>>>>>>>>>>>> I think for 'mark' and 'preclean' they are okay. (there >>>>>>>>>>>>> are non-product functions call before CMSPhaseAccounting. >>>>>>>>>>>>> But they are okay). >>>>>>>>>>>>> For 'abortable-preclean' and 'reset', they are good to >>>>>>>>>>>>> have that. >>>>>>>>>>>>> But when it comes to 'sweep', there are timer and >>>>>>>>>>>>> CMSTokenSyncWithLocks related codes and I was not sure >>>>>>>>>>>>> about these. >>>>>>>>>>>>> If you think they are also okay, I will change as you >>>>>>>>>>>>> suggested. >>>>>>>>>>>> >>>>>>>>>>>> I think it is fine for the sweep part as well. If the >>>>>>>>>>>> CMSPhaseAccounting instance is not measuring the correct >>>>>>>>>>>> part of the work I think we should change it to measure >>>>>>>>>>>> what we want. That way we improve the existing measurements >>>>>>>>>>>> too. >>>>>>>>>>>> >>>>>>>>>>>> But as you stated in your follow up email, I think the >>>>>>>>>>>> sweep code is actually pretty much ok from this perspective. >>>>>>>>>>>> >>>>>>>>>>>> So, I would prefer to go with the CMSPhaseAccounting approach. >>>>>>>>>>> Okay, I already changed as you suggested. :) >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> G1. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think the use of _concurrent_marking_from_roots is >>>>>>>>>>>>>> unfortunate. It would be much cleaner if >>>>>>>>>>>>>> ConcurrentMark::register_mark_from_roots_phase_end() >>>>>>>>>>>>>> called register_gc_concurrent_end() directly. >>>>>>>>>>>>> I wanted to avoid introducing the new flag but the reason >>>>>>>>>>>>> of it was, as you know, to handle 'abort'. >>>>>>>>>>>>> When 'abort' happens we do need to end all timers before >>>>>>>>>>>>> calling 'GCTracer::report_gc_end()'. >>>>>>>>>>>>> And at this point we need a way to know whether concurrent >>>>>>>>>>>>> timer is started or not. >>>>>>>>>>>> >>>>>>>>>>>> As I tried to describe I think you can extend the scope of >>>>>>>>>>>> the timing to cover the part until the marking thread >>>>>>>>>>>> discovers that the marking was aborted. Basically moving >>>>>>>>>>>> the timing in to ConcurrentMarkThread::run_service(). >>>>>>>>>>> Oh, I mis-understood your point. Sorry. >>>>>>>>>>> I will try your recommendation. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> I realize that this would change the timing for when a >>>>>>>>>>>>>> concurrent marking is aborted. The whole time for a full >>>>>>>>>>>>>> GC (or even several full GCs) would be included in the >>>>>>>>>>>>>> concurrent marking phase. But from a code perspective >>>>>>>>>>>>>> that is what happens, so maybe that is the correct time >>>>>>>>>>>>>> to report? Also, I think the logging is reported that way >>>>>>>>>>>>>> so if we want to make it easy to match the timing events >>>>>>>>>>>>>> with the logging we might want to use about the same >>>>>>>>>>>>>> scope for timing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Why do we only measure the concurrent mark phase for G1? >>>>>>>>>>>>> This is good question. :) >>>>>>>>>>>>> I was comparing CMS and G1 for major concurrent phases. >>>>>>>>>>>>> And the candidates were 'concurrent mark/sweep (CMS)' and >>>>>>>>>>>>> 'concurrent mark(G1)'. >>>>>>>>>>>>> >>>>>>>>>>>>>> Wouldn't it be good to measure all concurrent phases? >>>>>>>>>>>>> Okay, Stefan Karlsson also pointed to have them as well so >>>>>>>>>>>>> I filed a separate CR for this. >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8143951 >>>>>>>>>>>> >>>>>>>>>>>> Ok. Is there a reason why we want to split this up into two >>>>>>>>>>>> changes? Why not add all the concurrent timing events at once? >>>>>>>>>>>> >>>>>>>>>>>> I'm ok with splitting it up into two changes, but then >>>>>>>>>>>> maybe the title for JDK-8068394 should be changed to >>>>>>>>>>>> indicate that it only adds events for the marking phase. >>>>>>>>>>>> Also, if we go with the CMSPhaseAccounting approach for >>>>>>>>>>>> CMS, you get events for all phases there. So, it will be a >>>>>>>>>>>> bit odd to have all concurrent phases handled for CMS but >>>>>>>>>>>> only concurrent mark for G1. >>>>>>>>>>> You are correct and I agree with you. >>>>>>>>>>> The only reason of split was due to limited time for FC. >>>>>>>>>>> But as we have enough time, let me close JDK-8143951 and >>>>>>>>>>> include concurrent mark for G1 as well. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> gcTraceSend.cpp >>>>>>>>>>>>>> >>>>>>>>>>>>>> 389 void visit(GCPhase* phase) { >>>>>>>>>>>>>> 390 switch (phase->type()) { >>>>>>>>>>>>>> 391 case GCPhase::PausePhaseType: >>>>>>>>>>>>>> 392 assert(phase->level() < >>>>>>>>>>>>>> PhasesStack::PHASE_LEVELS, "Need more event types for >>>>>>>>>>>>>> PausePhase"); >>>>>>>>>>>>>> 393 >>>>>>>>>>>>>> 394 switch (phase->level()) { >>>>>>>>>>>>>> 395 case 0: >>>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>>> 396 case 1: >>>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>>> 397 case 2: >>>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>>> 398 case 3: >>>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>>> 399 default: /* Ignore sending this phase */ >>>>>>>>>>>>>> break; >>>>>>>>>>>>>> 400 } >>>>>>>>>>>>>> 401 break; >>>>>>>>>>>>>> 402 >>>>>>>>>>>>>> 403 case GCPhase::ConcurrentPhaseType: >>>>>>>>>>>>>> 404 assert(phase->level() < 1, "There's only one >>>>>>>>>>>>>> level for ConcurrentPhase"); >>>>>>>>>>>>>> 405 >>>>>>>>>>>>>> 406 switch (phase->level()) { >>>>>>>>>>>>>> 407 case 0: >>>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>>> 408 default: /* Ignore sending this phase */ >>>>>>>>>>>>>> break; >>>>>>>>>>>>>> 409 } >>>>>>>>>>>>>> 410 break; >>>>>>>>>>>>>> 411 } >>>>>>>>>>>>>> 412 } >>>>>>>>>>>>>> 413 }; >>>>>>>>>>>>>> >>>>>>>>>>>>>> Since there are only two values for GCPhase::PhaseType it >>>>>>>>>>>>>> seems a bit odd to use a switch statement. I think I >>>>>>>>>>>>>> would prefer to factor out the code for the different >>>>>>>>>>>>>> types a bit too. So, maybe something like: >>>>>>>>>>>>>> >>>>>>>>>>>>>> void visit(GCPhase* phase) { >>>>>>>>>>>>>> if (phase->type() == GCPhase::PausePhaseType) { >>>>>>>>>>>>>> visit_pause(phase); >>>>>>>>>>>>>> } else { >>>>>>>>>>>>>> assert(phase->type() == GCPhase::ConcurrentPhaseType, >>>>>>>>>>>>>> ""); >>>>>>>>>>>>>> visit_concurrent(phase); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> } >>>>>>>>>>>>> This seems better. I will fix. >>>>>>>>>>>> >>>>>>>>>>>> Good. Thanks! >>>>>>>>>>> :) >>>>>>>>>>> >>>>>>>>>>> I will post next webrev when I'm ready, including >>>>>>>>>>> JDK-8143951 part as well. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Sangheon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Bengt >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Sangheon >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Bengt >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Testing: JPRT >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Sangheon >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From thomas.schatzl at oracle.com Fri Dec 18 13:23:52 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 18 Dec 2015 14:23:52 +0100 Subject: RFR (S): 8145534: TestRemsetLogging.java takes a long time In-Reply-To: <5672E452.8020101@oracle.com> References: <1450286283.2322.49.camel@oracle.com> <5671F0AE.6020705@oracle.com> <1450350324.2137.5.camel@oracle.com> <5672E452.8020101@oracle.com> Message-ID: <1450445032.9072.1.camel@oracle.com> Hi Jon, On Thu, 2015-12-17 at 08:35 -0800, Jon Masamitsu wrote: > > On 12/17/2015 03:05 AM, Thomas Schatzl wrote: > > Hi Jon, > > > > thanks for your review. > > thanks again. Thomas From thomas.schatzl at oracle.com Fri Dec 18 13:31:30 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 18 Dec 2015 14:31:30 +0100 Subject: RFR (XXXS): 8145752: Fix include guards in GC code In-Reply-To: <5673F5F6.3030109@oracle.com> References: <1450440012.2496.31.camel@oracle.com> <5673F5F6.3030109@oracle.com> Message-ID: <1450445490.9072.3.camel@oracle.com> Mikael, Stefan, thanks for the review. I am treating this change as a trivial change and push it right away without waiting further reviews. Thanks, Thomas On Fri, 2015-12-18 at 13:03 +0100, Mikael Gerdin wrote: > Thomas, > > On 2015-12-18 13:00, Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for this change that fixes include guards in GC > > code? > > > > In the review for 8145667 StefanK noticed that some include guards are > > > > #endif /* SHARE_VM_GC_G1_G1FROMCARDCACHE_HPP */ > > > > while they should be > > > > #endif // SHARE_VM_GC_G1_HEAPREGIONREMSET_HPP > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8145752 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8145752/webrev/ > > Looks good :) > /Mikael > > > Testing: > > local compilation > > > > Thanks, > > Thomas > > > > > From thomas.schatzl at oracle.com Fri Dec 18 13:39:57 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 18 Dec 2015 14:39:57 +0100 Subject: RFR (XXS): 8145673: G1RemSetSummary.hpp uses FREE_C_HEAP_ARRAY In-Reply-To: <5673EFEA.5080900@oracle.com> References: <1450435567.2496.3.camel@oracle.com> <5673EFEA.5080900@oracle.com> Message-ID: <1450445997.9072.4.camel@oracle.com> Hi Stefan, Mikael, thanks for the reviews. I think of this change as a trivial change and pushing right away. Thanks, Thomas On Fri, 2015-12-18 at 12:37 +0100, Stefan Karlsson wrote: > Looks good. > > Thanks, > StefanK > > On 2015-12-18 11:46, Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for this change that fixes some include problem > > with G1RemSetSummary? > > > > The .hpp file uses FREE_C_HEAP_ARRAY, which is defined in an .inline.hpp > > file. For some reason, g1RemSetSummary.hpp does not even include that > > one, but only relies on other code using it doing the right thing (tm). > > > > The fix is to move the code into the .cpp file and do the correct > > includes. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8145673 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8145673/webrev/ > > Testing: > > jprt, build all platforms > > > > Thanks, > > Thomas > > > > > From volker.simonis at gmail.com Fri Dec 18 13:52:29 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 18 Dec 2015 14:52:29 +0100 Subject: RFR (XS): 8145674: Fix includes and forward declarations in g1Remset files In-Reply-To: <1450438532.2496.26.camel@oracle.com> References: <1450435704.2496.5.camel@oracle.com> <1450438532.2496.26.camel@oracle.com> Message-ID: On Fri, Dec 18, 2015 at 12:35 PM, Thomas Schatzl wrote: > Hi Volker, > > thanks for your comments. > > On Fri, 2015-12-18 at 12:22 +0100, Volker Simonis wrote: >> Hi Thomas, >> >> I like such kind of changes, nevertheless I have some comments: >> >> in g1RemSet.hpp the following classes: >> >> G1BlockOffsetSharedArray >> G1SATBCardTableModRefBS > > Both used in the ScanRSClosure class. Sorry, you're right. I accidentally checked in an older hs-comp repository where '8142390: Move ScanRSClosure to header file' wasn't pushed. > >> outputStream >> >> are not used or referenced, so there's no need to forward declare them. > > I will remove that one. Sorry, overlooked that one. > >> If files which include g1RemSet.hpp need them, than they should >> forward declare the classes (and only the classes) they really require >> themselves. There's no need to provide forward declarations in a >> header file to fulfill requirements of users of that header file. > > That has not been the intent. > >> You added an include of "gc/g1/heapRegion.hpp" to g1RemSet.hpp but >> also a forward declaration for "class HeapRegion". So either the >> forward declaration of HeapRegion is enough to fulfil all the >> requirements in heapRegion.hpp in which case you could remove the >> include or the include is really needed (why?) in which case you can >> remove the forward declaration because heapRegion.hpp defines >> HeapReagion. From a first look it seems you are only using HeapRegion >> pointers in g1RemSet.hpp so you should probably drop the inclusion of >> heapRegion.hpp. > > The file has ScanRSClosure that inherits from HeapRegionClosure that is > also in heapRegion.hpp. I would assume that inheriting from something > needs its definition (i.e. a forward declaration is not sufficient), no? > You're right (same reason as above). > I did not remove the HeapRegion* forward declarations after adding > heapRegion.hpp. > I suppose you wanted to say "I did remove...". At least that's what the new webrev says. Why did you had to add "memory/allocation.hpp" now? Was this intentional ? Otherwise looks good. Regards, Volker >> The other extra includes are fine. >> >> The inclusion of "gc/g1/heapRegion.inline.hpp" into g1RemSet.cpp is >> also fine because g1RemSet.cpp uses the inline function >> HeapRegion::in_collection_set() which is defined in >> "gc/g1/heapRegion.inline.hpp" >> >> Regards, >> Volker >> >> >> On Fri, Dec 18, 2015 at 11:48 AM, Thomas Schatzl >> wrote: >> > Hi all, >> > >> > can I have reviews for this change that adds necessary includes and >> > forward declarations in g1RemSet.?pp files? While it compiles right now >> > as is, if something changes in this area, compilation tends to break in >> > interesting ways. >> > >> > CR: >> > https://bugs.openjdk.java.net/browse/JDK-8145674 >> > Webrev: >> > http://cr.openjdk.java.net/~tschatzl/8145674/webrev/ >> > Testing: >> > jprt > > New webrevs (pending another jprt run): > > http://cr.openjdk.java.net/~tschatzl/8145674/webrev.1 (full) > http://cr.openjdk.java.net/~tschatzl/8145674/webrev.0_to_1 (diff) > > > Thanks, > Thomas > > From marcus.larsson at oracle.com Fri Dec 18 14:04:28 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 18 Dec 2015 15:04:28 +0100 Subject: [PING] Re: RFR (XS): Forward port of 8065331: Add trace events for failed allocations In-Reply-To: <56716773.1050408@oracle.com> References: <55DACA18.2070605@oracle.com> <55DD8F43.7070003@oracle.com> <5665511F.8000509@oracle.com> <56681744.4030907@oracle.com> <56716773.1050408@oracle.com> Message-ID: <5674126C.3080407@oracle.com> Pretty please? :) On 2015-12-16 14:30, Marcus Larsson wrote: > Need one more review for this. > > Thanks, > Marcus > > On 2015-12-09 12:57, Marcus Larsson wrote: >> Hi, >> >> After offline discussions with Bengt, I've decided to omit the >> Pending GCId from the event. The ID used previously was never >> guaranteed to be correct, since it came from the peek() method. >> Sometimes a GCId would be skipped which then caused some of the >> events to have an "invalid" GCId. Grouping these events together with >> some GC will now instead have to be done by the event timestamps. >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.02/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.01-02/ >> >> Thanks, >> Marcus >> >> On 2015-12-07 10:27, Marcus Larsson wrote: >>> Hi all, >>> >>> Still need approval for this forward port. >>> >>> New webrev due to changes in how GCId works: >>> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.01/ >>> >>> Had to add a peek method in order to find the pending GC id for the >>> event. >>> This and the changes to includes should be the only things differing >>> from the original patch. >>> >>> Thanks, >>> Marcus >>> >>> On 2015-08-26 12:04, Marcus Larsson wrote: >>>> Ping! >>>> >>>> On 2015-08-24 09:39, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> Please review the following patch to forward port the JEP-242 >>>>> event to JDK9. The patch was originally reviewed in April/March >>>>> [1], but was only integrated in 8u60. The original patch no longer >>>>> applies cleanly to 9, due to directory restructuring and changes >>>>> to includes, so I need a quick re-review for this. >>>>> >>>>> The new patch has updated #includes for the new directory >>>>> structure but should otherwise be identical to the previous patch. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.00/ >>>>> >>>>> Original webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8065331/webrev.02/ >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8065331 >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>> [1]: >>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-March/012408.html >>>> >>> >> > From thomas.schatzl at oracle.com Fri Dec 18 14:15:13 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 18 Dec 2015 15:15:13 +0100 Subject: RFR (XS): 8145674: Fix includes and forward declarations in g1Remset files In-Reply-To: References: <1450435704.2496.5.camel@oracle.com> <1450438532.2496.26.camel@oracle.com> Message-ID: <1450448113.9072.7.camel@oracle.com> Hi, On Fri, 2015-12-18 at 14:52 +0100, Volker Simonis wrote: > On Fri, Dec 18, 2015 at 12:35 PM, Thomas Schatzl > wrote: [...] > > I did not remove the HeapRegion* forward declarations after adding > > heapRegion.hpp. > > > > I suppose you wanted to say "I did remove...". At least that's what > the new webrev says. > > Why did you had to add "memory/allocation.hpp" now? Was this intentional ? > > Otherwise looks good. G1RemSet inherits from CHeapObj :) Thanks, Thomas From volker.simonis at gmail.com Fri Dec 18 14:23:12 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 18 Dec 2015 15:23:12 +0100 Subject: RFR (XS): 8145674: Fix includes and forward declarations in g1Remset files In-Reply-To: <1450448113.9072.7.camel@oracle.com> References: <1450435704.2496.5.camel@oracle.com> <1450438532.2496.26.camel@oracle.com> <1450448113.9072.7.camel@oracle.com> Message-ID: OK, you convinced me :) Thumbs up! Volker On Fri, Dec 18, 2015 at 3:15 PM, Thomas Schatzl wrote: > Hi, > > On Fri, 2015-12-18 at 14:52 +0100, Volker Simonis wrote: >> On Fri, Dec 18, 2015 at 12:35 PM, Thomas Schatzl >> wrote: > [...] >> > I did not remove the HeapRegion* forward declarations after adding >> > heapRegion.hpp. >> > >> >> I suppose you wanted to say "I did remove...". At least that's what >> the new webrev says. >> >> Why did you had to add "memory/allocation.hpp" now? Was this intentional ? >> >> Otherwise looks good. > > G1RemSet inherits from CHeapObj :) > > Thanks, > Thomas > > From erik.helin at oracle.com Fri Dec 18 15:05:52 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 18 Dec 2015 16:05:52 +0100 Subject: [PING] Re: RFR (XS): Forward port of 8065331: Add trace events for failed allocations In-Reply-To: <56716773.1050408@oracle.com> References: <55DACA18.2070605@oracle.com> <55DD8F43.7070003@oracle.com> <5665511F.8000509@oracle.com> <56681744.4030907@oracle.com> <56716773.1050408@oracle.com> Message-ID: <20151218150552.GD26406@ehelin.jrpg.bea.com> On 2015-12-16, Marcus Larsson wrote: > Need one more review for this. Looks good, Reviewed. Thanks, Erik > Thanks, > Marcus > > On 2015-12-09 12:57, Marcus Larsson wrote: > >Hi, > > > >After offline discussions with Bengt, I've decided to omit the Pending > >GCId from the event. The ID used previously was never guaranteed to be > >correct, since it came from the peek() method. Sometimes a GCId would be > >skipped which then caused some of the events to have an "invalid" GCId. > >Grouping these events together with some GC will now instead have to be > >done by the event timestamps. > > > >New webrev: > >http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.02/ > > > >Incremental: > >http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.01-02/ > > > >Thanks, > >Marcus > > > >On 2015-12-07 10:27, Marcus Larsson wrote: > >>Hi all, > >> > >>Still need approval for this forward port. > >> > >>New webrev due to changes in how GCId works: > >>http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.01/ > >> > >>Had to add a peek method in order to find the pending GC id for the > >>event. > >>This and the changes to includes should be the only things differing > >>from the original patch. > >> > >>Thanks, > >>Marcus > >> > >>On 2015-08-26 12:04, Marcus Larsson wrote: > >>>Ping! > >>> > >>>On 2015-08-24 09:39, Marcus Larsson wrote: > >>>>Hi, > >>>> > >>>>Please review the following patch to forward port the JEP-242 event > >>>>to JDK9. The patch was originally reviewed in April/March [1], but > >>>>was only integrated in 8u60. The original patch no longer applies > >>>>cleanly to 9, due to directory restructuring and changes to > >>>>includes, so I need a quick re-review for this. > >>>> > >>>>The new patch has updated #includes for the new directory structure > >>>>but should otherwise be identical to the previous patch. > >>>> > >>>>Webrev: > >>>>http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.00/ > >>>> > >>>>Original webrev: > >>>>http://cr.openjdk.java.net/~mlarsson/8065331/webrev.02/ > >>>> > >>>>Issue: > >>>>https://bugs.openjdk.java.net/browse/JDK-8065331 > >>>> > >>>>Thanks, > >>>>Marcus > >>>> > >>>>[1]: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-March/012408.html > >>> > >> > > > From marcus.larsson at oracle.com Fri Dec 18 15:16:32 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 18 Dec 2015 16:16:32 +0100 Subject: [PING] Re: RFR (XS): Forward port of 8065331: Add trace events for failed allocations In-Reply-To: <20151218150552.GD26406@ehelin.jrpg.bea.com> References: <55DACA18.2070605@oracle.com> <55DD8F43.7070003@oracle.com> <5665511F.8000509@oracle.com> <56681744.4030907@oracle.com> <56716773.1050408@oracle.com> <20151218150552.GD26406@ehelin.jrpg.bea.com> Message-ID: <56742350.1090003@oracle.com> On 2015-12-18 16:05, Erik Helin wrote: > On 2015-12-16, Marcus Larsson wrote: >> Need one more review for this. > Looks good, Reviewed. Great, thanks for reviewing! Regards, Marcus > > Thanks, > Erik > >> Thanks, >> Marcus >> >> On 2015-12-09 12:57, Marcus Larsson wrote: >>> Hi, >>> >>> After offline discussions with Bengt, I've decided to omit the Pending >>> GCId from the event. The ID used previously was never guaranteed to be >>> correct, since it came from the peek() method. Sometimes a GCId would be >>> skipped which then caused some of the events to have an "invalid" GCId. >>> Grouping these events together with some GC will now instead have to be >>> done by the event timestamps. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.02/ >>> >>> Incremental: >>> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.01-02/ >>> >>> Thanks, >>> Marcus >>> >>> On 2015-12-07 10:27, Marcus Larsson wrote: >>>> Hi all, >>>> >>>> Still need approval for this forward port. >>>> >>>> New webrev due to changes in how GCId works: >>>> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.01/ >>>> >>>> Had to add a peek method in order to find the pending GC id for the >>>> event. >>>> This and the changes to includes should be the only things differing >>> >from the original patch. >>>> Thanks, >>>> Marcus >>>> >>>> On 2015-08-26 12:04, Marcus Larsson wrote: >>>>> Ping! >>>>> >>>>> On 2015-08-24 09:39, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the following patch to forward port the JEP-242 event >>>>>> to JDK9. The patch was originally reviewed in April/March [1], but >>>>>> was only integrated in 8u60. The original patch no longer applies >>>>>> cleanly to 9, due to directory restructuring and changes to >>>>>> includes, so I need a quick re-review for this. >>>>>> >>>>>> The new patch has updated #includes for the new directory structure >>>>>> but should otherwise be identical to the previous patch. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.00/ >>>>>> >>>>>> Original webrev: >>>>>> http://cr.openjdk.java.net/~mlarsson/8065331/webrev.02/ >>>>>> >>>>>> Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8065331 >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>> [1]: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-March/012408.html From marcus.larsson at oracle.com Fri Dec 18 15:16:56 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 18 Dec 2015 16:16:56 +0100 Subject: RFR (XS): Forward port of 8065331: Add trace events for failed allocations In-Reply-To: <56694528.70605@oracle.com> References: <55DACA18.2070605@oracle.com> <55DD8F43.7070003@oracle.com> <5665511F.8000509@oracle.com> <56681744.4030907@oracle.com> <56694528.70605@oracle.com> Message-ID: <56742368.1040804@oracle.com> On 2015-12-10 10:26, Bengt Rutisson wrote: > > Hi Marcus, > > Looks good. Thanks for reviewing! Regards, Marcus > > Bengt > > On 2015-12-09 12:57, Marcus Larsson wrote: >> Hi, >> >> After offline discussions with Bengt, I've decided to omit the >> Pending GCId from the event. The ID used previously was never >> guaranteed to be correct, since it came from the peek() method. >> Sometimes a GCId would be skipped which then caused some of the >> events to have an "invalid" GCId. Grouping these events together with >> some GC will now instead have to be done by the event timestamps. >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.02/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.01-02/ >> >> Thanks, >> Marcus >> >> On 2015-12-07 10:27, Marcus Larsson wrote: >>> Hi all, >>> >>> Still need approval for this forward port. >>> >>> New webrev due to changes in how GCId works: >>> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.01/ >>> >>> Had to add a peek method in order to find the pending GC id for the >>> event. >>> This and the changes to includes should be the only things differing >>> from the original patch. >>> >>> Thanks, >>> Marcus >>> >>> On 2015-08-26 12:04, Marcus Larsson wrote: >>>> Ping! >>>> >>>> On 2015-08-24 09:39, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> Please review the following patch to forward port the JEP-242 >>>>> event to JDK9. The patch was originally reviewed in April/March >>>>> [1], but was only integrated in 8u60. The original patch no longer >>>>> applies cleanly to 9, due to directory restructuring and changes >>>>> to includes, so I need a quick re-review for this. >>>>> >>>>> The new patch has updated #includes for the new directory >>>>> structure but should otherwise be identical to the previous patch. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8065331_to_9/webrev.00/ >>>>> >>>>> Original webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8065331/webrev.02/ >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8065331 >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>> [1]: >>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-March/012408.html >>>> >>> >> > From sangheon.kim at oracle.com Fri Dec 18 15:55:01 2015 From: sangheon.kim at oracle.com (sangheon) Date: Fri, 18 Dec 2015 07:55:01 -0800 Subject: RFR (M): JDK-8068394: Trace event for concurrent GC phases In-Reply-To: <5673FF04.9020905@oracle.com> References: <56282271.5090108@oracle.com> <56546233.20006@oracle.com> <5654B10E.1060701@oracle.com> <565EB318.8060607@oracle.com> <565F33A8.6060608@oracle.com> <565FF761.30200@oracle.com> <566FB2BA.5020408@oracle.com> <566FD637.4060909@oracle.com> <56706A22.9070803@oracle.com> <56706AC7.1070708@oracle.com> <56706BF8.6030604@oracle.com> <567091A1.1050105@oracle.com> <56727382.4030800@oracle.com> <5672FE80.6070100@oracle.com> <5673D7DE.8000103@oracle.com> <5673FF04.9020905@oracle.com> Message-ID: <56742C55.1050605@oracle.com> Hi Bengt, Thank you for kindly pushing this, however there is a closed part patch too. I will request to other to sponsor this. Thanks, Sangheon On 12/18/2015 04:41 AM, Bengt Rutisson wrote: > > Hi Sangheon, > > There was a test failure when I ran JPRT: > > http://sthjprt.uk.oracle.com/archives/2015/12/2015-12-18-095536.brutisso.8068394/logs/macosx_x64_10.9-fastdebug-c2-jdk_svc_sanity.log.FAILED.log > > > > ACTION: main -- Failed. Execution failed: `main' threw exception: > java.lang.Exception: Preset 'Continuous' doesn't configure event > 'http://www.oracle.com/hotspot/jvm/vm/gc/phases/concurrent' Preset > 'Profiling' doesn't configure event > 'http://www.oracle.com/hotspot/jvm/vm/gc/phases/concurrent' > > > I think you need to add your new event to: > jdk/test/closed/com/oracle/jfr/api/ConfigurationTest/TestDefaultPresets.java > > > I'll be on vacation next week. Not sure if I will check email. If you > get the TestDefaultPresets test to pass you can still list me as a > reviewer. But someone else needs to sponsor the push. > > Thanks, > Bengt > > On 2015-12-18 10:54, Bengt Rutisson wrote: >> >> Hi Sangheon, >> >> On 2015-12-17 19:27, sangheon wrote: >>> Hi Bengt and Stefan, >>> >>> Thank you for reviewing this. >>> And all the suggestions and advices. >>> >>> I will a sponsor this patch, anyone could help me? >> >> I'm pushing this now. >> >> Thanks, >> Bengt >> >>> >>> Thanks, >>> Sangheon >>> >>> >>> On 12/17/2015 12:34 AM, Bengt Rutisson wrote: >>>> >>>> Hi Sangheon, >>>> >>>> On 2015-12-15 23:18, sangheon wrote: >>>>> Hi Stefan, >>>>> >>>>> Here's the next webrev which includes your suggestion. >>>>> - Removed 'NOT_PRODUCT' and '#ifndef PRODUCT'. (Stefan) >>>>> - Removed volatile keyword at >>>>> ConcurrentGCTimer::_is_concurrent_phase_active. (Stefan) >>>>> - Removed volatile keyword at >>>>> ConcurrentMark::_concurrent_phase_started. This should be removed >>>>> as well. >>>>> >>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.02 >>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.02_to_01/ >>>> >>>> This looks good to me. >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>> On 12/15/2015 11:37 AM, sangheon wrote: >>>>>> Hi Stefan, >>>>>> >>>>>> On 12/15/2015 11:32 AM, Stefan Karlsson wrote: >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> On 2015-12-15 20:29, sangheon wrote: >>>>>>>> Hi Stefan, >>>>>>>> >>>>>>>> Thank you for looking at official RFR as well. >>>>>>>> >>>>>>>> On 12/15/2015 12:58 AM, Stefan Karlsson wrote: >>>>>>>>> Hi Sangheon, >>>>>>>>> >>>>>>>>> On 2015-12-15 07:27, sangheon wrote: >>>>>>>>>> Hi Bengt and all, >>>>>>>>>> >>>>>>>>>> Here's a next webrev. >>>>>>>>>> Bengt and I had a discussion on other thread and he and >>>>>>>>>> Stefan Karlsson suggested simpler design. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01 >>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01_to_00 >>>>>>>>> >>>>>>>>> Thanks for doing the simplifications of the patch. >>>>>>>>> >>>>>>>>> I have a couple of comments: >>>>>>>>> Could you replace NOT_PRODUCT with DEBUG_ONLY, and #ifndef >>>>>>>>> PRODUCT with #ifdef ASSERT. Otherwise, you'll get >>>>>>>>> inconsistencies when building with optimized builds where >>>>>>>>> neither PRODUCT nor ASSERT is defined. >>>>>>>> Okay, I will do. >>>>>>>> But you also pointed that whether this flag is really needed >>>>>>>> below. >>>>>>>> >>>>>>>>> >>>>>>>>> 81 void ConcurrentGCTimer::register_gc_concurrent_start(const >>>>>>>>> char* name, const Ticks& time) { >>>>>>>>> 82 assert(!_is_concurrent_phase_active, "A concurrent phase is >>>>>>>>> already active."); >>>>>>>>> 83 _time_partitions.report_gc_phase_start(name, time, >>>>>>>>> GCPhase::ConcurrentPhaseType); >>>>>>>>> 84 NOT_PRODUCT(_is_concurrent_phase_active = true;) >>>>>>>>> 85 } >>>>>>>>> >>>>>>>>> 162 class ConcurrentGCTimer : public GCTimer { >>>>>>>>> 163 // ConcurrentGCTimer can't be used if there is an overlap >>>>>>>>> between a pause phase and a concurrent phase. >>>>>>>>> 164 // _is_concurrent_phase_active is used to find above case. >>>>>>>>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >>>>>>>>> 166 >>>>>>>>> 167 public: >>>>>>>>> 168 #ifndef PRODUCT >>>>>>>>> 169 ConcurrentGCTimer(): GCTimer(), >>>>>>>>> _is_concurrent_phase_active(false) {}; >>>>>>>>> 170 #endif Is it really worth optimizing away the boolean? The >>>>>>>>> code would be cleaner without these macros. >>>>>>>> I just wanted to prevent mis-use of concurrent timer for >>>>>>>> overlapping phase. >>>>>>>> A pause phase nor another concurrent phase can't be started if >>>>>>>> a concurrent phase is already started. >>>>>>>> I think this would be nice to have. But I don't have a strong >>>>>>>> opinion on this as currently we don't have these situations. >>>>>>> >>>>>>> I meant that we could keep the the variable in the product >>>>>>> builds as well. Just to get rid of the noisy PRODUCT / >>>>>>> DEBUG_ONLY macros. It could even be useful for future debugging. ;) >>>>>> Oops! >>>>>> I am okay with removing this macro. >>>>>> >>>>>> Let me post a new webrev soon. >>>>>> Thank you for the real time answer! >>>>>> >>>>>> Sangheon >>>>>> >>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Why are you using volatile here? I don't see why that should >>>>>>>>> be needed. >>>>>>>>> >>>>>>>>> 162 class ConcurrentGCTimer : public GCTimer { >>>>>>>>> 163 // ConcurrentGCTimer can't be used if there is an overlap >>>>>>>>> between a pause phase and a concurrent phase. >>>>>>>>> 164 // _is_concurrent_phase_active is used to find above case. >>>>>>>>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >>>>>>>> You are right, volatile is not needed here. >>>>>>>> I was thinking register_gc_concurrent_end() would be called >>>>>>>> from different threads(ConcurrentMarkThread and VMThread), but >>>>>>>> as it only happens from safepoint, I think volatile should be >>>>>>>> removed. >>>>>>>> >>>>>>>> I will post a new webrev with your opinion about the flag. >>>>>>> >>>>>>> Great. >>>>>>> >>>>>>> Thanks, >>>>>>> StefanK >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> StefanK >>>>>>>>> >>>>>>>>>> >>>>>>>>>> This webrev includes: >>>>>>>>>> 1. Moving concurrent phase measurement into >>>>>>>>>> CMSPhaseAccounting class. So we can check all concurrent >>>>>>>>>> phases from CMS. >>>>>>>>>> >>>>>>>>>> 2. Renamed a new flag introduced from webrev.00 for general >>>>>>>>>> use, _concurrent_phase_started. >>>>>>>>>> >>>>>>>>>> 3. Added helper class for concurrent phase measurement, >>>>>>>>>> GCConcPhaseTimer. And used this class for all concurrent phases. >>>>>>>>>> >>>>>>>>>> 4. Flag checking is moved from >>>>>>>>>> G1CollectedHeap::register_concurrent_cycle_end() to >>>>>>>>>> ConcurrentMark::abort(). >>>>>>>>>> >>>>>>>>>> 5. Changed switch() to if else statement at gcTraceSend. >>>>>>>>>> >>>>>>>>>> Many thanks to Bengt and Stefan Karlsson for the discussion. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Sangheon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 12/03/2015 12:03 AM, Bengt Rutisson wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Sangheon, >>>>>>>>>>> >>>>>>>>>>> This all sounds good. Looking forward to the next webrev. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Bengt >>>>>>>>>>> >>>>>>>>>>> On 2015-12-02 19:08, sangheon.kim wrote: >>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 12/02/2015 01:00 AM, Bengt Rutisson wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Sangheon, >>>>>>>>>>>>> >>>>>>>>>>>>> Sorry again for the late reply. Comments inline. >>>>>>>>>>>> No not at all. >>>>>>>>>>>> Thank you for taking time for this review! >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2015-11-24 19:48, sangheon.kim wrote: >>>>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you so much for reviewing this patch! >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/24/2015 05:12 AM, Bengt Rutisson wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Sangheon, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sorry for the very late reply to this review request. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2015-10-22 01:40, sangheon.kim wrote: >>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Can I get some reviews for this change of adding a >>>>>>>>>>>>>>>> trace event for concurrent phases on CMS and G1? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Currently we only measure pause times for major phases. >>>>>>>>>>>>>>>> But I want to add 'concurrent mark' and 'concurrent >>>>>>>>>>>>>>>> sweep' phases for CMS and 'concurrent mark' phase for G1. >>>>>>>>>>>>>>>> To achieve this, I had to change ConcurrentGCTimer and >>>>>>>>>>>>>>>> related classes. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This patch includes: >>>>>>>>>>>>>>>> 1) A concurrent phase can be measured only from >>>>>>>>>>>>>>>> ConcurrentGCTimer and measuring an overlap between >>>>>>>>>>>>>>>> concurrent and pause is not allowed as currently we >>>>>>>>>>>>>>>> don't have that use case. And TimePartitions class(or >>>>>>>>>>>>>>>> related classes) will be simpler than an overlap >>>>>>>>>>>>>>>> allowed case. >>>>>>>>>>>>>>>> 2) I removed PausePhase and ConcurrentPhase which are >>>>>>>>>>>>>>>> derived from GCPhase because I wanted to avoid heap >>>>>>>>>>>>>>>> allocation when adding to GrowableArray. Instead >>>>>>>>>>>>>>>> introduced 'type' member variable at GCPhase. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8068394 >>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Nice work! It is great to get some timing information >>>>>>>>>>>>>>> for the concurrent phases. >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> A few questions/comments: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> CMS. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You have added timing events for the concurrent phases >>>>>>>>>>>>>>> mark and sweep, but not for other concurrent phases >>>>>>>>>>>>>>> (preclean, abortable_preclean and reset_concurrent). I >>>>>>>>>>>>>>> think that if you moved your calls to >>>>>>>>>>>>>>> _gc_timer_cm->register_gc_concurrent_start() and >>>>>>>>>>>>>>> _gc_timer_cm->register_gc_concurrent_end() into the >>>>>>>>>>>>>>> constructor and destructor of CMSPhaseAccounting you >>>>>>>>>>>>>>> would automatically get timing events for all concurrent >>>>>>>>>>>>>>> phases. >>>>>>>>>>>>>> I also considered about this idea but I was not clear >>>>>>>>>>>>>> whether it is good measurement especially for 'sweep'. >>>>>>>>>>>>>> We are using CMSPhaseAccounting for 5 cases. >>>>>>>>>>>>>> I think for 'mark' and 'preclean' they are okay. (there >>>>>>>>>>>>>> are non-product functions call before CMSPhaseAccounting. >>>>>>>>>>>>>> But they are okay). >>>>>>>>>>>>>> For 'abortable-preclean' and 'reset', they are good to >>>>>>>>>>>>>> have that. >>>>>>>>>>>>>> But when it comes to 'sweep', there are timer and >>>>>>>>>>>>>> CMSTokenSyncWithLocks related codes and I was not sure >>>>>>>>>>>>>> about these. >>>>>>>>>>>>>> If you think they are also okay, I will change as you >>>>>>>>>>>>>> suggested. >>>>>>>>>>>>> >>>>>>>>>>>>> I think it is fine for the sweep part as well. If the >>>>>>>>>>>>> CMSPhaseAccounting instance is not measuring the correct >>>>>>>>>>>>> part of the work I think we should change it to measure >>>>>>>>>>>>> what we want. That way we improve the existing >>>>>>>>>>>>> measurements too. >>>>>>>>>>>>> >>>>>>>>>>>>> But as you stated in your follow up email, I think the >>>>>>>>>>>>> sweep code is actually pretty much ok from this perspective. >>>>>>>>>>>>> >>>>>>>>>>>>> So, I would prefer to go with the CMSPhaseAccounting >>>>>>>>>>>>> approach. >>>>>>>>>>>> Okay, I already changed as you suggested. :) >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> G1. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think the use of _concurrent_marking_from_roots is >>>>>>>>>>>>>>> unfortunate. It would be much cleaner if >>>>>>>>>>>>>>> ConcurrentMark::register_mark_from_roots_phase_end() >>>>>>>>>>>>>>> called register_gc_concurrent_end() directly. >>>>>>>>>>>>>> I wanted to avoid introducing the new flag but the reason >>>>>>>>>>>>>> of it was, as you know, to handle 'abort'. >>>>>>>>>>>>>> When 'abort' happens we do need to end all timers before >>>>>>>>>>>>>> calling 'GCTracer::report_gc_end()'. >>>>>>>>>>>>>> And at this point we need a way to know whether >>>>>>>>>>>>>> concurrent timer is started or not. >>>>>>>>>>>>> >>>>>>>>>>>>> As I tried to describe I think you can extend the scope of >>>>>>>>>>>>> the timing to cover the part until the marking thread >>>>>>>>>>>>> discovers that the marking was aborted. Basically moving >>>>>>>>>>>>> the timing in to ConcurrentMarkThread::run_service(). >>>>>>>>>>>> Oh, I mis-understood your point. Sorry. >>>>>>>>>>>> I will try your recommendation. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I realize that this would change the timing for when a >>>>>>>>>>>>>>> concurrent marking is aborted. The whole time for a full >>>>>>>>>>>>>>> GC (or even several full GCs) would be included in the >>>>>>>>>>>>>>> concurrent marking phase. But from a code perspective >>>>>>>>>>>>>>> that is what happens, so maybe that is the correct time >>>>>>>>>>>>>>> to report? Also, I think the logging is reported that >>>>>>>>>>>>>>> way so if we want to make it easy to match the timing >>>>>>>>>>>>>>> events with the logging we might want to use about the >>>>>>>>>>>>>>> same scope for timing. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Why do we only measure the concurrent mark phase for G1? >>>>>>>>>>>>>> This is good question. :) >>>>>>>>>>>>>> I was comparing CMS and G1 for major concurrent phases. >>>>>>>>>>>>>> And the candidates were 'concurrent mark/sweep (CMS)' and >>>>>>>>>>>>>> 'concurrent mark(G1)'. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Wouldn't it be good to measure all concurrent phases? >>>>>>>>>>>>>> Okay, Stefan Karlsson also pointed to have them as well >>>>>>>>>>>>>> so I filed a separate CR for this. >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8143951 >>>>>>>>>>>>> >>>>>>>>>>>>> Ok. Is there a reason why we want to split this up into >>>>>>>>>>>>> two changes? Why not add all the concurrent timing events >>>>>>>>>>>>> at once? >>>>>>>>>>>>> >>>>>>>>>>>>> I'm ok with splitting it up into two changes, but then >>>>>>>>>>>>> maybe the title for JDK-8068394 should be changed to >>>>>>>>>>>>> indicate that it only adds events for the marking phase. >>>>>>>>>>>>> Also, if we go with the CMSPhaseAccounting approach for >>>>>>>>>>>>> CMS, you get events for all phases there. So, it will be a >>>>>>>>>>>>> bit odd to have all concurrent phases handled for CMS but >>>>>>>>>>>>> only concurrent mark for G1. >>>>>>>>>>>> You are correct and I agree with you. >>>>>>>>>>>> The only reason of split was due to limited time for FC. >>>>>>>>>>>> But as we have enough time, let me close JDK-8143951 and >>>>>>>>>>>> include concurrent mark for G1 as well. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> gcTraceSend.cpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 389 void visit(GCPhase* phase) { >>>>>>>>>>>>>>> 390 switch (phase->type()) { >>>>>>>>>>>>>>> 391 case GCPhase::PausePhaseType: >>>>>>>>>>>>>>> 392 assert(phase->level() < >>>>>>>>>>>>>>> PhasesStack::PHASE_LEVELS, "Need more event types for >>>>>>>>>>>>>>> PausePhase"); >>>>>>>>>>>>>>> 393 >>>>>>>>>>>>>>> 394 switch (phase->level()) { >>>>>>>>>>>>>>> 395 case 0: >>>>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>>>> 396 case 1: >>>>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>>>> 397 case 2: >>>>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>>>> 398 case 3: >>>>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>>>> 399 default: /* Ignore sending this phase */ >>>>>>>>>>>>>>> break; >>>>>>>>>>>>>>> 400 } >>>>>>>>>>>>>>> 401 break; >>>>>>>>>>>>>>> 402 >>>>>>>>>>>>>>> 403 case GCPhase::ConcurrentPhaseType: >>>>>>>>>>>>>>> 404 assert(phase->level() < 1, "There's only >>>>>>>>>>>>>>> one level for ConcurrentPhase"); >>>>>>>>>>>>>>> 405 >>>>>>>>>>>>>>> 406 switch (phase->level()) { >>>>>>>>>>>>>>> 407 case 0: >>>>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>>>> 408 default: /* Ignore sending this phase */ >>>>>>>>>>>>>>> break; >>>>>>>>>>>>>>> 409 } >>>>>>>>>>>>>>> 410 break; >>>>>>>>>>>>>>> 411 } >>>>>>>>>>>>>>> 412 } >>>>>>>>>>>>>>> 413 }; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Since there are only two values for GCPhase::PhaseType >>>>>>>>>>>>>>> it seems a bit odd to use a switch statement. I think I >>>>>>>>>>>>>>> would prefer to factor out the code for the different >>>>>>>>>>>>>>> types a bit too. So, maybe something like: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> void visit(GCPhase* phase) { >>>>>>>>>>>>>>> if (phase->type() == GCPhase::PausePhaseType) { >>>>>>>>>>>>>>> visit_pause(phase); >>>>>>>>>>>>>>> } else { >>>>>>>>>>>>>>> assert(phase->type() == >>>>>>>>>>>>>>> GCPhase::ConcurrentPhaseType, ""); >>>>>>>>>>>>>>> visit_concurrent(phase); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>> This seems better. I will fix. >>>>>>>>>>>>> >>>>>>>>>>>>> Good. Thanks! >>>>>>>>>>>> :) >>>>>>>>>>>> >>>>>>>>>>>> I will post next webrev when I'm ready, including >>>>>>>>>>>> JDK-8143951 part as well. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Sangheon >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Bengt >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Sangheon >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Bengt >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Testing: JPRT >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Sangheon >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From bengt.rutisson at oracle.com Fri Dec 18 16:22:42 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 18 Dec 2015 17:22:42 +0100 Subject: RFR (M): JDK-8068394: Trace event for concurrent GC phases In-Reply-To: <56742C55.1050605@oracle.com> References: <56282271.5090108@oracle.com> <56546233.20006@oracle.com> <5654B10E.1060701@oracle.com> <565EB318.8060607@oracle.com> <565F33A8.6060608@oracle.com> <565FF761.30200@oracle.com> <566FB2BA.5020408@oracle.com> <566FD637.4060909@oracle.com> <56706A22.9070803@oracle.com> <56706AC7.1070708@oracle.com> <56706BF8.6030604@oracle.com> <567091A1.1050105@oracle.com> <56727382.4030800@oracle.com> <5672FE80.6070100@oracle.com> <5673D7DE.8000103@oracle.com> <5673FF04.9020905@oracle.com> <56742C55.1050605@oracle.com> Message-ID: <567432D2.6060908@oracle.com> Hi Sangheon, On 2015-12-18 16:55, sangheon wrote: > Hi Bengt, > > Thank you for kindly pushing this, however there is a closed part > patch too. > I will request to other to sponsor this. Sorry I had forgotten about that. I'm retrying the push now. Bengt > > Thanks, > Sangheon > > > On 12/18/2015 04:41 AM, Bengt Rutisson wrote: >> >> Hi Sangheon, >> >> There was a test failure when I ran JPRT: >> >> http://sthjprt.uk.oracle.com/archives/2015/12/2015-12-18-095536.brutisso.8068394/logs/macosx_x64_10.9-fastdebug-c2-jdk_svc_sanity.log.FAILED.log >> >> >> >> ACTION: main -- Failed. Execution failed: `main' threw exception: >> java.lang.Exception: Preset 'Continuous' doesn't configure event >> 'http://www.oracle.com/hotspot/jvm/vm/gc/phases/concurrent' Preset >> 'Profiling' doesn't configure event >> 'http://www.oracle.com/hotspot/jvm/vm/gc/phases/concurrent' >> >> >> I think you need to add your new event to: >> jdk/test/closed/com/oracle/jfr/api/ConfigurationTest/TestDefaultPresets.java >> >> >> I'll be on vacation next week. Not sure if I will check email. If you >> get the TestDefaultPresets test to pass you can still list me as a >> reviewer. But someone else needs to sponsor the push. >> >> Thanks, >> Bengt >> >> On 2015-12-18 10:54, Bengt Rutisson wrote: >>> >>> Hi Sangheon, >>> >>> On 2015-12-17 19:27, sangheon wrote: >>>> Hi Bengt and Stefan, >>>> >>>> Thank you for reviewing this. >>>> And all the suggestions and advices. >>>> >>>> I will a sponsor this patch, anyone could help me? >>> >>> I'm pushing this now. >>> >>> Thanks, >>> Bengt >>> >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> On 12/17/2015 12:34 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi Sangheon, >>>>> >>>>> On 2015-12-15 23:18, sangheon wrote: >>>>>> Hi Stefan, >>>>>> >>>>>> Here's the next webrev which includes your suggestion. >>>>>> - Removed 'NOT_PRODUCT' and '#ifndef PRODUCT'. (Stefan) >>>>>> - Removed volatile keyword at >>>>>> ConcurrentGCTimer::_is_concurrent_phase_active. (Stefan) >>>>>> - Removed volatile keyword at >>>>>> ConcurrentMark::_concurrent_phase_started. This should be removed >>>>>> as well. >>>>>> >>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.02 >>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.02_to_01/ >>>>> >>>>> This looks good to me. >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>> On 12/15/2015 11:37 AM, sangheon wrote: >>>>>>> Hi Stefan, >>>>>>> >>>>>>> On 12/15/2015 11:32 AM, Stefan Karlsson wrote: >>>>>>>> Hi Sangheon, >>>>>>>> >>>>>>>> On 2015-12-15 20:29, sangheon wrote: >>>>>>>>> Hi Stefan, >>>>>>>>> >>>>>>>>> Thank you for looking at official RFR as well. >>>>>>>>> >>>>>>>>> On 12/15/2015 12:58 AM, Stefan Karlsson wrote: >>>>>>>>>> Hi Sangheon, >>>>>>>>>> >>>>>>>>>> On 2015-12-15 07:27, sangheon wrote: >>>>>>>>>>> Hi Bengt and all, >>>>>>>>>>> >>>>>>>>>>> Here's a next webrev. >>>>>>>>>>> Bengt and I had a discussion on other thread and he and >>>>>>>>>>> Stefan Karlsson suggested simpler design. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01 >>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.01_to_00 >>>>>>>>>> >>>>>>>>>> Thanks for doing the simplifications of the patch. >>>>>>>>>> >>>>>>>>>> I have a couple of comments: >>>>>>>>>> Could you replace NOT_PRODUCT with DEBUG_ONLY, and #ifndef >>>>>>>>>> PRODUCT with #ifdef ASSERT. Otherwise, you'll get >>>>>>>>>> inconsistencies when building with optimized builds where >>>>>>>>>> neither PRODUCT nor ASSERT is defined. >>>>>>>>> Okay, I will do. >>>>>>>>> But you also pointed that whether this flag is really needed >>>>>>>>> below. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 81 void ConcurrentGCTimer::register_gc_concurrent_start(const >>>>>>>>>> char* name, const Ticks& time) { >>>>>>>>>> 82 assert(!_is_concurrent_phase_active, "A concurrent phase >>>>>>>>>> is already active."); >>>>>>>>>> 83 _time_partitions.report_gc_phase_start(name, time, >>>>>>>>>> GCPhase::ConcurrentPhaseType); >>>>>>>>>> 84 NOT_PRODUCT(_is_concurrent_phase_active = true;) >>>>>>>>>> 85 } >>>>>>>>>> >>>>>>>>>> 162 class ConcurrentGCTimer : public GCTimer { >>>>>>>>>> 163 // ConcurrentGCTimer can't be used if there is an overlap >>>>>>>>>> between a pause phase and a concurrent phase. >>>>>>>>>> 164 // _is_concurrent_phase_active is used to find above case. >>>>>>>>>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >>>>>>>>>> 166 >>>>>>>>>> 167 public: >>>>>>>>>> 168 #ifndef PRODUCT >>>>>>>>>> 169 ConcurrentGCTimer(): GCTimer(), >>>>>>>>>> _is_concurrent_phase_active(false) {}; >>>>>>>>>> 170 #endif Is it really worth optimizing away the boolean? >>>>>>>>>> The code would be cleaner without these macros. >>>>>>>>> I just wanted to prevent mis-use of concurrent timer for >>>>>>>>> overlapping phase. >>>>>>>>> A pause phase nor another concurrent phase can't be started if >>>>>>>>> a concurrent phase is already started. >>>>>>>>> I think this would be nice to have. But I don't have a strong >>>>>>>>> opinion on this as currently we don't have these situations. >>>>>>>> >>>>>>>> I meant that we could keep the the variable in the product >>>>>>>> builds as well. Just to get rid of the noisy PRODUCT / >>>>>>>> DEBUG_ONLY macros. It could even be useful for future >>>>>>>> debugging. ;) >>>>>>> Oops! >>>>>>> I am okay with removing this macro. >>>>>>> >>>>>>> Let me post a new webrev soon. >>>>>>> Thank you for the real time answer! >>>>>>> >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Why are you using volatile here? I don't see why that should >>>>>>>>>> be needed. >>>>>>>>>> >>>>>>>>>> 162 class ConcurrentGCTimer : public GCTimer { >>>>>>>>>> 163 // ConcurrentGCTimer can't be used if there is an >>>>>>>>>> overlap between a pause phase and a concurrent phase. >>>>>>>>>> 164 // _is_concurrent_phase_active is used to find above case. >>>>>>>>>> 165 NOT_PRODUCT(volatile bool _is_concurrent_phase_active;) >>>>>>>>> You are right, volatile is not needed here. >>>>>>>>> I was thinking register_gc_concurrent_end() would be called >>>>>>>>> from different threads(ConcurrentMarkThread and VMThread), but >>>>>>>>> as it only happens from safepoint, I think volatile should be >>>>>>>>> removed. >>>>>>>>> >>>>>>>>> I will post a new webrev with your opinion about the flag. >>>>>>>> >>>>>>>> Great. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> StefanK >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sangheon >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> StefanK >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This webrev includes: >>>>>>>>>>> 1. Moving concurrent phase measurement into >>>>>>>>>>> CMSPhaseAccounting class. So we can check all concurrent >>>>>>>>>>> phases from CMS. >>>>>>>>>>> >>>>>>>>>>> 2. Renamed a new flag introduced from webrev.00 for general >>>>>>>>>>> use, _concurrent_phase_started. >>>>>>>>>>> >>>>>>>>>>> 3. Added helper class for concurrent phase measurement, >>>>>>>>>>> GCConcPhaseTimer. And used this class for all concurrent >>>>>>>>>>> phases. >>>>>>>>>>> >>>>>>>>>>> 4. Flag checking is moved from >>>>>>>>>>> G1CollectedHeap::register_concurrent_cycle_end() to >>>>>>>>>>> ConcurrentMark::abort(). >>>>>>>>>>> >>>>>>>>>>> 5. Changed switch() to if else statement at gcTraceSend. >>>>>>>>>>> >>>>>>>>>>> Many thanks to Bengt and Stefan Karlsson for the discussion. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Sangheon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 12/03/2015 12:03 AM, Bengt Rutisson wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Sangheon, >>>>>>>>>>>> >>>>>>>>>>>> This all sounds good. Looking forward to the next webrev. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Bengt >>>>>>>>>>>> >>>>>>>>>>>> On 2015-12-02 19:08, sangheon.kim wrote: >>>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 12/02/2015 01:00 AM, Bengt Rutisson wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Sangheon, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sorry again for the late reply. Comments inline. >>>>>>>>>>>>> No not at all. >>>>>>>>>>>>> Thank you for taking time for this review! >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2015-11-24 19:48, sangheon.kim wrote: >>>>>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you so much for reviewing this patch! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/24/2015 05:12 AM, Bengt Rutisson wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Sangheon, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sorry for the very late reply to this review request. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2015-10-22 01:40, sangheon.kim wrote: >>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Can I get some reviews for this change of adding a >>>>>>>>>>>>>>>>> trace event for concurrent phases on CMS and G1? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Currently we only measure pause times for major phases. >>>>>>>>>>>>>>>>> But I want to add 'concurrent mark' and 'concurrent >>>>>>>>>>>>>>>>> sweep' phases for CMS and 'concurrent mark' phase for G1. >>>>>>>>>>>>>>>>> To achieve this, I had to change ConcurrentGCTimer and >>>>>>>>>>>>>>>>> related classes. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This patch includes: >>>>>>>>>>>>>>>>> 1) A concurrent phase can be measured only from >>>>>>>>>>>>>>>>> ConcurrentGCTimer and measuring an overlap between >>>>>>>>>>>>>>>>> concurrent and pause is not allowed as currently we >>>>>>>>>>>>>>>>> don't have that use case. And TimePartitions class(or >>>>>>>>>>>>>>>>> related classes) will be simpler than an overlap >>>>>>>>>>>>>>>>> allowed case. >>>>>>>>>>>>>>>>> 2) I removed PausePhase and ConcurrentPhase which are >>>>>>>>>>>>>>>>> derived from GCPhase because I wanted to avoid heap >>>>>>>>>>>>>>>>> allocation when adding to GrowableArray. Instead >>>>>>>>>>>>>>>>> introduced 'type' member variable at GCPhase. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8068394 >>>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8068394/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Nice work! It is great to get some timing information >>>>>>>>>>>>>>>> for the concurrent phases. >>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> A few questions/comments: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> CMS. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You have added timing events for the concurrent phases >>>>>>>>>>>>>>>> mark and sweep, but not for other concurrent phases >>>>>>>>>>>>>>>> (preclean, abortable_preclean and reset_concurrent). I >>>>>>>>>>>>>>>> think that if you moved your calls to >>>>>>>>>>>>>>>> _gc_timer_cm->register_gc_concurrent_start() and >>>>>>>>>>>>>>>> _gc_timer_cm->register_gc_concurrent_end() into the >>>>>>>>>>>>>>>> constructor and destructor of CMSPhaseAccounting you >>>>>>>>>>>>>>>> would automatically get timing events for all >>>>>>>>>>>>>>>> concurrent phases. >>>>>>>>>>>>>>> I also considered about this idea but I was not clear >>>>>>>>>>>>>>> whether it is good measurement especially for 'sweep'. >>>>>>>>>>>>>>> We are using CMSPhaseAccounting for 5 cases. >>>>>>>>>>>>>>> I think for 'mark' and 'preclean' they are okay. (there >>>>>>>>>>>>>>> are non-product functions call before >>>>>>>>>>>>>>> CMSPhaseAccounting. But they are okay). >>>>>>>>>>>>>>> For 'abortable-preclean' and 'reset', they are good to >>>>>>>>>>>>>>> have that. >>>>>>>>>>>>>>> But when it comes to 'sweep', there are timer and >>>>>>>>>>>>>>> CMSTokenSyncWithLocks related codes and I was not sure >>>>>>>>>>>>>>> about these. >>>>>>>>>>>>>>> If you think they are also okay, I will change as you >>>>>>>>>>>>>>> suggested. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think it is fine for the sweep part as well. If the >>>>>>>>>>>>>> CMSPhaseAccounting instance is not measuring the correct >>>>>>>>>>>>>> part of the work I think we should change it to measure >>>>>>>>>>>>>> what we want. That way we improve the existing >>>>>>>>>>>>>> measurements too. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But as you stated in your follow up email, I think the >>>>>>>>>>>>>> sweep code is actually pretty much ok from this perspective. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So, I would prefer to go with the CMSPhaseAccounting >>>>>>>>>>>>>> approach. >>>>>>>>>>>>> Okay, I already changed as you suggested. :) >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> G1. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think the use of _concurrent_marking_from_roots is >>>>>>>>>>>>>>>> unfortunate. It would be much cleaner if >>>>>>>>>>>>>>>> ConcurrentMark::register_mark_from_roots_phase_end() >>>>>>>>>>>>>>>> called register_gc_concurrent_end() directly. >>>>>>>>>>>>>>> I wanted to avoid introducing the new flag but the >>>>>>>>>>>>>>> reason of it was, as you know, to handle 'abort'. >>>>>>>>>>>>>>> When 'abort' happens we do need to end all timers before >>>>>>>>>>>>>>> calling 'GCTracer::report_gc_end()'. >>>>>>>>>>>>>>> And at this point we need a way to know whether >>>>>>>>>>>>>>> concurrent timer is started or not. >>>>>>>>>>>>>> >>>>>>>>>>>>>> As I tried to describe I think you can extend the scope >>>>>>>>>>>>>> of the timing to cover the part until the marking thread >>>>>>>>>>>>>> discovers that the marking was aborted. Basically moving >>>>>>>>>>>>>> the timing in to ConcurrentMarkThread::run_service(). >>>>>>>>>>>>> Oh, I mis-understood your point. Sorry. >>>>>>>>>>>>> I will try your recommendation. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I realize that this would change the timing for when a >>>>>>>>>>>>>>>> concurrent marking is aborted. The whole time for a >>>>>>>>>>>>>>>> full GC (or even several full GCs) would be included in >>>>>>>>>>>>>>>> the concurrent marking phase. But from a code >>>>>>>>>>>>>>>> perspective that is what happens, so maybe that is the >>>>>>>>>>>>>>>> correct time to report? Also, I think the logging is >>>>>>>>>>>>>>>> reported that way so if we want to make it easy to >>>>>>>>>>>>>>>> match the timing events with the logging we might want >>>>>>>>>>>>>>>> to use about the same scope for timing. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Why do we only measure the concurrent mark phase for G1? >>>>>>>>>>>>>>> This is good question. :) >>>>>>>>>>>>>>> I was comparing CMS and G1 for major concurrent phases. >>>>>>>>>>>>>>> And the candidates were 'concurrent mark/sweep (CMS)' >>>>>>>>>>>>>>> and 'concurrent mark(G1)'. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Wouldn't it be good to measure all concurrent phases? >>>>>>>>>>>>>>> Okay, Stefan Karlsson also pointed to have them as well >>>>>>>>>>>>>>> so I filed a separate CR for this. >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8143951 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ok. Is there a reason why we want to split this up into >>>>>>>>>>>>>> two changes? Why not add all the concurrent timing events >>>>>>>>>>>>>> at once? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm ok with splitting it up into two changes, but then >>>>>>>>>>>>>> maybe the title for JDK-8068394 should be changed to >>>>>>>>>>>>>> indicate that it only adds events for the marking phase. >>>>>>>>>>>>>> Also, if we go with the CMSPhaseAccounting approach for >>>>>>>>>>>>>> CMS, you get events for all phases there. So, it will be >>>>>>>>>>>>>> a bit odd to have all concurrent phases handled for CMS >>>>>>>>>>>>>> but only concurrent mark for G1. >>>>>>>>>>>>> You are correct and I agree with you. >>>>>>>>>>>>> The only reason of split was due to limited time for FC. >>>>>>>>>>>>> But as we have enough time, let me close JDK-8143951 and >>>>>>>>>>>>> include concurrent mark for G1 as well. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> gcTraceSend.cpp >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 389 void visit(GCPhase* phase) { >>>>>>>>>>>>>>>> 390 switch (phase->type()) { >>>>>>>>>>>>>>>> 391 case GCPhase::PausePhaseType: >>>>>>>>>>>>>>>> 392 assert(phase->level() < PhasesStack::PHASE_LEVELS, >>>>>>>>>>>>>>>> "Need more event types for PausePhase"); >>>>>>>>>>>>>>>> 393 >>>>>>>>>>>>>>>> 394 switch (phase->level()) { >>>>>>>>>>>>>>>> 395 case 0: >>>>>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>>>>> 396 case 1: >>>>>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>>>>> 397 case 2: >>>>>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>>>>> 398 case 3: >>>>>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>>>>> 399 default: /* Ignore sending this phase */ >>>>>>>>>>>>>>>> break; >>>>>>>>>>>>>>>> 400 } >>>>>>>>>>>>>>>> 401 break; >>>>>>>>>>>>>>>> 402 >>>>>>>>>>>>>>>> 403 case GCPhase::ConcurrentPhaseType: >>>>>>>>>>>>>>>> 404 assert(phase->level() < 1, "There's only one level >>>>>>>>>>>>>>>> for ConcurrentPhase"); >>>>>>>>>>>>>>>> 405 >>>>>>>>>>>>>>>> 406 switch (phase->level()) { >>>>>>>>>>>>>>>> 407 case 0: >>>>>>>>>>>>>>>> send_phase(phase); break; >>>>>>>>>>>>>>>> 408 default: /* Ignore sending this phase */ >>>>>>>>>>>>>>>> break; >>>>>>>>>>>>>>>> 409 } >>>>>>>>>>>>>>>> 410 break; >>>>>>>>>>>>>>>> 411 } >>>>>>>>>>>>>>>> 412 } >>>>>>>>>>>>>>>> 413 }; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Since there are only two values for GCPhase::PhaseType >>>>>>>>>>>>>>>> it seems a bit odd to use a switch statement. I think I >>>>>>>>>>>>>>>> would prefer to factor out the code for the different >>>>>>>>>>>>>>>> types a bit too. So, maybe something like: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> void visit(GCPhase* phase) { >>>>>>>>>>>>>>>> if (phase->type() == GCPhase::PausePhaseType) { >>>>>>>>>>>>>>>> visit_pause(phase); >>>>>>>>>>>>>>>> } else { >>>>>>>>>>>>>>>> assert(phase->type() == >>>>>>>>>>>>>>>> GCPhase::ConcurrentPhaseType, ""); >>>>>>>>>>>>>>>> visit_concurrent(phase); >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> This seems better. I will fix. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Good. Thanks! >>>>>>>>>>>>> :) >>>>>>>>>>>>> >>>>>>>>>>>>> I will post next webrev when I'm ready, including >>>>>>>>>>>>> JDK-8143951 part as well. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Sangheon >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Bengt >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Sangheon >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Bengt >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Testing: JPRT >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Sangheon >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From mandy.chung at oracle.com Fri Dec 18 17:02:54 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 18 Dec 2015 09:02:54 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <5673DC23.4050304@gmail.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> <5673DC23.4050304@gmail.com> Message-ID: > On Dec 18, 2015, at 2:12 AM, Peter Levart wrote: > > Hi, > > Now that PhantomReference(s) (excluding sun.misc.Cleaner(s)) are treated equally to sun.misc.Cleaner(s), the split between _discoveredPhantomRefs and _discoveredCleanerRefs is not needed any more right? Will this be a separate simplification? Yes that?s the plan. http://bugs.openjdk.java.net/browse/JDK-8143847 Mandy From jon.masamitsu at oracle.com Fri Dec 18 17:13:22 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 18 Dec 2015 09:13:22 -0800 Subject: RFR (XXS): 8145671: Rename FromCardCache to G1FromCardCache In-Reply-To: <1450435997.2496.10.camel@oracle.com> References: <1450435997.2496.10.camel@oracle.com> Message-ID: <56743EB2.90706@oracle.com> Looks good. Jon On 12/18/2015 2:53 AM, Thomas Schatzl wrote: > Hi all, > > as the title for this change implies, this code changes the name of > the FromCardCache class into G1FromCardCache to adhere to other class > names. > > It is based on 8145667. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8145671 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8145671/webrev/ > Testing: > jprt > > Thanks, > Thomas > > > From jon.masamitsu at oracle.com Fri Dec 18 18:23:41 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 18 Dec 2015 10:23:41 -0800 Subject: RFR (S): 8145672: Remove dependency of G1FromCardCache to HeapRegionRemSet In-Reply-To: <1450436572.2496.17.camel@oracle.com> References: <1450436572.2496.17.camel@oracle.com> Message-ID: <56744F2D.1040304@oracle.com> Thomas, A couple of questions about code that are not part of your change (you can ignore) and a suggestion on expanding a comment. http://cr.openjdk.java.net/~tschatzl/8145672/webrev/src/share/vm/gc/g1/g1CollectedHeap.cpp.frames.html Not a part of your change but is the guarantee() in the right place? > 1936 const uint max_region_idx = (1U << (sizeof(RegionIdx_t)*BitsPerByte-1)) - 1; > 1937 guarantee((max_regions() - 1) <= max_region_idx, "too many regions"); > 1938 > 1939 G1RemSet::init_heap(max_regions()); Meaning, isn't _max_regions initialized in init_heap() after the guarantee()? http://cr.openjdk.java.net/~tschatzl/8145672/webrev/src/share/vm/gc/g1/g1FromCardCache.cpp.frames.html Again, not part of your change but can lines 52 and 53 be lifted out of the loop at 51? > 51 for (uint i = 0; i < G1RemSet::num_par_rem_sets(); i++) { > 52 uint end_idx = (start_idx + (uint)new_num_regions); > 53 assert(end_idx <= _max_regions, "Must be within max."); > 54 for (uint j = start_idx; j < end_idx; j++) { > 55 set(i, j, InvalidCard); > 56 } > 57 } http://cr.openjdk.java.net/~tschatzl/8145672/webrev/src/share/vm/gc/g1/g1RemSet.hpp.frames.html Thank you for adding this comment. > 79 // Gives an approximation on how many threads add records to a > remembered set > 80 // in parallel for sizing buffers to decrease performance losses > due to sharing. > 81 // Examples are mutator threads together with the concurrent > refinement threads > 82 // or GC threads. > 83 static uint num_par_rem_sets(); Can you add what kind of buffers to "for sizing ??? buffers"? Would this be too specific to the current implementation? Meaning do you want a more general descriptions? // Examples are the maximum number of mutator threads plus the maximum number of // concurrent refinement threads or the maximum number of GC threads, whichever is // larger. Leave out the "maximum" (in all 3 places if it is understood). Otherwise, looks good. None of these are critical to the patch (since mostly not part of your change) so no need to delay your push for any of these. Jon On 12/18/2015 3:02 AM, Thomas Schatzl wrote: > Hi all, > > can I have review for the following change that removes the remaining > dependency of G1FromCardCache to HeapRegionRemSet? > > G1FromCardCache references some static method that returns some > configuration value for G1FromCardCache. Imo it is better to move that > into G1RemSet as it is some value that is used for configuring parts of > the entire remembered set. > > I.e. G1FromCardCache is actually pretty independent of HeapRegionRemSet. > > I also removed some unnecessary references to (former) > HeapRegionRemSet::num_par_rem_sets() across the code. > > This allows easier hg rm heapRegionRemset* later, or at least adds some > explanation for the methods :) > > CR: > https://bugs.openjdk.java.net/browse/JDK-8145672 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8145672/webrev > Testing: > jprt > > Thanks, > Thomas > > From kim.barrett at oracle.com Fri Dec 18 20:20:05 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 18 Dec 2015 15:20:05 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> <84A72B6D-A101-435E-88D5-7D9EE1363EC9@oracle.com> Message-ID: <4B0BD0CA-957B-4CA6-8D1C-1FBEA28400A6@oracle.com> On Dec 18, 2015, at 12:46 AM, Tao Mao wrote: > > > On Thu, Dec 17, 2015 at 9:34 PM, Mandy Chung wrote: > > > On Dec 17, 2015, at 6:05 PM, Tao Mao wrote: > > On line 38, can we also add "through a chain of strong, soft, and weak references." to the above, which I think is the case? > > > > Yes it is and this is not strictly needed. For phantom reference case, this can be left ?unqualified? as it?s basically a chain of any reference type. > > Strictly speaking, any reference type but phantom reference. This wording (for weak references, with similar wording for others): At that time it will atomically clear all weak references to that object and all weak references to any other weakly-reachable objects from which that object is reachable through a chain of strong and soft references. exists to require that an implementation ensures that, after a reference has been cleared, it is no longer possible for an application to recover the former referent of that reference via a sequence of references of the same or greater strength as that reference. It can be shown by induction that the same reference type as that being cleared doesn't need to be mentioned in order to achieve that effect. Adding the cleared reference type to the chain list might impose a stronger requirement on implementations. However, we don't think an implementation can usefully take advantage of any difference, so in the case of phantom references we opted for shorter wording. From sangheon.kim at oracle.com Fri Dec 18 23:02:59 2015 From: sangheon.kim at oracle.com (sangheon) Date: Fri, 18 Dec 2015 15:02:59 -0800 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <567351E9.40109@oracle.com> References: <5670B5F1.7010505@oracle.com> <56717944.1030402@oracle.com> <56724973.4060405@oracle.com> <5673290E.7080106@oracle.com> <567351E9.40109@oracle.com> Message-ID: <567490A3.5020104@oracle.com> Hi Tom, On 12/17/2015 04:23 PM, sangheon wrote: > Hi Tom, > > Thank you for reviewing this! > > On 12/17/2015 01:28 PM, Tom Benson wrote: >> Hi Sangheon, >> I like the new approach, but just have a couple of comments. > Thanks. > >> >> I think you should check the VirtualQuery return status and return >> false from protect_pages_individually if zero. > Right. > I will fix this. > >> >> I don't *think* you need to have the "!UseLargePages" restriction >> anymore with this approach, do you? > protect_pages_individually() doesn't have previous restriction on its > usage. > However I wanted to remain the caller(os::protect_memory) as is > because, as you already mentioned below, I didn't want to have an > additional call of VirtualQuery() for simpler code. > I don't have strong opinion on this. > > Let me post next webrev after concluding this. Tom, do you prefer to always use protect_pages_individually()? Does anyone have opinion on this? Thanks, Sangheon > > Thanks, > Sangheon > > >> >> Actually, I think you could just always use >> protect_pages_individually regardless of whether UseNUMAInterleaving >> was enabled or not, and the right thing would happen. But this way, >> you save an unnecessary system call plus some overhead. >> Tom >> >> >> On 12/17/2015 12:34 AM, sangheon wrote: >>> Hi Jesper, >>> >>> Thank you for looking at this! >>> >>> On 12/16/2015 06:46 AM, Jesper Wilhelmsson wrote: >>>> Hi Sangheon, >>>> >>>> * It seems to me that protect_pages_individually() can only be >>>> called if UseLargePages is false. Still it looks at UseLargePages >>>> to decide page_size. I would prefer if there was an >>>> assert(!UseLargePages) at the start of protect_pages_individually() >>>> to emphasize that this code has not been used or tested with large >>>> pages. >>>> >>>> * I'm not sure if this matters, but it seems to me that if the size >>>> of the area is not an even multiple of pages, you will start >>>> protecting the smaller part, and then continue with page sized >>>> areas. E.g. If page size is 4k and we want to protect a 10k area, >>>> we will start with a 2k block and then take two 4k blocks. This has >>>> the effect that if we pass in a page aligned address, the areas we >>>> protect will not cover one page at a time. This may be a non-issue >>>> though. It depends on if we usually get page aligned addresses and >>>> if it matters if we protect one page at a time or not. >>> Your second comment made me to change the function which maybe >>> doesn't need an assert now and removed potential alignment problem. >>> Currently protect_pages_individually() is only called when >>> "UseNUMAInterleaving && !UseLargePages" and >>> protect_pages_indivisually() will always have aligned size as >>> allocate_pages_individually() allocate aligned size. This means, as >>> you pointed, we need an assert to prevent wrong use and would have >>> alignment issue. >>> >>> So I changed the function to read currently allocated chunk size(via >>> Windows API) rather than calculating chunk size and then try to >>> protect the chunk. >>> With this change, we don't need to care about the flags neither >>> align matter. >>> >>>> >>>> * You use UINT32_FORMAT to print an uint. %u is the recommended way >>>> to print an uint. >>> Fixed. >>> >>>> >>>> * if (!ret) return false; We should always use { } >>> Fixed. >>> >>> Here's a next webrev. >>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.01/ >>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.01_to_00/ >>> >>> Testing: JPRT (TestOptionsWithRanges.java), RBT >>> (hotspot_all,testlist,noncolo.testlist for Windows only) >>> >>> * Added more tests. >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> Thanks, >>>> /Jesper >>>> >>>> >>>> >>>> Den 16/12/15 kl. 01:53, skrev sangheon: >>>>> Hi all, >>>>> >>>>> Could I get a couple of reviews for Windows >>>>> NUMAInterleaveGranularity change? >>>>> >>>>> Current Windows implementation can't handle correctly when we >>>>> reserve a heap >>>>> with disjoint heap base mode with NUMAInterleaveGranularity. >>>>> >>>>> Windows, os::protect_memory fails in above case, as we are trying >>>>> to protect the >>>>> whole reserved heap at one time. But we reserved that area with >>>>> separate/contiguous chunks based on NUMAInterleaveGranularity >>>>> size. MSDN >>>>> describes to call the API separately. >>>>> I changed protect API to be called multiple times if needed. >>>>> >>>>> Skipped adding a test as TestOptionsWithRanges.java is enough. >>>>> 'java -XX:+UseNUMA -XX:+UseNUMAInterleaving' is enough to >>>>> reproduce on large >>>>> memory Windows machine. However we need to specify heap size if >>>>> the machine >>>>> doesn't have large memory. e.g. -Xms30g -Xmx30g >>>>> >>>>> This patch is based on the patch for JDK-8144949 which includes >>>>> the change of >>>>> the max range of NUMAInterleaveGranularity to 2G(32bit), >>>>> 8192G(64bit). >>>>> >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8145000 >>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8145000/webrev.00 >>>>> Testing: JPRT (with TestOptionsWithRanges.java enabled), manual >>>>> tests on Windows >>>>> machine(to test on large memory). >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>> >> > From jon.masamitsu at oracle.com Fri Dec 18 23:20:59 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 18 Dec 2015 15:20:59 -0800 Subject: RFR: JDK-8145442: Add an option to verify remembered sets for G1 In-Reply-To: <567086E1.7080501@oracle.com> References: <567086E1.7080501@oracle.com> Message-ID: <567494DB.1080201@oracle.com> Poonam, Generally looks good. http://cr.openjdk.java.net/~poonam/8145442/webrev.00/src/share/vm/gc/g1/g1CollectedHeap.cpp.frames.html The new GC unified logging implementation has been pushed so you'll need to replace of gclog_or_tty(). > 4060 if (G1VerifyRSetsAfterEvacuationPause) { > 4061 gclog_or_tty->print("[Verifying RSets]"); > 4062 VerifyRegionRSetClosure v_cl; > 4063 heap_region_iterate(&v_cl); > 4064 } Probably with log_debug(gc, verify)("[Verifying RSets]"); http://cr.openjdk.java.net/~poonam/8145442/webrev.00/src/share/vm/gc/g1/heapRegion.hpp.frames.html > 755 void verifyRSet(VerifyOption vo, bool *failures) const; Any comment worth adding for verifyRSet()? Are there conditions on where and when it can be used? In verifyRSet() you always use VerifyOption_G1UsePrevMarking. Will that always be the value for the VerifyOption? If it is always going to be that, does it work to remove the VerifyOption parameter from verifyRSet() and has verifyRSet() always pass VerifyOption_G1UsePrevMarking to VerifyRSetClosure? http://cr.openjdk.java.net/~poonam/8145442/webrev.00/src/share/vm/gc/g1/heapRegion.cpp.frames.html 917 VerifyRSetClosure v_rset_cl(g1, VerifyOption_G1UsePrevMarking); I can see HeapRegionVerifyClosure::verifyRemSets() is used and it works out well but it seems odd for HeapRegionVerifyClosure (which has a name that I read as generally useful with different Verify closures) to have a method that is specific to remembered-set verification. I think it is like this. HeapRegionVerifyClosure had a verifyRemSets() method that is called from do_oop in VerifyRSetClosure and VerifyLiveClosure. Then when you want to do remembered-set verification you use a VerifyRSetClosure and when you want to verify liveness, you use a VerifyLiveClosure and get the remembered-set verfication included in the VerifyLiveClosure. An alternative would be to put verifyRemSets() into VerifyRSetClosure and have a VerifyRSetClosure as part of the VerifyLiveClosure. Then instead of calling verifyRemSets() (as inherited from HeapRegionVerifyClosure) in VerifyLiveClosure, you could call verifyRemSets() using the embedded VerifyRSetClosure. Or you could collapse HeapRegionVerifyClosure and VerifyRSetClosure together (give it the name VerifyRSetClosure so that having a verifyRemSets() seems more natural) and derive VerifyLiveClosure from the new VerifyRSetClosure. Jon On 12/15/2015 1:32 PM, Poonam Bajaj Parhar wrote: > Hello, > > Please review these changes that add a diagnostic VM option > 'G1VerifyRSetsAfterEvacuationPause' that when turned on enables the > verification of Rem Sets of heap regions. > > Bug: JDK-8145442: Add an option to verify remembered sets for G1 > Webrev: http://cr.openjdk.java.net/~poonam/8145442/webrev.00/ > Testing: JPRT, GCBasher > > Thanks, > Poonam > From tom.benson at oracle.com Fri Dec 18 23:39:46 2015 From: tom.benson at oracle.com (Tom Benson) Date: Fri, 18 Dec 2015 18:39:46 -0500 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <567490A3.5020104@oracle.com> References: <5670B5F1.7010505@oracle.com> <56717944.1030402@oracle.com> <56724973.4060405@oracle.com> <5673290E.7080106@oracle.com> <567351E9.40109@oracle.com> <567490A3.5020104@oracle.com> Message-ID: <56749942.10707@oracle.com> Hi Sangheon, On 12/18/2015 6:02 PM, sangheon wrote: > Hi Tom, > > On 12/17/2015 04:23 PM, sangheon wrote: >> Hi Tom, >> >> Thank you for reviewing this! >> >> On 12/17/2015 01:28 PM, Tom Benson wrote: >>> Hi Sangheon, >>> I like the new approach, but just have a couple of comments. >> Thanks. >> >>> >>> I think you should check the VirtualQuery return status and return >>> false from protect_pages_individually if zero. >> Right. >> I will fix this. >> >>> >>> I don't *think* you need to have the "!UseLargePages" restriction >>> anymore with this approach, do you? >> protect_pages_individually() doesn't have previous restriction on its >> usage. >> However I wanted to remain the caller(os::protect_memory) as is >> because, as you already mentioned below, I didn't want to have an >> additional call of VirtualQuery() for simpler code. >> I don't have strong opinion on this. >> >> Let me post next webrev after concluding this. > Tom, do you prefer to always use protect_pages_individually()? > Does anyone have opinion on this? > I'd vote for leaving the UseNUMAInterleaving test in. Tom > Thanks, > Sangheon > > >> >> Thanks, >> Sangheon >> >> >>> >>> Actually, I think you could just always use >>> protect_pages_individually regardless of whether UseNUMAInterleaving >>> was enabled or not, and the right thing would happen. But this way, >>> you save an unnecessary system call plus some overhead. >>> Tom >>> >>> From jon.masamitsu at oracle.com Fri Dec 18 23:44:25 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 18 Dec 2015 15:44:25 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> Message-ID: <56749A59.9060108@oracle.com> Kim, On 12/17/2015 1:30 PM, Kim Barrett wrote: > On Dec 4, 2015, at 1:07 PM, Kim Barrett wrote: >> On Dec 3, 2015, at 6:04 PM, Mandy Chung wrote: >>>> [Indeed, this whole section isn't strictly necessary; all of it can be >>>> inferred from information in other places.] >>> Agree. This section is no longer necessary and maybe just remove it: >> I wasn't actually intending to suggest removal. It seems like there >> is useful overview information to be had here, rather than requiring >> readers to make not necessarily obvious inferences. My impression is >> that readability is valued more highly than terseness in Java >> documentation. > Sorry for the long gap in the discussion. Mandy and I have been > talking about what to do about the "Automatically-cleared references" > section that was the topic of some debate. We've decided to eliminate > it, which led us to some additional modifications. > > Here's the latest set of webrevs: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06/ > http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.06/ The hotspot change is as advertized. Reviewed. Jon > > They've been rebased to hs-rt tip, which required resolving a minor > merge conflict with a nearby change to logging in > referenceProcessor.cpp. Other than that, there are only specification > wording changes. Here's the incremental change from the previous > version: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06.inc/ > > We are treating the discussions around changing PhantomReference to > forbid a null queue as out of scope for this change. As Mandy said > earlier, she might propose a separate change for that in the future. > From fabian.lange at codecentric.de Sun Dec 20 13:27:27 2015 From: fabian.lange at codecentric.de (Fabian Lange) Date: Sun, 20 Dec 2015 14:27:27 +0100 Subject: Fwd: Feedback on G1GC In-Reply-To: References: Message-ID: Hi, (originall posted on adoption-discuss) since a while I have been recommending and using G1GC for JDK 8 applications. This week I was looking at an application which should be the ideal candidate. It was given 4GB ram, has a steady memory usage of about 1-2GB and during its work it generates only garbage. It reads data from sockets, deserializes it, manipulates it, serializes it and writes it out to sockets. It is processing 100k to 500k of such requests per second. With the default G1 settings the machine was very loaded. The collection times were pretty long. It even ran out of memory a few times because the GC could not catch up. When looking at the logs I was surprised to see extremely small eden/young sizes. The old gen was really big (like 3.5GB, but mostly empty) while G1 was churning on 300MB young. I raised the question on https://groups.google.com/a/jclarity.com/d/msg/friends/hsZiz6HTm9M/MbuttBioCgAJ where Charlie Hunt was so kind to explain the reasons behind the behaviour. It either did not make sense to me, or I did not understand the explanation. What I did is what I always did regardless of the collector: I increased young space, knowing it contains mostly garbage. The overall behaviour of the JVM was much improved by that. I found it irritating, that according to Charlie, the main reason for the small eden is the Pause Time Limit. Because GC was not meeting its goal it reduced eden. While I observed better results doing the opposite. I also enabled -XX:+ParallelRefProcEnabled. Logs are available from the above discussion, but I can send them in separate mail if desired. As far as I can tell the ergonomics are not working for me, and the changes I need to do are counter intuitive. From other discussions I learned that quite many people observed better overall performance with raising the pause time restriction. Is there public information to why the current defaults are as they are? How would feedback on these defaults work? Best regards, Fabian -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk at kodewerk.com Sun Dec 20 18:38:07 2015 From: kirk at kodewerk.com (kirk at kodewerk.com) Date: Sun, 20 Dec 2015 18:38:07 +0000 Subject: Feedback on G1GC In-Reply-To: References: Message-ID: Hi Fabian, I don?t think the experimentation with your app is over. I don?t think the differences between the two runs can easily be dismissed as the result of changing the values of a few flags. In the first relatively short run, reference processing times clearly dominated resulting in Eden being shrunk in a feeble attempt to meet the pause time goal. I don?t think that the shrinkage in reference processing time cannot be solely attributed to turning on parallel reference processing. It seems as if something else changed. At any rate, I believe you should relax the minimum Eden size from 25%. I have posted a number of charts which anyone should be able to see @ https://drive.google.com/a/jclarity.com/file/d/0B6IuyTuhCQTPUGpFcDA4bF8zbUk/view?usp=sharing . Regards, Kirk > On Dec 20, 2015, at 1:27 PM, Fabian Lange wrote: > > Hi, > (originall posted on adoption-discuss) > since a while I have been recommending and using G1GC for JDK 8 applications. > > This week I was looking at an application which should be the ideal candidate. > It was given 4GB ram, has a steady memory usage of about 1-2GB and during its work it generates only garbage. It reads data from sockets, deserializes it, manipulates it, serializes it and writes it out to sockets. It is processing 100k to 500k of such requests per second. > > With the default G1 settings the machine was very loaded. The collection times were pretty long. It even ran out of memory a few times because the GC could not catch up. > > When looking at the logs I was surprised to see extremely small eden/young sizes. The old gen was really big (like 3.5GB, but mostly empty) while G1 was churning on 300MB young. > > I raised the question on https://groups.google.com/a/jclarity.com/d/msg/friends/hsZiz6HTm9M/MbuttBioCgAJ where Charlie Hunt was so kind to explain the reasons behind the behaviour. It either did not make sense to me, or I did not understand the explanation. > > What I did is what I always did regardless of the collector: I increased young space, knowing it contains mostly garbage. > The overall behaviour of the JVM was much improved by that. > > I found it irritating, that according to Charlie, the main reason for the small eden is the Pause Time Limit. Because GC was not meeting its goal it reduced eden. While I observed better results doing the opposite. > > I also enabled -XX:+ParallelRefProcEnabled. > > Logs are available from the above discussion, but I can send them in separate mail if desired. > > As far as I can tell the ergonomics are not working for me, and the changes I need to do are counter intuitive. From other discussions I learned that quite many people observed better overall performance with raising the pause time restriction. > > Is there public information to why the current defaults are as they are? How would feedback on these defaults work? > > Best regards, > Fabian > -------------- 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 fabian.lange at codecentric.de Sun Dec 20 19:48:42 2015 From: fabian.lange at codecentric.de (Fabian Lange) Date: Sun, 20 Dec 2015 20:48:42 +0100 Subject: Feedback on G1GC In-Reply-To: References: Message-ID: Hi Kirk, I know that it is questioned also on the other list, where I will continue to discuss potential better settings, but I can tell you that the workload is really reproducible, as this system measures its data ingress and the rate was close to equal. Data egress was radically different. My main concern here on hotspot-gc-dev is that the defaults produced a bad result. Plus I have the feeling the GC optimizes in the wrong direction (shrinking eden instead of increasing eden). I will come back to this list when we manually figured out good settings. Fabian On Sun, Dec 20, 2015 at 7:38 PM, kirk at kodewerk.com wrote: > Hi Fabian, > > I don?t think the experimentation with your app is over. I don?t think the > differences between the two runs can easily be dismissed as the result of > changing the values of a few flags. In the first relatively short run, > reference processing times clearly dominated resulting in Eden being shrunk > in a feeble attempt to meet the pause time goal. I don?t think that the > shrinkage in reference processing time cannot be solely attributed to > turning on parallel reference processing. It seems as if something else > changed. At any rate, I believe you should relax the minimum Eden size from > 25%. I have posted a number of charts which anyone should be able to see @ > https://drive.google.com/a/jclarity.com/file/d/0B6IuyTuhCQTPUGpFcDA4bF8zbUk/view?usp=sharing > . > > Regards, > Kirk > > > On Dec 20, 2015, at 1:27 PM, Fabian Lange > wrote: > > Hi, > (originall posted on adoption-discuss) > since a while I have been recommending and using G1GC for JDK 8 > applications. > > This week I was looking at an application which should be the ideal > candidate. > It was given 4GB ram, has a steady memory usage of about 1-2GB and during > its work it generates only garbage. It reads data from sockets, > deserializes it, manipulates it, serializes it and writes it out to > sockets. It is processing 100k to 500k of such requests per second. > > With the default G1 settings the machine was very loaded. The collection > times were pretty long. It even ran out of memory a few times because the > GC could not catch up. > > When looking at the logs I was surprised to see extremely small eden/young > sizes. The old gen was really big (like 3.5GB, but mostly empty) while G1 > was churning on 300MB young. > > I raised the question on > https://groups.google.com/a/jclarity.com/d/msg/friends/hsZiz6HTm9M/MbuttBioCgAJ > where Charlie Hunt was so kind to explain the reasons behind the behaviour. > It either did not make sense to me, or I did not understand the > explanation. > > What I did is what I always did regardless of the collector: I increased > young space, knowing it contains mostly garbage. > The overall behaviour of the JVM was much improved by that. > > I found it irritating, that according to Charlie, the main reason for the > small eden is the Pause Time Limit. Because GC was not meeting its goal it > reduced eden. While I observed better results doing the opposite. > > I also enabled -XX:+ParallelRefProcEnabled. > > Logs are available from the above discussion, but I can send them in > separate mail if desired. > > As far as I can tell the ergonomics are not working for me, and the > changes I need to do are counter intuitive. From other discussions I > learned that quite many people observed better overall performance with > raising the pause time restriction. > > Is there public information to why the current defaults are as they are? > How would feedback on these defaults work? > > Best regards, > Fabian > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlie.hunt at oracle.com Sun Dec 20 22:43:35 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Sun, 20 Dec 2015 16:43:35 -0600 Subject: Feedback on G1GC In-Reply-To: References: Message-ID: <1D29F348-2D6C-4E68-A9F2-B43E1C7C4540@oracle.com> Hi Fabian, I?m glad you brought this discussion to hotspot-gc-dev. This is a very good place to have this discussion. If others on hotspot-gc-dev need a bit more context of the thread of discussion, I?d be glad to do so. The gist of the issue is whether G1 should reduce the size of eden space when MaxGCPauseMillis is exceeded. To pickup things on where this thread is going ? If the workload is very reproducible, then is it unreasonable to ask for a configuration run that enabled ParallelRefProcEnabled with set of command line options that were used in the first run? How about we exercise some good practices here and change one configuration setting at a time? And, let?s also ensure we have results that are reproducible. We have several unanswered questions between the first and second run, i.e. why did ref proc times drop so drastically, is it all due to ParallelRefProcEnabled? How could a forced larger Eden size allow Ref Proc times to be reduced? Is the workload producing repeatable results / behavior? Aside from the specifics just mentioned, I think the key thing to understand here is the school thought behind shrinking the size of eden when GC pauses exceed MaxGCPauseMillis, and why it is not a good idea to grow the size of Eden in such a case? Perhaps one of the long time GC engineers would like to join the fun? ;-) @Kirk: You mentioned, ?reference processing times clearly dominated resulting in Eden being shrunk in a feeble attempt to meet the pause time goal?. Can you offer some alternatives that would be a better alternative that G1 could do adaptively to meet the pause time goal in the presence of high reference processing times, and for bonus points, could you file those enhancements in JIRA so they can be further evaluated and vetted? thanks, charlie > On Dec 20, 2015, at 1:48 PM, Fabian Lange wrote: > > Hi Kirk, > I know that it is questioned also on the other list, where I will continue to discuss potential better settings, but I can tell you that the workload is really reproducible, as this system measures its data ingress and the rate was close to equal. Data egress was radically different. > My main concern here on hotspot-gc-dev is that the defaults produced a bad result. Plus I have the feeling the GC optimizes in the wrong direction (shrinking eden instead of increasing eden). > I will come back to this list when we manually figured out good settings. > > Fabian > > On Sun, Dec 20, 2015 at 7:38 PM, kirk at kodewerk.com > wrote: > Hi Fabian, > > I don?t think the experimentation with your app is over. I don?t think the differences between the two runs can easily be dismissed as the result of changing the values of a few flags. In the first relatively short run, reference processing times clearly dominated resulting in Eden being shrunk in a feeble attempt to meet the pause time goal. I don?t think that the shrinkage in reference processing time cannot be solely attributed to turning on parallel reference processing. It seems as if something else changed. At any rate, I believe you should relax the minimum Eden size from 25%. I have posted a number of charts which anyone should be able to see @ https://drive.google.com/a/jclarity.com/file/d/0B6IuyTuhCQTPUGpFcDA4bF8zbUk/view?usp=sharing . > > Regards, > Kirk > > >> On Dec 20, 2015, at 1:27 PM, Fabian Lange > wrote: >> >> Hi, >> (originall posted on adoption-discuss) >> since a while I have been recommending and using G1GC for JDK 8 applications. >> >> This week I was looking at an application which should be the ideal candidate. >> It was given 4GB ram, has a steady memory usage of about 1-2GB and during its work it generates only garbage. It reads data from sockets, deserializes it, manipulates it, serializes it and writes it out to sockets. It is processing 100k to 500k of such requests per second. >> >> With the default G1 settings the machine was very loaded. The collection times were pretty long. It even ran out of memory a few times because the GC could not catch up. >> >> When looking at the logs I was surprised to see extremely small eden/young sizes. The old gen was really big (like 3.5GB, but mostly empty) while G1 was churning on 300MB young. >> >> I raised the question on https://groups.google.com/a/jclarity.com/d/msg/friends/hsZiz6HTm9M/MbuttBioCgAJ where Charlie Hunt was so kind to explain the reasons behind the behaviour. It either did not make sense to me, or I did not understand the explanation. >> >> What I did is what I always did regardless of the collector: I increased young space, knowing it contains mostly garbage. >> The overall behaviour of the JVM was much improved by that. >> >> I found it irritating, that according to Charlie, the main reason for the small eden is the Pause Time Limit. Because GC was not meeting its goal it reduced eden. While I observed better results doing the opposite. >> >> I also enabled -XX:+ParallelRefProcEnabled. >> >> Logs are available from the above discussion, but I can send them in separate mail if desired. >> >> As far as I can tell the ergonomics are not working for me, and the changes I need to do are counter intuitive. From other discussions I learned that quite many people observed better overall performance with raising the pause time restriction. >> >> Is there public information to why the current defaults are as they are? How would feedback on these defaults work? >> >> Best regards, >> Fabian >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sangheon.kim at oracle.com Mon Dec 21 06:52:21 2015 From: sangheon.kim at oracle.com (sangheon) Date: Sun, 20 Dec 2015 22:52:21 -0800 Subject: RFR(s): 8144527: NewSizeThreadIncrease would make an overflow Message-ID: <5677A1A5.4000401@oracle.com> Hi all, Can I have reviews for this change to prevent an overflow for NewSizeThreadIncrease? This option is used with non-daemon threads count when calculate new size. And as we can't know the thread count at start-up time, this overflow can't be checked by argument validation framework. Instead I changed related routines to prevent the overflow and when it happens desired new size will be previous size. This will affect only for Serial GC. I added simple test to have 5 threads and then check the log whether we had heap expansion or not. CR: https://bugs.openjdk.java.net/browse/JDK-8144527 Webrev: http://cr.openjdk.java.net/~sangheki/8144527/webrev.00 Testing: JPRT Thanks, Sangheon From kirk at kodewerk.com Mon Dec 21 08:02:30 2015 From: kirk at kodewerk.com (kirk at kodewerk.com) Date: Mon, 21 Dec 2015 08:02:30 +0000 Subject: Feedback on G1GC In-Reply-To: <1D29F348-2D6C-4E68-A9F2-B43E1C7C4540@oracle.com> References: <1D29F348-2D6C-4E68-A9F2-B43E1C7C4540@oracle.com> Message-ID: <1482C8D4-9B8E-4B29-B570-98B55D0028F4@kodewerk.com> Hi Charlie, > > The gist of the issue is whether G1 should reduce the size of eden space when MaxGCPauseMillis is exceeded. > > To pickup things on where this thread is going ? > > If the workload is very reproducible, then is it unreasonable to ask for a configuration run that enabled ParallelRefProcEnabled with set of command line options that were used in the first run? How about we exercise some good practices here and change one configuration setting at a time? Very much agreed here. It seems like a number of things changed which is why I would also like to back-off on all the changes ?cept ParallelRefProcEnabled if this is at all possible. > And, let?s also ensure we have results that are reproducible. We have several unanswered questions between the first and second run, i.e. why did ref proc times drop so drastically, is it all due to ParallelRefProcEnabled? How could a forced larger Eden size allow Ref Proc times to be reduced? Is the workload producing repeatable results / behavior? Completely agree... > > Aside from the specifics just mentioned, I think the key thing to understand here is the school thought behind shrinking the size of eden when GC pauses exceed MaxGCPauseMillis, and why it is not a good idea to grow the size of Eden in such a case? Perhaps one of the long time GC engineers would like to join the fun? ;-) > > @Kirk: You mentioned, ?reference processing times clearly dominated resulting in Eden being shrunk in a feeble attempt to meet the pause time goal?. Can you offer some alternatives that would be a better alternative that G1 could do adaptively to meet the pause time goal in the presence of high reference processing times, and for bonus points, could you file those enhancements in JIRA so they can be further evaluated and vetted? I wish I could but at this point in time I don?t have a good answer. The problem is I simply have too few G1 GC logs from real apps to clearly see the problems. My feeling is that adaptive sizing, as it is currently implemented, doesn?t take into account all of the factors and simply shrinking or growing heap in reaction to meeting or missing a pause time goal maybe too simplistic. Unfortunately, one cannot really generalize the results produce by this app is that there hasn?t been a methodical attempt to understand what is going on. However, what I can say is that quite often if one gets a poor reaction to a tuning strategy, typically one should tune in the opposite direction. So, I would say that in this case taking memory away didn?t work, so the logical reaction is to add memory. This is what was done in this case but many other things seemed to have changed between runs and so we are left trying to discuss inconclusive results. My understanding is that this is a production application and if it?s current performance is acceptable I fear we?re done. I would like to see a run with the min shrinkage percent relaxed but unless someone is willing to take the time and effort to move it to a proper test environment?.. Regards, Kirk -------------- 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 thomas.schatzl at oracle.com Mon Dec 21 11:06:31 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 21 Dec 2015 12:06:31 +0100 Subject: RFR (XS): 8145674: Fix includes and forward declarations in g1Remset files In-Reply-To: References: <1450435704.2496.5.camel@oracle.com> <1450438532.2496.26.camel@oracle.com> <1450448113.9072.7.camel@oracle.com> Message-ID: <1450695991.3214.1.camel@oracle.com> Hi Volker, On Fri, 2015-12-18 at 15:23 +0100, Volker Simonis wrote: > OK, you convinced me :) > > Thumbs up! > thanks to you and Stefan for the reviews. Thomas From thomas.schatzl at oracle.com Mon Dec 21 11:07:33 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 21 Dec 2015 12:07:33 +0100 Subject: RFR (XXS): 8145671: Rename FromCardCache to G1FromCardCache In-Reply-To: <56743EB2.90706@oracle.com> References: <1450435997.2496.10.camel@oracle.com> <56743EB2.90706@oracle.com> Message-ID: <1450696053.3214.2.camel@oracle.com> Hi Jon, Mikael, On Fri, 2015-12-18 at 09:13 -0800, Jon Masamitsu wrote: > Looks good. > > Jon > thanks for the reviews. Thomas From thomas.schatzl at oracle.com Mon Dec 21 11:07:55 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 21 Dec 2015 12:07:55 +0100 Subject: RFR (XS): 8145667: Move FromCardCache into separate files In-Reply-To: <5673F455.4040601@oracle.com> References: <1450435780.2496.7.camel@oracle.com> <5673F13F.4080805@oracle.com> <1450439281.2496.28.camel@oracle.com> <5673F455.4040601@oracle.com> Message-ID: <1450696075.3214.3.camel@oracle.com> Hi Stefan, Mikael, On Fri, 2015-12-18 at 12:56 +0100, Stefan Karlsson wrote: > Looks good. > > StefanK > thanks for the reviews. Thomas From thomas.schatzl at oracle.com Mon Dec 21 11:37:33 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 21 Dec 2015 12:37:33 +0100 Subject: RFR (S): 8145672: Remove dependency of G1FromCardCache to HeapRegionRemSet In-Reply-To: <56744F2D.1040304@oracle.com> References: <1450436572.2496.17.camel@oracle.com> <56744F2D.1040304@oracle.com> Message-ID: <1450697853.3214.10.camel@oracle.com> Hi Jon, thanks for the review. Comments inline. On Fri, 2015-12-18 at 10:23 -0800, Jon Masamitsu wrote: > Thomas, > > A couple of questions about code that are not part of your change (you > can ignore) and a suggestion on expanding a comment. > > http://cr.openjdk.java.net/~tschatzl/8145672/webrev/src/share/vm/gc/g1/g1CollectedHeap.cpp.frames.html > > Not a part of your change but is the guarantee() in the right place? > > > 1936 const uint max_region_idx = (1U << (sizeof(RegionIdx_t)*BitsPerByte-1)) - 1; > > 1937 guarantee((max_regions() - 1) <= max_region_idx, "too many regions"); > > 1938 > > 1939 G1RemSet::init_heap(max_regions()); > Meaning, isn't _max_regions initialized in init_heap() after the > guarantee()? There is no _max_regions, it is derived from G1CollectedHeap::reserved(). Also, the init_heap() you are referring to is G1RemSet::init_heap(). I renamed the method to G1RemSet::initialize(), which is of course more generic and bland, but I hope it avoids this kind of confusion. (I did not want to use after_heap_initialized() or such as I found it even worse). > > http://cr.openjdk.java.net/~tschatzl/8145672/webrev/src/share/vm/gc/g1/g1FromCardCache.cpp.frames.html > > Again, not part of your change but can lines 52 and 53 be lifted out of > the loop at 51? > > > 51 for (uint i = 0; i < G1RemSet::num_par_rem_sets(); i++) { > > 52 uint end_idx = (start_idx + (uint)new_num_regions); > > 53 assert(end_idx <= _max_regions, "Must be within max."); > > 54 for (uint j = start_idx; j < end_idx; j++) { > > 55 set(i, j, InvalidCard); > > 56 } > > 57 } Done. > http://cr.openjdk.java.net/~tschatzl/8145672/webrev/src/share/vm/gc/g1/g1RemSet.hpp.frames.html > > Thank you for adding this comment. > > > 79 // Gives an approximation on how many threads add records to a > > remembered set > > 80 // in parallel for sizing buffers to decrease performance losses > > due to sharing. > > 81 // Examples are mutator threads together with the concurrent > > refinement threads > > 82 // or GC threads. > > 83 static uint num_par_rem_sets(); > > Can you add what kind of buffers to "for sizing ??? buffers"? I changed it to: 78 // Gives an approximation on how many threads can be expected to add records to 79 // a remembered set in parallel. This can be used for sizing data structures to 80 // decrease performance losses due to data structure sharing. 81 // Examples for quantities that influence this value are the maximum number of 82 // mutator threads, maximum number of concurrent refinement or GC threads. I hope this is somewhat better. The current formula may actually be overkill for very large system (like using the processor count in the formula directly). I think it could be scaled down to some degree for "large" systems without performance penalty. However that is different work. > Would this be too specific to the current implementation? Meaning do > you want a more > general descriptions? > > // Examples are the maximum number of mutator threads plus the maximum > number of > // concurrent refinement threads or the maximum number of GC threads, > whichever is > // larger. See above. > > Leave out the "maximum" (in all 3 places if it is understood). > > Otherwise, looks good. > > None of these are critical to the patch (since mostly not part of > your change) so no need to delay your push for any of these. New webrevs at http://cr.openjdk.java.net/~tschatzl/8145672/webrev.1/ (full) http://cr.openjdk.java.net/~tschatzl/8145672/webrev.0_to_1/ (diff) From jesper.wilhelmsson at oracle.com Mon Dec 21 11:40:21 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 21 Dec 2015 12:40:21 +0100 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <56749942.10707@oracle.com> References: <5670B5F1.7010505@oracle.com> <56717944.1030402@oracle.com> <56724973.4060405@oracle.com> <5673290E.7080106@oracle.com> <567351E9.40109@oracle.com> <567490A3.5020104@oracle.com> <56749942.10707@oracle.com> Message-ID: <5677E525.6060609@oracle.com> Hi Sangheon, I like this version a lot better. I have no further comments except for what Tom already mentioned about checking VirtualQuery return value. /Jesper Den 19/12/15 kl. 00:39, skrev Tom Benson: > Hi Sangheon, > > On 12/18/2015 6:02 PM, sangheon wrote: >> Hi Tom, >> >> On 12/17/2015 04:23 PM, sangheon wrote: >>> Hi Tom, >>> >>> Thank you for reviewing this! >>> >>> On 12/17/2015 01:28 PM, Tom Benson wrote: >>>> Hi Sangheon, >>>> I like the new approach, but just have a couple of comments. >>> Thanks. >>> >>>> >>>> I think you should check the VirtualQuery return status and return false >>>> from protect_pages_individually if zero. >>> Right. >>> I will fix this. >>> >>>> >>>> I don't *think* you need to have the "!UseLargePages" restriction anymore >>>> with this approach, do you? >>> protect_pages_individually() doesn't have previous restriction on its usage. >>> However I wanted to remain the caller(os::protect_memory) as is because, as >>> you already mentioned below, I didn't want to have an additional call of >>> VirtualQuery() for simpler code. >>> I don't have strong opinion on this. >>> >>> Let me post next webrev after concluding this. >> Tom, do you prefer to always use protect_pages_individually()? >> Does anyone have opinion on this? >> > > I'd vote for leaving the UseNUMAInterleaving test in. > Tom > >> Thanks, >> Sangheon >> >> >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> Actually, I think you could just always use protect_pages_individually >>>> regardless of whether UseNUMAInterleaving was enabled or not, and the right >>>> thing would happen. But this way, you save an unnecessary system call plus >>>> some overhead. >>>> Tom >>>> >>>> > From mikael.gerdin at oracle.com Mon Dec 21 14:11:18 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 21 Dec 2015 15:11:18 +0100 Subject: RFR: JDK-8145442: Add an option to verify remembered sets for G1 In-Reply-To: <567086E1.7080501@oracle.com> References: <567086E1.7080501@oracle.com> Message-ID: <56780886.1090003@oracle.com> Hi Poonam, On 2015-12-15 22:32, Poonam Bajaj Parhar wrote: > Hello, > > Please review these changes that add a diagnostic VM option > 'G1VerifyRSetsAfterEvacuationPause' that when turned on enables the > verification of Rem Sets of heap regions. > > Bug: JDK-8145442: Add an option to verify remembered sets for G1 > Webrev: http://cr.openjdk.java.net/~poonam/8145442/webrev.00/ I have some general comments on the structure of the code: First of all, I would prefer if we could avoid adding yet another command line flag. I think it would be preferable to either use VerifyRememberedSets which already exists or to use the code you've proposed adding under 8072725 with a "remset" verification subset (and deprecating VerifyRememberedSets). Having RSet verification only post-gc and not before does not appeal to me, since it's quite possible that we can have missing write barriers in compiled code leading to missing remembered set entries as well. Folding this into the VerifyBefore/After code would allow users to select -XX:+VerifyAfterGC -XX:VerifySubSet=remset to get the behavior you are suggesting in this webrev. I like Jon's suggestion of moving all the remset verification to a VerifyRemSetClosure which can be aggregated in the VerifyLiveClosure if full verification is enabled. So, given that I've asked for re-use of the VerifyBefore/After code I would suggest some changes in HeapRegion::verify(VerifyOption vo, bool* failures) to make the code select either the VerifyLiveClosure or the VerifyRemSetClosure depending on the level of verification. The BOT verification near the end of ::verify could be conditionalized on VerifySubSet=bot or something similar. /Mikael > Testing: JPRT, GCBasher > > Thanks, > Poonam > From jesper.wilhelmsson at oracle.com Mon Dec 21 14:35:52 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 21 Dec 2015 15:35:52 +0100 Subject: RFR(s): 8144527: NewSizeThreadIncrease would make an overflow In-Reply-To: <5677A1A5.4000401@oracle.com> References: <5677A1A5.4000401@oracle.com> Message-ID: <56780E48.6030401@oracle.com> Hi Sangheon, Did you consider a simpler approach with only nested ifs instead of the do-while with breaks? At least to me, that would be easier to read. Besides that it looks good. /Jesper Den 21/12/15 kl. 07:52, skrev sangheon: > Hi all, > > Can I have reviews for this change to prevent an overflow for > NewSizeThreadIncrease? > > This option is used with non-daemon threads count when calculate new size. And > as we can't know the thread count at start-up time, this overflow can't be > checked by argument validation framework. Instead I changed related routines to > prevent the overflow and when it happens desired new size will be previous size. > This will affect only for Serial GC. > > I added simple test to have 5 threads and then check the log whether we had heap > expansion or not. > > CR: https://bugs.openjdk.java.net/browse/JDK-8144527 > Webrev: http://cr.openjdk.java.net/~sangheki/8144527/webrev.00 > Testing: JPRT > > Thanks, > Sangheon > > From thomas.schatzl at oracle.com Mon Dec 21 15:01:45 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 21 Dec 2015 16:01:45 +0100 Subject: RFR (S): 8145774: Move scrubbing setup code away out of ConcurrentMark Message-ID: <1450710105.3214.46.camel@oracle.com> Hi all, can I have reviews for this change that moves setup and parallelization detail code for the remset scrubbing code out of ConcurrentMark into G1CollectedHeap? This way, ConcurrentMark does not need a direct reference to G1RemSet and HeapRegionManager any more, and anyway, I think setting up the gangtask by determining the number of threads to use is better suited to be placed into G1CollectedHeap. CR: https://bugs.openjdk.java.net/browse/JDK-8145774 Webrev: http://cr.openjdk.java.net/~tschatzl/8145774/webrev/ Testing: jprt Thanks, Thomas From sky1young at gmail.com Mon Dec 21 15:09:02 2015 From: sky1young at gmail.com (ray alex) Date: Mon, 21 Dec 2015 23:09:02 +0800 Subject: [PATCH] enhancement to ParallelScavenge Full GC In-Reply-To: <56703CA3.9050605@oracle.com> References: <1450104486.2316.46.camel@oracle.com> <1450111786.11162.34.camel@oracle.com> <56703CA3.9050605@oracle.com> Message-ID: Hi Thomas, Mikael, I've refined the code based on your recommendations on the code style. However, in my opinion, to provide an additional context in GCThread instead of Thread may lead to massive modifications and I'm not sure if it may bring some impact on the correctness of other codes. So I have not revised this part so far, in order to keep our patch pure and independent. (Or maybe it's because I did not quite catch your ideas?) May I have your reviews on the new patch? 2015-12-16 0:15 GMT+08:00 Mikael Gerdin : > Hi, > > > On 2015-12-14 17:49, Thomas Schatzl wrote: > >> Hi, >> >> On Mon, 2015-12-14 at 23:57 +0800, ray alex wrote: >> >>> Thanks, Thomas! >>> >>> I will refine my code carefully according to your suggestions as soon >>> as possible. >>> >> >> Thanks. >> >>> >>> Since I'm new in contributing to OpenJDK, actually I'm not sure how to >>> upload when my new code is ready? >>> Just upload an attach of diffs as I did, or some other ways? >>> >> >> The best way as long as we have no confirmation about the OCA signing, >> is to attach a patch (or a webrev, see >> http://openjdk.java.net/contribute/) and send it to this list. Later it >> will be more convenient to send me a patch that I will convert into a >> webrev and put on cr.openjdk.java.net. >> >> As soon as you have two contributions, you can upload patches yourselves >> onto your own account on cr.openjdk.java.net. >> >>> >>> Besides, I'm currently processing my signed OCA for the committer >>> rights, >>> I'm not sure how long it will take, does it matter? >>> >> >> The OCA is only for us to be able to accept your patch in Hotspot. The >> various levels of contributor status are a different matter, and signify >> your level of expertise within the community. >> >> See also http://openjdk.java.net/contribute/ for more information. >> >> As for the VM Thread, it does a serial adjust_roots() within the >>> current thread (VM thread) during >>> PSParallelCompact::invoke_no_policy(). >>> I think psCompactionManager.cpp:117 and the surrounding comments >>> confirm the use of VMThread in full GC. >>> Do you agree with my above understanding of the use of VMThread? >>> >>> You are right :( >> >> There are multiple options to provide an additional per-thread context: >> >> - passing around some context. Looks like lots of work. >> > > I actually think this is the correct way to go. > In my mind you would only have to change > ParCompactionMangager::update_contents to pass on the ParCompactionManager* > through oopDesc::pc_update_contents to *Klass::oop_pc_update_contents > It's similar to how the marking phase passes around the current worker's > compaction manager. > > Then the AdjustPointerClosure needs to become a per-ParCompactionManager > thing and then it's all set :) > > /Mikael > > > > - change the code so that even that serial portion is performed by some >> GCTaskThread (which actually sounds best to me) >> - Another would be to add a field to both GCTaskThread and VMThread, and >> via a virtual method in Thread get the necessary values. >> - make VMThread a WorkerThread (that has an id that can be used to query >> an extra data structure for this cache) >> - others >> >> Let's see if other people have a better idea. >> >> Thanks, >> Thomas >> >> >> >> > -- Lei Tianyang -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: parallelScavenge_v2.patch Type: text/x-patch Size: 5846 bytes Desc: not available URL: From mikael.gerdin at oracle.com Mon Dec 21 15:34:04 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 21 Dec 2015 16:34:04 +0100 Subject: [PATCH] enhancement to ParallelScavenge Full GC In-Reply-To: References: <1450104486.2316.46.camel@oracle.com> <1450111786.11162.34.camel@oracle.com> <56703CA3.9050605@oracle.com> Message-ID: <56781BEC.7030404@oracle.com> Hi, On 2015-12-21 16:09, ray alex wrote: > Hi Thomas, Mikael, > > I've refined the code based on your recommendations on the code style. > > However, in my opinion, to provide an additional context in GCThread instead of Thread may lead to massive modifications > > and I'm not sure if it may bring some impact on the correctness of other codes. > So I have not revised this part so far, in order to keep our patch pure and independent. > (Or maybe it's because I did not quite catch your ideas?) > > May I have your reviews on the new patch? It may be that your patch works, but one of the issues with working with such a large code base as this is to not just make changes which are functionally correct, but they also need to "fit in" and make sense with how the rest of the code works. Putting 3 member variables in the Thread superclass just because a small phase of one of the garbage collectors needs some thread local state does not "fit in". In HotSpot, all the garbage collectors maintain their thread-local state by passing explicit context parameters. I think that the only solution which makes sense for the fix to ParallelCompact is to modify ParCompactionManager::update_contents(oop obj) to pass itself like this: obj->pc_update_contents(this); and modifying oopDesc::pc_update_contents(ParCompactionManager* cm) to pass it on: k->oop_pc_update_pointers(this, cm); and modify all Klass subclasses to use the new parameter such as void InstanceKlass::oop_pc_update_pointers(oop obj, ParCompactionManager* cm) { PSParallelCompact::AdjustPointerClosre closure(cm); oop_oop_iterate_oop_maps(obj, &cm); } That way the call oop new_obj = (oop)summary_data().calc_new_pointer(obj); in AdjustPointerClosure can pass the "cm" parameter on to live_words_in_range. /Mikael > > > > 2015-12-16 0:15 GMT+08:00 Mikael Gerdin >: > > Hi, > > > On 2015-12-14 17:49, Thomas Schatzl wrote: > > Hi, > > On Mon, 2015-12-14 at 23:57 +0800, ray alex wrote: > > Thanks, Thomas! > > I will refine my code carefully according to your > suggestions as soon > as possible. > > > Thanks. > > > Since I'm new in contributing to OpenJDK, actually I'm not > sure how to > upload when my new code is ready? > Just upload an attach of diffs as I did, or some other ways? > > > The best way as long as we have no confirmation about the OCA > signing, > is to attach a patch (or a webrev, see > http://openjdk.java.net/contribute/) and send it to this list. > Later it > will be more convenient to send me a patch that I will convert > into a > webrev and put on cr.openjdk.java.net . > > As soon as you have two contributions, you can upload patches > yourselves > onto your own account on cr.openjdk.java.net > . > > > Besides, I'm currently processing my signed OCA for the > committer > rights, > I'm not sure how long it will take, does it matter? > > > The OCA is only for us to be able to accept your patch in > Hotspot. The > various levels of contributor status are a different matter, and > signify > your level of expertise within the community. > > See also http://openjdk.java.net/contribute/ for more information. > > As for the VM Thread, it does a serial adjust_roots() within the > current thread (VM thread) during > PSParallelCompact::invoke_no_policy(). > I think psCompactionManager.cpp:117 and the surrounding > comments > confirm the use of VMThread in full GC. > Do you agree with my above understanding of the use of VMThread? > > You are right :( > > There are multiple options to provide an additional per-thread > context: > > - passing around some context. Looks like lots of work. > > > I actually think this is the correct way to go. > In my mind you would only have to change > ParCompactionMangager::update_contents to pass on the > ParCompactionManager* through oopDesc::pc_update_contents to > *Klass::oop_pc_update_contents > It's similar to how the marking phase passes around the current > worker's compaction manager. > > Then the AdjustPointerClosure needs to become a > per-ParCompactionManager thing and then it's all set :) > > /Mikael > > > > - change the code so that even that serial portion is performed > by some > GCTaskThread (which actually sounds best to me) > - Another would be to add a field to both GCTaskThread and > VMThread, and > via a virtual method in Thread get the necessary values. > - make VMThread a WorkerThread (that has an id that can be used > to query > an extra data structure for this cache) > - others > > Let's see if other people have a better idea. > > Thanks, > Thomas > > > > > > > > -- > Lei Tianyang > From mikael.gerdin at oracle.com Mon Dec 21 15:39:43 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 21 Dec 2015 16:39:43 +0100 Subject: RFR (S): 8145774: Move scrubbing setup code away out of ConcurrentMark In-Reply-To: <1450710105.3214.46.camel@oracle.com> References: <1450710105.3214.46.camel@oracle.com> Message-ID: <56781D3F.3090809@oracle.com> Hi, On 2015-12-21 16:01, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that moves setup and > parallelization detail code for the remset scrubbing code out of > ConcurrentMark into G1CollectedHeap? > > This way, ConcurrentMark does not need a direct reference to G1RemSet > and HeapRegionManager any more, and anyway, I think setting up the > gangtask by determining the number of threads to use is better suited to > be placed into G1CollectedHeap. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8145774 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8145774/webrev/ I had a short discussion with Thomas about this with regard to further enhancements but we decided that this change in itself is good to integrate regardless of that. It's nice to break down some dependencies between the different G1 components. /Mikael > Testing: > jprt > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Mon Dec 21 16:21:56 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 21 Dec 2015 17:21:56 +0100 Subject: RFR (S): 8145774: Move scrubbing setup code away out of ConcurrentMark In-Reply-To: <56781D3F.3090809@oracle.com> References: <1450710105.3214.46.camel@oracle.com> <56781D3F.3090809@oracle.com> Message-ID: <1450714916.3214.50.camel@oracle.com> Hi, On Mon, 2015-12-21 at 16:39 +0100, Mikael Gerdin wrote: > Hi, > > On 2015-12-21 16:01, Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for this change that moves setup and > > parallelization detail code for the remset scrubbing code out of > > ConcurrentMark into G1CollectedHeap? > > > > This way, ConcurrentMark does not need a direct reference to G1RemSet > > and HeapRegionManager any more, and anyway, I think setting up the > > gangtask by determining the number of threads to use is better suited to > > be placed into G1CollectedHeap. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8145774 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8145774/webrev/ > > I had a short discussion with Thomas about this with regard to further > enhancements but we decided that this change in itself is good to > integrate regardless of that. > It's nice to break down some dependencies between the different G1 > components. thanks for the review. Fyi, one of the suggested enhancements has been filed in https://bugs.openjdk.java.net/browse/JDK-8145911. As mentioned in the initial RFR, the main idea for this change is to remove some dependencies of the ConcurrentMark class. Thanks, Thomas From sangheon.kim at oracle.com Mon Dec 21 17:48:14 2015 From: sangheon.kim at oracle.com (sangheon) Date: Mon, 21 Dec 2015 09:48:14 -0800 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <5677E525.6060609@oracle.com> References: <5670B5F1.7010505@oracle.com> <56717944.1030402@oracle.com> <56724973.4060405@oracle.com> <5673290E.7080106@oracle.com> <567351E9.40109@oracle.com> <567490A3.5020104@oracle.com> <56749942.10707@oracle.com> <5677E525.6060609@oracle.com> Message-ID: <56783B5E.2060001@oracle.com> Hi Jesper and Tom, Here's next webrev which includes below: - Check return value of VirtualQuery. (Tom, Jesper) - Always call protect_pages_individually() from os::protect_memory(). (Tom) Webrev: http://cr.openjdk.java.net/~sangheki/8145000/webrev.02 http://cr.openjdk.java.net/~sangheki/8145000/webrev.02_to_01/ Test: JPRT, RBT (hotspot/test/:hotspot_all,testlist,noncolo.testlist --add-tonga-keyword quick for Windows only) Thanks, Sangheon On 12/21/2015 03:40 AM, Jesper Wilhelmsson wrote: > Hi Sangheon, > > I like this version a lot better. > I have no further comments except for what Tom already mentioned about > checking VirtualQuery return value. > /Jesper > > > Den 19/12/15 kl. 00:39, skrev Tom Benson: >> Hi Sangheon, >> >> On 12/18/2015 6:02 PM, sangheon wrote: >>> Hi Tom, >>> >>> On 12/17/2015 04:23 PM, sangheon wrote: >>>> Hi Tom, >>>> >>>> Thank you for reviewing this! >>>> >>>> On 12/17/2015 01:28 PM, Tom Benson wrote: >>>>> Hi Sangheon, >>>>> I like the new approach, but just have a couple of comments. >>>> Thanks. >>>> >>>>> >>>>> I think you should check the VirtualQuery return status and return >>>>> false >>>>> from protect_pages_individually if zero. >>>> Right. >>>> I will fix this. >>>> >>>>> >>>>> I don't *think* you need to have the "!UseLargePages" restriction >>>>> anymore >>>>> with this approach, do you? >>>> protect_pages_individually() doesn't have previous restriction on >>>> its usage. >>>> However I wanted to remain the caller(os::protect_memory) as is >>>> because, as >>>> you already mentioned below, I didn't want to have an additional >>>> call of >>>> VirtualQuery() for simpler code. >>>> I don't have strong opinion on this. >>>> >>>> Let me post next webrev after concluding this. >>> Tom, do you prefer to always use protect_pages_individually()? >>> Does anyone have opinion on this? >>> >> >> I'd vote for leaving the UseNUMAInterleaving test in. >> Tom >> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> Actually, I think you could just always use >>>>> protect_pages_individually >>>>> regardless of whether UseNUMAInterleaving was enabled or not, and >>>>> the right >>>>> thing would happen. But this way, you save an unnecessary system >>>>> call plus >>>>> some overhead. >>>>> Tom >>>>> >>>>> >> From jesper.wilhelmsson at oracle.com Mon Dec 21 18:57:46 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 21 Dec 2015 19:57:46 +0100 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <56783B5E.2060001@oracle.com> References: <5670B5F1.7010505@oracle.com> <56717944.1030402@oracle.com> <56724973.4060405@oracle.com> <5673290E.7080106@oracle.com> <567351E9.40109@oracle.com> <567490A3.5020104@oracle.com> <56749942.10707@oracle.com> <5677E525.6060609@oracle.com> <56783B5E.2060001@oracle.com> Message-ID: <56784BAA.4070106@oracle.com> Hi Sangheon, I was under the impression that Tom wanted to keep the UseNUMAInterleaving test and not always call protect_pages_individually(). At least that's what I would prefer. If you revert that change I think we have something here :) /Jesper Den 21/12/15 kl. 18:48, skrev sangheon: > Hi Jesper and Tom, > > Here's next webrev which includes below: > - Check return value of VirtualQuery. (Tom, Jesper) > - Always call protect_pages_individually() from os::protect_memory(). (Tom) > > Webrev: > http://cr.openjdk.java.net/~sangheki/8145000/webrev.02 > http://cr.openjdk.java.net/~sangheki/8145000/webrev.02_to_01/ > > Test: > JPRT, RBT (hotspot/test/:hotspot_all,testlist,noncolo.testlist > --add-tonga-keyword quick for Windows only) > > Thanks, > Sangheon > > > On 12/21/2015 03:40 AM, Jesper Wilhelmsson wrote: >> Hi Sangheon, >> >> I like this version a lot better. >> I have no further comments except for what Tom already mentioned about >> checking VirtualQuery return value. >> /Jesper >> >> >> Den 19/12/15 kl. 00:39, skrev Tom Benson: >>> Hi Sangheon, >>> >>> On 12/18/2015 6:02 PM, sangheon wrote: >>>> Hi Tom, >>>> >>>> On 12/17/2015 04:23 PM, sangheon wrote: >>>>> Hi Tom, >>>>> >>>>> Thank you for reviewing this! >>>>> >>>>> On 12/17/2015 01:28 PM, Tom Benson wrote: >>>>>> Hi Sangheon, >>>>>> I like the new approach, but just have a couple of comments. >>>>> Thanks. >>>>> >>>>>> >>>>>> I think you should check the VirtualQuery return status and return false >>>>>> from protect_pages_individually if zero. >>>>> Right. >>>>> I will fix this. >>>>> >>>>>> >>>>>> I don't *think* you need to have the "!UseLargePages" restriction anymore >>>>>> with this approach, do you? >>>>> protect_pages_individually() doesn't have previous restriction on its usage. >>>>> However I wanted to remain the caller(os::protect_memory) as is because, as >>>>> you already mentioned below, I didn't want to have an additional call of >>>>> VirtualQuery() for simpler code. >>>>> I don't have strong opinion on this. >>>>> >>>>> Let me post next webrev after concluding this. >>>> Tom, do you prefer to always use protect_pages_individually()? >>>> Does anyone have opinion on this? >>>> >>> >>> I'd vote for leaving the UseNUMAInterleaving test in. >>> Tom >>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>>> >>>>>> Actually, I think you could just always use protect_pages_individually >>>>>> regardless of whether UseNUMAInterleaving was enabled or not, and the right >>>>>> thing would happen. But this way, you save an unnecessary system call plus >>>>>> some overhead. >>>>>> Tom >>>>>> >>>>>> >>> > From tom.benson at oracle.com Mon Dec 21 19:19:23 2015 From: tom.benson at oracle.com (Tom Benson) Date: Mon, 21 Dec 2015 14:19:23 -0500 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <56784BAA.4070106@oracle.com> References: <5670B5F1.7010505@oracle.com> <56717944.1030402@oracle.com> <56724973.4060405@oracle.com> <5673290E.7080106@oracle.com> <567351E9.40109@oracle.com> <567490A3.5020104@oracle.com> <56749942.10707@oracle.com> <5677E525.6060609@oracle.com> <56783B5E.2060001@oracle.com> <56784BAA.4070106@oracle.com> Message-ID: <567850BB.5070002@oracle.com> Hi, On 12/21/2015 1:57 PM, Jesper Wilhelmsson wrote: > Hi Sangheon, > > I was under the impression that Tom wanted to keep the > UseNUMAInterleaving test and not always call > protect_pages_individually(). Yes, I'd said that was my vote, but wasn't adamant about it. If we agree, let's keep it. 8^) Tom > At least that's what I would prefer. If you revert that change I think > we have something here :) > /Jesper > > > Den 21/12/15 kl. 18:48, skrev sangheon: >> Hi Jesper and Tom, >> >> Here's next webrev which includes below: >> - Check return value of VirtualQuery. (Tom, Jesper) >> - Always call protect_pages_individually() from os::protect_memory(). >> (Tom) >> >> Webrev: >> http://cr.openjdk.java.net/~sangheki/8145000/webrev.02 >> http://cr.openjdk.java.net/~sangheki/8145000/webrev.02_to_01/ >> >> Test: >> JPRT, RBT (hotspot/test/:hotspot_all,testlist,noncolo.testlist >> --add-tonga-keyword quick for Windows only) >> >> Thanks, >> Sangheon >> >> >> On 12/21/2015 03:40 AM, Jesper Wilhelmsson wrote: >>> Hi Sangheon, >>> >>> I like this version a lot better. >>> I have no further comments except for what Tom already mentioned about >>> checking VirtualQuery return value. >>> /Jesper >>> >>> >>> Den 19/12/15 kl. 00:39, skrev Tom Benson: >>>> Hi Sangheon, >>>> >>>> On 12/18/2015 6:02 PM, sangheon wrote: >>>>> Hi Tom, >>>>> >>>>> On 12/17/2015 04:23 PM, sangheon wrote: >>>>>> Hi Tom, >>>>>> >>>>>> Thank you for reviewing this! >>>>>> >>>>>> On 12/17/2015 01:28 PM, Tom Benson wrote: >>>>>>> Hi Sangheon, >>>>>>> I like the new approach, but just have a couple of comments. >>>>>> Thanks. >>>>>> >>>>>>> >>>>>>> I think you should check the VirtualQuery return status and >>>>>>> return false >>>>>>> from protect_pages_individually if zero. >>>>>> Right. >>>>>> I will fix this. >>>>>> >>>>>>> >>>>>>> I don't *think* you need to have the "!UseLargePages" >>>>>>> restriction anymore >>>>>>> with this approach, do you? >>>>>> protect_pages_individually() doesn't have previous restriction on >>>>>> its usage. >>>>>> However I wanted to remain the caller(os::protect_memory) as is >>>>>> because, as >>>>>> you already mentioned below, I didn't want to have an additional >>>>>> call of >>>>>> VirtualQuery() for simpler code. >>>>>> I don't have strong opinion on this. >>>>>> >>>>>> Let me post next webrev after concluding this. >>>>> Tom, do you prefer to always use protect_pages_individually()? >>>>> Does anyone have opinion on this? >>>>> >>>> >>>> I'd vote for leaving the UseNUMAInterleaving test in. >>>> Tom >>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>>> >>>>>>> Actually, I think you could just always use >>>>>>> protect_pages_individually >>>>>>> regardless of whether UseNUMAInterleaving was enabled or not, >>>>>>> and the right >>>>>>> thing would happen. But this way, you save an unnecessary >>>>>>> system call plus >>>>>>> some overhead. >>>>>>> Tom >>>>>>> >>>>>>> >>>> >> From sangheon.kim at oracle.com Mon Dec 21 20:24:49 2015 From: sangheon.kim at oracle.com (sangheon) Date: Mon, 21 Dec 2015 12:24:49 -0800 Subject: RFR(s): 8144527: NewSizeThreadIncrease would make an overflow In-Reply-To: <56780E48.6030401@oracle.com> References: <5677A1A5.4000401@oracle.com> <56780E48.6030401@oracle.com> Message-ID: <56786011.1040804@oracle.com> Hi Jesper, Thank you for looking at this. On 12/21/2015 06:35 AM, Jesper Wilhelmsson wrote: > Hi Sangheon, > > Did you consider a simpler approach with only nested ifs instead of > the do-while with breaks? At least to me, that would be easier to read. You are right. Here's updated webrev. http://cr.openjdk.java.net/~sangheki/8144527/webrev.01 Thanks, Sangheon > > Besides that it looks good. > /Jesper > > > Den 21/12/15 kl. 07:52, skrev sangheon: >> Hi all, >> >> Can I have reviews for this change to prevent an overflow for >> NewSizeThreadIncrease? >> >> This option is used with non-daemon threads count when calculate new >> size. And >> as we can't know the thread count at start-up time, this overflow >> can't be >> checked by argument validation framework. Instead I changed related >> routines to >> prevent the overflow and when it happens desired new size will be >> previous size. >> This will affect only for Serial GC. >> >> I added simple test to have 5 threads and then check the log whether >> we had heap >> expansion or not. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8144527 >> Webrev: http://cr.openjdk.java.net/~sangheki/8144527/webrev.00 >> Testing: JPRT >> >> Thanks, >> Sangheon >> >> From yu.zhang at oracle.com Mon Dec 21 20:40:32 2015 From: yu.zhang at oracle.com (Yu Zhang) Date: Mon, 21 Dec 2015 12:40:32 -0800 Subject: Fwd: Feedback on G1GC In-Reply-To: References: Message-ID: <567863C0.8060805@oracle.com> Fabian, I am late to the party, still trying to figure out what is the issue. From what I can follow the from https://groups.google.com/a/jclarity.com/forum/#!msg/friends/hsZiz6HTm9M/MbuttBioCgAJ, the original complain is Ref Proc time is very long, and after you added ParallelRefProcEnabled and (maybe) other flags, it is better? I tried to look at the log gc.log.gz https://groups.google.com/a/jclarity.com/group/friends/attach/b13fb0b7fedd4/gc.log.gz?part=0.1&authuser=0&view=1 In that log, -XX:+ParallelRefProcEnabled and refproc seems ok. -XX:MaxHeapSize=4294967296, but the actual heap size is 1588m. G1 might not expand the heap aggressively. You can try to run with fixed Xms Xmx values. As for tenure distribution, yes, most of the objects(5-7m) die young, but about 2m objects do not die, can live up to age 12-15, and get promoted. Though the old gen usage does not increase after mixed gc, it is hard to tell if the mixed gc cleaned those objects, or did compaction. Maybe with -Xms=4g -Xmx=4g, the Eden size will increase, so is the survivor size, but those 2m objects still get promoted. I think we need more experiments to see if the ergonomic is doing the right thing. Thanks, Jenny On 12/20/2015 5:27 AM, Fabian Lange wrote: > Hi, > (originall posted on adoption-discuss) > since a while I have been recommending and using G1GC for JDK 8 > applications. > > This week I was looking at an application which should be the ideal > candidate. > It was given 4GB ram, has a steady memory usage of about 1-2GB and > during its work it generates only garbage. It reads data from sockets, > deserializes it, manipulates it, serializes it and writes it out to > sockets. It is processing 100k to 500k of such requests per second. > > With the default G1 settings the machine was very loaded. The > collection times were pretty long. It even ran out of memory a few > times because the GC could not catch up. > > When looking at the logs I was surprised to see extremely small > eden/young sizes. The old gen was really big (like 3.5GB, but mostly > empty) while G1 was churning on 300MB young. > > I raised the question on > https://groups.google.com/a/jclarity.com/d/msg/friends/hsZiz6HTm9M/MbuttBioCgAJ > where Charlie Hunt was so kind to explain the reasons behind the > behaviour. It either did not make sense to me, or I did not understand > the explanation. > > What I did is what I always did regardless of the collector: I > increased young space, knowing it contains mostly garbage. > The overall behaviour of the JVM was much improved by that. > > I found it irritating, that according to Charlie, the main reason for > the small eden is the Pause Time Limit. Because GC was not meeting its > goal it reduced eden. While I observed better results doing the opposite. > > I also enabled -XX:+ParallelRefProcEnabled. > > Logs are available from the above discussion, but I can send them in > separate mail if desired. > > As far as I can tell the ergonomics are not working for me, and the > changes I need to do are counter intuitive. From other discussions I > learned that quite many people observed better overall performance > with raising the pause time restriction. > > Is there public information to why the current defaults are as they > are? How would feedback on these defaults work? > > Best regards, > Fabian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Mon Dec 21 21:22:13 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 21 Dec 2015 13:22:13 -0800 Subject: RFR (S): 8145672: Remove dependency of G1FromCardCache to HeapRegionRemSet In-Reply-To: <1450697853.3214.10.camel@oracle.com> References: <1450436572.2496.17.camel@oracle.com> <56744F2D.1040304@oracle.com> <1450697853.3214.10.camel@oracle.com> Message-ID: <56786D85.7010707@oracle.com> On 12/21/2015 03:37 AM, Thomas Schatzl wrote: > Hi Jon, > > thanks for the review. > > Comments inline. > > On Fri, 2015-12-18 at 10:23 -0800, Jon Masamitsu wrote: >> Thomas, >> >> A couple of questions about code that are not part of your change (you >> can ignore) and a suggestion on expanding a comment. >> >> http://cr.openjdk.java.net/~tschatzl/8145672/webrev/src/share/vm/gc/g1/g1CollectedHeap.cpp.frames.html >> >> Not a part of your change but is the guarantee() in the right place? >> >>> 1936 const uint max_region_idx = (1U << (sizeof(RegionIdx_t)*BitsPerByte-1)) - 1; >>> 1937 guarantee((max_regions() - 1) <= max_region_idx, "too many regions"); >>> 1938 >>> 1939 G1RemSet::init_heap(max_regions()); >> Meaning, isn't _max_regions initialized in init_heap() after the >> guarantee()? > There is no _max_regions, it is derived from > G1CollectedHeap::reserved(). Also, the init_heap() you are referring to > is G1RemSet::init_heap(). > > I renamed the method to G1RemSet::initialize(), which is of course more > generic and bland, but I hope it avoids this kind of confusion. (I did > not want to use after_heap_initialized() or such as I found it even > worse). Ok. >> http://cr.openjdk.java.net/~tschatzl/8145672/webrev/src/share/vm/gc/g1/g1FromCardCache.cpp.frames.html >> >> Again, not part of your change but can lines 52 and 53 be lifted out of >> the loop at 51? >> >>> 51 for (uint i = 0; i < G1RemSet::num_par_rem_sets(); i++) { >>> 52 uint end_idx = (start_idx + (uint)new_num_regions); >>> 53 assert(end_idx <= _max_regions, "Must be within max."); >>> 54 for (uint j = start_idx; j < end_idx; j++) { >>> 55 set(i, j, InvalidCard); >>> 56 } >>> 57 } > Done. > >> http://cr.openjdk.java.net/~tschatzl/8145672/webrev/src/share/vm/gc/g1/g1RemSet.hpp.frames.html >> >> Thank you for adding this comment. >> >>> 79 // Gives an approximation on how many threads add records to a >>> remembered set >>> 80 // in parallel for sizing buffers to decrease performance losses >>> due to sharing. >>> 81 // Examples are mutator threads together with the concurrent >>> refinement threads >>> 82 // or GC threads. >>> 83 static uint num_par_rem_sets(); >> Can you add what kind of buffers to "for sizing ??? buffers"? > I changed it to: > > 78 // Gives an approximation on how many threads can be expected to > add records to > 79 // a remembered set in parallel. This can be used for sizing data structures to > 80 // decrease performance losses due to data structure sharing. > 81 // Examples for quantities that influence this value are the maximum number of > 82 // mutator threads, maximum number of concurrent refinement or GC threads. > > I hope this is somewhat better. Thanks. > > The current formula may actually be overkill for very large system (like > using the processor count in the formula directly). I think it could be > scaled down to some degree for "large" systems without performance > penalty. However that is different work. > >> Would this be too specific to the current implementation? Meaning do >> you want a more >> general descriptions? >> >> // Examples are the maximum number of mutator threads plus the maximum >> number of >> // concurrent refinement threads or the maximum number of GC threads, >> whichever is >> // larger. > See above. > >> Leave out the "maximum" (in all 3 places if it is understood). >> >> Otherwise, looks good. >> >> None of these are critical to the patch (since mostly not part of >> your change) so no need to delay your push for any of these. > New webrevs at > http://cr.openjdk.java.net/~tschatzl/8145672/webrev.1/ (full) > http://cr.openjdk.java.net/~tschatzl/8145672/webrev.0_to_1/ (diff) > http://cr.openjdk.java.net/~tschatzl/8145672/webrev.0_to_1/src/share/vm/gc/g1/g1RemSet.hpp.udiff.html This doesn't quite sound right. + // Initialize data that depends on that the heap size is known. Maybe // Initialize data that depends on the heap size being known. I don't need a new webrev. Jon From sangheon.kim at oracle.com Mon Dec 21 21:43:26 2015 From: sangheon.kim at oracle.com (sangheon) Date: Mon, 21 Dec 2015 13:43:26 -0800 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <567850BB.5070002@oracle.com> References: <5670B5F1.7010505@oracle.com> <56717944.1030402@oracle.com> <56724973.4060405@oracle.com> <5673290E.7080106@oracle.com> <567351E9.40109@oracle.com> <567490A3.5020104@oracle.com> <56749942.10707@oracle.com> <5677E525.6060609@oracle.com> <56783B5E.2060001@oracle.com> <56784BAA.4070106@oracle.com> <567850BB.5070002@oracle.com> Message-ID: <5678727E.3040005@oracle.com> Hi all, Tom and I did some discussion(previously I misunderstood Tom's comment) and here's the next webrev which includes: 1. Call protect_pages_individually() when UseNUMAInterleaving is enabled (Tom) 2. Added a comment why we need to call protect_pages_individually(). (Tom) 3. Changed VirtualQuery() handling code. (Tom) http://cr.openjdk.java.net/~sangheki/8145000/webrev.03 http://cr.openjdk.java.net/~sangheki/8145000/webrev.03_to_02 Thanks, Sangheon On 12/21/2015 11:19 AM, Tom Benson wrote: > Hi, > > On 12/21/2015 1:57 PM, Jesper Wilhelmsson wrote: >> Hi Sangheon, >> >> I was under the impression that Tom wanted to keep the >> UseNUMAInterleaving test and not always call >> protect_pages_individually(). > > Yes, I'd said that was my vote, but wasn't adamant about it. If we > agree, let's keep it. 8^) > Tom > >> At least that's what I would prefer. If you revert that change I >> think we have something here :) >> /Jesper >> >> >> Den 21/12/15 kl. 18:48, skrev sangheon: >>> Hi Jesper and Tom, >>> >>> Here's next webrev which includes below: >>> - Check return value of VirtualQuery. (Tom, Jesper) >>> - Always call protect_pages_individually() from >>> os::protect_memory(). (Tom) >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.02 >>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.02_to_01/ >>> >>> Test: >>> JPRT, RBT (hotspot/test/:hotspot_all,testlist,noncolo.testlist >>> --add-tonga-keyword quick for Windows only) >>> >>> Thanks, >>> Sangheon >>> >>> >>> On 12/21/2015 03:40 AM, Jesper Wilhelmsson wrote: >>>> Hi Sangheon, >>>> >>>> I like this version a lot better. >>>> I have no further comments except for what Tom already mentioned about >>>> checking VirtualQuery return value. >>>> /Jesper >>>> >>>> >>>> Den 19/12/15 kl. 00:39, skrev Tom Benson: >>>>> Hi Sangheon, >>>>> >>>>> On 12/18/2015 6:02 PM, sangheon wrote: >>>>>> Hi Tom, >>>>>> >>>>>> On 12/17/2015 04:23 PM, sangheon wrote: >>>>>>> Hi Tom, >>>>>>> >>>>>>> Thank you for reviewing this! >>>>>>> >>>>>>> On 12/17/2015 01:28 PM, Tom Benson wrote: >>>>>>>> Hi Sangheon, >>>>>>>> I like the new approach, but just have a couple of comments. >>>>>>> Thanks. >>>>>>> >>>>>>>> >>>>>>>> I think you should check the VirtualQuery return status and >>>>>>>> return false >>>>>>>> from protect_pages_individually if zero. >>>>>>> Right. >>>>>>> I will fix this. >>>>>>> >>>>>>>> >>>>>>>> I don't *think* you need to have the "!UseLargePages" >>>>>>>> restriction anymore >>>>>>>> with this approach, do you? >>>>>>> protect_pages_individually() doesn't have previous restriction >>>>>>> on its usage. >>>>>>> However I wanted to remain the caller(os::protect_memory) as is >>>>>>> because, as >>>>>>> you already mentioned below, I didn't want to have an additional >>>>>>> call of >>>>>>> VirtualQuery() for simpler code. >>>>>>> I don't have strong opinion on this. >>>>>>> >>>>>>> Let me post next webrev after concluding this. >>>>>> Tom, do you prefer to always use protect_pages_individually()? >>>>>> Does anyone have opinion on this? >>>>>> >>>>> >>>>> I'd vote for leaving the UseNUMAInterleaving test in. >>>>> Tom >>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Actually, I think you could just always use >>>>>>>> protect_pages_individually >>>>>>>> regardless of whether UseNUMAInterleaving was enabled or not, >>>>>>>> and the right >>>>>>>> thing would happen. But this way, you save an unnecessary >>>>>>>> system call plus >>>>>>>> some overhead. >>>>>>>> Tom >>>>>>>> >>>>>>>> >>>>> >>> > From jon.masamitsu at oracle.com Mon Dec 21 21:44:10 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 21 Dec 2015 13:44:10 -0800 Subject: RFR (S): 8145774: Move scrubbing setup code away out of ConcurrentMark In-Reply-To: <1450710105.3214.46.camel@oracle.com> References: <1450710105.3214.46.camel@oracle.com> Message-ID: <567872AA.1080807@oracle.com> Changes look good. Jon On 12/21/2015 07:01 AM, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that moves setup and > parallelization detail code for the remset scrubbing code out of > ConcurrentMark into G1CollectedHeap? > > This way, ConcurrentMark does not need a direct reference to G1RemSet > and HeapRegionManager any more, and anyway, I think setting up the > gangtask by determining the number of threads to use is better suited to > be placed into G1CollectedHeap. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8145774 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8145774/webrev/ > Testing: > jprt > > Thanks, > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Mon Dec 21 22:29:47 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 21 Dec 2015 14:29:47 -0800 Subject: RFR: JDK-8072725: Provide more granular levels for GC verification In-Reply-To: <56709EF7.9020003@oracle.com> References: <56709EF7.9020003@oracle.com> Message-ID: <56787D5B.50806@oracle.com> Poonam, Some of the string list parameters allow separation by , or " ". Did you consider adding that? Jon PS. See share/vm/compiler/compilerDirectives.cpp ccstrlist DirectiveSet::canonicalize_disableintrinsic(ccstrlist option_value) On 12/15/2015 03:15 PM, Poonam Bajaj Parhar wrote: > Hello, > > Please review these changes that split up the work done under > Verify*GC options. This will be very useful in debugging GC > issues/crashes where verifying the whole memory system with Verify*GC > options slows down the process and makes it impossible to reproduce > the problem. > > The changes introduce a new option /VerifySubSet///that can be used to > specify the specific memory sub-systems that one wants to verify. It > can be one or more of the sub-systems from these: threads, heap, > symbol_table, string_table, codecache, dictionary, > classloader_data_graph, metaspace, jni_handles, c-heap and > codecache_oops. If nothing is specified with /VerifySubSet/ then whole > of the memory system is verified with Verify*GC options. > > Bug:JDK-8072725: > Provide more granular levels for GC verification > Webrev: http://cr.openjdk.java.net/~poonam/8072725/webrev.00/ > Testing: JPRT, tested the changes with a simple test program. > > Thanks, > Poonam > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From poonam.bajaj at oracle.com Tue Dec 22 00:24:17 2015 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Mon, 21 Dec 2015 16:24:17 -0800 Subject: RFR: JDK-8145442: Add an option to verify remembered sets for G1 In-Reply-To: <567494DB.1080201@oracle.com> References: <567086E1.7080501@oracle.com> <567494DB.1080201@oracle.com> Message-ID: <56789831.8040305@oracle.com> Hello Jon, Thanks for taking a look at the changes. Here's the updated webrev and please see my comments inline: http://cr.openjdk.java.net/~poonam/8145442/webrev.01/ On 12/18/2015 3:20 PM, Jon Masamitsu wrote: > Poonam, > > Generally looks good. > > http://cr.openjdk.java.net/~poonam/8145442/webrev.00/src/share/vm/gc/g1/g1CollectedHeap.cpp.frames.html > > > The new GC unified logging implementation has been pushed so you'll > need to replace of gclog_or_tty(). > >> 4060 if (G1VerifyRSetsAfterEvacuationPause) { >> 4061 gclog_or_tty->print("[Verifying RSets]"); >> 4062 VerifyRegionRSetClosure v_cl; >> 4063 heap_region_iterate(&v_cl); >> 4064 } > > Probably with > > log_debug(gc, verify)("[Verifying RSets]"); > > Done. Thanks for pointing out. > http://cr.openjdk.java.net/~poonam/8145442/webrev.00/src/share/vm/gc/g1/heapRegion.hpp.frames.html > > >> 755 void verifyRSet(VerifyOption vo, bool *failures) const; > > Any comment worth adding for verifyRSet()? Are there conditions on > where and > when it can be used? Added a comment there. I don't think there is any specific condition when it should be used. It verifies the rem-set entries for that heap region. > > In verifyRSet() you always use VerifyOption_G1UsePrevMarking. Will > that always > be the value for the VerifyOption? If it is always going to be that, > does it work > to remove the VerifyOption parameter from verifyRSet() and has > verifyRSet() > always pass VerifyOption_G1UsePrevMarking to VerifyRSetClosure? > Currently it is only VerifyOption_G1UsePrevMarking that is being passed to this function. But I would prefer to leave it like this to keep it consistent with the verify() funtion: void verify(VerifyOption vo, bool *failures) const; The comments for verify() in heapRegion.hpp are true for verifyRSet() too. > http://cr.openjdk.java.net/~poonam/8145442/webrev.00/src/share/vm/gc/g1/heapRegion.cpp.frames.html > > > 917 VerifyRSetClosure v_rset_cl(g1, VerifyOption_G1UsePrevMarking); > > I can see HeapRegionVerifyClosure::verifyRemSets() is used and it > works out > well but it seems odd for HeapRegionVerifyClosure (which has a name > that I read as generally useful with different Verify closures) to have > a method that is specific to remembered-set verification. > > I think it is like this. > > HeapRegionVerifyClosure had a verifyRemSets() method that is > called from do_oop in VerifyRSetClosure and VerifyLiveClosure. > > Then when you want to do remembered-set verification you > use a VerifyRSetClosure and when you want to verify liveness, > you use a VerifyLiveClosure and get the remembered-set > verfication included in the VerifyLiveClosure. > > An alternative would be to put verifyRemSets() into VerifyRSetClosure > and have a VerifyRSetClosure as part of the VerifyLiveClosure. Then > instead of calling verifyRemSets() (as inherited from > HeapRegionVerifyClosure) > in VerifyLiveClosure, you could call verifyRemSets() using the embedded > VerifyRSetClosure. > > Or you could collapse HeapRegionVerifyClosure and VerifyRSetClosure > together (give it the name VerifyRSetClosure so that having a > verifyRemSets() > seems more natural) and derive VerifyLiveClosure from the new > VerifyRSetClosure. > I like the second alternative better. I have made the changes in the latest webrev to this effect. Please take a look at the new webrev and let me know your feedback. Thanks, Poonam > Jon > > On 12/15/2015 1:32 PM, Poonam Bajaj Parhar wrote: >> Hello, >> >> Please review these changes that add a diagnostic VM option >> 'G1VerifyRSetsAfterEvacuationPause' that when turned on enables the >> verification of Rem Sets of heap regions. >> >> Bug: JDK-8145442: Add an option to verify remembered sets for G1 >> Webrev: http://cr.openjdk.java.net/~poonam/8145442/webrev.00/ >> Testing: JPRT, GCBasher >> >> Thanks, >> Poonam >> > From poonam.bajaj at oracle.com Tue Dec 22 00:34:39 2015 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Mon, 21 Dec 2015 16:34:39 -0800 Subject: RFR: JDK-8145442: Add an option to verify remembered sets for G1 In-Reply-To: <56780886.1090003@oracle.com> References: <567086E1.7080501@oracle.com> <56780886.1090003@oracle.com> Message-ID: <56789A9F.5070200@oracle.com> Hello Mikael, Thanks for your feedback. Here's the updated webrev: http://cr.openjdk.java.net/~poonam/8145442/webrev.01/ On 12/21/2015 6:11 AM, Mikael Gerdin wrote: > Hi Poonam, > > On 2015-12-15 22:32, Poonam Bajaj Parhar wrote: >> Hello, >> >> Please review these changes that add a diagnostic VM option >> 'G1VerifyRSetsAfterEvacuationPause' that when turned on enables the >> verification of Rem Sets of heap regions. >> >> Bug: JDK-8145442: Add an option to verify remembered sets for G1 >> Webrev: http://cr.openjdk.java.net/~poonam/8145442/webrev.00/ > > I have some general comments on the structure of the code: > > First of all, I would prefer if we could avoid adding yet another > command line flag. > I think it would be preferable to either use VerifyRememberedSets > which already exists or to use the code you've proposed adding under > 8072725 with a "remset" verification subset (and deprecating > VerifyRememberedSets). > I removed the new option and am using VerifyRememberedSets now. After I have integrated the changes for 8072725, we can add 'remset' to the VerifySubSet and can control the rem-set verification of all the collectors under that. > Having RSet verification only post-gc and not before does not appeal > to me, since it's quite possible that we can have missing write > barriers in compiled code leading to missing remembered set entries as > well. > I have made changes to verify rem-sets both before and after GC. > Folding this into the VerifyBefore/After code would allow users to select > -XX:+VerifyAfterGC -XX:VerifySubSet=remset > to get the behavior you are suggesting in this webrev. > > > I like Jon's suggestion of moving all the remset verification to a > VerifyRemSetClosure which can be aggregated in the VerifyLiveClosure > if full verification is enabled. > I moved the rem-set verification code to VerifyRSetClosure and derived VerifyLiveClosure from that. > So, given that I've asked for re-use of the VerifyBefore/After code I > would suggest some changes in > HeapRegion::verify(VerifyOption vo, bool* failures) > to make the code select either the VerifyLiveClosure or the > VerifyRemSetClosure depending on the level of verification. > Yes, sure we can add more VerifySubSet levels after I have integrated the changes for 8072725. Thanks, Poonam > The BOT verification near the end of ::verify could be conditionalized > on VerifySubSet=bot or something similar. > > /Mikael > >> Testing: JPRT, GCBasher >> >> Thanks, >> Poonam >> > From jesper.wilhelmsson at oracle.com Tue Dec 22 00:38:29 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 22 Dec 2015 01:38:29 +0100 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <5678727E.3040005@oracle.com> References: <5670B5F1.7010505@oracle.com> <56717944.1030402@oracle.com> <56724973.4060405@oracle.com> <5673290E.7080106@oracle.com> <567351E9.40109@oracle.com> <567490A3.5020104@oracle.com> <56749942.10707@oracle.com> <5677E525.6060609@oracle.com> <56783B5E.2060001@oracle.com> <56784BAA.4070106@oracle.com> <567850BB.5070002@oracle.com> <5678727E.3040005@oracle.com> Message-ID: <56789B85.3040104@oracle.com> Hi Sangheon, Just a comment about the assert in protect_pages_individually(). To me it looks strange to have an assert and then on the next line handle the case that was just asserted that it can't happen. Either we assume it can happen and handle it, or we say that it can't happen and assert that it doesn't. It would be nice if you either remove the assert or add a comment that explains why it is there. I do not need to re-review if you decide to do either. Besides that, looks good! /Jesper Den 21/12/15 kl. 22:43, skrev sangheon: > Hi all, > > Tom and I did some discussion(previously I misunderstood Tom's comment) and > here's the next webrev which includes: > > 1. Call protect_pages_individually() when UseNUMAInterleaving is enabled (Tom) > 2. Added a comment why we need to call protect_pages_individually(). (Tom) > 3. Changed VirtualQuery() handling code. (Tom) > > http://cr.openjdk.java.net/~sangheki/8145000/webrev.03 > http://cr.openjdk.java.net/~sangheki/8145000/webrev.03_to_02 > > Thanks, > Sangheon > > > On 12/21/2015 11:19 AM, Tom Benson wrote: >> Hi, >> >> On 12/21/2015 1:57 PM, Jesper Wilhelmsson wrote: >>> Hi Sangheon, >>> >>> I was under the impression that Tom wanted to keep the UseNUMAInterleaving >>> test and not always call protect_pages_individually(). >> >> Yes, I'd said that was my vote, but wasn't adamant about it. If we agree, >> let's keep it. 8^) >> Tom >> >>> At least that's what I would prefer. If you revert that change I think we >>> have something here :) >>> /Jesper >>> >>> >>> Den 21/12/15 kl. 18:48, skrev sangheon: >>>> Hi Jesper and Tom, >>>> >>>> Here's next webrev which includes below: >>>> - Check return value of VirtualQuery. (Tom, Jesper) >>>> - Always call protect_pages_individually() from os::protect_memory(). (Tom) >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.02 >>>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.02_to_01/ >>>> >>>> Test: >>>> JPRT, RBT (hotspot/test/:hotspot_all,testlist,noncolo.testlist >>>> --add-tonga-keyword quick for Windows only) >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> On 12/21/2015 03:40 AM, Jesper Wilhelmsson wrote: >>>>> Hi Sangheon, >>>>> >>>>> I like this version a lot better. >>>>> I have no further comments except for what Tom already mentioned about >>>>> checking VirtualQuery return value. >>>>> /Jesper >>>>> >>>>> >>>>> Den 19/12/15 kl. 00:39, skrev Tom Benson: >>>>>> Hi Sangheon, >>>>>> >>>>>> On 12/18/2015 6:02 PM, sangheon wrote: >>>>>>> Hi Tom, >>>>>>> >>>>>>> On 12/17/2015 04:23 PM, sangheon wrote: >>>>>>>> Hi Tom, >>>>>>>> >>>>>>>> Thank you for reviewing this! >>>>>>>> >>>>>>>> On 12/17/2015 01:28 PM, Tom Benson wrote: >>>>>>>>> Hi Sangheon, >>>>>>>>> I like the new approach, but just have a couple of comments. >>>>>>>> Thanks. >>>>>>>> >>>>>>>>> >>>>>>>>> I think you should check the VirtualQuery return status and return false >>>>>>>>> from protect_pages_individually if zero. >>>>>>>> Right. >>>>>>>> I will fix this. >>>>>>>> >>>>>>>>> >>>>>>>>> I don't *think* you need to have the "!UseLargePages" restriction anymore >>>>>>>>> with this approach, do you? >>>>>>>> protect_pages_individually() doesn't have previous restriction on its >>>>>>>> usage. >>>>>>>> However I wanted to remain the caller(os::protect_memory) as is because, as >>>>>>>> you already mentioned below, I didn't want to have an additional call of >>>>>>>> VirtualQuery() for simpler code. >>>>>>>> I don't have strong opinion on this. >>>>>>>> >>>>>>>> Let me post next webrev after concluding this. >>>>>>> Tom, do you prefer to always use protect_pages_individually()? >>>>>>> Does anyone have opinion on this? >>>>>>> >>>>>> >>>>>> I'd vote for leaving the UseNUMAInterleaving test in. >>>>>> Tom >>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Actually, I think you could just always use protect_pages_individually >>>>>>>>> regardless of whether UseNUMAInterleaving was enabled or not, and the >>>>>>>>> right >>>>>>>>> thing would happen. But this way, you save an unnecessary system call >>>>>>>>> plus >>>>>>>>> some overhead. >>>>>>>>> Tom >>>>>>>>> >>>>>>>>> >>>>>> >>>> >> > From jesper.wilhelmsson at oracle.com Tue Dec 22 00:39:08 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 22 Dec 2015 01:39:08 +0100 Subject: RFR(s): 8144527: NewSizeThreadIncrease would make an overflow In-Reply-To: <56786011.1040804@oracle.com> References: <5677A1A5.4000401@oracle.com> <56780E48.6030401@oracle.com> <56786011.1040804@oracle.com> Message-ID: <56789BAC.9070403@oracle.com> Looks good! /Jesper Den 21/12/15 kl. 21:24, skrev sangheon: > Hi Jesper, > > Thank you for looking at this. > > On 12/21/2015 06:35 AM, Jesper Wilhelmsson wrote: >> Hi Sangheon, >> >> Did you consider a simpler approach with only nested ifs instead of the >> do-while with breaks? At least to me, that would be easier to read. > You are right. > > Here's updated webrev. > http://cr.openjdk.java.net/~sangheki/8144527/webrev.01 > > Thanks, > Sangheon > > >> >> Besides that it looks good. >> /Jesper >> >> >> Den 21/12/15 kl. 07:52, skrev sangheon: >>> Hi all, >>> >>> Can I have reviews for this change to prevent an overflow for >>> NewSizeThreadIncrease? >>> >>> This option is used with non-daemon threads count when calculate new size. And >>> as we can't know the thread count at start-up time, this overflow can't be >>> checked by argument validation framework. Instead I changed related routines to >>> prevent the overflow and when it happens desired new size will be previous size. >>> This will affect only for Serial GC. >>> >>> I added simple test to have 5 threads and then check the log whether we had heap >>> expansion or not. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8144527 >>> Webrev: http://cr.openjdk.java.net/~sangheki/8144527/webrev.00 >>> Testing: JPRT >>> >>> Thanks, >>> Sangheon >>> >>> > From poonam.bajaj at oracle.com Tue Dec 22 00:40:13 2015 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Mon, 21 Dec 2015 16:40:13 -0800 Subject: RFR: JDK-8072725: Provide more granular levels for GC verification In-Reply-To: <56787D5B.50806@oracle.com> References: <56709EF7.9020003@oracle.com> <56787D5B.50806@oracle.com> Message-ID: <56789BED.3020304@oracle.com> Hello Jon, On 12/21/2015 2:29 PM, Jon Masamitsu wrote: > Poonam, > > Some of the string list parameters allow separation by , or " ". Did > you consider adding that? > The VerifySubSet string list can accept the strings separated by comma or a space. Before verification, we just need to check if a particular subset is present in the VerifySubSet list or not. We don't need any complicated processing of the strings list here. Thanks, Poonam > Jon > > PS. See share/vm/compiler/compilerDirectives.cpp > > ccstrlist DirectiveSet::canonicalize_disableintrinsic(ccstrlist > option_value) > > > On 12/15/2015 03:15 PM, Poonam Bajaj Parhar wrote: >> Hello, >> >> Please review these changes that split up the work done under >> Verify*GC options. This will be very useful in debugging GC >> issues/crashes where verifying the whole memory system with Verify*GC >> options slows down the process and makes it impossible to reproduce >> the problem. >> >> The changes introduce a new option /VerifySubSet///that can be used >> to specify the specific memory sub-systems that one wants to verify. >> It can be one or more of the sub-systems from these: threads, heap, >> symbol_table, string_table, codecache, dictionary, >> classloader_data_graph, metaspace, jni_handles, c-heap and >> codecache_oops. If nothing is specified with /VerifySubSet/ then >> whole of the memory system is verified with Verify*GC options. >> >> Bug:JDK-8072725: >> Provide more granular levels for GC verification >> Webrev: http://cr.openjdk.java.net/~poonam/8072725/webrev.00/ >> Testing: JPRT, tested the changes with a simple test program. >> >> Thanks, >> Poonam >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sangheon.kim at oracle.com Tue Dec 22 00:40:25 2015 From: sangheon.kim at oracle.com (sangheon) Date: Mon, 21 Dec 2015 16:40:25 -0800 Subject: RFR(s): 8144527: NewSizeThreadIncrease would make an overflow In-Reply-To: <56789BAC.9070403@oracle.com> References: <5677A1A5.4000401@oracle.com> <56780E48.6030401@oracle.com> <56786011.1040804@oracle.com> <56789BAC.9070403@oracle.com> Message-ID: <56789BF9.90300@oracle.com> Hi Jesper, Thank you for the review. Sangheon On 12/21/2015 04:39 PM, Jesper Wilhelmsson wrote: > Looks good! > /Jesper > > Den 21/12/15 kl. 21:24, skrev sangheon: >> Hi Jesper, >> >> Thank you for looking at this. >> >> On 12/21/2015 06:35 AM, Jesper Wilhelmsson wrote: >>> Hi Sangheon, >>> >>> Did you consider a simpler approach with only nested ifs instead of the >>> do-while with breaks? At least to me, that would be easier to read. >> You are right. >> >> Here's updated webrev. >> http://cr.openjdk.java.net/~sangheki/8144527/webrev.01 >> >> Thanks, >> Sangheon >> >> >>> >>> Besides that it looks good. >>> /Jesper >>> >>> >>> Den 21/12/15 kl. 07:52, skrev sangheon: >>>> Hi all, >>>> >>>> Can I have reviews for this change to prevent an overflow for >>>> NewSizeThreadIncrease? >>>> >>>> This option is used with non-daemon threads count when calculate >>>> new size. And >>>> as we can't know the thread count at start-up time, this overflow >>>> can't be >>>> checked by argument validation framework. Instead I changed related >>>> routines to >>>> prevent the overflow and when it happens desired new size will be >>>> previous size. >>>> This will affect only for Serial GC. >>>> >>>> I added simple test to have 5 threads and then check the log >>>> whether we had heap >>>> expansion or not. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8144527 >>>> Webrev: http://cr.openjdk.java.net/~sangheki/8144527/webrev.00 >>>> Testing: JPRT >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >> From sangheon.kim at oracle.com Tue Dec 22 01:36:59 2015 From: sangheon.kim at oracle.com (sangheon) Date: Mon, 21 Dec 2015 17:36:59 -0800 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <56789B85.3040104@oracle.com> References: <5670B5F1.7010505@oracle.com> <56717944.1030402@oracle.com> <56724973.4060405@oracle.com> <5673290E.7080106@oracle.com> <567351E9.40109@oracle.com> <567490A3.5020104@oracle.com> <56749942.10707@oracle.com> <5677E525.6060609@oracle.com> <56783B5E.2060001@oracle.com> <56784BAA.4070106@oracle.com> <567850BB.5070002@oracle.com> <5678727E.3040005@oracle.com> <56789B85.3040104@oracle.com> Message-ID: <5678A93B.6030808@oracle.com> Hi Jesper, On 12/21/2015 04:38 PM, Jesper Wilhelmsson wrote: > Hi Sangheon, > > Just a comment about the assert in protect_pages_individually(). To me > it looks strange to have an assert and then on the next line handle > the case that was just asserted that it can't happen. Either we assume > it can happen and handle it, or we say that it can't happen and assert > that it doesn't. I agree, assert is wrong. And looking at current usage of os::protect_memory(), caller is handling the situation. So I think 'warning' seems correct as the log is intended to show which chunk is making problem. - assert(ret, "Failed protecting chunk #%u", count); + warning("Failed protecting chunk #%u", count); What do you think? Thanks, Sangheon > > It would be nice if you either remove the assert or add a comment that > explains why it is there. I do not need to re-review if you decide to > do either. > > Besides that, looks good! > /Jesper > > Den 21/12/15 kl. 22:43, skrev sangheon: >> Hi all, >> >> Tom and I did some discussion(previously I misunderstood Tom's >> comment) and >> here's the next webrev which includes: >> >> 1. Call protect_pages_individually() when UseNUMAInterleaving is >> enabled (Tom) >> 2. Added a comment why we need to call protect_pages_individually(). >> (Tom) >> 3. Changed VirtualQuery() handling code. (Tom) >> >> http://cr.openjdk.java.net/~sangheki/8145000/webrev.03 >> http://cr.openjdk.java.net/~sangheki/8145000/webrev.03_to_02 >> >> Thanks, >> Sangheon >> >> >> On 12/21/2015 11:19 AM, Tom Benson wrote: >>> Hi, >>> >>> On 12/21/2015 1:57 PM, Jesper Wilhelmsson wrote: >>>> Hi Sangheon, >>>> >>>> I was under the impression that Tom wanted to keep the >>>> UseNUMAInterleaving >>>> test and not always call protect_pages_individually(). >>> >>> Yes, I'd said that was my vote, but wasn't adamant about it. If we >>> agree, >>> let's keep it. 8^) >>> Tom >>> >>>> At least that's what I would prefer. If you revert that change I >>>> think we >>>> have something here :) >>>> /Jesper >>>> >>>> >>>> Den 21/12/15 kl. 18:48, skrev sangheon: >>>>> Hi Jesper and Tom, >>>>> >>>>> Here's next webrev which includes below: >>>>> - Check return value of VirtualQuery. (Tom, Jesper) >>>>> - Always call protect_pages_individually() from >>>>> os::protect_memory(). (Tom) >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.02 >>>>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.02_to_01/ >>>>> >>>>> Test: >>>>> JPRT, RBT (hotspot/test/:hotspot_all,testlist,noncolo.testlist >>>>> --add-tonga-keyword quick for Windows only) >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>> On 12/21/2015 03:40 AM, Jesper Wilhelmsson wrote: >>>>>> Hi Sangheon, >>>>>> >>>>>> I like this version a lot better. >>>>>> I have no further comments except for what Tom already mentioned >>>>>> about >>>>>> checking VirtualQuery return value. >>>>>> /Jesper >>>>>> >>>>>> >>>>>> Den 19/12/15 kl. 00:39, skrev Tom Benson: >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> On 12/18/2015 6:02 PM, sangheon wrote: >>>>>>>> Hi Tom, >>>>>>>> >>>>>>>> On 12/17/2015 04:23 PM, sangheon wrote: >>>>>>>>> Hi Tom, >>>>>>>>> >>>>>>>>> Thank you for reviewing this! >>>>>>>>> >>>>>>>>> On 12/17/2015 01:28 PM, Tom Benson wrote: >>>>>>>>>> Hi Sangheon, >>>>>>>>>> I like the new approach, but just have a couple of comments. >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think you should check the VirtualQuery return status and >>>>>>>>>> return false >>>>>>>>>> from protect_pages_individually if zero. >>>>>>>>> Right. >>>>>>>>> I will fix this. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I don't *think* you need to have the "!UseLargePages" >>>>>>>>>> restriction anymore >>>>>>>>>> with this approach, do you? >>>>>>>>> protect_pages_individually() doesn't have previous restriction >>>>>>>>> on its >>>>>>>>> usage. >>>>>>>>> However I wanted to remain the caller(os::protect_memory) as >>>>>>>>> is because, as >>>>>>>>> you already mentioned below, I didn't want to have an >>>>>>>>> additional call of >>>>>>>>> VirtualQuery() for simpler code. >>>>>>>>> I don't have strong opinion on this. >>>>>>>>> >>>>>>>>> Let me post next webrev after concluding this. >>>>>>>> Tom, do you prefer to always use protect_pages_individually()? >>>>>>>> Does anyone have opinion on this? >>>>>>>> >>>>>>> >>>>>>> I'd vote for leaving the UseNUMAInterleaving test in. >>>>>>> Tom >>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sangheon >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Actually, I think you could just always use >>>>>>>>>> protect_pages_individually >>>>>>>>>> regardless of whether UseNUMAInterleaving was enabled or not, >>>>>>>>>> and the >>>>>>>>>> right >>>>>>>>>> thing would happen. But this way, you save an unnecessary >>>>>>>>>> system call >>>>>>>>>> plus >>>>>>>>>> some overhead. >>>>>>>>>> Tom >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>> >> From mikael.gerdin at oracle.com Tue Dec 22 09:31:35 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 22 Dec 2015 10:31:35 +0100 Subject: RFR(s): 8144527: NewSizeThreadIncrease would make an overflow In-Reply-To: <56789BF9.90300@oracle.com> References: <5677A1A5.4000401@oracle.com> <56780E48.6030401@oracle.com> <56786011.1040804@oracle.com> <56789BAC.9070403@oracle.com> <56789BF9.90300@oracle.com> Message-ID: <56791877.6040605@oracle.com> Hi Sangheon, On 12/22/2015 01:40 AM, sangheon wrote: > Hi Jesper, > > Thank you for the review. > > Sangheon > > > On 12/21/2015 04:39 PM, Jesper Wilhelmsson wrote: >> Looks good! >> /Jesper >> >> Den 21/12/15 kl. 21:24, skrev sangheon: >>> Hi Jesper, >>> >>> Thank you for looking at this. >>> >>> On 12/21/2015 06:35 AM, Jesper Wilhelmsson wrote: >>>> Hi Sangheon, >>>> >>>> Did you consider a simpler approach with only nested ifs instead of the >>>> do-while with breaks? At least to me, that would be easier to read. >>> You are right. >>> >>> Here's updated webrev. >>> http://cr.openjdk.java.net/~sangheki/8144527/webrev.01 Would you mind moving the code for NewSizeThreadIncrease to a method? Something like "DefNewGeneration::adjust_for_thread_increase()" Otherwise it looks good. (I'll be on vacation after today so I don't need to see a new webrev for the update) /Mikael >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> Besides that it looks good. >>>> /Jesper >>>> >>>> >>>> Den 21/12/15 kl. 07:52, skrev sangheon: >>>>> Hi all, >>>>> >>>>> Can I have reviews for this change to prevent an overflow for >>>>> NewSizeThreadIncrease? >>>>> >>>>> This option is used with non-daemon threads count when calculate >>>>> new size. And >>>>> as we can't know the thread count at start-up time, this overflow >>>>> can't be >>>>> checked by argument validation framework. Instead I changed related >>>>> routines to >>>>> prevent the overflow and when it happens desired new size will be >>>>> previous size. >>>>> This will affect only for Serial GC. >>>>> >>>>> I added simple test to have 5 threads and then check the log >>>>> whether we had heap >>>>> expansion or not. >>>>> >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8144527 >>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8144527/webrev.00 >>>>> Testing: JPRT >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>> > From mikael.gerdin at oracle.com Tue Dec 22 09:52:57 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 22 Dec 2015 10:52:57 +0100 Subject: RFR (S): 8145672: Remove dependency of G1FromCardCache to HeapRegionRemSet In-Reply-To: <56786D85.7010707@oracle.com> References: <1450436572.2496.17.camel@oracle.com> <56744F2D.1040304@oracle.com> <1450697853.3214.10.camel@oracle.com> <56786D85.7010707@oracle.com> Message-ID: <56791D79.1000901@oracle.com> Hi, On 12/21/2015 10:22 PM, Jon Masamitsu wrote: > > > On 12/21/2015 03:37 AM, Thomas Schatzl wrote: >> Hi Jon, >> >> thanks for the review. >> >> Comments inline. >> >> On Fri, 2015-12-18 at 10:23 -0800, Jon Masamitsu wrote: >>> Thomas, >>> >>> A couple of questions about code that are not part of your change (you >>> can ignore) and a suggestion on expanding a comment. >>> >>> http://cr.openjdk.java.net/~tschatzl/8145672/webrev/src/share/vm/gc/g1/g1CollectedHeap.cpp.frames.html >>> >>> >>> Not a part of your change but is the guarantee() in the right place? >>> >>>> 1936 const uint max_region_idx = (1U << >>>> (sizeof(RegionIdx_t)*BitsPerByte-1)) - 1; >>>> 1937 guarantee((max_regions() - 1) <= max_region_idx, "too many >>>> regions"); >>>> 1938 >>>> 1939 G1RemSet::init_heap(max_regions()); >>> Meaning, isn't _max_regions initialized in init_heap() after the >>> guarantee()? >> There is no _max_regions, it is derived from >> G1CollectedHeap::reserved(). Also, the init_heap() you are referring to >> is G1RemSet::init_heap(). >> >> I renamed the method to G1RemSet::initialize(), which is of course more >> generic and bland, but I hope it avoids this kind of confusion. (I did >> not want to use after_heap_initialized() or such as I found it even >> worse). > > Ok. > >>> http://cr.openjdk.java.net/~tschatzl/8145672/webrev/src/share/vm/gc/g1/g1FromCardCache.cpp.frames.html >>> >>> >>> Again, not part of your change but can lines 52 and 53 be lifted out of >>> the loop at 51? >>> >>>> 51 for (uint i = 0; i < G1RemSet::num_par_rem_sets(); i++) { >>>> 52 uint end_idx = (start_idx + (uint)new_num_regions); >>>> 53 assert(end_idx <= _max_regions, "Must be within max."); >>>> 54 for (uint j = start_idx; j < end_idx; j++) { >>>> 55 set(i, j, InvalidCard); >>>> 56 } >>>> 57 } >> Done. >> >>> http://cr.openjdk.java.net/~tschatzl/8145672/webrev/src/share/vm/gc/g1/g1RemSet.hpp.frames.html >>> >>> >>> Thank you for adding this comment. >>> >>>> 79 // Gives an approximation on how many threads add records to a >>>> remembered set >>>> 80 // in parallel for sizing buffers to decrease performance losses >>>> due to sharing. >>>> 81 // Examples are mutator threads together with the concurrent >>>> refinement threads >>>> 82 // or GC threads. >>>> 83 static uint num_par_rem_sets(); >>> Can you add what kind of buffers to "for sizing ??? buffers"? >> I changed it to: >> >> 78 // Gives an approximation on how many threads can be expected to >> add records to >> 79 // a remembered set in parallel. This can be used for sizing >> data structures to >> 80 // decrease performance losses due to data structure sharing. >> 81 // Examples for quantities that influence this value are the >> maximum number of >> 82 // mutator threads, maximum number of concurrent refinement or >> GC threads. >> >> I hope this is somewhat better. > > Thanks. > >> >> The current formula may actually be overkill for very large system (like >> using the processor count in the formula directly). I think it could be >> scaled down to some degree for "large" systems without performance >> penalty. However that is different work. >> >>> Would this be too specific to the current implementation? Meaning do >>> you want a more >>> general descriptions? >>> >>> // Examples are the maximum number of mutator threads plus the maximum >>> number of >>> // concurrent refinement threads or the maximum number of GC threads, >>> whichever is >>> // larger. >> See above. >> >>> Leave out the "maximum" (in all 3 places if it is understood). >>> >>> Otherwise, looks good. >>> >>> None of these are critical to the patch (since mostly not part of >>> your change) so no need to delay your push for any of these. >> New webrevs at >> http://cr.openjdk.java.net/~tschatzl/8145672/webrev.1/ (full) >> http://cr.openjdk.java.net/~tschatzl/8145672/webrev.0_to_1/ (diff) >> > > > http://cr.openjdk.java.net/~tschatzl/8145672/webrev.0_to_1/src/share/vm/gc/g1/g1RemSet.hpp.udiff.html > > > This doesn't quite sound right. > > + // Initialize data that depends on that the heap size is known. > > Maybe > > // Initialize data that depends on the heap size being known. > > > I don't need a new webrev. Looks good to me as well modulo Jon's suggestion above. /Mikael > > Jon > From thomas.schatzl at oracle.com Tue Dec 22 11:22:32 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 22 Dec 2015 12:22:32 +0100 Subject: RFR (S): 8145672: Remove dependency of G1FromCardCache to HeapRegionRemSet In-Reply-To: <56791D79.1000901@oracle.com> References: <1450436572.2496.17.camel@oracle.com> <56744F2D.1040304@oracle.com> <1450697853.3214.10.camel@oracle.com> <56786D85.7010707@oracle.com> <56791D79.1000901@oracle.com> Message-ID: <1450783352.2500.0.camel@oracle.com> Hi Mikael, Jon, thanks for the reviews. Thomas From thomas.schatzl at oracle.com Tue Dec 22 11:23:32 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 22 Dec 2015 12:23:32 +0100 Subject: RFR (S): 8145774: Move scrubbing setup code away out of ConcurrentMark In-Reply-To: <567872AA.1080807@oracle.com> References: <1450710105.3214.46.camel@oracle.com> <567872AA.1080807@oracle.com> Message-ID: <1450783412.2500.1.camel@oracle.com> Hi Jon, On Mon, 2015-12-21 at 13:44 -0800, Jon Masamitsu wrote: > Changes look good. Thanks for the review. Thomas From thomas.schatzl at oracle.com Tue Dec 22 12:34:32 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 22 Dec 2015 13:34:32 +0100 Subject: Request for code review - 8145037 Clean up FreeIdSet usage In-Reply-To: <56731C83.6050507@oracle.com> References: <566F1ADA.30608@oracle.com> <56731C83.6050507@oracle.com> Message-ID: <1450787672.2500.3.camel@oracle.com> Hi Alex, On Thu, 2015-12-17 at 15:35 -0500, Alexander Harlap wrote: > > JDK-8145037 - Clean up FreeIdSet usage > > Proposed change: > http://cr.openjdk.java.net/~aharlap/8145037/webrev.00/ > what kind of testing has been performed? Please always mention that in your RFR emails. Looks good though. Thanks, Thomas From jesper.wilhelmsson at oracle.com Tue Dec 22 13:14:03 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 22 Dec 2015 14:14:03 +0100 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <5678A93B.6030808@oracle.com> References: <5670B5F1.7010505@oracle.com> <56717944.1030402@oracle.com> <56724973.4060405@oracle.com> <5673290E.7080106@oracle.com> <567351E9.40109@oracle.com> <567490A3.5020104@oracle.com> <56749942.10707@oracle.com> <5677E525.6060609@oracle.com> <56783B5E.2060001@oracle.com> <56784BAA.4070106@oracle.com> <567850BB.5070002@oracle.com> <5678727E.3040005@oracle.com> <56789B85.3040104@oracle.com> <5678A93B.6030808@oracle.com> Message-ID: <56794C9B.5030905@oracle.com> Den 22/12/15 kl. 02:36, skrev sangheon: > Hi Jesper, > > On 12/21/2015 04:38 PM, Jesper Wilhelmsson wrote: >> Hi Sangheon, >> >> Just a comment about the assert in protect_pages_individually(). To me it >> looks strange to have an assert and then on the next line handle the case that >> was just asserted that it can't happen. Either we assume it can happen and >> handle it, or we say that it can't happen and assert that it doesn't. > I agree, assert is wrong. > And looking at current usage of os::protect_memory(), caller is handling the > situation. > So I think 'warning' seems correct as the log is intended to show which chunk is > making problem. > > - assert(ret, "Failed protecting chunk #%u", count); > + warning("Failed protecting chunk #%u", count); > > What do you think? Yes, a warning seems appropriate. Ship it! /Jesper > > Thanks, > Sangheon > > >> >> It would be nice if you either remove the assert or add a comment that >> explains why it is there. I do not need to re-review if you decide to do either. >> >> Besides that, looks good! >> /Jesper >> >> Den 21/12/15 kl. 22:43, skrev sangheon: >>> Hi all, >>> >>> Tom and I did some discussion(previously I misunderstood Tom's comment) and >>> here's the next webrev which includes: >>> >>> 1. Call protect_pages_individually() when UseNUMAInterleaving is enabled (Tom) >>> 2. Added a comment why we need to call protect_pages_individually(). (Tom) >>> 3. Changed VirtualQuery() handling code. (Tom) >>> >>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.03 >>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.03_to_02 >>> >>> Thanks, >>> Sangheon >>> >>> >>> On 12/21/2015 11:19 AM, Tom Benson wrote: >>>> Hi, >>>> >>>> On 12/21/2015 1:57 PM, Jesper Wilhelmsson wrote: >>>>> Hi Sangheon, >>>>> >>>>> I was under the impression that Tom wanted to keep the UseNUMAInterleaving >>>>> test and not always call protect_pages_individually(). >>>> >>>> Yes, I'd said that was my vote, but wasn't adamant about it. If we agree, >>>> let's keep it. 8^) >>>> Tom >>>> >>>>> At least that's what I would prefer. If you revert that change I think we >>>>> have something here :) >>>>> /Jesper >>>>> >>>>> >>>>> Den 21/12/15 kl. 18:48, skrev sangheon: >>>>>> Hi Jesper and Tom, >>>>>> >>>>>> Here's next webrev which includes below: >>>>>> - Check return value of VirtualQuery. (Tom, Jesper) >>>>>> - Always call protect_pages_individually() from os::protect_memory(). (Tom) >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.02 >>>>>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.02_to_01/ >>>>>> >>>>>> Test: >>>>>> JPRT, RBT (hotspot/test/:hotspot_all,testlist,noncolo.testlist >>>>>> --add-tonga-keyword quick for Windows only) >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>> On 12/21/2015 03:40 AM, Jesper Wilhelmsson wrote: >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> I like this version a lot better. >>>>>>> I have no further comments except for what Tom already mentioned about >>>>>>> checking VirtualQuery return value. >>>>>>> /Jesper >>>>>>> >>>>>>> >>>>>>> Den 19/12/15 kl. 00:39, skrev Tom Benson: >>>>>>>> Hi Sangheon, >>>>>>>> >>>>>>>> On 12/18/2015 6:02 PM, sangheon wrote: >>>>>>>>> Hi Tom, >>>>>>>>> >>>>>>>>> On 12/17/2015 04:23 PM, sangheon wrote: >>>>>>>>>> Hi Tom, >>>>>>>>>> >>>>>>>>>> Thank you for reviewing this! >>>>>>>>>> >>>>>>>>>> On 12/17/2015 01:28 PM, Tom Benson wrote: >>>>>>>>>>> Hi Sangheon, >>>>>>>>>>> I like the new approach, but just have a couple of comments. >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I think you should check the VirtualQuery return status and return false >>>>>>>>>>> from protect_pages_individually if zero. >>>>>>>>>> Right. >>>>>>>>>> I will fix this. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I don't *think* you need to have the "!UseLargePages" restriction >>>>>>>>>>> anymore >>>>>>>>>>> with this approach, do you? >>>>>>>>>> protect_pages_individually() doesn't have previous restriction on its >>>>>>>>>> usage. >>>>>>>>>> However I wanted to remain the caller(os::protect_memory) as is >>>>>>>>>> because, as >>>>>>>>>> you already mentioned below, I didn't want to have an additional call of >>>>>>>>>> VirtualQuery() for simpler code. >>>>>>>>>> I don't have strong opinion on this. >>>>>>>>>> >>>>>>>>>> Let me post next webrev after concluding this. >>>>>>>>> Tom, do you prefer to always use protect_pages_individually()? >>>>>>>>> Does anyone have opinion on this? >>>>>>>>> >>>>>>>> >>>>>>>> I'd vote for leaving the UseNUMAInterleaving test in. >>>>>>>> Tom >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sangheon >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Sangheon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Actually, I think you could just always use protect_pages_individually >>>>>>>>>>> regardless of whether UseNUMAInterleaving was enabled or not, and the >>>>>>>>>>> right >>>>>>>>>>> thing would happen. But this way, you save an unnecessary system call >>>>>>>>>>> plus >>>>>>>>>>> some overhead. >>>>>>>>>>> Tom >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> > From alexander.harlap at oracle.com Tue Dec 22 14:47:49 2015 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Tue, 22 Dec 2015 09:47:49 -0500 Subject: Request for code review - 8145037 Clean up FreeIdSet usage In-Reply-To: <1450787672.2500.3.camel@oracle.com> References: <566F1ADA.30608@oracle.com> <56731C83.6050507@oracle.com> <1450787672.2500.3.camel@oracle.com> Message-ID: <56796295.2020501@oracle.com> Testing - JPRT passed Alex On 12/22/2015 7:34 AM, Thomas Schatzl wrote: > Hi Alex, > > On Thu, 2015-12-17 at 15:35 -0500, Alexander Harlap wrote: >> JDK-8145037 - Clean up FreeIdSet usage >> >> Proposed change: >> http://cr.openjdk.java.net/~aharlap/8145037/webrev.00/ >> > what kind of testing has been performed? Please always mention that in > your RFR emails. > > Looks good though. > > Thanks, > Thomas > > From tom.benson at oracle.com Tue Dec 22 15:33:30 2015 From: tom.benson at oracle.com (Tom Benson) Date: Tue, 22 Dec 2015 10:33:30 -0500 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <56794C9B.5030905@oracle.com> References: <5670B5F1.7010505@oracle.com> <56717944.1030402@oracle.com> <56724973.4060405@oracle.com> <5673290E.7080106@oracle.com> <567351E9.40109@oracle.com> <567490A3.5020104@oracle.com> <56749942.10707@oracle.com> <5677E525.6060609@oracle.com> <56783B5E.2060001@oracle.com> <56784BAA.4070106@oracle.com> <567850BB.5070002@oracle.com> <5678727E.3040005@oracle.com> <56789B85.3040104@oracle.com> <5678A93B.6030808@oracle.com> <56794C9B.5030905@oracle.com> Message-ID: <56796D4A.2020700@oracle.com> Looks OK to me as well. Tom On 12/22/2015 8:14 AM, Jesper Wilhelmsson wrote: > Den 22/12/15 kl. 02:36, skrev sangheon: >> Hi Jesper, >> >> On 12/21/2015 04:38 PM, Jesper Wilhelmsson wrote: >>> Hi Sangheon, >>> >>> Just a comment about the assert in protect_pages_individually(). To >>> me it >>> looks strange to have an assert and then on the next line handle the >>> case that >>> was just asserted that it can't happen. Either we assume it can >>> happen and >>> handle it, or we say that it can't happen and assert that it doesn't. >> I agree, assert is wrong. >> And looking at current usage of os::protect_memory(), caller is >> handling the >> situation. >> So I think 'warning' seems correct as the log is intended to show >> which chunk is >> making problem. >> >> - assert(ret, "Failed protecting chunk #%u", count); >> + warning("Failed protecting chunk #%u", count); >> >> What do you think? > > Yes, a warning seems appropriate. > Ship it! > /Jesper > >> >> Thanks, >> Sangheon >> >> >>> >>> It would be nice if you either remove the assert or add a comment that >>> explains why it is there. I do not need to re-review if you decide >>> to do either. >>> >>> Besides that, looks good! >>> /Jesper >>> >>> Den 21/12/15 kl. 22:43, skrev sangheon: >>>> Hi all, >>>> >>>> Tom and I did some discussion(previously I misunderstood Tom's >>>> comment) and >>>> here's the next webrev which includes: >>>> >>>> 1. Call protect_pages_individually() when UseNUMAInterleaving is >>>> enabled (Tom) >>>> 2. Added a comment why we need to call >>>> protect_pages_individually(). (Tom) >>>> 3. Changed VirtualQuery() handling code. (Tom) >>>> >>>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.03 >>>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.03_to_02 >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> On 12/21/2015 11:19 AM, Tom Benson wrote: >>>>> Hi, >>>>> >>>>> On 12/21/2015 1:57 PM, Jesper Wilhelmsson wrote: >>>>>> Hi Sangheon, >>>>>> >>>>>> I was under the impression that Tom wanted to keep the >>>>>> UseNUMAInterleaving >>>>>> test and not always call protect_pages_individually(). >>>>> >>>>> Yes, I'd said that was my vote, but wasn't adamant about it. If we >>>>> agree, >>>>> let's keep it. 8^) >>>>> Tom >>>>> >>>>>> At least that's what I would prefer. If you revert that change I >>>>>> think we >>>>>> have something here :) >>>>>> /Jesper >>>>>> >>>>>> >>>>>> Den 21/12/15 kl. 18:48, skrev sangheon: >>>>>>> Hi Jesper and Tom, >>>>>>> >>>>>>> Here's next webrev which includes below: >>>>>>> - Check return value of VirtualQuery. (Tom, Jesper) >>>>>>> - Always call protect_pages_individually() from >>>>>>> os::protect_memory(). (Tom) >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.02 >>>>>>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.02_to_01/ >>>>>>> >>>>>>> Test: >>>>>>> JPRT, RBT (hotspot/test/:hotspot_all,testlist,noncolo.testlist >>>>>>> --add-tonga-keyword quick for Windows only) >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>> On 12/21/2015 03:40 AM, Jesper Wilhelmsson wrote: >>>>>>>> Hi Sangheon, >>>>>>>> >>>>>>>> I like this version a lot better. >>>>>>>> I have no further comments except for what Tom already >>>>>>>> mentioned about >>>>>>>> checking VirtualQuery return value. >>>>>>>> /Jesper >>>>>>>> >>>>>>>> >>>>>>>> Den 19/12/15 kl. 00:39, skrev Tom Benson: >>>>>>>>> Hi Sangheon, >>>>>>>>> >>>>>>>>> On 12/18/2015 6:02 PM, sangheon wrote: >>>>>>>>>> Hi Tom, >>>>>>>>>> >>>>>>>>>> On 12/17/2015 04:23 PM, sangheon wrote: >>>>>>>>>>> Hi Tom, >>>>>>>>>>> >>>>>>>>>>> Thank you for reviewing this! >>>>>>>>>>> >>>>>>>>>>> On 12/17/2015 01:28 PM, Tom Benson wrote: >>>>>>>>>>>> Hi Sangheon, >>>>>>>>>>>> I like the new approach, but just have a couple of comments. >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I think you should check the VirtualQuery return status and >>>>>>>>>>>> return false >>>>>>>>>>>> from protect_pages_individually if zero. >>>>>>>>>>> Right. >>>>>>>>>>> I will fix this. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I don't *think* you need to have the "!UseLargePages" >>>>>>>>>>>> restriction >>>>>>>>>>>> anymore >>>>>>>>>>>> with this approach, do you? >>>>>>>>>>> protect_pages_individually() doesn't have previous >>>>>>>>>>> restriction on its >>>>>>>>>>> usage. >>>>>>>>>>> However I wanted to remain the caller(os::protect_memory) as is >>>>>>>>>>> because, as >>>>>>>>>>> you already mentioned below, I didn't want to have an >>>>>>>>>>> additional call of >>>>>>>>>>> VirtualQuery() for simpler code. >>>>>>>>>>> I don't have strong opinion on this. >>>>>>>>>>> >>>>>>>>>>> Let me post next webrev after concluding this. >>>>>>>>>> Tom, do you prefer to always use protect_pages_individually()? >>>>>>>>>> Does anyone have opinion on this? >>>>>>>>>> >>>>>>>>> >>>>>>>>> I'd vote for leaving the UseNUMAInterleaving test in. >>>>>>>>> Tom >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Sangheon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Sangheon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Actually, I think you could just always use >>>>>>>>>>>> protect_pages_individually >>>>>>>>>>>> regardless of whether UseNUMAInterleaving was enabled or >>>>>>>>>>>> not, and the >>>>>>>>>>>> right >>>>>>>>>>>> thing would happen. But this way, you save an unnecessary >>>>>>>>>>>> system call >>>>>>>>>>>> plus >>>>>>>>>>>> some overhead. >>>>>>>>>>>> Tom >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >> From jon.masamitsu at oracle.com Tue Dec 22 15:43:52 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 22 Dec 2015 07:43:52 -0800 Subject: RFR: JDK-8072725: Provide more granular levels for GC verification In-Reply-To: <56789BED.3020304@oracle.com> References: <56709EF7.9020003@oracle.com> <56787D5B.50806@oracle.com> <56789BED.3020304@oracle.com> Message-ID: <56796FB8.5040302@oracle.com> On 12/21/2015 4:40 PM, Poonam Bajaj Parhar wrote: > Hello Jon, > > On 12/21/2015 2:29 PM, Jon Masamitsu wrote: >> Poonam, >> >> Some of the string list parameters allow separation by , or " ". Did >> you consider adding that? >> > The VerifySubSet string list can accept the strings separated by comma > or a space. Before verification, we just need to check if a particular > subset is present in the VerifySubSet list or not. We don't need any > complicated processing of the strings list here. Ok. Thanks for the explanation. You mention in the RFR that you have a simple test to test the change. Can you add that as a jtreg test? I'm thinking about something like test/gc/TestVerifyDuringStartup.java test/gc/TestVerifySilently.java Jon > > Thanks, > Poonam > >> Jon >> >> PS. See share/vm/compiler/compilerDirectives.cpp >> >> ccstrlist DirectiveSet::canonicalize_disableintrinsic(ccstrlist >> option_value) >> >> >> On 12/15/2015 03:15 PM, Poonam Bajaj Parhar wrote: >>> Hello, >>> >>> Please review these changes that split up the work done under >>> Verify*GC options. This will be very useful in debugging GC >>> issues/crashes where verifying the whole memory system with >>> Verify*GC options slows down the process and makes it impossible to >>> reproduce the problem. >>> >>> The changes introduce a new option /VerifySubSet///that can be used >>> to specify the specific memory sub-systems that one wants to verify. >>> It can be one or more of the sub-systems from these: threads, heap, >>> symbol_table, string_table, codecache, dictionary, >>> classloader_data_graph, metaspace, jni_handles, c-heap and >>> codecache_oops. If nothing is specified with /VerifySubSet/ then >>> whole of the memory system is verified with Verify*GC options. >>> >>> Bug:JDK-8072725: >>> Provide more granular levels for GC verification >>> Webrev: http://cr.openjdk.java.net/~poonam/8072725/webrev.00/ >>> Testing: JPRT, tested the changes with a simple test program. >>> >>> Thanks, >>> Poonam >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sangheon.kim at oracle.com Tue Dec 22 17:48:35 2015 From: sangheon.kim at oracle.com (sangheon) Date: Tue, 22 Dec 2015 09:48:35 -0800 Subject: RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536 In-Reply-To: <56796D4A.2020700@oracle.com> References: <5670B5F1.7010505@oracle.com> <56717944.1030402@oracle.com> <56724973.4060405@oracle.com> <5673290E.7080106@oracle.com> <567351E9.40109@oracle.com> <567490A3.5020104@oracle.com> <56749942.10707@oracle.com> <5677E525.6060609@oracle.com> <56783B5E.2060001@oracle.com> <56784BAA.4070106@oracle.com> <567850BB.5070002@oracle.com> <5678727E.3040005@oracle.com> <56789B85.3040104@oracle.com> <5678A93B.6030808@oracle.com> <56794C9B.5030905@oracle.com> <56796D4A.2020700@oracle.com> Message-ID: <56798CF3.2070109@oracle.com> Hi Jesper and Tom, Thank you for reviewing this. Sangheon On 12/22/2015 07:33 AM, Tom Benson wrote: > Looks OK to me as well. > Tom > > On 12/22/2015 8:14 AM, Jesper Wilhelmsson wrote: >> Den 22/12/15 kl. 02:36, skrev sangheon: >>> Hi Jesper, >>> >>> On 12/21/2015 04:38 PM, Jesper Wilhelmsson wrote: >>>> Hi Sangheon, >>>> >>>> Just a comment about the assert in protect_pages_individually(). To >>>> me it >>>> looks strange to have an assert and then on the next line handle >>>> the case that >>>> was just asserted that it can't happen. Either we assume it can >>>> happen and >>>> handle it, or we say that it can't happen and assert that it doesn't. >>> I agree, assert is wrong. >>> And looking at current usage of os::protect_memory(), caller is >>> handling the >>> situation. >>> So I think 'warning' seems correct as the log is intended to show >>> which chunk is >>> making problem. >>> >>> - assert(ret, "Failed protecting chunk #%u", count); >>> + warning("Failed protecting chunk #%u", count); >>> >>> What do you think? >> >> Yes, a warning seems appropriate. >> Ship it! >> /Jesper >> >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> It would be nice if you either remove the assert or add a comment that >>>> explains why it is there. I do not need to re-review if you decide >>>> to do either. >>>> >>>> Besides that, looks good! >>>> /Jesper >>>> >>>> Den 21/12/15 kl. 22:43, skrev sangheon: >>>>> Hi all, >>>>> >>>>> Tom and I did some discussion(previously I misunderstood Tom's >>>>> comment) and >>>>> here's the next webrev which includes: >>>>> >>>>> 1. Call protect_pages_individually() when UseNUMAInterleaving is >>>>> enabled (Tom) >>>>> 2. Added a comment why we need to call >>>>> protect_pages_individually(). (Tom) >>>>> 3. Changed VirtualQuery() handling code. (Tom) >>>>> >>>>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.03 >>>>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.03_to_02 >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>> On 12/21/2015 11:19 AM, Tom Benson wrote: >>>>>> Hi, >>>>>> >>>>>> On 12/21/2015 1:57 PM, Jesper Wilhelmsson wrote: >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> I was under the impression that Tom wanted to keep the >>>>>>> UseNUMAInterleaving >>>>>>> test and not always call protect_pages_individually(). >>>>>> >>>>>> Yes, I'd said that was my vote, but wasn't adamant about it. If >>>>>> we agree, >>>>>> let's keep it. 8^) >>>>>> Tom >>>>>> >>>>>>> At least that's what I would prefer. If you revert that change I >>>>>>> think we >>>>>>> have something here :) >>>>>>> /Jesper >>>>>>> >>>>>>> >>>>>>> Den 21/12/15 kl. 18:48, skrev sangheon: >>>>>>>> Hi Jesper and Tom, >>>>>>>> >>>>>>>> Here's next webrev which includes below: >>>>>>>> - Check return value of VirtualQuery. (Tom, Jesper) >>>>>>>> - Always call protect_pages_individually() from >>>>>>>> os::protect_memory(). (Tom) >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.02 >>>>>>>> http://cr.openjdk.java.net/~sangheki/8145000/webrev.02_to_01/ >>>>>>>> >>>>>>>> Test: >>>>>>>> JPRT, RBT (hotspot/test/:hotspot_all,testlist,noncolo.testlist >>>>>>>> --add-tonga-keyword quick for Windows only) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>> >>>>>>>> On 12/21/2015 03:40 AM, Jesper Wilhelmsson wrote: >>>>>>>>> Hi Sangheon, >>>>>>>>> >>>>>>>>> I like this version a lot better. >>>>>>>>> I have no further comments except for what Tom already >>>>>>>>> mentioned about >>>>>>>>> checking VirtualQuery return value. >>>>>>>>> /Jesper >>>>>>>>> >>>>>>>>> >>>>>>>>> Den 19/12/15 kl. 00:39, skrev Tom Benson: >>>>>>>>>> Hi Sangheon, >>>>>>>>>> >>>>>>>>>> On 12/18/2015 6:02 PM, sangheon wrote: >>>>>>>>>>> Hi Tom, >>>>>>>>>>> >>>>>>>>>>> On 12/17/2015 04:23 PM, sangheon wrote: >>>>>>>>>>>> Hi Tom, >>>>>>>>>>>> >>>>>>>>>>>> Thank you for reviewing this! >>>>>>>>>>>> >>>>>>>>>>>> On 12/17/2015 01:28 PM, Tom Benson wrote: >>>>>>>>>>>>> Hi Sangheon, >>>>>>>>>>>>> I like the new approach, but just have a couple of comments. >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I think you should check the VirtualQuery return status >>>>>>>>>>>>> and return false >>>>>>>>>>>>> from protect_pages_individually if zero. >>>>>>>>>>>> Right. >>>>>>>>>>>> I will fix this. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I don't *think* you need to have the "!UseLargePages" >>>>>>>>>>>>> restriction >>>>>>>>>>>>> anymore >>>>>>>>>>>>> with this approach, do you? >>>>>>>>>>>> protect_pages_individually() doesn't have previous >>>>>>>>>>>> restriction on its >>>>>>>>>>>> usage. >>>>>>>>>>>> However I wanted to remain the caller(os::protect_memory) >>>>>>>>>>>> as is >>>>>>>>>>>> because, as >>>>>>>>>>>> you already mentioned below, I didn't want to have an >>>>>>>>>>>> additional call of >>>>>>>>>>>> VirtualQuery() for simpler code. >>>>>>>>>>>> I don't have strong opinion on this. >>>>>>>>>>>> >>>>>>>>>>>> Let me post next webrev after concluding this. >>>>>>>>>>> Tom, do you prefer to always use protect_pages_individually()? >>>>>>>>>>> Does anyone have opinion on this? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'd vote for leaving the UseNUMAInterleaving test in. >>>>>>>>>> Tom >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Sangheon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Sangheon >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Actually, I think you could just always use >>>>>>>>>>>>> protect_pages_individually >>>>>>>>>>>>> regardless of whether UseNUMAInterleaving was enabled or >>>>>>>>>>>>> not, and the >>>>>>>>>>>>> right >>>>>>>>>>>>> thing would happen. But this way, you save an unnecessary >>>>>>>>>>>>> system call >>>>>>>>>>>>> plus >>>>>>>>>>>>> some overhead. >>>>>>>>>>>>> Tom >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> > From sangheon.kim at oracle.com Wed Dec 23 02:15:25 2015 From: sangheon.kim at oracle.com (sangheon) Date: Tue, 22 Dec 2015 18:15:25 -0800 Subject: RFR(s): 8144527: NewSizeThreadIncrease would make an overflow In-Reply-To: <56791877.6040605@oracle.com> References: <5677A1A5.4000401@oracle.com> <56780E48.6030401@oracle.com> <56786011.1040804@oracle.com> <56789BAC.9070403@oracle.com> <56789BF9.90300@oracle.com> <56791877.6040605@oracle.com> Message-ID: <16E038B4-71A4-444A-9363-4DF0C9B519EC@oracle.com> Hi Mikael, Thank you for reviewing this. > On 12/22/2015 01:31 AM, Mikael Gerdin wrote: > Hi Sangheon, > >> On 12/22/2015 01:40 AM, sangheon wrote: >> Hi Jesper, >> >> Thank you for the review. >> >> Sangheon >> >> >>> On 12/21/2015 04:39 PM, Jesper Wilhelmsson wrote: >>> Looks good! >>> /Jesper >>> >>>> Den 21/12/15 kl. 21:24, skrev sangheon: >>>> Hi Jesper, >>>> >>>> Thank you for looking at this. >>>> >>>>> On 12/21/2015 06:35 AM, Jesper Wilhelmsson wrote: >>>>> Hi Sangheon, >>>>> >>>>> Did you consider a simpler approach with only nested ifs instead of the >>>>> do-while with breaks? At least to me, that would be easier to read. >>>> You are right. >>>> >>>> Here's updated webrev. >>>> http://cr.openjdk.java.net/~sangheki/8144527/webrev.01 > > Would you mind moving the code for NewSizeThreadIncrease to a method? > Something like "DefNewGeneration::adjust_for_thread_increase()" > > Otherwise it looks good. > (I'll be on vacation after today so I don't need to see a new webrev for the update) Okay. To make sure, I'm posting next webrev which includes Mikael's comment. Webrev: http://cr.openjdk.java.net/~sangheki/8144527/webrev.02 Testing: JPRT Thanks, Sangheon > /Mikael > >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> Besides that it looks good. >>>>> /Jesper >>>>> >>>>> >>>>>> Den 21/12/15 kl. 07:52, skrev sangheon: >>>>>> Hi all, >>>>>> >>>>>> Can I have reviews for this change to prevent an overflow for >>>>>> NewSizeThreadIncrease? >>>>>> >>>>>> This option is used with non-daemon threads count when calculate >>>>>> new size. And >>>>>> as we can't know the thread count at start-up time, this overflow >>>>>> can't be >>>>>> checked by argument validation framework. Instead I changed related >>>>>> routines to >>>>>> prevent the overflow and when it happens desired new size will be >>>>>> previous size. >>>>>> This will affect only for Serial GC. >>>>>> >>>>>> I added simple test to have 5 threads and then check the log >>>>>> whether we had heap >>>>>> expansion or not. >>>>>> >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8144527 >>>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8144527/webrev.00 >>>>>> Testing: JPRT >>>>>> >>>>>> Thanks, >>>>>> Sangheon -------------- next part -------------- An HTML attachment was scrubbed... URL: From michail.chernov at oracle.com Wed Dec 23 12:11:08 2015 From: michail.chernov at oracle.com (Michail Chernov) Date: Wed, 23 Dec 2015 15:11:08 +0300 Subject: RFR(s): 8144527: NewSizeThreadIncrease would make an overflow In-Reply-To: <16E038B4-71A4-444A-9363-4DF0C9B519EC@oracle.com> References: <5677A1A5.4000401@oracle.com> <56780E48.6030401@oracle.com> <56786011.1040804@oracle.com> <56789BAC.9070403@oracle.com> <56789BF9.90300@oracle.com> <56791877.6040605@oracle.com> <16E038B4-71A4-444A-9363-4DF0C9B519EC@oracle.com> Message-ID: <567A8F5C.2040806@oracle.com> Hi Shangheon, Could you please fix @requires tag. Should be: @requires vm.gc=="Serial" | vm.gc=="null" Also @requires tag should be placed with other tag in one /*..*/ comment, otherwise it doesn't work, see http://openjdk.java.net/jtreg/tag-spec.html#LEADING_COMMENTS . Thanks Michail >> > Okay. > > To make sure, I'm posting next webrev which includes Mikael's comment. > > Webrev: http://cr.openjdk.java.net/~sangheki/8144527/webrev.02 > Testing: JPRT > > Thanks, > Sangheon From sangheon.kim at oracle.com Wed Dec 23 15:44:52 2015 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Wed, 23 Dec 2015 07:44:52 -0800 Subject: RFR(s): 8144527: NewSizeThreadIncrease would make an overflow In-Reply-To: <567A8F5C.2040806@oracle.com> References: <5677A1A5.4000401@oracle.com> <56780E48.6030401@oracle.com> <56786011.1040804@oracle.com> <56789BAC.9070403@oracle.com> <56789BF9.90300@oracle.com> <56791877.6040605@oracle.com> <16E038B4-71A4-444A-9363-4DF0C9B519EC@oracle.com> <567A8F5C.2040806@oracle.com> Message-ID: <3883A862-9D36-44B0-B0A3-8023742684ED@oracle.com> Hi Michail, Thanks for the comment. > On Dec 23, 2015, at 4:11 AM, Michail Chernov wrote: > > Hi Shangheon, > > Could you please fix @requires tag. Should be: @requires vm.gc=="Serial" | vm.gc=="null" In this test, only serial gc is needed. Still 'null' is necessary? > > Also @requires tag should be placed with other tag in one /*..*/ comment, otherwise it doesn't work, see http://openjdk.java.net/jtreg/tag-spec.html#LEADING_COMMENTS . This is leftover for local test. :) All previous webrev versions were correct but not this one. Thanks, Sangheon > > Thanks > Michail > >> Okay. >> >> To make sure, I'm posting next webrev which includes Mikael's comment. >> >> Webrev: http://cr.openjdk.java.net/~sangheki/8144527/webrev.02 >> Testing: JPRT >> >> Thanks, >> Sangheon > From jon.masamitsu at oracle.com Wed Dec 23 16:32:03 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 23 Dec 2015 08:32:03 -0800 Subject: RFR: JDK-8145442: Add an option to verify remembered sets for G1 In-Reply-To: <56789831.8040305@oracle.com> References: <567086E1.7080501@oracle.com> <567494DB.1080201@oracle.com> <56789831.8040305@oracle.com> Message-ID: <567ACC83.50407@oracle.com> Poonam, Thanks for the changes. Looks good. Reviewed. Jon On 12/21/2015 4:24 PM, Poonam Bajaj Parhar wrote: > Hello Jon, > > Thanks for taking a look at the changes. Here's the updated webrev and > please see my comments inline: > http://cr.openjdk.java.net/~poonam/8145442/webrev.01/ > > On 12/18/2015 3:20 PM, Jon Masamitsu wrote: >> Poonam, >> >> Generally looks good. >> >> http://cr.openjdk.java.net/~poonam/8145442/webrev.00/src/share/vm/gc/g1/g1CollectedHeap.cpp.frames.html >> >> >> The new GC unified logging implementation has been pushed so you'll >> need to replace of gclog_or_tty(). >> >>> 4060 if (G1VerifyRSetsAfterEvacuationPause) { >>> 4061 gclog_or_tty->print("[Verifying RSets]"); >>> 4062 VerifyRegionRSetClosure v_cl; >>> 4063 heap_region_iterate(&v_cl); >>> 4064 } >> >> Probably with >> >> log_debug(gc, verify)("[Verifying RSets]"); >> >> > Done. Thanks for pointing out. > >> http://cr.openjdk.java.net/~poonam/8145442/webrev.00/src/share/vm/gc/g1/heapRegion.hpp.frames.html >> >> >>> 755 void verifyRSet(VerifyOption vo, bool *failures) const; >> >> Any comment worth adding for verifyRSet()? Are there conditions on >> where and >> when it can be used? > > Added a comment there. I don't think there is any specific condition > when it should be used. > It verifies the rem-set entries for that heap region. >> >> In verifyRSet() you always use VerifyOption_G1UsePrevMarking. Will >> that always >> be the value for the VerifyOption? If it is always going to be that, >> does it work >> to remove the VerifyOption parameter from verifyRSet() and has >> verifyRSet() >> always pass VerifyOption_G1UsePrevMarking to VerifyRSetClosure? >> > Currently it is only VerifyOption_G1UsePrevMarking that is being > passed to this function. But I would > prefer to leave it like this to keep it consistent with the verify() > funtion: > > void verify(VerifyOption vo, bool *failures) const; > > The comments for verify() in heapRegion.hpp are true for verifyRSet() > too. > >> http://cr.openjdk.java.net/~poonam/8145442/webrev.00/src/share/vm/gc/g1/heapRegion.cpp.frames.html >> >> >> 917 VerifyRSetClosure v_rset_cl(g1, VerifyOption_G1UsePrevMarking); >> >> I can see HeapRegionVerifyClosure::verifyRemSets() is used and it >> works out >> well but it seems odd for HeapRegionVerifyClosure (which has a name >> that I read as generally useful with different Verify closures) to have >> a method that is specific to remembered-set verification. >> >> I think it is like this. >> >> HeapRegionVerifyClosure had a verifyRemSets() method that is >> called from do_oop in VerifyRSetClosure and VerifyLiveClosure. >> >> Then when you want to do remembered-set verification you >> use a VerifyRSetClosure and when you want to verify liveness, >> you use a VerifyLiveClosure and get the remembered-set >> verfication included in the VerifyLiveClosure. >> >> An alternative would be to put verifyRemSets() into VerifyRSetClosure >> and have a VerifyRSetClosure as part of the VerifyLiveClosure. Then >> instead of calling verifyRemSets() (as inherited from >> HeapRegionVerifyClosure) >> in VerifyLiveClosure, you could call verifyRemSets() using the embedded >> VerifyRSetClosure. >> >> Or you could collapse HeapRegionVerifyClosure and VerifyRSetClosure >> together (give it the name VerifyRSetClosure so that having a >> verifyRemSets() >> seems more natural) and derive VerifyLiveClosure from the new >> VerifyRSetClosure. >> > I like the second alternative better. I have made the changes in the > latest webrev to this effect. > > Please take a look at the new webrev and let me know your feedback. > > Thanks, > Poonam > >> Jon >> >> On 12/15/2015 1:32 PM, Poonam Bajaj Parhar wrote: >>> Hello, >>> >>> Please review these changes that add a diagnostic VM option >>> 'G1VerifyRSetsAfterEvacuationPause' that when turned on enables the >>> verification of Rem Sets of heap regions. >>> >>> Bug: JDK-8145442: Add an option to verify remembered sets for G1 >>> Webrev: http://cr.openjdk.java.net/~poonam/8145442/webrev.00/ >>> Testing: JPRT, GCBasher >>> >>> Thanks, >>> Poonam >>> >> > From sangheon.kim at oracle.com Wed Dec 23 17:06:09 2015 From: sangheon.kim at oracle.com (sangheon) Date: Wed, 23 Dec 2015 09:06:09 -0800 Subject: RFR(s): 8144527: NewSizeThreadIncrease would make an overflow In-Reply-To: <3883A862-9D36-44B0-B0A3-8023742684ED@oracle.com> References: <5677A1A5.4000401@oracle.com> <56780E48.6030401@oracle.com> <56786011.1040804@oracle.com> <56789BAC.9070403@oracle.com> <56789BF9.90300@oracle.com> <56791877.6040605@oracle.com> <16E038B4-71A4-444A-9363-4DF0C9B519EC@oracle.com> <567A8F5C.2040806@oracle.com> <3883A862-9D36-44B0-B0A3-8023742684ED@oracle.com> Message-ID: <567AD481.5000800@oracle.com> Hi Michail again, I thought previous versions are fine, but they aren't. I know that it will not work and this is why I temporarily moved to below line for local test. But I will fix it before push. Thanks, Sangheon On 12/23/2015 07:44 AM, sangheon.kim at oracle.com wrote: > Hi Michail, > > Thanks for the comment. > >> On Dec 23, 2015, at 4:11 AM, Michail Chernov wrote: >> >> Hi Shangheon, >> >> Could you please fix @requires tag. Should be: @requires vm.gc=="Serial" | vm.gc=="null" > In this test, only serial gc is needed. > Still 'null' is necessary? > >> Also @requires tag should be placed with other tag in one /*..*/ comment, otherwise it doesn't work, see http://openjdk.java.net/jtreg/tag-spec.html#LEADING_COMMENTS . > This is leftover for local test. :) > All previous webrev versions were correct but not this one. > > Thanks, > Sangheon > > >> Thanks >> Michail >> >>> Okay. >>> >>> To make sure, I'm posting next webrev which includes Mikael's comment. >>> >>> Webrev: http://cr.openjdk.java.net/~sangheki/8144527/webrev.02 >>> Testing: JPRT >>> >>> Thanks, >>> Sangheon From poonam.bajaj at oracle.com Wed Dec 23 17:26:33 2015 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Wed, 23 Dec 2015 09:26:33 -0800 Subject: RFR: JDK-8072725: Provide more granular levels for GC verification In-Reply-To: <56796FB8.5040302@oracle.com> References: <56709EF7.9020003@oracle.com> <56787D5B.50806@oracle.com> <56789BED.3020304@oracle.com> <56796FB8.5040302@oracle.com> Message-ID: <567AD949.204@oracle.com> Hello Jon, I have added a testcase to test the VerifySubSet option: http://cr.openjdk.java.net/~poonam/8072725/webrev.01/ Here, I run the test with one set of VerifySubSet options, and then check the output that those sub-systems were verified and the ones not specified were not verified. Thanks, Poonam On 12/22/2015 7:43 AM, Jon Masamitsu wrote: > > > On 12/21/2015 4:40 PM, Poonam Bajaj Parhar wrote: >> Hello Jon, >> >> On 12/21/2015 2:29 PM, Jon Masamitsu wrote: >>> Poonam, >>> >>> Some of the string list parameters allow separation by , or " ". Did >>> you consider adding that? >>> >> The VerifySubSet string list can accept the strings separated by >> comma or a space. Before verification, we just need to check if a >> particular subset is present in the VerifySubSet list or not. We >> don't need any complicated processing of the strings list here. > > Ok. Thanks for the explanation. > > You mention in the RFR that you have a simple test to test the > change. Can you add that as a jtreg test? I'm thinking about > something like > > test/gc/TestVerifyDuringStartup.java > test/gc/TestVerifySilently.java > > Jon > >> >> Thanks, >> Poonam >> >>> Jon >>> >>> PS. See share/vm/compiler/compilerDirectives.cpp >>> >>> ccstrlist DirectiveSet::canonicalize_disableintrinsic(ccstrlist >>> option_value) >>> >>> >>> On 12/15/2015 03:15 PM, Poonam Bajaj Parhar wrote: >>>> Hello, >>>> >>>> Please review these changes that split up the work done under >>>> Verify*GC options. This will be very useful in debugging GC >>>> issues/crashes where verifying the whole memory system with >>>> Verify*GC options slows down the process and makes it impossible to >>>> reproduce the problem. >>>> >>>> The changes introduce a new option /VerifySubSet///that can be used >>>> to specify the specific memory sub-systems that one wants to >>>> verify. It can be one or more of the sub-systems from these: >>>> threads, heap, symbol_table, string_table, codecache, dictionary, >>>> classloader_data_graph, metaspace, jni_handles, c-heap and >>>> codecache_oops. If nothing is specified with /VerifySubSet/ then >>>> whole of the memory system is verified with Verify*GC options. >>>> >>>> Bug:JDK-8072725: >>>> Provide more granular levels for GC verification >>>> Webrev: http://cr.openjdk.java.net/~poonam/8072725/webrev.00/ >>>> Testing: JPRT, tested the changes with a simple test program. >>>> >>>> Thanks, >>>> Poonam >>>> >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Wed Dec 23 17:53:21 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 23 Dec 2015 09:53:21 -0800 Subject: RFR: JDK-8072725: Provide more granular levels for GC verification In-Reply-To: <567AD949.204@oracle.com> References: <56709EF7.9020003@oracle.com> <56787D5B.50806@oracle.com> <56789BED.3020304@oracle.com> <56796FB8.5040302@oracle.com> <567AD949.204@oracle.com> Message-ID: <567ADF91.7020205@oracle.com> On 12/23/2015 9:26 AM, Poonam Bajaj Parhar wrote: > Hello Jon, > > I have added a testcase to test the VerifySubSet option: > http://cr.openjdk.java.net/~poonam/8072725/webrev.01/ > > Here, I run the test with one set of VerifySubSet options, and then > check the output that those sub-systems were verified and the ones not > specified were not verified. Excellent. Thanks for adding the test. Reviewed. Jon > > Thanks, > Poonam > > On 12/22/2015 7:43 AM, Jon Masamitsu wrote: >> >> >> On 12/21/2015 4:40 PM, Poonam Bajaj Parhar wrote: >>> Hello Jon, >>> >>> On 12/21/2015 2:29 PM, Jon Masamitsu wrote: >>>> Poonam, >>>> >>>> Some of the string list parameters allow separation by , or " ". Did >>>> you consider adding that? >>>> >>> The VerifySubSet string list can accept the strings separated by >>> comma or a space. Before verification, we just need to check if a >>> particular subset is present in the VerifySubSet list or not. We >>> don't need any complicated processing of the strings list here. >> >> Ok. Thanks for the explanation. >> >> You mention in the RFR that you have a simple test to test the >> change. Can you add that as a jtreg test? I'm thinking about >> something like >> >> test/gc/TestVerifyDuringStartup.java >> test/gc/TestVerifySilently.java >> >> Jon >> >>> >>> Thanks, >>> Poonam >>> >>>> Jon >>>> >>>> PS. See share/vm/compiler/compilerDirectives.cpp >>>> >>>> ccstrlist DirectiveSet::canonicalize_disableintrinsic(ccstrlist >>>> option_value) >>>> >>>> >>>> On 12/15/2015 03:15 PM, Poonam Bajaj Parhar wrote: >>>>> Hello, >>>>> >>>>> Please review these changes that split up the work done under >>>>> Verify*GC options. This will be very useful in debugging GC >>>>> issues/crashes where verifying the whole memory system with >>>>> Verify*GC options slows down the process and makes it impossible >>>>> to reproduce the problem. >>>>> >>>>> The changes introduce a new option /VerifySubSet///that can be >>>>> used to specify the specific memory sub-systems that one wants to >>>>> verify. It can be one or more of the sub-systems from these: >>>>> threads, heap, symbol_table, string_table, codecache, dictionary, >>>>> classloader_data_graph, metaspace, jni_handles, c-heap and >>>>> codecache_oops. If nothing is specified with /VerifySubSet/ then >>>>> whole of the memory system is verified with Verify*GC options. >>>>> >>>>> Bug:JDK-8072725: >>>>> Provide more >>>>> granular levels for GC verification >>>>> Webrev: http://cr.openjdk.java.net/~poonam/8072725/webrev.00/ >>>>> Testing: JPRT, tested the changes with a simple test program. >>>>> >>>>> Thanks, >>>>> Poonam >>>>> >>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michail.chernov at oracle.com Thu Dec 24 12:02:22 2015 From: michail.chernov at oracle.com (Michail Chernov) Date: Thu, 24 Dec 2015 15:02:22 +0300 Subject: RFR(s): 8144527: NewSizeThreadIncrease would make an overflow In-Reply-To: <3883A862-9D36-44B0-B0A3-8023742684ED@oracle.com> References: <5677A1A5.4000401@oracle.com> <56780E48.6030401@oracle.com> <56786011.1040804@oracle.com> <56789BAC.9070403@oracle.com> <56789BF9.90300@oracle.com> <56791877.6040605@oracle.com> <16E038B4-71A4-444A-9363-4DF0C9B519EC@oracle.com> <567A8F5C.2040806@oracle.com> <3883A862-9D36-44B0-B0A3-8023742684ED@oracle.com> Message-ID: <567BDECE.1040009@oracle.com> Hi Sangheon, Yes, 'null' allows to execute tests with default collector, because you use -XX:+UseSerialGC explicitly in your test. If you use only 'Serial', test won't be executed with default collector. You can see at hotspot/test/gc/g1/* - there are a lot of similar usage of vm.gc in @requires tag. Thanks Michail On 23.12.2015 18:44, sangheon.kim at oracle.com wrote: > Hi Michail, > > Thanks for the comment. > >> On Dec 23, 2015, at 4:11 AM, Michail Chernov wrote: >> >> Hi Shangheon, >> >> Could you please fix @requires tag. Should be: @requires vm.gc=="Serial" | vm.gc=="null" > In this test, only serial gc is needed. > Still 'null' is necessary? > >> Also @requires tag should be placed with other tag in one /*..*/ comment, otherwise it doesn't work, see http://openjdk.java.net/jtreg/tag-spec.html#LEADING_COMMENTS . > This is leftover for local test. :) > All previous webrev versions were correct but not this one. > > Thanks, > Sangheon > > >> Thanks >> Michail >> >>> Okay. >>> >>> To make sure, I'm posting next webrev which includes Mikael's comment. >>> >>> Webrev: http://cr.openjdk.java.net/~sangheki/8144527/webrev.02 >>> Testing: JPRT >>> >>> Thanks, >>> Sangheon From sky1young at gmail.com Thu Dec 24 15:15:23 2015 From: sky1young at gmail.com (ray alex) Date: Thu, 24 Dec 2015 23:15:23 +0800 Subject: [PATCH] enhancement to ParallelScavenge Full GC In-Reply-To: <56781BEC.7030404@oracle.com> References: <1450104486.2316.46.camel@oracle.com> <1450111786.11162.34.camel@oracle.com> <56703CA3.9050605@oracle.com> <56781BEC.7030404@oracle.com> Message-ID: Hi Mikael, Thomas, According to your recommendation, I have put all the cache-related variables in the ParCompactionManager class. Now that we do not need to modify the Thread class anymore. May I have your reviews on this new patch? 2015-12-21 23:34 GMT+08:00 Mikael Gerdin : > Hi, > > On 2015-12-21 16:09, ray alex wrote: > >> Hi Thomas, Mikael, >> >> I've refined the code based on your recommendations on the code style. >> >> However, in my opinion, to provide an additional context in GCThread >> instead of Thread may lead to massive modifications >> >> and I'm not sure if it may bring some impact on the correctness of other >> codes. >> So I have not revised this part so far, in order to keep our patch pure >> and independent. >> (Or maybe it's because I did not quite catch your ideas?) >> >> May I have your reviews on the new patch? >> > > It may be that your patch works, but one of the issues with working with > such a large code base as this is to not just make changes which are > functionally correct, but they also need to "fit in" and make sense with > how the rest of the code works. > > Putting 3 member variables in the Thread superclass just because a small > phase of one of the garbage collectors needs some thread local state does > not "fit in". > > In HotSpot, all the garbage collectors maintain their thread-local state > by passing explicit context parameters. > I think that the only solution which makes sense for the fix to > ParallelCompact is to modify > ParCompactionManager::update_contents(oop obj) > to pass itself like this: > obj->pc_update_contents(this); > > and modifying > oopDesc::pc_update_contents(ParCompactionManager* cm) > to pass it on: > k->oop_pc_update_pointers(this, cm); > > and modify all Klass subclasses to use the new parameter such as > > void InstanceKlass::oop_pc_update_pointers(oop obj, ParCompactionManager* > cm) { > PSParallelCompact::AdjustPointerClosre closure(cm); > oop_oop_iterate_oop_maps(obj, &cm); > } > > That way the call > oop new_obj = (oop)summary_data().calc_new_pointer(obj); > in AdjustPointerClosure > can pass the "cm" parameter on to live_words_in_range. > > /Mikael > > > >> >> >> 2015-12-16 0:15 GMT+08:00 Mikael Gerdin > >: >> >> Hi, >> >> >> On 2015-12-14 17:49, Thomas Schatzl wrote: >> >> Hi, >> >> On Mon, 2015-12-14 at 23:57 +0800, ray alex wrote: >> >> Thanks, Thomas! >> >> I will refine my code carefully according to your >> suggestions as soon >> as possible. >> >> >> Thanks. >> >> >> Since I'm new in contributing to OpenJDK, actually I'm not >> sure how to >> upload when my new code is ready? >> Just upload an attach of diffs as I did, or some other >> ways? >> >> >> The best way as long as we have no confirmation about the OCA >> signing, >> is to attach a patch (or a webrev, see >> http://openjdk.java.net/contribute/) and send it to this list. >> Later it >> will be more convenient to send me a patch that I will convert >> into a >> webrev and put on cr.openjdk.java.net > >. >> >> As soon as you have two contributions, you can upload patches >> yourselves >> onto your own account on cr.openjdk.java.net >> . >> >> >> >> Besides, I'm currently processing my signed OCA for the >> committer >> rights, >> I'm not sure how long it will take, does it matter? >> >> >> The OCA is only for us to be able to accept your patch in >> Hotspot. The >> various levels of contributor status are a different matter, and >> signify >> your level of expertise within the community. >> >> See also http://openjdk.java.net/contribute/ for more >> information. >> >> As for the VM Thread, it does a serial adjust_roots() within >> the >> current thread (VM thread) during >> PSParallelCompact::invoke_no_policy(). >> I think psCompactionManager.cpp:117 and the surrounding >> comments >> confirm the use of VMThread in full GC. >> Do you agree with my above understanding of the use of >> VMThread? >> >> You are right :( >> >> There are multiple options to provide an additional per-thread >> context: >> >> - passing around some context. Looks like lots of work. >> >> >> I actually think this is the correct way to go. >> In my mind you would only have to change >> ParCompactionMangager::update_contents to pass on the >> ParCompactionManager* through oopDesc::pc_update_contents to >> *Klass::oop_pc_update_contents >> It's similar to how the marking phase passes around the current >> worker's compaction manager. >> >> Then the AdjustPointerClosure needs to become a >> per-ParCompactionManager thing and then it's all set :) >> >> /Mikael >> >> >> >> - change the code so that even that serial portion is performed >> by some >> GCTaskThread (which actually sounds best to me) >> - Another would be to add a field to both GCTaskThread and >> VMThread, and >> via a virtual method in Thread get the necessary values. >> - make VMThread a WorkerThread (that has an id that can be used >> to query >> an extra data structure for this cache) >> - others >> >> Let's see if other people have a better idea. >> >> Thanks, >> Thomas >> >> >> >> >> >> >> >> -- >> Lei Tianyang >> >> > -- Lei Tianyang -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: parallelScavenge_v3.patch Type: text/x-patch Size: 25507 bytes Desc: not available URL: From sangheon.kim at oracle.com Thu Dec 24 17:03:26 2015 From: sangheon.kim at oracle.com (sangheon) Date: Thu, 24 Dec 2015 09:03:26 -0800 Subject: RFR(s): 8144527: NewSizeThreadIncrease would make an overflow In-Reply-To: <567BDECE.1040009@oracle.com> References: <5677A1A5.4000401@oracle.com> <56780E48.6030401@oracle.com> <56786011.1040804@oracle.com> <56789BAC.9070403@oracle.com> <56789BF9.90300@oracle.com> <56791877.6040605@oracle.com> <16E038B4-71A4-444A-9363-4DF0C9B519EC@oracle.com> <567A8F5C.2040806@oracle.com> <3883A862-9D36-44B0-B0A3-8023742684ED@oracle.com> <567BDECE.1040009@oracle.com> Message-ID: <567C255E.6010506@oracle.com> Hi Michail, On 12/24/2015 04:02 AM, Michail Chernov wrote: > Hi Sangheon, > > Yes, 'null' allows to execute tests with default collector, because > you use -XX:+UseSerialGC explicitly in your test. If you use only > 'Serial', test won't be executed with default collector. You can see > at hotspot/test/gc/g1/* - there are a lot of similar usage of vm.gc in > @requires tag. Okay, I will fix it. That is my understanding regarding "null = default collector" and I wanted to run only for serial. But as you said, as I explicitly set "UseSerialGC" in the test, I will fix as you mentioned. Webrev: http://cr.openjdk.java.net/~sangheki/8144527/webrev.03 Thanks, Sangheon > > Thanks > Michail > > On 23.12.2015 18:44, sangheon.kim at oracle.com wrote: >> Hi Michail, >> >> Thanks for the comment. >> >>> On Dec 23, 2015, at 4:11 AM, Michail Chernov >>> wrote: >>> >>> Hi Shangheon, >>> >>> Could you please fix @requires tag. Should be: @requires >>> vm.gc=="Serial" | vm.gc=="null" >> In this test, only serial gc is needed. >> Still 'null' is necessary? >> >>> Also @requires tag should be placed with other tag in one /*..*/ >>> comment, otherwise it doesn't work, see >>> http://openjdk.java.net/jtreg/tag-spec.html#LEADING_COMMENTS . >> This is leftover for local test. :) >> All previous webrev versions were correct but not this one. >> >> Thanks, >> Sangheon >> >> >>> Thanks >>> Michail >>> >>>> Okay. >>>> >>>> To make sure, I'm posting next webrev which includes Mikael's comment. >>>> >>>> Webrev: http://cr.openjdk.java.net/~sangheki/8144527/webrev.02 >>>> Testing: JPRT >>>> >>>> Thanks, >>>> Sangheon > From michail.chernov at oracle.com Thu Dec 24 17:18:12 2015 From: michail.chernov at oracle.com (Michail Chernov) Date: Thu, 24 Dec 2015 20:18:12 +0300 Subject: RFR(s): 8144527: NewSizeThreadIncrease would make an overflow In-Reply-To: <567C255E.6010506@oracle.com> References: <5677A1A5.4000401@oracle.com> <56780E48.6030401@oracle.com> <56786011.1040804@oracle.com> <56789BAC.9070403@oracle.com> <56789BF9.90300@oracle.com> <56791877.6040605@oracle.com> <16E038B4-71A4-444A-9363-4DF0C9B519EC@oracle.com> <567A8F5C.2040806@oracle.com> <3883A862-9D36-44B0-B0A3-8023742684ED@oracle.com> <567BDECE.1040009@oracle.com> <567C255E.6010506@oracle.com> Message-ID: <567C28D4.70108@oracle.com> Hi Sangheon, Changes look good to me. Thanks Michail On 24.12.2015 20:03, sangheon wrote: > Hi Michail, > > On 12/24/2015 04:02 AM, Michail Chernov wrote: >> Hi Sangheon, >> >> Yes, 'null' allows to execute tests with default collector, because >> you use -XX:+UseSerialGC explicitly in your test. If you use only >> 'Serial', test won't be executed with default collector. You can see >> at hotspot/test/gc/g1/* - there are a lot of similar usage of vm.gc >> in @requires tag. > Okay, I will fix it. > That is my understanding regarding "null = default collector" and I > wanted to run only for serial. But as you said, as I explicitly set > "UseSerialGC" in the test, I will fix as you mentioned. > > Webrev: http://cr.openjdk.java.net/~sangheki/8144527/webrev.03 > > Thanks, > Sangheon >> >> Thanks >> Michail >> >> On 23.12.2015 18:44, sangheon.kim at oracle.com wrote: >>> Hi Michail, >>> >>> Thanks for the comment. >>> >>>> On Dec 23, 2015, at 4:11 AM, Michail Chernov >>>> wrote: >>>> >>>> Hi Shangheon, >>>> >>>> Could you please fix @requires tag. Should be: @requires >>>> vm.gc=="Serial" | vm.gc=="null" >>> In this test, only serial gc is needed. >>> Still 'null' is necessary? >>> >>>> Also @requires tag should be placed with other tag in one /*..*/ >>>> comment, otherwise it doesn't work, see >>>> http://openjdk.java.net/jtreg/tag-spec.html#LEADING_COMMENTS . >>> This is leftover for local test. :) >>> All previous webrev versions were correct but not this one. >>> >>> Thanks, >>> Sangheon >>> >>> >>>> Thanks >>>> Michail >>>> >>>>> Okay. >>>>> >>>>> To make sure, I'm posting next webrev which includes Mikael's >>>>> comment. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8144527/webrev.02 >>>>> Testing: JPRT >>>>> >>>>> Thanks, >>>>> Sangheon >> > > From kim.barrett at oracle.com Mon Dec 28 23:43:09 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 28 Dec 2015 18:43:09 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <56749A59.9060108@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> <56749A59.9060108@oracle.com> Message-ID: <260B99B3-7A01-4C85-8B96-E5ABEEBA68A1@oracle.com> On Dec 18, 2015, at 6:44 PM, Jon Masamitsu wrote: > > On 12/17/2015 1:30 PM, Kim Barrett wrote: >> Here's the latest set of webrevs: >> http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06/ >> http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.06/ > > The hotspot change is as advertized. Reviewed. > > Jon Thanks! From dmitry.fazunenko at oracle.com Wed Dec 30 16:43:22 2015 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 30 Dec 2015 19:43:22 +0300 Subject: RFR: 8134963 [Newtests] New tests for G1 remembered set up and down In-Reply-To: <56461E54.7080105@oracle.com> References: <5645FE96.10800@oracle.com> <56461E54.7080105@oracle.com> Message-ID: <568409AA.8030203@oracle.com> Hi everyone, An updated version of the stress test for Remembered Set: http://cr.openjdk.java.net/~dfazunen/8134963/webrev.03/ Tested in RBT in many configurations. Many thanks to Thomas for his offline comments. Happy New Year! Dima On 13.11.2015 20:31, Dmitry Fazunenko wrote: > I was noticed that this is a stress test and should be properly marked > with "@key stress" > The test was also moved from test/gc/g1/ to tests/stress/gc. > > New webrev: http://cr.openjdk.java.net/~dfazunen/8134963/webrev.02/ > > If you are interested in how an output from the test will look like: > ----------System.out:(17/502)---------- > %% Memory > %% used : 2M > %% available : 2045M > %% to allocate : 1840M > %% G1 Region Size: 1M > %% Objects: > %% Number of objects: 18400 > %% objects in region: 10 > %% N (array length) : 26210 > %% Reference size : 4 > %% Approximate size : 104840(102K) > %% Reference number : 1840 > %% Execution: > %% Number of iterations: 15 > %% Time spent: 10seconds > %% Free memory left: 195M > %% Test passed > > Thanks, > Dima > ----------System.err:(1/15)---------- > > On 13.11.2015 18:15, Dmitry Fazunenko wrote: >> Hi everyone, >> >> Can I have a couple of reviews for the new test for G1 Remembered Set: >> >> https://bugs.openjdk.java.net/browse/JDK-8134963 >> http://cr.openjdk.java.net/~dfazunen/8134963/ >> >> The test creates a lot of cross region references (making RSet to >> grow up) and then clear that references up. >> The test doesn't check any particular assertions, it just expects >> that there will be no crash. >> >> Thanks, >> Dima >