From john.cuthbertson at oracle.com Wed May 2 07:14:39 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 02 May 2012 00:14:39 -0700 Subject: G1 feedback: adaptive size problems ? In-Reply-To: References: Message-ID: <4FA0DEDF.4080409@oracle.com> Hi Simone, Thanks for trying out G1. I'll try and answer your questions. On 4/30/2012 6:15 AM, Simone Bordet wrote: > Hi, > > using JDK 1.7.0_04, Ubuntu Linux 12.04 64 bit, attached you can find > the GC log of my Java IDE. > > Startup options: > > -Xmx1024m > -Xms1024m > -Xmn512m > -XX:+UseG1GC > -XX:MaxGCPauseMillis=200 > -XX:+PrintGCDetails > -XX:+PrintGCDateStamps > -XX:MaxPermSize=256m > -XX:ReservedCodeCacheSize=64m > -ea > > I noticed that sometimes G1 performs a "to-space overflow" collections > that last way more than the target pause (in my case, up to 3+ > seconds), and that after these kind of pauses the survivor spaces get > a big size reduction (e.g from 64 MiB to 6 MiB), which causes more > "to-space overflow" collections until a Full GC seems to restore > normal conditions. "to-space overflow" is what we call an evacuation failure or promotion failure. This happens when we run out of heap regions during the GC (for either/both survivors and promoted objects). As you can see this can be expensive. When an evacuation failure occurs, the GC still has to continue - we have a mixture of successfully and unsuccessfully copied objects and we have to fixup references to the objects that were successfully copied. Objects that were not successfully copied are effectively tenured in place. Any updates to remembered sets of regions in the collection set (which we would ordinarily discard) have to be regenerated. As a result of the in-place tenuring, the old generation occupancy will increase (hopefully temporarily). Also if the evacuation failure occurs during marking - the in-place tenuring may make some regions look like bad candidates for collection during the following set of mixed GCs (it can look like they are fairly full of live data and hence expensive to collect). There are a few things to try and stop the evacuation failure. The first is increase the heap size. Another is to increase G1ReservePercent (default 10). This flag creates a false ceiling in the heap and increasing that ceiling can reduce evacuation failures; decreasing it might allow the heap to expand a little - which may be enough to get the application running on the verge of getting an evacuation failure but without actually getting one. Starting marking earlier by reducing InitiatingHeapOccupancyPercent (default 45) or increasing the number of marking threads (ConcGCThreads) may help marking complete earlier and free up some space at the end of marking. > At one point I see in the log this entry: > > [Eden: 0B(512M)->0B(512M) Survivors: 0B->0B Heap: 1002M(1024M)->1002M(1024M)] This looks weird but indicates an empty collection set - most likely because we can't allocate a region for the application to allocate into. I'll take a look at the full GC log and see if any other suggestions come to mind. Regards, JohnC From rednaxelafx at gmail.com Thu May 3 07:24:17 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 3 May 2012 15:24:17 +0800 Subject: bad narrowOop in objArrayKlass::oop_oop_iterate_nv Message-ID: Hi all, A couple of our servers in production has hit a segfault during minor GC in a ParNew/CMS configuration, with compressed oops on. The symptom looks pretty much alike some crashes we hit last year, and the same problem may have showed up on this list and hotspot-gc-use list already [1][2]. But I couldn't find the bug ID that matches this symptom. Does anybody know if this is a known bug, if so, is it fixed yet? Right now I've upgraded one of the crashing servers to JDK6u32/HS20, hoping that the problem doesn't reproduce in this version. Detail description: Environment: JRE version: 6.0_23-b05 Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b09 mixed mode linux-amd64 compressed oops) RHEL 5.4 SIGSEGV at 0x0000000000000030 in a GCTaskThread. Relevant VM args: -Xms4g -Xmx4g -XX:PermSize=96m -XX:MaxPermSize=256m -Xmn2000m -XX:MaxTenuringThreshold=5 -XX:+UseConcMarkSweepGC -XX:+UseCompressedOops -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -Xloggc:/home/admin/logs/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow -XX:+DoEscapeAnalysis Relevant stack trace: V [libjvm.so+0x3e62c3] (unsigned int*, bool, bool)+0x63> V [libjvm.so+0x60bc83] V [libjvm.so+0x6318d4] V [libjvm.so+0x6323ce] V [libjvm.so+0x632626] V [libjvm.so+0x78018d] V [libjvm.so+0x7800a4] V [libjvm.so+0x623e1f] Debugging the core dump, I was able to track down the object in question in objArrayKlass::oop_oop_iterate_nv(): (gdb) x/3g 0x760cba7a8 # String[] of length 1 0x760cba7a8: 0x0000000000000009 0x00000001fe01c4c7 0x760cba7b8: 0x0000000000000005 Which is a String array of length 1. The sole element in this array is a narrowOop 0x00000005, which is definitely a bad pointer. The segfault site was dereferencing the uncompressed value of this pointer (0x30 == 0x05 << 3). I don't have any idea yet how this bad pointer came into being, hard to tell just from a core dump. This is a production site server so I can't turn on heap verification on it, either. Worse, no repros in our development environment. Ramki mentioned the following in a reply to [1]: On Mon, Apr 18, 2011 at 11:31 PM, Y. Srinivas Ramakrishna < y.s.ramakrishna at oracle.com> wrote: > i wonder if it's an issue with array copy stubs which leave random > junk in some locations of the array, or if there's a race that causes > some locations to transiently have bad data. Seems unlikely, but the > involvement of object arrays raises some suspicions. I'll see if any > array copying bugs have surfaced or been fixed recently although none > comes readily to mind... > > PS: if it's production runs, you won't be able to use heap verification, > but if you have a test load that reproduces the problem, may be > heap verification might give us some clues (although given the nature of > the problem, I am not hopeful). If you have a support contract, > I'd suggest filing an official ticket and sending in a couple of core > files, if you have any sitting around. That may be the only way to > make progress on this kind of issue. > > -- ramki I could investigate further with this core dump at hand. Any instructions/suggestions would be appriciated :-) I can provide other relevant information as needed. (I'm sorry I can't attach the full crash log in this mail because there's confidential information in it.) Regards, Kris [1]: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-April/002535.html [2]: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-September/003133.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbordet at intalio.com Thu May 3 08:59:04 2012 From: sbordet at intalio.com (Simone Bordet) Date: Thu, 3 May 2012 10:59:04 +0200 Subject: G1 feedback: adaptive size problems ? In-Reply-To: <4FA0DEDF.4080409@oracle.com> References: <4FA0DEDF.4080409@oracle.com> Message-ID: Hi, On Wed, May 2, 2012 at 9:14 AM, John Cuthbertson wrote: > Hi Simone, > > Thanks for trying out G1. I'll try and answer your questions. Thank you for getting back to me. > "to-space overflow" is what we call an evacuation failure or promotion > failure. This happens when we run out of heap regions during the GC (for > either/both survivors and promoted objects). As you can see this can be > expensive. When an evacuation failure occurs, the GC still has to continue - > we have a mixture of successfully and unsuccessfully copied objects and we > have to fixup references to the objects that were successfully copied. > ?Objects that were not successfully copied are effectively tenured in place. > Any updates to remembered sets of regions in the collection set (which we > would ordinarily discard) have to be regenerated. > > As a result of the in-place tenuring, the old generation occupancy will > increase (hopefully temporarily). Also if the evacuation failure occurs > during marking - the in-place tenuring may make some regions look like bad > candidates for collection during the following set of mixed GCs (it can look > like they are fairly full of live data and hence expensive to collect). Seems like a condition to avoid at all costs, since it's so expensive. > There are a few things to try and stop the evacuation failure. The first is > increase the heap size. Right. I doubled the sizes, and I could run the whole day with just young GCs, but the target GC pause was mostly never respected, and I had worst cases up to 500+ ms (target = 200 ms). While I understand is a soft limit, it was mostly respected with a 1 GiB heap. However, other algorithms (ParallelOld, CMS and JRockit's deterministic, in particular the latter) do well with 1 GiB heap. Perhaps I am pushing G1 to its low-end limit here, as I understand G1 targets larger heaps ? But then why would the pauses be that longer for bigger heaps (also given they were all young GC with a low survivor rate) ? I had a suggestion to remove the -Xmn setting and leave G1 manage the young generation, and I am trying that with a 1 GiB heap. Thanks ! Simon -- http://cometd.org http://intalio.com http://bordet.blogspot.com ---- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless.?? Victoria Livschitz From xerox.time.tech at gmail.com Thu May 3 18:57:50 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Thu, 3 May 2012 14:57:50 -0400 Subject: object allocation in JITted method Message-ID: I am new to hotspot. I am wondering how object allocation is done in JITed method ? is it done by calling out to GC runtines or every Java thread has a thread local heap in which a simple increment of a pointer in the thread local heap is all that is needed ( and the heap is replenished by calling out to GC runtines if exhausted ). Thanks Xin From rednaxelafx at gmail.com Thu May 3 22:26:36 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 4 May 2012 06:26:36 +0800 Subject: object allocation in JITted method In-Reply-To: References: Message-ID: Hi Xin, HotSpot uses the fast-path/slow-path idiom in a lot of places. Object allocation is one of them. The common slow-path fallbacks are GC routines written in C++. There's separate implementation of the fast-path in the interpreter and the two JIT compilers; they do object allocations directly, and only fallback to the slow-path if they fail. By default, HotSpot uses TLAB (thread-local allocation buffer), similar to the thread-local heap you had in mind: a simple unsynchronized pointer bump works in the common case. But I wouldn't call that "thread-local heap", because the term TLH tends to imply that the area can be collected independently of other threads, which is not (yet) true for HotSpot. - Kris On 2012-5-4, at 2:57, Xin Tong wrote: > I am new to hotspot. I am wondering how object allocation is done in > JITed method ? is it done by calling out to GC runtines or every Java > thread has a thread local heap in which a simple increment of a > pointer in the thread local heap is all that is needed ( and the heap > is replenished by calling out to GC runtines if exhausted ). > > Thanks > > Xin From mikael.vidstedt at oracle.com Fri May 4 10:03:51 2012 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 04 May 2012 12:03:51 +0200 Subject: RFR(S): 7158457: division by zero in adaptiveweightedaverage In-Reply-To: <4F98A720.1090706@oracle.com> References: <4F96EA96.2010004@oracle.com> <9485F5F2-BDA7-4845-ADC2-674DF555E6C3@gmail.com> <4F98A720.1090706@oracle.com> Message-ID: <4FA3A987.3090400@oracle.com> Update: I'd like to continue working on this issue, and as part of that look at how the promoted and pretenured counters are used today and potentially update the logic given the insights around bytes vs. words etc. I think it would be helpful to address the crash problem short term though, and so I'd like to get feedback on the updated webrev: http://cr.openjdk.java.net/~mikael/7158457/webrev.01/ It's essentially the same as the previous one with Igor's suggested _is_old check improvement. Would it be ok to make this fix and clone the bug to track the follow-up work cleaning up the actual logic/heuristics? Thanks, Mikael On 2012-04-26 03:38, Mikael Vidstedt wrote: > > On 2012-04-24 23:50, Igor Veresov wrote: >> Wasn't it the case that _avg_pretenured value is formed incorrectly? >> I don't think it should be sampled at every allocation, I think it >> should measure the amount of data allocated in the old gen between >> young collections, also if you remember we agreed that the dimensions >> are wrong. Or were you able to find a better explanation as opposed >> to what we discussed before? > > Thanks for reminding me - I believe you're absolutely right. For a > while I was thinking it actually did make sense after all, but I just > did an experiment to see what actually happens at runtime: > > The _avg_pretenured counter is indeed sampled every time an allocation > is made directly in old gen. The actual value reflects the average > size *in words* of the object that was allocated. Put differently, > it's the average size of pretenured objects in words. > > The counter is used in PSAdaptiveSizePolicy::update_averages to > calculate the average amount of promoted data: > > avg_promoted()->sample(promoted + _avg_pretenured->padded_average()); > > The promoted parameter is the number of *bytes* that were just > promoted. To sum it up, that appears to imply that there are two > problems with the above computation: > > 1. It's taking the size of everything that was just promoted and adds > the size of an average prenured object (as opposed to the total size > of all recently pretenured objects) > 2. It's adding variables with different dimensions - promoted is in > bytes, and the _avg_pretenured padded average is in words > > Since that effectively means _avg_pretenured it's off by a factor > (word_size * number_of_objects) I'm guessing it will in the common > case not really matter to the calculation of avg_promoted... > > >> >> As for the treatment of the symptom, the code looks good to me. Do >> you think it might be beneficial to check the old value of _is_old >> before assigning to it? Would cause less memory traffic, if >> increment_count() is called frequently. >> 60 void increment_count() { >> 61 _sample_count++; >> 62 if (!_is_old&& _sample_count> OLD_THRESHOLD) { >> 63 _is_old = true; >> 64 } >> 65 } > > Good suggestion. I'll update my change with this in case we need > something urgently, but given the above issues it's likely a good idea > to take another pass at this. > > Thanks, > Mikael > >> >> igor >> >> On Apr 24, 2012, at 8:01 AM, Mikael Vidstedt wrote: >> >>> >>> Hi all, >>> >>> The statistical counters in gcUtil are used to keep track of >>> historical information about various key metrics in the garbage >>> collectors. Built in to the core AdaptiveWeightedAverage base class >>> is the concept of aging the values, essentially treating the first >>> 100 values differently and putting more weight on them since there's >>> not yet enough historical data built up. >>> >>> In the class there is a 32-bit counter (_sample_count) that >>> incremented for every sample and used to compute scale the weight of >>> the added value (see compute_adaptive_average), and the scaling >>> logic divides 100 by the count. In the normal case this is not a >>> problem - the counters are reset every once in a while and/or grow >>> very slowly. In some pathological cases the counter will however >>> continue to increment and eventually overflow/wrap, meaning the >>> 32-bit count will go back to zero and the division in >>> compute_adaptive_average will lead to a div-by-zero crash. >>> >>> The test case where this is observed is a test that stress tests >>> allocation in combination with the GC locker. Specifically, the test >>> is multi-threaded which pounds on java.util.zip.Deflater.deflate, >>> which internally uses the GetPrimitiveArrayCritical JNI function to >>> temporarily lock out the GC (using the GC locker). The garbage >>> collector used is in this case the parallel scavenger and the the >>> counter that overflows is _avg_pretenured. _avg_pretenured is >>> incremented/sampled every time an allocation is made directly in the >>> old gen, which I believe is more likely when the GC locker is active. >>> >>> >>> The suggested fix is to only perform the division in >>> compute_adaptive_average when it is relevant, which currently is for >>> the first 100 values. Once there are more than 100 samples there is >>> no longer a need to scale the weight. >>> >>> This problem is tracked in 7158457 (stress: jdk7 u4 core dumps >>> during megacart stress test run). >>> >>> Please review and comment on the webrev below: >>> >>> http://cr.openjdk.java.net/~mikael/7158457/webrev.00 >>> >>> >>> Thanks, >>> Mikael >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iggy.veresov at gmail.com Fri May 4 18:40:27 2012 From: iggy.veresov at gmail.com (Igor Veresov) Date: Fri, 4 May 2012 11:40:27 -0700 Subject: RFR(S): 7158457: division by zero in adaptiveweightedaverage In-Reply-To: <4FA3A987.3090400@oracle.com> References: <4F96EA96.2010004@oracle.com> <9485F5F2-BDA7-4845-ADC2-674DF555E6C3@gmail.com> <4F98A720.1090706@oracle.com> <4FA3A987.3090400@oracle.com> Message-ID: Looks good to me. igor On May 4, 2012, at 3:03 AM, Mikael Vidstedt wrote: > > Update: > > I'd like to continue working on this issue, and as part of that look at how the promoted and pretenured counters are used today and potentially update the logic given the insights around bytes vs. words etc. > > I think it would be helpful to address the crash problem short term though, and so I'd like to get feedback on the updated webrev: > > http://cr.openjdk.java.net/~mikael/7158457/webrev.01/ > > It's essentially the same as the previous one with Igor's suggested _is_old check improvement. Would it be ok to make this fix and clone the bug to track the follow-up work cleaning up the actual logic/heuristics? > > Thanks, > Mikael > > On 2012-04-26 03:38, Mikael Vidstedt wrote: >> >> >> On 2012-04-24 23:50, Igor Veresov wrote: >>> >>> Wasn't it the case that _avg_pretenured value is formed incorrectly? I don't think it should be sampled at every allocation, I think it should measure the amount of data allocated in the old gen between young collections, also if you remember we agreed that the dimensions are wrong. Or were you able to find a better explanation as opposed to what we discussed before? >> >> Thanks for reminding me - I believe you're absolutely right. For a while I was thinking it actually did make sense after all, but I just did an experiment to see what actually happens at runtime: >> >> The _avg_pretenured counter is indeed sampled every time an allocation is made directly in old gen. The actual value reflects the average size *in words* of the object that was allocated. Put differently, it's the average size of pretenured objects in words. >> >> The counter is used in PSAdaptiveSizePolicy::update_averages to calculate the average amount of promoted data: >> >> avg_promoted()->sample(promoted + _avg_pretenured->padded_average()); >> >> The promoted parameter is the number of *bytes* that were just promoted. To sum it up, that appears to imply that there are two problems with the above computation: >> >> 1. It's taking the size of everything that was just promoted and adds the size of an average prenured object (as opposed to the total size of all recently pretenured objects) >> 2. It's adding variables with different dimensions - promoted is in bytes, and the _avg_pretenured padded average is in words >> >> Since that effectively means _avg_pretenured it's off by a factor (word_size * number_of_objects) I'm guessing it will in the common case not really matter to the calculation of avg_promoted... >> >> >>> >>> As for the treatment of the symptom, the code looks good to me. Do you think it might be beneficial to check the old value of _is_old before assigning to it? Would cause less memory traffic, if increment_count() is called frequently. >>> 60 void increment_count() { >>> 61 _sample_count++; >>> 62 if (!_is_old && _sample_count > OLD_THRESHOLD) { >>> 63 _is_old = true; >>> 64 } >>> 65 } >> >> Good suggestion. I'll update my change with this in case we need something urgently, but given the above issues it's likely a good idea to take another pass at this. >> >> Thanks, >> Mikael >> >>> >>> igor >>> >>> On Apr 24, 2012, at 8:01 AM, Mikael Vidstedt wrote: >>> >>>> >>>> Hi all, >>>> >>>> The statistical counters in gcUtil are used to keep track of historical information about various key metrics in the garbage collectors. Built in to the core AdaptiveWeightedAverage base class is the concept of aging the values, essentially treating the first 100 values differently and putting more weight on them since there's not yet enough historical data built up. >>>> >>>> In the class there is a 32-bit counter (_sample_count) that incremented for every sample and used to compute scale the weight of the added value (see compute_adaptive_average), and the scaling logic divides 100 by the count. In the normal case this is not a problem - the counters are reset every once in a while and/or grow very slowly. In some pathological cases the counter will however continue to increment and eventually overflow/wrap, meaning the 32-bit count will go back to zero and the division in compute_adaptive_average will lead to a div-by-zero crash. >>>> >>>> The test case where this is observed is a test that stress tests allocation in combination with the GC locker. Specifically, the test is multi-threaded which pounds on java.util.zip.Deflater.deflate, which internally uses the GetPrimitiveArrayCritical JNI function to temporarily lock out the GC (using the GC locker). The garbage collector used is in this case the parallel scavenger and the the counter that overflows is _avg_pretenured. _avg_pretenured is incremented/sampled every time an allocation is made directly in the old gen, which I believe is more likely when the GC locker is active. >>>> >>>> >>>> The suggested fix is to only perform the division in compute_adaptive_average when it is relevant, which currently is for the first 100 values. Once there are more than 100 samples there is no longer a need to scale the weight. >>>> >>>> This problem is tracked in 7158457 (stress: jdk7 u4 core dumps during megacart stress test run). >>>> >>>> Please review and comment on the webrev below: >>>> >>>> http://cr.openjdk.java.net/~mikael/7158457/webrev.00 >>>> >>>> Thanks, >>>> Mikael >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alejandro.murillo at oracle.com Sat May 5 03:45:17 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 05 May 2012 03:45:17 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 14 new changesets Message-ID: <20120505034544.E726847169@hg.openjdk.java.net> Changeset: bfcf92bfefb8 Author: katleman Date: 2012-04-26 14:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bfcf92bfefb8 Added tag jdk8-b36 for changeset 50b4400ca1ec ! .hgtags Changeset: f3a4ee95783b Author: kevinw Date: 2012-04-20 14:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f3a4ee95783b 7162488: VM not printing unknown -XX options Reviewed-by: dholmes, kamg ! src/share/vm/runtime/arguments.cpp + test/runtime/7162488/Test7162488.sh Changeset: 29ee40a082d3 Author: sla Date: 2012-04-23 13:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/29ee40a082d3 7162063: libsaproc debug print should format size_t correctly on 64bit platform Reviewed-by: rbackman, mgronlun, dholmes ! agent/src/os/linux/ps_core.c Changeset: f33c4d0f4c9e Author: dcubed Date: 2012-04-23 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f33c4d0f4c9e Merge Changeset: d652a62d6e03 Author: dcubed Date: 2012-03-23 11:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d652a62d6e03 7102323: RFE: enable Full Debug Symbols Phase 1 on Solaris Summary: Add support for ENABLE_FULL_DEBUG_SYMBOLS and ZIP_DEBUGINFO_FILES build flags. Add support for .diz files. Reviewed-by: dholmes, ohair, sspitsyn ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! make/windows/build.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make ! make/windows/makefiles/sa.make Changeset: 744728c16316 Author: dcubed Date: 2012-04-03 09:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/744728c16316 7158067: FDS: ENABLE_FULL_DEBUG_SYMBOLS flag should only affect product builds Summary: Build option FULL_DEBUG_SYMBOLS=0 only affects product builds. Reviewed-by: ohair, jmelvin, sspitsyn ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/defs.make ! make/solaris/Makefile ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make Changeset: 74c359c4a9e5 Author: dcubed Date: 2012-04-24 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/74c359c4a9e5 Merge ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! make/windows/build.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make Changeset: d6c393b0164b Author: dcubed Date: 2012-04-25 15:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d6c393b0164b 7164344: enabling ZIP_DEBUGINFO_FILES causes unexpected test failures on Solaris and Windows Summary: Disable FDS by default on Solaris; disable ZIP_DEBUGINFO_FILES by default on Windows. Reviewed-by: acorn, sspitsyn ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make Changeset: 973046802b6f Author: dlong Date: 2012-04-26 16:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/973046802b6f 7162955: Attach api on Solaris, too many open files Summary: Release server-side socket after client receives it. Reviewed-by: sla, dsamersoff, dcubed, acorn Contributed-by: dean.long at oracle.com ! src/os/solaris/vm/attachListener_solaris.cpp Changeset: 6f0612ea55ce Author: jprovino Date: 2012-05-02 15:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6f0612ea55ce Merge Changeset: bb18e8eecb7e Author: jcoomes Date: 2012-05-04 10:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bb18e8eecb7e Merge - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp Changeset: 7d5ec8bf38d1 Author: amurillo Date: 2012-05-04 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7d5ec8bf38d1 Merge - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp Changeset: 4e6554041847 Author: amurillo Date: 2012-05-04 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4e6554041847 Added tag hs24-b09 for changeset 7d5ec8bf38d1 ! .hgtags Changeset: 36538fd1225e Author: amurillo Date: 2012-05-04 15:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/36538fd1225e 7166615: new hotspot build - hs24-b10 Reviewed-by: jcoomes ! make/hotspot_version From ysr1729 at gmail.com Sat May 5 09:57:29 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Sat, 5 May 2012 02:57:29 -0700 Subject: RFR(S): 7158457: division by zero in adaptiveweightedaverage In-Reply-To: <4FA3A987.3090400@oracle.com> References: <4F96EA96.2010004@oracle.com> <9485F5F2-BDA7-4845-ADC2-674DF555E6C3@gmail.com> <4F98A720.1090706@oracle.com> <4FA3A987.3090400@oracle.com> Message-ID: Mikael -- I agree that this fix would be good to get in, at least to address the immediate crash. reviewed. -- ramki On Fri, May 4, 2012 at 3:03 AM, Mikael Vidstedt wrote: > > Update: > > I'd like to continue working on this issue, and as part of that look at > how the promoted and pretenured counters are used today and potentially > update the logic given the insights around bytes vs. words etc. > > I think it would be helpful to address the crash problem short term > though, and so I'd like to get feedback on the updated webrev: > > http://cr.openjdk.java.net/~mikael/7158457/webrev.01/ > > It's essentially the same as the previous one with Igor's suggested > _is_old check improvement. Would it be ok to make this fix and clone the > bug to track the follow-up work cleaning up the actual logic/heuristics? > > Thanks, > Mikael > > > On 2012-04-26 03:38, Mikael Vidstedt wrote: > > > On 2012-04-24 23:50, Igor Veresov wrote: > > Wasn't it the case that _avg_pretenured value is formed incorrectly? I > don't think it should be sampled at every allocation, I think it should > measure the amount of data allocated in the old gen between young > collections, also if you remember we agreed that the dimensions are wrong. > Or were you able to find a better explanation as opposed to what we > discussed before? > > > Thanks for reminding me - I believe you're absolutely right. For a while I > was thinking it actually did make sense after all, but I just did an > experiment to see what actually happens at runtime: > > The _avg_pretenured counter is indeed sampled every time an allocation is > made directly in old gen. The actual value reflects the average size *in > words* of the object that was allocated. Put differently, it's the average > size of pretenured objects in words. > > The counter is used in PSAdaptiveSizePolicy::update_averages to calculate > the average amount of promoted data: > > avg_promoted()->sample(promoted + _avg_pretenured->padded_average()); > > The promoted parameter is the number of *bytes* that were just promoted. > To sum it up, that appears to imply that there are two problems with the > above computation: > > 1. It's taking the size of everything that was just promoted and adds the > size of an average prenured object (as opposed to the total size of all > recently pretenured objects) > 2. It's adding variables with different dimensions - promoted is in bytes, > and the _avg_pretenured padded average is in words > > Since that effectively means _avg_pretenured it's off by a factor > (word_size * number_of_objects) I'm guessing it will in the common case not > really matter to the calculation of avg_promoted... > > > > As for the treatment of the symptom, the code looks good to me. Do you > think it might be beneficial to check the old value of _is_old before > assigning to it? Would cause less memory traffic, if increment_count() is > called frequently. > > 60 void increment_count() { 61 _sample_count++; > > 62 if (!_is_old && _sample_count > OLD_THRESHOLD) { > > 63 _is_old = true; 64 } 65 } > > > Good suggestion. I'll update my change with this in case we need something > urgently, but given the above issues it's likely a good idea to take > another pass at this. > > Thanks, > Mikael > > > igor > > On Apr 24, 2012, at 8:01 AM, Mikael Vidstedt wrote: > > > Hi all, > > The statistical counters in gcUtil are used to keep track of historical > information about various key metrics in the garbage collectors. Built in > to the core AdaptiveWeightedAverage base class is the concept of aging the > values, essentially treating the first 100 values differently and putting > more weight on them since there's not yet enough historical data built up. > > In the class there is a 32-bit counter (_sample_count) that incremented > for every sample and used to compute scale the weight of the added value > (see compute_adaptive_average), and the scaling logic divides 100 by the > count. In the normal case this is not a problem - the counters are reset > every once in a while and/or grow very slowly. In some pathological cases > the counter will however continue to increment and eventually > overflow/wrap, meaning the 32-bit count will go back to zero and the > division in compute_adaptive_average will lead to a div-by-zero crash. > > The test case where this is observed is a test that stress tests > allocation in combination with the GC locker. Specifically, the test is > multi-threaded which pounds on java.util.zip.Deflater.deflate, which > internally uses the GetPrimitiveArrayCritical JNI function to temporarily > lock out the GC (using the GC locker). The garbage collector used is in > this case the parallel scavenger and the the counter that overflows is > _avg_pretenured. _avg_pretenured is incremented/sampled every time an > allocation is made directly in the old gen, which I believe is more likely > when the GC locker is active. > > > The suggested fix is to only perform the division in > compute_adaptive_average when it is relevant, which currently is for the > first 100 values. Once there are more than 100 samples there is no longer a > need to scale the weight. > > This problem is tracked in 7158457 (stress: jdk7 u4 core dumps during > megacart stress test run). > > Please review and comment on the webrev below: > > http://cr.openjdk.java.net/~mikael/7158457/webrev.00 > > Thanks, > Mikael > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Mon May 7 12:31:48 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 07 May 2012 14:31:48 +0200 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors Message-ID: <4FA7C0B4.40905@oracle.com> Hi all, Can I get a couple of reviews of this simple change: http://cr.openjdk.java.net/~brutisso/7166894/webrev/ Background: I recently pushed a similar fix for G1 as "7163848: G1: Log GC Cause for a GC". That fix adds the GC cause information to all G1 GCs. It was discussed if we should do this for all collectors and we came to the conclusion that it would be fairly safe to do it for all Full GCs. These log messages already contain the text "(System)" or "(System.gc())" when a System.gc() happens and PrintGCDetails are enabled. Now they will always contain the cause in parenthesis, even when only PrintGC is enabled. Hopefully most parsing will work with this. Thanks, Bengt From rednaxelafx at gmail.com Mon May 7 13:19:40 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 7 May 2012 21:19:40 +0800 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: <4FA7C0B4.40905@oracle.com> References: <4FA7C0B4.40905@oracle.com> Message-ID: Hi Bengt, FYI, I did something similar to CMS as well, covered by a new flag called "PrintGCReason" in my build. It's primitive, compared with your change. I was striving to keep the log within the brackets just as they were, and instead print extra information before the opening bracket, on a separate line. The parsing tool we use tend to ignore the lines it couldn't recognize, so doing it this way interrupted the tool the least. An example of the output can be found here [1], page 42. The motivation to add the extra logging was to track down a mysterious behavior in CMS that it keep doing back-to-back collections, without much gains, as explained in [1]. I needed to know why it was triggered. Some of our applications actually liked the extra logging, so it remained in the code base after the bug was found. Anyway, I like the idea of getting more info out of GC logs, in a uniform way. Would you mind adding the extra logging to CMS, too? - Kris [1]: http://www.slideshare.net/RednaxelaFX/jvm-taobao On Mon, May 7, 2012 at 8:31 PM, Bengt Rutisson wrote: > > Hi all, > > Can I get a couple of reviews of this simple change: > http://cr.openjdk.java.net/~**brutisso/7166894/webrev/ > > Background: > I recently pushed a similar fix for G1 as "7163848: G1: Log GC Cause for a > GC". That fix adds the GC cause information to all G1 GCs. It was discussed > if we should do this for all collectors and we came to the conclusion that > it would be fairly safe to do it for all Full GCs. These log messages > already contain the text "(System)" or "(System.gc())" when a System.gc() > happens and PrintGCDetails are enabled. Now they will always contain the > cause in parenthesis, even when only PrintGC is enabled. Hopefully most > parsing will work with this. > > Thanks, > Bengt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Mon May 7 13:31:52 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 7 May 2012 09:31:52 -0400 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: <4FA7C0B4.40905@oracle.com> References: <4FA7C0B4.40905@oracle.com> Message-ID: Hi Bengt, The allocation of the buffer to hold the string and sprintf'ing to it is repeated at the places you changed. Do you think it's worth it to factor that out into a common function or maybe some stack allocated class whose destructor would free the message buffer? Just a thought ... Also, probably better to use snprintf instead of sprintf. Regards, Vitaly Sent from my phone On May 7, 2012 8:35 AM, "Bengt Rutisson" wrote: > > Hi all, > > Can I get a couple of reviews of this simple change: > http://cr.openjdk.java.net/~**brutisso/7166894/webrev/ > > Background: > I recently pushed a similar fix for G1 as "7163848: G1: Log GC Cause for a > GC". That fix adds the GC cause information to all G1 GCs. It was discussed > if we should do this for all collectors and we came to the conclusion that > it would be fairly safe to do it for all Full GCs. These log messages > already contain the text "(System)" or "(System.gc())" when a System.gc() > happens and PrintGCDetails are enabled. Now they will always contain the > cause in parenthesis, even when only PrintGC is enabled. Hopefully most > parsing will work with this. > > Thanks, > Bengt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Mon May 7 13:33:06 2012 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 07 May 2012 15:33:06 +0200 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: <4FA7C0B4.40905@oracle.com> References: <4FA7C0B4.40905@oracle.com> Message-ID: <4FA7CF12.6070509@oracle.com> Hi Bengt, Since you used fixed-size on stack buffers for the gc causes, would you mind using snprintf instead of sprintf just to be sure that you don't write outside the buffer? I know that no gc cause string is that long currently but better safe than sorry, right? :) /mg On 2012-05-07 14:31, Bengt Rutisson wrote: > > Hi all, > > Can I get a couple of reviews of this simple change: > http://cr.openjdk.java.net/~brutisso/7166894/webrev/ > > Background: > I recently pushed a similar fix for G1 as "7163848: G1: Log GC Cause for > a GC". That fix adds the GC cause information to all G1 GCs. It was > discussed if we should do this for all collectors and we came to the > conclusion that it would be fairly safe to do it for all Full GCs. These > log messages already contain the text "(System)" or "(System.gc())" when > a System.gc() happens and PrintGCDetails are enabled. Now they will > always contain the cause in parenthesis, even when only PrintGC is > enabled. Hopefully most parsing will work with this. > > Thanks, > Bengt From bengt.rutisson at oracle.com Mon May 7 13:40:31 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 07 May 2012 15:40:31 +0200 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: References: <4FA7C0B4.40905@oracle.com> Message-ID: <4FA7D0CF.7040606@oracle.com> Hi Vitaly, Thanks for looking at this! On 2012-05-07 15:31, Vitaly Davidovich wrote: > > Hi Bengt, > > The allocation of the buffer to hold the string and sprintf'ing to it > is repeated at the places you changed. Do you think it's worth it to > factor that out into a common function or maybe some stack allocated > class whose destructor would free the message buffer? Just a thought ... > I see your point, but I'm not sure this would actually simplify the code. > Also, probably better to use snprintf instead of sprintf. > Good point. I'll fix this. This code fragment is actually copied from existing G1 code, so I'll go back and change that too. Thanks again for looking at it! Bengt > Regards, > > Vitaly > > Sent from my phone > > On May 7, 2012 8:35 AM, "Bengt Rutisson" > wrote: > > > Hi all, > > Can I get a couple of reviews of this simple change: > http://cr.openjdk.java.net/~brutisso/7166894/webrev/ > > > Background: > I recently pushed a similar fix for G1 as "7163848: G1: Log GC > Cause for a GC". That fix adds the GC cause information to all G1 > GCs. It was discussed if we should do this for all collectors and > we came to the conclusion that it would be fairly safe to do it > for all Full GCs. These log messages already contain the text > "(System)" or "(System.gc())" when a System.gc() happens and > PrintGCDetails are enabled. Now they will always contain the cause > in parenthesis, even when only PrintGC is enabled. Hopefully most > parsing will work with this. > > Thanks, > Bengt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Mon May 7 13:45:47 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 7 May 2012 09:45:47 -0400 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: <4FA7D0CF.7040606@oracle.com> References: <4FA7C0B4.40905@oracle.com> <4FA7D0CF.7040606@oracle.com> Message-ID: Yup, I don't think it would simplify the code but rather make any potential maintenance easier, I suspect. For example (and it's a stretch), if you wanted to change the size of the message buffer, you'd modify just one place. However, this is very minor so your call. Thanks, Vitaly Sent from my phone On May 7, 2012 9:41 AM, "Bengt Rutisson" wrote: > ** > > Hi Vitaly, > > Thanks for looking at this! > > On 2012-05-07 15:31, Vitaly Davidovich wrote: > > Hi Bengt, > > The allocation of the buffer to hold the string and sprintf'ing to it is > repeated at the places you changed. Do you think it's worth it to factor > that out into a common function or maybe some stack allocated class whose > destructor would free the message buffer? Just a thought ... > > > I see your point, but I'm not sure this would actually simplify the code. > > Also, probably better to use snprintf instead of sprintf. > > > Good point. I'll fix this. This code fragment is actually copied from > existing G1 code, so I'll go back and change that too. > > Thanks again for looking at it! > Bengt > > Regards, > > Vitaly > > Sent from my phone > On May 7, 2012 8:35 AM, "Bengt Rutisson" > wrote: > >> >> Hi all, >> >> Can I get a couple of reviews of this simple change: >> http://cr.openjdk.java.net/~brutisso/7166894/webrev/ >> >> Background: >> I recently pushed a similar fix for G1 as "7163848: G1: Log GC Cause for >> a GC". That fix adds the GC cause information to all G1 GCs. It was >> discussed if we should do this for all collectors and we came to the >> conclusion that it would be fairly safe to do it for all Full GCs. These >> log messages already contain the text "(System)" or "(System.gc())" when a >> System.gc() happens and PrintGCDetails are enabled. Now they will always >> contain the cause in parenthesis, even when only PrintGC is enabled. >> Hopefully most parsing will work with this. >> >> Thanks, >> Bengt >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Mon May 7 20:09:22 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 07 May 2012 22:09:22 +0200 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: References: <4FA7C0B4.40905@oracle.com> <4FA7D0CF.7040606@oracle.com> Message-ID: <4FA82BF2.8010403@oracle.com> Hi Vitaly and Mikael, Thanks both of you for looking at this! Here is an updated webrev using jio_snprintf: http://cr.openjdk.java.net/~brutisso/7166894/webrev.01/ On 2012-05-07 15:45, Vitaly Davidovich wrote: > > Yup, I don't think it would simplify the code but rather make any > potential maintenance easier, I suspect. For example (and it's a > stretch), if you wanted to change the size of the message buffer, > you'd modify just one place. However, this is very minor so your call. > When I went back to look at the G1 code I think that code will benefit even more from some abstraction like you suggested. But on the other hand there is a lot of logging code that would benefit from that. So, I have to think a bit about how much I would like to change. I'll leave it as it is for now. Thanks again, Bengt > Thanks, > > Vitaly > > Sent from my phone > > On May 7, 2012 9:41 AM, "Bengt Rutisson" > wrote: > > > Hi Vitaly, > > Thanks for looking at this! > > On 2012-05-07 15:31, Vitaly Davidovich wrote: >> >> Hi Bengt, >> >> The allocation of the buffer to hold the string and sprintf'ing >> to it is repeated at the places you changed. Do you think it's >> worth it to factor that out into a common function or maybe some >> stack allocated class whose destructor would free the message >> buffer? Just a thought ... >> > > I see your point, but I'm not sure this would actually simplify > the code. > >> Also, probably better to use snprintf instead of sprintf. >> > > Good point. I'll fix this. This code fragment is actually copied > from existing G1 code, so I'll go back and change that too. > > Thanks again for looking at it! > Bengt > >> Regards, >> >> Vitaly >> >> Sent from my phone >> >> On May 7, 2012 8:35 AM, "Bengt Rutisson" >> > wrote: >> >> >> Hi all, >> >> Can I get a couple of reviews of this simple change: >> http://cr.openjdk.java.net/~brutisso/7166894/webrev/ >> >> >> Background: >> I recently pushed a similar fix for G1 as "7163848: G1: Log >> GC Cause for a GC". That fix adds the GC cause information to >> all G1 GCs. It was discussed if we should do this for all >> collectors and we came to the conclusion that it would be >> fairly safe to do it for all Full GCs. These log messages >> already contain the text "(System)" or "(System.gc())" when a >> System.gc() happens and PrintGCDetails are enabled. Now they >> will always contain the cause in parenthesis, even when only >> PrintGC is enabled. Hopefully most parsing will work with this. >> >> Thanks, >> Bengt >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Mon May 7 21:10:00 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 07 May 2012 23:10:00 +0200 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: References: <4FA7C0B4.40905@oracle.com> Message-ID: <4FA83A28.1040504@oracle.com> Hi Kris, Thanks for looking at this! Good point regarding CMS. I guess I am a bit concerned about changing that since it might start breaking more parsers. I'll send a question out on the hotspot-gc-use mailing list to get some feedback. If we do go for adding this information to CMS we can probably also take the chance of adding it to all the young GCs. I looked at the log sample you referred to. It looks like you were logging more details about exactly why a GC was triggered. That is probably a good idea, but for now I think we should settle for just the text message describing the cause. Thanks again for looking at this, Bengt On 2012-05-07 15:19, Krystal Mok wrote: > Hi Bengt, > > FYI, I did something similar to CMS as well, covered by a new flag > called "PrintGCReason" in my build. > It's primitive, compared with your change. I was striving to keep the > log within the brackets just as they were, and instead print extra > information before the opening bracket, on a separate line. The > parsing tool we use tend to ignore the lines it couldn't recognize, so > doing it this way interrupted the tool the least. > > An example of the output can be found here [1], page 42. The > motivation to add the extra logging was to track down a mysterious > behavior in CMS that it keep doing back-to-back collections, without > much gains, as explained in [1]. I needed to know why it was > triggered. Some of our applications actually liked the extra logging, > so it remained in the code base after the bug was found. > > Anyway, I like the idea of getting more info out of GC logs, in a > uniform way. > Would you mind adding the extra logging to CMS, too? > > - Kris > > [1]: http://www.slideshare.net/RednaxelaFX/jvm-taobao > > On Mon, May 7, 2012 at 8:31 PM, Bengt Rutisson > > wrote: > > > Hi all, > > Can I get a couple of reviews of this simple change: > http://cr.openjdk.java.net/~brutisso/7166894/webrev/ > > > Background: > I recently pushed a similar fix for G1 as "7163848: G1: Log GC > Cause for a GC". That fix adds the GC cause information to all G1 > GCs. It was discussed if we should do this for all collectors and > we came to the conclusion that it would be fairly safe to do it > for all Full GCs. These log messages already contain the text > "(System)" or "(System.gc())" when a System.gc() happens and > PrintGCDetails are enabled. Now they will always contain the cause > in parenthesis, even when only PrintGC is enabled. Hopefully most > parsing will work with this. > > Thanks, > Bengt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Mon May 7 21:07:41 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 7 May 2012 17:07:41 -0400 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: <4FA82BF2.8010403@oracle.com> References: <4FA7C0B4.40905@oracle.com> <4FA7D0CF.7040606@oracle.com> <4FA82BF2.8010403@oracle.com> Message-ID: Looks good to me. I see your point about refactoring the logging code, but I'd probably at least define the buf size (i.e. 128) as a constant somewhere and use that, but that's very minor. Cheers Sent from my phone On May 7, 2012 4:05 PM, "Bengt Rutisson" wrote: > > Hi Vitaly and Mikael, > > Thanks both of you for looking at this! Here is an updated webrev using > jio_snprintf: > http://cr.openjdk.java.net/~brutisso/7166894/webrev.01/ > > On 2012-05-07 15:45, Vitaly Davidovich wrote: > > Yup, I don't think it would simplify the code but rather make any > potential maintenance easier, I suspect. For example (and it's a stretch), > if you wanted to change the size of the message buffer, you'd modify just > one place. However, this is very minor so your call. > > > When I went back to look at the G1 code I think that code will benefit > even more from some abstraction like you suggested. But on the other hand > there is a lot of logging code that would benefit from that. So, I have to > think a bit about how much I would like to change. I'll leave it as it is > for now. > > Thanks again, > Bengt > > Thanks, > > Vitaly > > Sent from my phone > On May 7, 2012 9:41 AM, "Bengt Rutisson" > wrote: > >> >> Hi Vitaly, >> >> Thanks for looking at this! >> >> On 2012-05-07 15:31, Vitaly Davidovich wrote: >> >> Hi Bengt, >> >> The allocation of the buffer to hold the string and sprintf'ing to it is >> repeated at the places you changed. Do you think it's worth it to factor >> that out into a common function or maybe some stack allocated class whose >> destructor would free the message buffer? Just a thought ... >> >> >> I see your point, but I'm not sure this would actually simplify the code. >> >> Also, probably better to use snprintf instead of sprintf. >> >> >> Good point. I'll fix this. This code fragment is actually copied from >> existing G1 code, so I'll go back and change that too. >> >> Thanks again for looking at it! >> Bengt >> >> Regards, >> >> Vitaly >> >> Sent from my phone >> On May 7, 2012 8:35 AM, "Bengt Rutisson" >> wrote: >> >>> >>> Hi all, >>> >>> Can I get a couple of reviews of this simple change: >>> http://cr.openjdk.java.net/~brutisso/7166894/webrev/ >>> >>> Background: >>> I recently pushed a similar fix for G1 as "7163848: G1: Log GC Cause for >>> a GC". That fix adds the GC cause information to all G1 GCs. It was >>> discussed if we should do this for all collectors and we came to the >>> conclusion that it would be fairly safe to do it for all Full GCs. These >>> log messages already contain the text "(System)" or "(System.gc())" when a >>> System.gc() happens and PrintGCDetails are enabled. Now they will always >>> contain the cause in parenthesis, even when only PrintGC is enabled. >>> Hopefully most parsing will work with this. >>> >>> Thanks, >>> Bengt >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk at kodewerk.com Tue May 8 05:28:54 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 8 May 2012 07:28:54 +0200 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: <4FA82BF2.8010403@oracle.com> References: <4FA7C0B4.40905@oracle.com> <4FA7D0CF.7040606@oracle.com> <4FA82BF2.8010403@oracle.com> Message-ID: This 7166894: Add gc cause to Full GC logging for all collectors leads me to an internal Oracle server. Regards, Kirk On 2012-05-07, at 10:09 PM, Bengt Rutisson wrote: > > Hi Vitaly and Mikael, > > Thanks both of you for looking at this! Here is an updated webrev using jio_snprintf: > http://cr.openjdk.java.net/~brutisso/7166894/webrev.01/ > > On 2012-05-07 15:45, Vitaly Davidovich wrote: >> >> Yup, I don't think it would simplify the code but rather make any potential maintenance easier, I suspect. For example (and it's a stretch), if you wanted to change the size of the message buffer, you'd modify just one place. However, this is very minor so your call. >> > > When I went back to look at the G1 code I think that code will benefit even more from some abstraction like you suggested. But on the other hand there is a lot of logging code that would benefit from that. So, I have to think a bit about how much I would like to change. I'll leave it as it is for now. > > Thanks again, > Bengt > >> Thanks, >> >> Vitaly >> >> Sent from my phone >> >> On May 7, 2012 9:41 AM, "Bengt Rutisson" wrote: >> >> Hi Vitaly, >> >> Thanks for looking at this! >> >> On 2012-05-07 15:31, Vitaly Davidovich wrote: >>> >>> Hi Bengt, >>> >>> The allocation of the buffer to hold the string and sprintf'ing to it is repeated at the places you changed. Do you think it's worth it to factor that out into a common function or maybe some stack allocated class whose destructor would free the message buffer? Just a thought ... >>> >> >> I see your point, but I'm not sure this would actually simplify the code. >> >>> Also, probably better to use snprintf instead of sprintf. >>> >> >> Good point. I'll fix this. This code fragment is actually copied from existing G1 code, so I'll go back and change that too. >> >> Thanks again for looking at it! >> Bengt >> >>> Regards, >>> >>> Vitaly >>> >>> Sent from my phone >>> >>> On May 7, 2012 8:35 AM, "Bengt Rutisson" wrote: >>> >>> Hi all, >>> >>> Can I get a couple of reviews of this simple change: >>> http://cr.openjdk.java.net/~brutisso/7166894/webrev/ >>> >>> Background: >>> I recently pushed a similar fix for G1 as "7163848: G1: Log GC Cause for a GC". That fix adds the GC cause information to all G1 GCs. It was discussed if we should do this for all collectors and we came to the conclusion that it would be fairly safe to do it for all Full GCs. These log messages already contain the text "(System)" or "(System.gc())" when a System.gc() happens and PrintGCDetails are enabled. Now they will always contain the cause in parenthesis, even when only PrintGC is enabled. Hopefully most parsing will work with this. >>> >>> Thanks, >>> Bengt >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk at kodewerk.com Tue May 8 05:32:57 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 8 May 2012 07:32:57 +0200 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: <4FA82BF2.8010403@oracle.com> References: <4FA7C0B4.40905@oracle.com> <4FA7D0CF.7040606@oracle.com> <4FA82BF2.8010403@oracle.com> Message-ID: <794B2655-2F89-47DB-8C61-14DF145A09D0@kodewerk.com> Hi Bengt, This is a much more reasonable change then adding log levels of fine and finest (changes which I still strongly object to as they are flags with absolutely no meaning). The PrintReason flag also seems like a reasonable thing to include across all collectors. If the information is contained in brackets (similar to (system) indication of System.gc()) then that is something parser will either handle or should easily be adjusted to handle. I'd welcome that also. Regards, Kirk On 2012-05-07, at 10:09 PM, Bengt Rutisson wrote: > > Hi Vitaly and Mikael, > > Thanks both of you for looking at this! Here is an updated webrev using jio_snprintf: > http://cr.openjdk.java.net/~brutisso/7166894/webrev.01/ > > On 2012-05-07 15:45, Vitaly Davidovich wrote: >> >> Yup, I don't think it would simplify the code but rather make any potential maintenance easier, I suspect. For example (and it's a stretch), if you wanted to change the size of the message buffer, you'd modify just one place. However, this is very minor so your call. >> > > When I went back to look at the G1 code I think that code will benefit even more from some abstraction like you suggested. But on the other hand there is a lot of logging code that would benefit from that. So, I have to think a bit about how much I would like to change. I'll leave it as it is for now. > > Thanks again, > Bengt > >> Thanks, >> >> Vitaly >> >> Sent from my phone >> >> On May 7, 2012 9:41 AM, "Bengt Rutisson" wrote: >> >> Hi Vitaly, >> >> Thanks for looking at this! >> >> On 2012-05-07 15:31, Vitaly Davidovich wrote: >>> >>> Hi Bengt, >>> >>> The allocation of the buffer to hold the string and sprintf'ing to it is repeated at the places you changed. Do you think it's worth it to factor that out into a common function or maybe some stack allocated class whose destructor would free the message buffer? Just a thought ... >>> >> >> I see your point, but I'm not sure this would actually simplify the code. >> >>> Also, probably better to use snprintf instead of sprintf. >>> >> >> Good point. I'll fix this. This code fragment is actually copied from existing G1 code, so I'll go back and change that too. >> >> Thanks again for looking at it! >> Bengt >> >>> Regards, >>> >>> Vitaly >>> >>> Sent from my phone >>> >>> On May 7, 2012 8:35 AM, "Bengt Rutisson" wrote: >>> >>> Hi all, >>> >>> Can I get a couple of reviews of this simple change: >>> http://cr.openjdk.java.net/~brutisso/7166894/webrev/ >>> >>> Background: >>> I recently pushed a similar fix for G1 as "7163848: G1: Log GC Cause for a GC". That fix adds the GC cause information to all G1 GCs. It was discussed if we should do this for all collectors and we came to the conclusion that it would be fairly safe to do it for all Full GCs. These log messages already contain the text "(System)" or "(System.gc())" when a System.gc() happens and PrintGCDetails are enabled. Now they will always contain the cause in parenthesis, even when only PrintGC is enabled. Hopefully most parsing will work with this. >>> >>> Thanks, >>> Bengt >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Tue May 8 12:59:52 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 08 May 2012 14:59:52 +0200 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: References: <4FA7C0B4.40905@oracle.com> <4FA7D0CF.7040606@oracle.com> <4FA82BF2.8010403@oracle.com> Message-ID: <4FA918C8.2000708@oracle.com> On 2012-05-08 07:28, Kirk Pepperdine wrote: > This 7166894: Add gc cause to Full GC logging for all collectors > leads me to an > internal Oracle server. This is unfortunate, but it is a consequence of the fact that we still do not have a publicly available JIRA installation for OpenJDK issues. As you are aware there is active work on creating such an installation. In the mean time the public access to the bug system is through bugs.sun.com, which is lagging several days behind. The current bug is still not available there, but will hopefully be soon, on this URL: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7166894 Bengt > > Regards, > Kirk > > On 2012-05-07, at 10:09 PM, Bengt Rutisson wrote: > >> >> Hi Vitaly and Mikael, >> >> Thanks both of you for looking at this! Here is an updated webrev >> using jio_snprintf: >> http://cr.openjdk.java.net/~brutisso/7166894/webrev.01/ >> >> On 2012-05-07 15:45, Vitaly Davidovich wrote: >>> >>> Yup, I don't think it would simplify the code but rather make any >>> potential maintenance easier, I suspect. For example (and it's a >>> stretch), if you wanted to change the size of the message buffer, >>> you'd modify just one place. However, this is very minor so your call. >>> >> >> When I went back to look at the G1 code I think that code will >> benefit even more from some abstraction like you suggested. But on >> the other hand there is a lot of logging code that would benefit from >> that. So, I have to think a bit about how much I would like to >> change. I'll leave it as it is for now. >> >> Thanks again, >> Bengt >> >>> Thanks, >>> >>> Vitaly >>> >>> Sent from my phone >>> >>> On May 7, 2012 9:41 AM, "Bengt Rutisson" >> > wrote: >>> >>> >>> Hi Vitaly, >>> >>> Thanks for looking at this! >>> >>> On 2012-05-07 15:31, Vitaly Davidovich wrote: >>>> >>>> Hi Bengt, >>>> >>>> The allocation of the buffer to hold the string and sprintf'ing >>>> to it is repeated at the places you changed. Do you think it's >>>> worth it to factor that out into a common function or maybe >>>> some stack allocated class whose destructor would free the >>>> message buffer? Just a thought ... >>>> >>> >>> I see your point, but I'm not sure this would actually simplify >>> the code. >>> >>>> Also, probably better to use snprintf instead of sprintf. >>>> >>> >>> Good point. I'll fix this. This code fragment is actually copied >>> from existing G1 code, so I'll go back and change that too. >>> >>> Thanks again for looking at it! >>> Bengt >>> >>>> Regards, >>>> >>>> Vitaly >>>> >>>> Sent from my phone >>>> >>>> On May 7, 2012 8:35 AM, "Bengt Rutisson" >>>> > >>>> wrote: >>>> >>>> >>>> Hi all, >>>> >>>> Can I get a couple of reviews of this simple change: >>>> http://cr.openjdk.java.net/~brutisso/7166894/webrev/ >>>> >>>> >>>> Background: >>>> I recently pushed a similar fix for G1 as "7163848: G1: Log >>>> GC Cause for a GC". That fix adds the GC cause information >>>> to all G1 GCs. It was discussed if we should do this for >>>> all collectors and we came to the conclusion that it would >>>> be fairly safe to do it for all Full GCs. These log >>>> messages already contain the text "(System)" or >>>> "(System.gc())" when a System.gc() happens and >>>> PrintGCDetails are enabled. Now they will always contain >>>> the cause in parenthesis, even when only PrintGC is >>>> enabled. Hopefully most parsing will work with this. >>>> >>>> Thanks, >>>> Bengt >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Tue May 8 14:18:07 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 08 May 2012 16:18:07 +0200 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: <4FA83A28.1040504@oracle.com> References: <4FA7C0B4.40905@oracle.com> <4FA83A28.1040504@oracle.com> Message-ID: <4FA92B1F.6000804@oracle.com> Hi again everyone, It seems like the feedback on hotspot-gc-use is that we should add the GC cause to all collectors but also provide a switch to turn this logging off. Here is an updated webrev: http://cr.openjdk.java.net/~brutisso/7166894/webrev.03/ Changes: * GC cause logged for all collectors * Added the flag -XX:-PrintGCCause to turn the new information off * Refactored the string concatenation code into a helper class I guess I will also have to update the CR to now reflect the fact that this does not just concern full GCs anymore. Thanks, Bengt On 2012-05-07 23:10, Bengt Rutisson wrote: > > Hi Kris, > > Thanks for looking at this! > > Good point regarding CMS. I guess I am a bit concerned about changing > that since it might start breaking more parsers. I'll send a question > out on the hotspot-gc-use mailing list to get some feedback. > > If we do go for adding this information to CMS we can probably also > take the chance of adding it to all the young GCs. > > I looked at the log sample you referred to. It looks like you were > logging more details about exactly why a GC was triggered. That is > probably a good idea, but for now I think we should settle for just > the text message describing the cause. > > Thanks again for looking at this, > Bengt > > On 2012-05-07 15:19, Krystal Mok wrote: >> Hi Bengt, >> >> FYI, I did something similar to CMS as well, covered by a new flag >> called "PrintGCReason" in my build. >> It's primitive, compared with your change. I was striving to keep the >> log within the brackets just as they were, and instead print extra >> information before the opening bracket, on a separate line. The >> parsing tool we use tend to ignore the lines it couldn't recognize, >> so doing it this way interrupted the tool the least. >> >> An example of the output can be found here [1], page 42. The >> motivation to add the extra logging was to track down a mysterious >> behavior in CMS that it keep doing back-to-back collections, without >> much gains, as explained in [1]. I needed to know why it was >> triggered. Some of our applications actually liked the extra logging, >> so it remained in the code base after the bug was found. >> >> Anyway, I like the idea of getting more info out of GC logs, in a >> uniform way. >> Would you mind adding the extra logging to CMS, too? >> >> - Kris >> >> [1]: http://www.slideshare.net/RednaxelaFX/jvm-taobao >> >> On Mon, May 7, 2012 at 8:31 PM, Bengt Rutisson >> > wrote: >> >> >> Hi all, >> >> Can I get a couple of reviews of this simple change: >> http://cr.openjdk.java.net/~brutisso/7166894/webrev/ >> >> >> Background: >> I recently pushed a similar fix for G1 as "7163848: G1: Log GC >> Cause for a GC". That fix adds the GC cause information to all G1 >> GCs. It was discussed if we should do this for all collectors and >> we came to the conclusion that it would be fairly safe to do it >> for all Full GCs. These log messages already contain the text >> "(System)" or "(System.gc())" when a System.gc() happens and >> PrintGCDetails are enabled. Now they will always contain the >> cause in parenthesis, even when only PrintGC is enabled. >> Hopefully most parsing will work with this. >> >> Thanks, >> Bengt >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rednaxelafx at gmail.com Tue May 8 14:43:23 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 8 May 2012 22:43:23 +0800 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: <4FA92B1F.6000804@oracle.com> References: <4FA7C0B4.40905@oracle.com> <4FA83A28.1040504@oracle.com> <4FA92B1F.6000804@oracle.com> Message-ID: Hi Bengt, The current factoring looks nice and uniform. Thanks :-) But for most minor GCs and both CMS pause phases, the extra logging doesn't really give additional information. Most minor GCs are going to say "Allocation Failure", and the two CMS phases would change from, e.g. [GC [1 CMS-initial-mark to something like [GC (CMS Initial Mark) [1 CMS-initial-mark which is probably reasonable given the scope of the change, but not really helpful. The "real cause", such as which generation (or perhaps System.gc() with ExplicitGCInvokesConcurrent, or even GC locker) is triggering this collection cycle, may be more useful, but it's hard to fit into the current form. - Kris On Tue, May 8, 2012 at 10:18 PM, Bengt Rutisson wrote: > > Hi again everyone, > > It seems like the feedback on hotspot-gc-use is that we should add the GC > cause to all collectors but also provide a switch to turn this logging off. > > Here is an updated webrev: > http://cr.openjdk.java.net/~brutisso/7166894/webrev.03/ > > Changes: > * GC cause logged for all collectors > * Added the flag -XX:-PrintGCCause to turn the new information off > * Refactored the string concatenation code into a helper class > > I guess I will also have to update the CR to now reflect the fact that > this does not just concern full GCs anymore. > > Thanks, > Bengt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Wed May 9 08:08:53 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 09 May 2012 10:08:53 +0200 Subject: Review request (XS): 7167437 - Can't build on linux without precompiled headers Message-ID: <4FAA2615.5020606@oracle.com> http://cr.openjdk.java.net/~stefank/7167437/webrev/ The inline function set_concurrent_iteration_safe_limit is not available when building binaryTreeDictionary.cpp. This breaks the build when compiling with USE_PRECOMPILED_HEADER=0. I moved the simple implementation to the .hpp file instead of the .inline.hpp file. StefanK From bengt.rutisson at oracle.com Thu May 10 07:57:00 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 10 May 2012 09:57:00 +0200 Subject: Review request (XS): 7167437 - Can't build on linux without precompiled headers In-Reply-To: <4FAA2615.5020606@oracle.com> References: <4FAA2615.5020606@oracle.com> Message-ID: <4FAB74CC.70904@oracle.com> Stefan, Looks good. Bengt On 2012-05-09 10:08, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/7167437/webrev/ > > The inline function set_concurrent_iteration_safe_limit is not > available when building binaryTreeDictionary.cpp. This breaks the > build when compiling with USE_PRECOMPILED_HEADER=0. > > I moved the simple implementation to the .hpp file instead of the > .inline.hpp file. > > StefanK From mikael.gerdin at oracle.com Thu May 10 09:05:31 2012 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 10 May 2012 11:05:31 +0200 Subject: Review request (XS): 7167437 - Can't build on linux without precompiled headers In-Reply-To: <4FAA2615.5020606@oracle.com> References: <4FAA2615.5020606@oracle.com> Message-ID: <4FAB84DB.5040104@oracle.com> Stefan, looks good to me. /Mikael On 2012-05-09 10:08, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/7167437/webrev/ > > The inline function set_concurrent_iteration_safe_limit is not available > when building binaryTreeDictionary.cpp. This breaks the build when > compiling with USE_PRECOMPILED_HEADER=0. > > I moved the simple implementation to the .hpp file instead of the > .inline.hpp file. > > StefanK From bengt.rutisson at oracle.com Thu May 10 09:07:57 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 10 May 2012 11:07:57 +0200 Subject: Request for review (S): 7167069: 6 VM flags crash the VM when queried via jinfo Message-ID: <4FAB856D.7070607@oracle.com> Hi all, Can I have some reviews of this simple fix: http://cr.openjdk.java.net/~brutisso/7167069/webrev.00/ Sending this to both Runtime and GC. The change is in runtime code, but all the concerned flags are GC flags and I plan to push this through the GC repository unless there are any objections to that. When command line flags with the double type were introduced the methods Flag::print_on() and Flag::print_as_flag() were not updated correspondingly. The Flag::print_on() method was updated as part of this change: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6ee479178066 But the Flag::print_as_flag() still didn't handle doubles. I created a JTReg test that should test one flag of each supported type. Thanks, Bengt From david.holmes at oracle.com Thu May 10 09:32:28 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 May 2012 19:32:28 +1000 Subject: Request for review (S): 7167069: 6 VM flags crash the VM when queried via jinfo In-Reply-To: <4FAB856D.7070607@oracle.com> References: <4FAB856D.7070607@oracle.com> Message-ID: <4FAB8B2C.2000206@oracle.com> Hi Bengt, Looks good to me. David On 10/05/2012 7:07 PM, Bengt Rutisson wrote: > > Hi all, > > Can I have some reviews of this simple fix: > http://cr.openjdk.java.net/~brutisso/7167069/webrev.00/ > > Sending this to both Runtime and GC. The change is in runtime code, but > all the concerned flags are GC flags and I plan to push this through the > GC repository unless there are any objections to that. > > When command line flags with the double type were introduced the methods > Flag::print_on() and Flag::print_as_flag() were not updated > correspondingly. The Flag::print_on() method was updated as part of this > change: > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6ee479178066 > > But the Flag::print_as_flag() still didn't handle doubles. > > I created a JTReg test that should test one flag of each supported type. > > Thanks, > Bengt From stefan.karlsson at oracle.com Thu May 10 09:37:51 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 10 May 2012 11:37:51 +0200 Subject: Request for review (S): 7167069: 6 VM flags crash the VM when queried via jinfo In-Reply-To: <4FAB856D.7070607@oracle.com> References: <4FAB856D.7070607@oracle.com> Message-ID: <4FAB8C6F.7070005@oracle.com> The fix looks good, but the test needs a copyright header and should probably use two spaces for the indentations. StefanK On 2012-05-10 11:07, Bengt Rutisson wrote: > > Hi all, > > Can I have some reviews of this simple fix: > http://cr.openjdk.java.net/~brutisso/7167069/webrev.00/ > > Sending this to both Runtime and GC. The change is in runtime code, > but all the concerned flags are GC flags and I plan to push this > through the GC repository unless there are any objections to that. > > When command line flags with the double type were introduced the > methods Flag::print_on() and Flag::print_as_flag() were not updated > correspondingly. The Flag::print_on() method was updated as part of > this change: > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6ee479178066 > > But the Flag::print_as_flag() still didn't handle doubles. > > I created a JTReg test that should test one flag of each supported type. > > Thanks, > Bengt From bengt.rutisson at oracle.com Thu May 10 12:01:28 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 10 May 2012 14:01:28 +0200 Subject: Request for review (S): 7167069: 6 VM flags crash the VM when queried via jinfo In-Reply-To: <4FAB8B2C.2000206@oracle.com> References: <4FAB856D.7070607@oracle.com> <4FAB8B2C.2000206@oracle.com> Message-ID: <4FABAE18.10307@oracle.com> Thanks for looking at this, David! Bengt On 2012-05-10 11:32, David Holmes wrote: > Hi Bengt, > > Looks good to me. > > David > > On 10/05/2012 7:07 PM, Bengt Rutisson wrote: >> >> Hi all, >> >> Can I have some reviews of this simple fix: >> http://cr.openjdk.java.net/~brutisso/7167069/webrev.00/ >> >> Sending this to both Runtime and GC. The change is in runtime code, but >> all the concerned flags are GC flags and I plan to push this through the >> GC repository unless there are any objections to that. >> >> When command line flags with the double type were introduced the methods >> Flag::print_on() and Flag::print_as_flag() were not updated >> correspondingly. The Flag::print_on() method was updated as part of this >> change: >> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6ee479178066 >> >> But the Flag::print_as_flag() still didn't handle doubles. >> >> I created a JTReg test that should test one flag of each supported type. >> >> Thanks, >> Bengt From bengt.rutisson at oracle.com Thu May 10 12:01:34 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 10 May 2012 14:01:34 +0200 Subject: Request for review (S): 7167069: 6 VM flags crash the VM when queried via jinfo In-Reply-To: <4FAB8C6F.7070005@oracle.com> References: <4FAB856D.7070607@oracle.com> <4FAB8C6F.7070005@oracle.com> Message-ID: <4FABAE1E.8070604@oracle.com> Stefan, Thanks for looking at this. On 2012-05-10 11:37, Stefan Karlsson wrote: > The fix looks good, but the test needs a copyright header and should > probably use two spaces for the indentations. There seem to be some inconsistencies within JTReg with regards to both copyright and indentation. But I did as you suggested. Here's an updated webrev: http://cr.openjdk.java.net/~brutisso/7167069/webrev.01/ Bengt > > StefanK > > On 2012-05-10 11:07, Bengt Rutisson wrote: >> >> Hi all, >> >> Can I have some reviews of this simple fix: >> http://cr.openjdk.java.net/~brutisso/7167069/webrev.00/ >> >> Sending this to both Runtime and GC. The change is in runtime code, >> but all the concerned flags are GC flags and I plan to push this >> through the GC repository unless there are any objections to that. >> >> When command line flags with the double type were introduced the >> methods Flag::print_on() and Flag::print_as_flag() were not updated >> correspondingly. The Flag::print_on() method was updated as part of >> this change: >> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6ee479178066 >> >> But the Flag::print_as_flag() still didn't handle doubles. >> >> I created a JTReg test that should test one flag of each supported type. >> >> Thanks, >> Bengt > From stefan.karlsson at oracle.com Thu May 10 15:40:09 2012 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Thu, 10 May 2012 15:40:09 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7167437: Can't build on linux without precompiled headers Message-ID: <20120510154011.E724D4722A@hg.openjdk.java.net> Changeset: a05a695ea044 Author: stefank Date: 2012-05-10 11:27 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a05a695ea044 7167437: Can't build on linux without precompiled headers Reviewed-by: brutisso, mgerdin ! src/share/vm/memory/space.hpp ! src/share/vm/memory/space.inline.hpp From John.Coomes at oracle.com Thu May 10 16:48:19 2012 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 10 May 2012 09:48:19 -0700 Subject: Review request (XS): 7167437 - Can't build on linux without precompiled headers In-Reply-To: <4FAA2615.5020606@oracle.com> References: <4FAA2615.5020606@oracle.com> Message-ID: <20395.61779.90016.627274@oracle.com> Stefan Karlsson (stefan.karlsson at oracle.com) wrote: > http://cr.openjdk.java.net/~stefank/7167437/webrev/ > > The inline function set_concurrent_iteration_safe_limit is not available > when building binaryTreeDictionary.cpp. This breaks the build when > compiling with USE_PRECOMPILED_HEADER=0. > > I moved the simple implementation to the .hpp file instead of the > .inline.hpp file. Change looks fine. I'm curious why it's necessary - Solaris compiles without pch. Would including space.inline.hpp in binaryTreeDictionary.cpp (or .hpp) also solve it? -John From stefan.karlsson at oracle.com Thu May 10 17:31:53 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 10 May 2012 19:31:53 +0200 Subject: Review request (XS): 7167437 - Can't build on linux without precompiled headers In-Reply-To: <20395.61779.90016.627274@oracle.com> References: <4FAA2615.5020606@oracle.com> <20395.61779.90016.627274@oracle.com> Message-ID: <4FABFB89.4050207@oracle.com> On 2012-05-10 18:48, John Coomes wrote: > Stefan Karlsson (stefan.karlsson at oracle.com) wrote: >> http://cr.openjdk.java.net/~stefank/7167437/webrev/ >> >> The inline function set_concurrent_iteration_safe_limit is not available >> when building binaryTreeDictionary.cpp. This breaks the build when >> compiling with USE_PRECOMPILED_HEADER=0. >> >> I moved the simple implementation to the .hpp file instead of the >> .inline.hpp file. > Change looks fine. Thanks. > > I'm curious why it's necessary - Solaris compiles without pch. The last time I encountered a similar problem the inline.hpp file was included after the usage for the inline function. The Sun Studio compiler seems to handle it but GCC complains. > Would > including space.inline.hpp in binaryTreeDictionary.cpp (or .hpp) also > solve it? Yes, but it's not apparent from the code in binaryTreeDictionary.cpp that it will end up using set_concurrent_iteration_safe_limit. A better solution, IMHO, is to not have calls in hpp files going to functions in inline.hpp files. This will also help us reduce the amount of dependencies and implementation code in the hpp files. Last time I checked almost all cpp files brought in around 400 hpp files. StefanK > > -John From John.Coomes at oracle.com Thu May 10 20:00:17 2012 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 10 May 2012 13:00:17 -0700 Subject: Request for review (S): 7167069: 6 VM flags crash the VM when queried via jinfo In-Reply-To: <4FABAE1E.8070604@oracle.com> References: <4FAB856D.7070607@oracle.com> <4FAB8C6F.7070005@oracle.com> <4FABAE1E.8070604@oracle.com> Message-ID: <20396.7761.611945.194006@oracle.com> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: > > Stefan, > > Thanks for looking at this. > > On 2012-05-10 11:37, Stefan Karlsson wrote: > > The fix looks good, but the test needs a copyright header and should > > probably use two spaces for the indentations. > > There seem to be some inconsistencies within JTReg with regards to both > copyright and indentation. But I did as you suggested. Here's an updated > webrev: > > http://cr.openjdk.java.net/~brutisso/7167069/webrev.01/ Looks good to me except for a nit on the copyright - the test is a new file, so list just the current year (remove 2008). -John > > On 2012-05-10 11:07, Bengt Rutisson wrote: > >> > >> Hi all, > >> > >> Can I have some reviews of this simple fix: > >> http://cr.openjdk.java.net/~brutisso/7167069/webrev.00/ > >> > >> Sending this to both Runtime and GC. The change is in runtime code, > >> but all the concerned flags are GC flags and I plan to push this > >> through the GC repository unless there are any objections to that. > >> > >> When command line flags with the double type were introduced the > >> methods Flag::print_on() and Flag::print_as_flag() were not updated > >> correspondingly. The Flag::print_on() method was updated as part of > >> this change: > >> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6ee479178066 > >> > >> But the Flag::print_as_flag() still didn't handle doubles. > >> > >> I created a JTReg test that should test one flag of each supported type. > >> > >> Thanks, > >> Bengt > > > From bengt.rutisson at oracle.com Thu May 10 20:33:27 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 10 May 2012 22:33:27 +0200 Subject: Request for review (S): 7167069: 6 VM flags crash the VM when queried via jinfo In-Reply-To: <20396.7761.611945.194006@oracle.com> References: <4FAB856D.7070607@oracle.com> <4FAB8C6F.7070005@oracle.com> <4FABAE1E.8070604@oracle.com> <20396.7761.611945.194006@oracle.com> Message-ID: <4FAC2617.5070809@oracle.com> John, On 2012-05-10 22:00, John Coomes wrote: > Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >> Stefan, >> >> Thanks for looking at this. >> >> On 2012-05-10 11:37, Stefan Karlsson wrote: >>> The fix looks good, but the test needs a copyright header and should >>> probably use two spaces for the indentations. >> There seem to be some inconsistencies within JTReg with regards to both >> copyright and indentation. But I did as you suggested. Here's an updated >> webrev: >> >> http://cr.openjdk.java.net/~brutisso/7167069/webrev.01/ > Looks good to me except for a nit on the copyright - the test is a new > file, so list just the current year (remove 2008). Good catch. Coleen pointed that out as well, so I fixed it before I started the JPRT job. The push job is currently executing on hotspotwest, so unfortunately I can't add you as a reviewer. But thanks for looking at this! Bengt > > -John > >>> On 2012-05-10 11:07, Bengt Rutisson wrote: >>>> Hi all, >>>> >>>> Can I have some reviews of this simple fix: >>>> http://cr.openjdk.java.net/~brutisso/7167069/webrev.00/ >>>> >>>> Sending this to both Runtime and GC. The change is in runtime code, >>>> but all the concerned flags are GC flags and I plan to push this >>>> through the GC repository unless there are any objections to that. >>>> >>>> When command line flags with the double type were introduced the >>>> methods Flag::print_on() and Flag::print_as_flag() were not updated >>>> correspondingly. The Flag::print_on() method was updated as part of >>>> this change: >>>> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6ee479178066 >>>> >>>> But the Flag::print_as_flag() still didn't handle doubles. >>>> >>>> I created a JTReg test that should test one flag of each supported type. >>>> >>>> Thanks, >>>> Bengt From bengt.rutisson at oracle.com Thu May 10 21:17:25 2012 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Thu, 10 May 2012 21:17:25 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7167069: 6 VM flags crash the VM when queried via jinfo Message-ID: <20120510211731.D1AA447245@hg.openjdk.java.net> Changeset: f47478089efc Author: brutisso Date: 2012-05-10 14:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f47478089efc 7167069: 6 VM flags crash the VM when queried via jinfo Summary: Added missing double format to Flag::print_as_flag() Reviewed-by: dholmes, stefank, coleenp ! src/share/vm/runtime/globals.cpp + test/runtime/7167069/PrintAsFlag.java From john.coomes at oracle.com Fri May 11 03:51:06 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 May 2012 03:51:06 +0000 Subject: hg: hsx/hotspot-gc: 6 new changesets Message-ID: <20120511035106.A180D47268@hg.openjdk.java.net> Changeset: afeeed8e5f8c Author: ihse Date: 2012-04-30 12:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/afeeed8e5f8c 7165277: Fix missing execute permission issue running logger.sh Reviewed-by: ohair ! common/autoconf/configure ! common/autoconf/configure.ac Changeset: b2972095a4b1 Author: katleman Date: 2012-05-02 15:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/b2972095a4b1 Merge Changeset: 2eeb9fac7dfc Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/2eeb9fac7dfc Added tag jdk8-b37 for changeset b2972095a4b1 ! .hgtags Changeset: 2f06b15e2439 Author: ewendeli Date: 2012-05-03 14:17 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/2f06b15e2439 7154130: Add Mac OS X Instructions to README-builds.html Reviewed-by: ohair Contributed-by: edvard.wendelin at oracle.com ! README-builds.html Changeset: d939bd0ab13c Author: katleman Date: 2012-05-09 16:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/d939bd0ab13c Merge Changeset: b67bdaca36c2 Author: katleman Date: 2012-05-10 10:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/b67bdaca36c2 Added tag jdk8-b38 for changeset d939bd0ab13c ! .hgtags From john.coomes at oracle.com Fri May 11 03:51:11 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 May 2012 03:51:11 +0000 Subject: hg: hsx/hotspot-gc/corba: 7 new changesets Message-ID: <20120511035117.4420747269@hg.openjdk.java.net> Changeset: c6c0b1047985 Author: jmelvin Date: 2012-04-16 17:10 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/c6c0b1047985 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 Summary: On Mac OS X, align system property "os.arch" with Apple legacy JDKs. Also, improve os.name string matching by using .contains() method instead of .startsWith(). This fix spans multiple repositories. Reviewed-by: dcubed, phh, ohair, katleman ! make/common/shared/Platform.gmk Changeset: 9cdcc0152526 Author: coffeys Date: 2012-04-20 17:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/9cdcc0152526 7161925: sjava files in corba don't have copyright string and legal notice Reviewed-by: chegar Contributed-by: misha.bykov at oracle.com ! src/share/classes/com/sun/corba/se/impl/orbutil/DefineWrapper.sjava ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLTypesUtil_save.sjava Changeset: df0c7369a86b Author: lana Date: 2012-04-26 14:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/df0c7369a86b Merge Changeset: 4a653e435441 Author: lana Date: 2012-05-01 11:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/4a653e435441 Merge Changeset: 2d2f6b0f855b Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/2d2f6b0f855b Added tag jdk8-b37 for changeset 83fac66442cf ! .hgtags Changeset: b8cbfb31139f Author: katleman Date: 2012-05-09 13:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/b8cbfb31139f Merge Changeset: 785af00e2827 Author: katleman Date: 2012-05-10 10:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/785af00e2827 Added tag jdk8-b38 for changeset b8cbfb31139f ! .hgtags From john.coomes at oracle.com Fri May 11 03:51:22 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 May 2012 03:51:22 +0000 Subject: hg: hsx/hotspot-gc/jaxp: 4 new changesets Message-ID: <20120511035137.41D0D4726A@hg.openjdk.java.net> Changeset: aabc08ea546f Author: ohair Date: 2012-04-30 16:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/aabc08ea546f 7165312: Fix jaxp source movement for new build-infra Reviewed-by: ohrstrom ! makefiles/Makefile Changeset: 90204bfab4e2 Author: katleman Date: 2012-05-02 15:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/90204bfab4e2 Merge Changeset: 5bbe0cb6f2f2 Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/5bbe0cb6f2f2 Added tag jdk8-b37 for changeset 90204bfab4e2 ! .hgtags Changeset: f95fdbe525c8 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/f95fdbe525c8 Added tag jdk8-b38 for changeset 5bbe0cb6f2f2 ! .hgtags From john.coomes at oracle.com Fri May 11 03:51:43 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 May 2012 03:51:43 +0000 Subject: hg: hsx/hotspot-gc/jaxws: 2 new changesets Message-ID: <20120511035150.A99324726B@hg.openjdk.java.net> Changeset: ac1ba3b56775 Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/ac1ba3b56775 Added tag jdk8-b37 for changeset b05a948db1b6 ! .hgtags Changeset: 7f6b44fd3034 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/7f6b44fd3034 Added tag jdk8-b38 for changeset ac1ba3b56775 ! .hgtags From john.coomes at oracle.com Fri May 11 03:53:45 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 May 2012 03:53:45 +0000 Subject: hg: hsx/hotspot-gc/jdk: 49 new changesets Message-ID: <20120511040236.B65E447271@hg.openjdk.java.net> Changeset: 8e3fb7dd21cd Author: skovatch Date: 2012-04-25 12:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8e3fb7dd21cd 7128699: Fix bundle name so it contains the bugfix number in the name. Reviewed-by: robilad ! make/common/Release-macosx.gmk Changeset: 919be2f7fd6e Author: cgruszka Date: 2012-04-27 14:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/919be2f7fd6e Merge Changeset: 762661efef30 Author: jgodinez Date: 2012-04-24 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/762661efef30 7157659: [macosx] Landscape Printing orientation doesn't work Reviewed-by: bae, prr ! src/macosx/native/sun/awt/PrinterView.m Changeset: cdaadcc2c6a4 Author: jgodinez Date: 2012-04-26 13:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cdaadcc2c6a4 7013850: Please change the mnemonic assignment system to avoid translation issue Reviewed-by: prr, mfang ! src/share/classes/sun/print/ServiceDialog.java ! src/share/classes/sun/print/resources/serviceui.properties ! src/share/classes/sun/print/resources/serviceui_de.properties ! src/share/classes/sun/print/resources/serviceui_es.properties ! src/share/classes/sun/print/resources/serviceui_fr.properties ! src/share/classes/sun/print/resources/serviceui_it.properties ! src/share/classes/sun/print/resources/serviceui_ja.properties ! src/share/classes/sun/print/resources/serviceui_ko.properties ! src/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_sv.properties ! src/share/classes/sun/print/resources/serviceui_zh_CN.properties ! src/share/classes/sun/print/resources/serviceui_zh_TW.properties Changeset: c2d29a375871 Author: lana Date: 2012-04-26 18:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c2d29a375871 Merge Changeset: 4a19075bb989 Author: lana Date: 2012-05-02 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4a19075bb989 Merge Changeset: 44beb8a52aec Author: zhouyx Date: 2012-04-20 10:34 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/44beb8a52aec 7129742: Unable to view focus in Non-Editable TextArea Summary: Make sure the cursor is visible by setVisible(true) Reviewed-by: rupashka, alexp ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java + test/java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java Changeset: dfa2ea47257d Author: luchsh Date: 2012-04-20 13:13 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/dfa2ea47257d 7055065: NullPointerException when sorting JTable with empty cell Reviewed-by: rupashka ! src/share/classes/javax/swing/JTable.java + test/javax/swing/JTable/7055065/bug7055065.java Changeset: 738b32fc3ef1 Author: anthony Date: 2012-04-24 17:47 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/738b32fc3ef1 7150109: [macosx] the Frame showed incomplete. Summary: Open-source the tests Reviewed-by: art + test/java/awt/Frame/FrameStateTest/FrameStateTest.html + test/java/awt/Frame/FrameStateTest/FrameStateTest.java Changeset: 9ed029a0326d Author: anthony Date: 2012-04-24 19:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9ed029a0326d 7163898: add isLoggable() check to doLog() Summary: Add the check and return immediately if it's false Reviewed-by: anthony, mchung, sla Contributed-by: Nicolas Carranza ! src/share/classes/sun/util/logging/PlatformLogger.java Changeset: 4a0f6ef43a09 Author: anthony Date: 2012-04-24 20:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4a0f6ef43a09 7131021: [macosx] Consider using system properties to pass arguments from the launcher to AWT/SplashScreen Summary: Document the environment variables and add tests Reviewed-by: ksrini ! src/macosx/bin/java_md_macosx.c + test/tools/launcher/EnvironmentVariables.java ! test/tools/launcher/TestHelper.java + test/tools/launcher/TestSpecialArgs.java Changeset: 36fd5078198b Author: alexsch Date: 2012-04-25 16:48 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/36fd5078198b 7163482: [macosx] Regtest closed/javax/swing/JTree/4908142/bug4908142.java intermittent failure Reviewed-by: rupashka + test/javax/swing/JTree/4908142/bug4908142.java Changeset: f1d1dab11a06 Author: leonidr Date: 2012-04-25 18:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f1d1dab11a06 7154480: [macosx] Not all popup menu items are visible Reviewed-by: art ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/sun/awt/SunToolkit.java Changeset: 340cda7e1430 Author: luchsh Date: 2012-04-26 12:39 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/340cda7e1430 7154030: java.awt.Component.hide() does not repaint parent component Reviewed-by: rupashka ! src/share/classes/javax/swing/JComponent.java + test/javax/swing/JComponent/7154030/bug7154030.java Changeset: 6314933aeaa9 Author: alexp Date: 2012-04-26 21:16 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6314933aeaa9 7124210: [macosx] Replacing text in a TextField does generate an extra TextEvent Reviewed-by: serb ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java Changeset: 4184e5cbf46e Author: alexp Date: 2012-04-26 21:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4184e5cbf46e 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value Reviewed-by: anthony ! src/share/classes/javax/swing/JDesktopPane.java Changeset: d148d3d194af Author: lana Date: 2012-04-26 18:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d148d3d194af Merge Changeset: bbbf4e63562b Author: dcherepanov Date: 2012-05-02 13:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bbbf4e63562b 7154062: [macosx] Mouse cursor isn't updated in applets Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/macosx/CCursorManager.java ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/macosx/native/sun/awt/CCursorManager.m Changeset: 0fad89bd606b Author: alexsch Date: 2012-05-02 17:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0fad89bd606b 7154048: [macosx] At least drag twice, the toolbar can be dragged to the left side Reviewed-by: anthony, leonidr ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTView.h ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java + test/java/awt/Mouse/EnterExitEvents/DragWindowTest.java + test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java ! test/java/awt/regtesthelpers/Util.java Changeset: f906d6068b43 Author: lana Date: 2012-05-02 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f906d6068b43 Merge Changeset: 7b023213681c Author: psandoz Date: 2012-04-19 14:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7b023213681c 7162262: (fs) Typo in java.nio.file.Path class description Reviewed-by: alanb ! src/share/classes/java/nio/file/Path.java Changeset: 77b35c5c4b95 Author: jmelvin Date: 2012-04-16 18:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/77b35c5c4b95 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 Summary: On Mac OS X, align system property "os.arch" with Apple legacy JDKs. Also, improve os.name string matching by using .contains() method instead of .startsWith(). This fix spans multiple repositories. Reviewed-by: dcubed, phh, ohair, katleman ! make/common/Defs-macosx.gmk ! make/common/shared/Platform.gmk ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/nio/Bits.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/sun/awt/OSInfo.java ! src/share/classes/sun/font/FontUtilities.java ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/print/PSPrinterJob.java ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/provider/ByteArrayAccess.java ! src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java ! test/demo/jvmti/DemoRun.java ! test/java/io/File/GetXSpace.java ! test/java/lang/ProcessBuilder/Basic.java ! test/java/lang/ProcessBuilder/Zombies.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/management/OperatingSystemMXBean/GetSystemLoadAverage.java ! test/java/nio/channels/FileChannel/Size.java ! test/java/nio/channels/FileChannel/Transfer.java ! test/java/nio/file/FileSystem/Basic.java ! test/sun/nio/ch/SelProvider.java ! test/tools/launcher/TestHelper.java Changeset: 079bb040b2ee Author: coleenp Date: 2012-04-19 10:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/079bb040b2ee Merge Changeset: 404c8e097ae9 Author: vinnie Date: 2012-04-19 16:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/404c8e097ae9 7162823: Modify the list of excluded tests (ProblemList Reviewed-by: alanb ! test/ProblemList.txt Changeset: bc51d0569ccd Author: khazra Date: 2012-04-19 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bc51d0569ccd 7162385: TEST_BUG: sun/net/www/protocol/jar/B4957695.java failing again Summary: Enable finding "foo1.jar" Reviewed-by: chegar ! test/sun/net/www/protocol/jar/B4957695.java Changeset: 715f50872ae7 Author: khazra Date: 2012-04-19 18:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/715f50872ae7 7158636: InterfaceAddress.getBroadcast() returns invalid broadcast address on WLAN Summary: Update Windows native code to infer WLAN interface type in Windows Vista and later Reviewed-by: chegar, alanb ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface.h Changeset: c3905c1f5da7 Author: zhouyx Date: 2012-04-20 16:11 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c3905c1f5da7 7159982: ZipFile uses static for error message when malformed zip file encountered Reviewed-by: alanb, dholmes ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c Changeset: ec9876082b4e Author: ksrini Date: 2012-04-22 06:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ec9876082b4e 6981776: Pack200 must support -target 7 bytecodes Summary: pack200 implementation of JSR-200 updated for JSR-292 changes Reviewed-by: jrose, ksrini Contributed-by: john.r.rose at oracle.com, kumar.x.srinivasan at oracle.com ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/TLGlobals.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/constants.h ! src/share/native/com/sun/java/util/jar/pack/defines.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.h ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/PackageVersionTest.java ! test/tools/pack200/Utils.java - test/tools/pack200/dyn.jar ! test/tools/pack200/pack200-verifier/data/README ! test/tools/pack200/pack200-verifier/data/golden.jar ! test/tools/pack200/pack200-verifier/make/build.xml ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: c2da01f0bdc1 Author: alanb Date: 2012-04-22 19:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c2da01f0bdc1 7163395: jdk8/tl no longer builds on Mac Reviewed-by: chegar, ohair, ksrini - src/macosx/bin/amd64/jvm.cfg + src/macosx/bin/x86_64/jvm.cfg Changeset: 07dab8d9e34a Author: alanb Date: 2012-04-22 19:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/07dab8d9e34a Merge - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: 1980be18d0f8 Author: alanb Date: 2012-04-22 21:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1980be18d0f8 7132924: (dc) DatagramChannel.disconnect throws SocketException with IPv4 socket and IPv6 enabled [macosx] Reviewed-by: chegar ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c + test/java/nio/channels/DatagramChannel/Disconnect.java Changeset: fd22345bf1bf Author: sla Date: 2012-04-23 16:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fd22345bf1bf 7163524: Add SecTaskAccess attribute to jstack [macosx] Reviewed-by: dholmes ! make/launchers/Makefile.launcher Changeset: 2c35304e885a Author: youdwei Date: 2012-04-24 21:06 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2c35304e885a 7163865: Performance improvement for DateFormatSymbols.getZoneIndex(String) Reviewed-by: okutsu ! src/share/classes/java/text/DateFormatSymbols.java Changeset: f68c854fa584 Author: ksrini Date: 2012-04-24 10:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f68c854fa584 7151434: java -jar -XX crashes java launcher Reviewed-by: mchung, darcy ! src/share/bin/java.c ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java Changeset: fcdbd1f34309 Author: khazra Date: 2012-04-24 14:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fcdbd1f34309 7144274: [macosx] Default IPv6 multicast interface is not being set when calling MulticastSocket.joinGroup() Summary: Get default interface for Mac OS X when interface is not set Reviewed-by: chegar ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/net_util_md.c Changeset: 3e398b549cea Author: khazra Date: 2012-04-25 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3e398b549cea 7160242: (prefs) Preferences.remove(null) does not throw NPE [macosx] Summary: Insert null check of argument in remove()'s implementation Reviewed-by: forax, chegar, alanb ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java + test/java/util/prefs/RemoveNullKeyCheck.java Changeset: 108a02a57b75 Author: khazra Date: 2012-04-26 12:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/108a02a57b75 7118100: (prefs) Inconsistency when using system and user preference on OSX Lion Summary: Enable user to read/write preferences to persistent storage Reviewed-by: alanb ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java Changeset: 1cdcca9f3530 Author: lana Date: 2012-04-26 14:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1cdcca9f3530 Merge Changeset: f0842ed897c3 Author: xuelei Date: 2012-04-27 04:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f0842ed897c3 6996372: synchronizing handshaking hash Summary: remove the unnecessary synchronization. Also reviewed by David Schlosnagle (schlosna at gmail.com) Reviewed-by: weijun ! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java Changeset: c22b2f9066dd Author: alanb Date: 2012-05-01 11:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c22b2f9066dd 7164570: (fs) WatchService queues CREATE event but not DELETE event for very short lived files [sol11] Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java + test/java/nio/file/WatchService/MayFlies.java Changeset: 71fdf32fdc65 Author: xuelei Date: 2012-05-01 03:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/71fdf32fdc65 7158688: Typo in SSLContext Spec Reviewed-by: weijun, wetmore ! src/share/classes/javax/net/ssl/SSLContext.java Changeset: 6c9c3d7ce9e2 Author: lana Date: 2012-05-01 11:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6c9c3d7ce9e2 Merge Changeset: 46e0bd218fcc Author: mchung Date: 2012-05-01 19:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/46e0bd218fcc 7164376: Replace use of sun.security.action.LoadLibraryAction with System.loadLibrary Reviewed-by: alanb, mullan, prr ! src/macosx/classes/apple/launcher/JavaAppLauncher.java ! src/macosx/classes/apple/security/KeychainStore.java ! src/macosx/classes/com/apple/concurrent/LibDispatchNative.java ! src/macosx/classes/com/apple/eawt/Application.java ! src/macosx/classes/com/apple/eio/FileManager.java ! src/macosx/classes/com/apple/laf/AquaFileView.java ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/com/apple/laf/AquaNativeResources.java ! src/macosx/classes/com/apple/laf/ScreenMenu.java ! src/macosx/classes/com/apple/laf/ScreenPopupFactory.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/classes/sun/awt/CGraphicsEnvironment.java ! src/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/event/NativeLibLoader.java ! src/share/classes/java/awt/image/ColorModel.java ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/DatagramPacket.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/sun/awt/NativeLibLoader.java ! src/share/classes/sun/awt/image/JPEGImageDecoder.java ! src/share/classes/sun/awt/image/NativeLibLoader.java ! src/share/classes/sun/java2d/Disposer.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/net/sdp/SdpSupport.java ! src/share/classes/sun/net/spi/DefaultProxySelector.java ! src/share/classes/sun/nio/ch/Util.java - src/share/classes/sun/security/action/LoadLibraryAction.java ! src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java ! src/share/classes/sun/security/smartcardio/PCSC.java ! src/share/classes/sun/tracing/dtrace/JVM.java ! src/solaris/classes/sun/management/FileSystemImpl.java ! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/management/FileSystemImpl.java ! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/sun/print/Win32PrintServiceLookup.java ! src/windows/classes/sun/security/smartcardio/PlatformPCSC.java Changeset: d78c6095dc98 Author: vinnie Date: 2012-05-02 14:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d78c6095dc98 7087021: TEST: com/sun/crypto/provider/Mac/MacClone.java failed on Solaris sparc 5.10 Reviewed-by: mullan ! test/com/sun/crypto/provider/Mac/MacClone.java Changeset: 717582c056f3 Author: lana Date: 2012-05-02 10:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/717582c056f3 Merge - src/macosx/bin/amd64/jvm.cfg - src/share/classes/sun/security/action/LoadLibraryAction.java ! test/tools/launcher/TestHelper.java - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: bc0f9e693620 Author: lana Date: 2012-05-08 13:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bc0f9e693620 Merge - src/macosx/bin/amd64/jvm.cfg - src/share/classes/sun/security/action/LoadLibraryAction.java - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: 185821106403 Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/185821106403 Added tag jdk8-b37 for changeset 9e82ac15ab80 ! .hgtags Changeset: c45f3509a707 Author: katleman Date: 2012-05-09 13:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c45f3509a707 Merge - src/macosx/bin/amd64/jvm.cfg - src/share/classes/sun/security/action/LoadLibraryAction.java - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: b5726775b0d8 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b5726775b0d8 Added tag jdk8-b38 for changeset c45f3509a707 ! .hgtags From bengt.rutisson at oracle.com Fri May 11 11:30:16 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 11 May 2012 13:30:16 +0200 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: References: <4FA7C0B4.40905@oracle.com> <4FA83A28.1040504@oracle.com> <4FA92B1F.6000804@oracle.com> Message-ID: <4FACF848.5030805@oracle.com> Hi Kris, Thanks again for looking at this. I had to make some minor changes make it compile on all platforms. Mostly some explicit casts to const char*. Here is an updated webrev: http://cr.openjdk.java.net/~brutisso/7166894/webrev.04/ More comments inline. On 2012-05-08 16:43, Krystal Mok wrote: > Hi Bengt, > > The current factoring looks nice and uniform. Thanks :-) > > But for most minor GCs and both CMS pause phases, the extra logging > doesn't really give additional information. > Most minor GCs are going to say "Allocation Failure", and the two CMS > phases would change from, e.g. > > [GC [1 CMS-initial-mark > > to something like > > [GC (CMS Initial Mark) [1 CMS-initial-mark > > which is probably reasonable given the scope of the change, but not > really helpful. > The "real cause", such as which generation (or perhaps System.gc() > with ExplicitGCInvokesConcurrent, or even GC locker) is triggering > this collection cycle, may be more useful, but it's hard to fit into > the current form. Yes, I think you are correct in both cases. The gc cause that we have available does not always add a lot of information. This is relevant to fix but it is a slightly different issue than what this patch sets out to fix. Let's try to get this in first and then evaluate how the GC causes should be set. Thanks, Bengt > > - Kris > > On Tue, May 8, 2012 at 10:18 PM, Bengt Rutisson > > wrote: > > > Hi again everyone, > > It seems like the feedback on hotspot-gc-use is that we should add > the GC cause to all collectors but also provide a switch to turn > this logging off. > > Here is an updated webrev: > http://cr.openjdk.java.net/~brutisso/7166894/webrev.03/ > > > Changes: > * GC cause logged for all collectors > * Added the flag -XX:-PrintGCCause to turn the new information off > * Refactored the string concatenation code into a helper class > > I guess I will also have to update the CR to now reflect the fact > that this does not just concern full GCs anymore. > > Thanks, > Bengt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.coomes at oracle.com Fri May 11 14:21:40 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 May 2012 14:21:40 +0000 Subject: hg: hsx/hotspot-gc/langtools: 9 new changesets Message-ID: <20120511142201.BD0E34728A@hg.openjdk.java.net> Changeset: 55ae94116e89 Author: jjg Date: 2012-04-06 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/55ae94116e89 7157626: Create a new test to check major version for a class file Reviewed-by: jjg Contributed-by: sonali.goel at oracle.com + test/tools/javac/classfiles/ClassVersionChecker.java Changeset: 9c429f38ca7e Author: ksrini Date: 2012-04-09 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/9c429f38ca7e 7156633: (javac) incorrect errors when parsing variable declaration in block statements. Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/IllegalStartOfStmt.java + test/tools/javac/diags/examples/NotAllowedClass.java + test/tools/javac/diags/examples/NotAllowedVariable.java ! test/tools/javac/parser/JavacParserTest.java Changeset: c35b158e2290 Author: lana Date: 2012-04-10 23:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/c35b158e2290 Merge Changeset: 6f0ed5a89c25 Author: mcimadamore Date: 2012-04-11 10:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/6f0ed5a89c25 7154127: Inference cleanup: remove bound check analysis from visitors in Types.java Summary: Remove bound checking rules from recursive subtype visitors in Types.java and replace with centralized bound-checking logic Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/Diagnostics/6722234/T6722234b_1.out ! test/tools/javac/Diagnostics/6722234/T6722234b_2.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/cast/7123100/T7123100a.out ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/CantApplyDiamond1.java ! test/tools/javac/diags/examples/IncompatibleTypes1.java + test/tools/javac/diags/examples/InferNoConformingAssignment.java - test/tools/javac/diags/examples/InferredDoNotConformToBounds.java + test/tools/javac/diags/examples/InferredDoNotConformToEq.java + test/tools/javac/diags/examples/InferredDoNotConformToLower.java + test/tools/javac/diags/examples/InferredDoNotConformToUpper.java ! test/tools/javac/diags/examples/InvalidInferredTypes.java ! test/tools/javac/diags/examples/WhereCaptured.java ! test/tools/javac/diags/examples/WhereCaptured1.java + test/tools/javac/diags/examples/WhereFreshTvar.java ! test/tools/javac/generics/diamond/neg/Neg06.out ! test/tools/javac/generics/diamond/neg/Neg07.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712d.out ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/6650759/T6650759m.out ! test/tools/javac/generics/inference/7086601/T7086601a.out + test/tools/javac/generics/inference/7154127/T7154127.java + test/tools/javac/generics/inference/7154127/T7154127.out Changeset: d023d5c3fbd2 Author: lana Date: 2012-04-18 10:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d023d5c3fbd2 Merge - test/tools/javac/diags/examples/InferredDoNotConformToBounds.java Changeset: 94bbaa67686f Author: lana Date: 2012-04-23 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/94bbaa67686f Merge - test/tools/javac/diags/examples/InferredDoNotConformToBounds.java Changeset: 5891b38985e8 Author: katleman Date: 2012-04-26 14:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/5891b38985e8 Added tag jdk8-b36 for changeset 94bbaa67686f ! .hgtags Changeset: 1f224f160aa8 Author: katleman Date: 2012-05-09 13:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/1f224f160aa8 Added tag jdk8-b37 for changeset 5891b38985e8 ! .hgtags Changeset: a9f547c218d9 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/a9f547c218d9 Added tag jdk8-b38 for changeset 1f224f160aa8 ! .hgtags From rednaxelafx at gmail.com Fri May 11 15:48:55 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 11 May 2012 23:48:55 +0800 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: <4FACF848.5030805@oracle.com> References: <4FA7C0B4.40905@oracle.com> <4FA83A28.1040504@oracle.com> <4FA92B1F.6000804@oracle.com> <4FACF848.5030805@oracle.com> Message-ID: On Fri, May 11, 2012 at 7:30 PM, Bengt Rutisson wrote: > > Yes, I think you are correct in both cases. The gc cause that we have > available does not always add a lot of information. This is relevant to fix > but it is a slightly different issue than what this patch sets out to fix. > Let's try to get this in first and then evaluate how the GC causes should > be set. > > Agreed. It's helpful for some cases, and people are gonna want it :-) > Thanks, > Bengt > > Regards, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.vidstedt at oracle.com Fri May 11 17:17:16 2012 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 11 May 2012 13:17:16 -0400 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: <4FACF848.5030805@oracle.com> References: <4FA7C0B4.40905@oracle.com> <4FA83A28.1040504@oracle.com> <4FA92B1F.6000804@oracle.com> <4FACF848.5030805@oracle.com> Message-ID: <4FAD499C.5070108@oracle.com> I'm all for improving the information in the log messages, great work! However, I'm not sure I'm warm and fuzzy about potentially breaking users' log parsers in a minor update. My preference would be to have the PrintGCCause flag be default false in jdk7 and default true in jdk8+. In general I'd prefer to only change the log messages in major releases. Reasonable? Cheers, Mikael On 2012-05-11 07:30, Bengt Rutisson wrote: > > Hi Kris, > > Thanks again for looking at this. > > I had to make some minor changes make it compile on all platforms. > Mostly some explicit casts to const char*. Here is an updated webrev: > http://cr.openjdk.java.net/~brutisso/7166894/webrev.04/ > > More comments inline. > > On 2012-05-08 16:43, Krystal Mok wrote: >> Hi Bengt, >> >> The current factoring looks nice and uniform. Thanks :-) >> >> But for most minor GCs and both CMS pause phases, the extra logging >> doesn't really give additional information. >> Most minor GCs are going to say "Allocation Failure", and the two CMS >> phases would change from, e.g. >> >> [GC [1 CMS-initial-mark >> >> to something like >> >> [GC (CMS Initial Mark) [1 CMS-initial-mark >> >> which is probably reasonable given the scope of the change, but not >> really helpful. >> The "real cause", such as which generation (or perhaps System.gc() >> with ExplicitGCInvokesConcurrent, or even GC locker) is triggering >> this collection cycle, may be more useful, but it's hard to fit into >> the current form. > > Yes, I think you are correct in both cases. The gc cause that we have > available does not always add a lot of information. This is relevant > to fix but it is a slightly different issue than what this patch sets > out to fix. Let's try to get this in first and then evaluate how the > GC causes should be set. > > Thanks, > Bengt > >> >> - Kris >> >> On Tue, May 8, 2012 at 10:18 PM, Bengt Rutisson >> > wrote: >> >> >> Hi again everyone, >> >> It seems like the feedback on hotspot-gc-use is that we should >> add the GC cause to all collectors but also provide a switch to >> turn this logging off. >> >> Here is an updated webrev: >> http://cr.openjdk.java.net/~brutisso/7166894/webrev.03/ >> >> >> Changes: >> * GC cause logged for all collectors >> * Added the flag -XX:-PrintGCCause to turn the new information off >> * Refactored the string concatenation code into a helper class >> >> I guess I will also have to update the CR to now reflect the fact >> that this does not just concern full GCs anymore. >> >> Thanks, >> Bengt >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ysr1729 at gmail.com Fri May 11 17:51:05 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 11 May 2012 10:51:05 -0700 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: <4FAD499C.5070108@oracle.com> References: <4FA7C0B4.40905@oracle.com> <4FA83A28.1040504@oracle.com> <4FA92B1F.6000804@oracle.com> <4FACF848.5030805@oracle.com> <4FAD499C.5070108@oracle.com> Message-ID: Mikael, thanks for sounding that note of caution... what you say makes sense. -- ramki On Fri, May 11, 2012 at 10:17 AM, Mikael Vidstedt < mikael.vidstedt at oracle.com> wrote: > > I'm all for improving the information in the log messages, great work! > However, I'm not sure I'm warm and fuzzy about potentially breaking users' > log parsers in a minor update. My preference would be to have the > PrintGCCause flag be default false in jdk7 and default true in jdk8+. In > general I'd prefer to only change the log messages in major releases. > > Reasonable? > > Cheers, > Mikael > > > On 2012-05-11 07:30, Bengt Rutisson wrote: > > > Hi Kris, > > Thanks again for looking at this. > > I had to make some minor changes make it compile on all platforms. Mostly > some explicit casts to const char*. Here is an updated webrev: > http://cr.openjdk.java.net/~brutisso/7166894/webrev.04/ > > More comments inline. > > On 2012-05-08 16:43, Krystal Mok wrote: > > Hi Bengt, > > The current factoring looks nice and uniform. Thanks :-) > > But for most minor GCs and both CMS pause phases, the extra logging > doesn't really give additional information. > Most minor GCs are going to say "Allocation Failure", and the two CMS > phases would change from, e.g. > > [GC [1 CMS-initial-mark > > to something like > > [GC (CMS Initial Mark) [1 CMS-initial-mark > > which is probably reasonable given the scope of the change, but not > really helpful. > The "real cause", such as which generation (or perhaps System.gc() with > ExplicitGCInvokesConcurrent, or even GC locker) is triggering this > collection cycle, may be more useful, but it's hard to fit into the current > form. > > > Yes, I think you are correct in both cases. The gc cause that we have > available does not always add a lot of information. This is relevant to fix > but it is a slightly different issue than what this patch sets out to fix. > Let's try to get this in first and then evaluate how the GC causes should > be set. > > Thanks, > Bengt > > > - Kris > > On Tue, May 8, 2012 at 10:18 PM, Bengt Rutisson > wrote: > >> >> Hi again everyone, >> >> It seems like the feedback on hotspot-gc-use is that we should add the GC >> cause to all collectors but also provide a switch to turn this logging off. >> >> Here is an updated webrev: >> http://cr.openjdk.java.net/~brutisso/7166894/webrev.03/ >> >> Changes: >> * GC cause logged for all collectors >> * Added the flag -XX:-PrintGCCause to turn the new information off >> * Refactored the string concatenation code into a helper class >> >> I guess I will also have to update the CR to now reflect the fact that >> this does not just concern full GCs anymore. >> >> Thanks, >> Bengt >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.vidstedt at oracle.com Fri May 11 19:13:05 2012 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 11 May 2012 15:13:05 -0400 Subject: RFR(S): 7158457: division by zero in adaptiveweightedaverage In-Reply-To: References: <4F96EA96.2010004@oracle.com> <9485F5F2-BDA7-4845-ADC2-674DF555E6C3@gmail.com> <4F98A720.1090706@oracle.com> <4FA3A987.3090400@oracle.com> Message-ID: <4FAD64C1.8030605@oracle.com> Final(?) version, only difference is the removed assert in sample(): http://cr.openjdk.java.net/~mikael/7158457/webrev.02/ I'm also looking for a sponsor for this fix - any takers? Thanks, Mikael On 2012-05-05 05:57, Srinivas Ramakrishna wrote: > Mikael -- I agree that this fix would be good to get in, at least to > address the immediate crash. > > reviewed. > -- ramki > > On Fri, May 4, 2012 at 3:03 AM, Mikael Vidstedt > > wrote: > > > Update: > > I'd like to continue working on this issue, and as part of that > look at how the promoted and pretenured counters are used today > and potentially update the logic given the insights around bytes > vs. words etc. > > I think it would be helpful to address the crash problem short > term though, and so I'd like to get feedback on the updated webrev: > > http://cr.openjdk.java.net/~mikael/7158457/webrev.01/ > > > It's essentially the same as the previous one with Igor's > suggested _is_old check improvement. Would it be ok to make this > fix and clone the bug to track the follow-up work cleaning up the > actual logic/heuristics? > > Thanks, > Mikael > > > On 2012-04-26 03:38, Mikael Vidstedt wrote: >> >> On 2012-04-24 23:50, Igor Veresov wrote: >>> Wasn't it the case that _avg_pretenured value is formed >>> incorrectly? I don't think it should be sampled at every >>> allocation, I think it should measure the amount of data >>> allocated in the old gen between young collections, also if you >>> remember we agreed that the dimensions are wrong. Or were you >>> able to find a better explanation as opposed to what we >>> discussed before? >> >> Thanks for reminding me - I believe you're absolutely right. For >> a while I was thinking it actually did make sense after all, but >> I just did an experiment to see what actually happens at runtime: >> >> The _avg_pretenured counter is indeed sampled every time an >> allocation is made directly in old gen. The actual value reflects >> the average size *in words* of the object that was allocated. Put >> differently, it's the average size of pretenured objects in words. >> >> The counter is used in PSAdaptiveSizePolicy::update_averages to >> calculate the average amount of promoted data: >> >> avg_promoted()->sample(promoted + _avg_pretenured->padded_average()); >> >> The promoted parameter is the number of *bytes* that were just >> promoted. To sum it up, that appears to imply that there are two >> problems with the above computation: >> >> 1. It's taking the size of everything that was just promoted and >> adds the size of an average prenured object (as opposed to the >> total size of all recently pretenured objects) >> 2. It's adding variables with different dimensions - promoted is >> in bytes, and the _avg_pretenured padded average is in words >> >> Since that effectively means _avg_pretenured it's off by a factor >> (word_size * number_of_objects) I'm guessing it will in the >> common case not really matter to the calculation of avg_promoted... >> >> >>> >>> As for the treatment of the symptom, the code looks good to me. >>> Do you think it might be beneficial to check the old value of >>> _is_old before assigning to it? Would cause less memory traffic, >>> if increment_count() is called frequently. >>> 60 void increment_count() { >>> 61 _sample_count++; >>> 62 if (!_is_old&& _sample_count> OLD_THRESHOLD) { >>> 63 _is_old = true; >>> 64 } >>> 65 } >> >> Good suggestion. I'll update my change with this in case we need >> something urgently, but given the above issues it's likely a good >> idea to take another pass at this. >> >> Thanks, >> Mikael >> >>> >>> igor >>> >>> On Apr 24, 2012, at 8:01 AM, Mikael Vidstedt wrote: >>> >>>> >>>> Hi all, >>>> >>>> The statistical counters in gcUtil are used to keep track of >>>> historical information about various key metrics in the garbage >>>> collectors. Built in to the core AdaptiveWeightedAverage base >>>> class is the concept of aging the values, essentially treating >>>> the first 100 values differently and putting more weight on >>>> them since there's not yet enough historical data built up. >>>> >>>> In the class there is a 32-bit counter (_sample_count) that >>>> incremented for every sample and used to compute scale the >>>> weight of the added value (see compute_adaptive_average), and >>>> the scaling logic divides 100 by the count. In the normal case >>>> this is not a problem - the counters are reset every once in a >>>> while and/or grow very slowly. In some pathological cases the >>>> counter will however continue to increment and eventually >>>> overflow/wrap, meaning the 32-bit count will go back to zero >>>> and the division in compute_adaptive_average will lead to a >>>> div-by-zero crash. >>>> >>>> The test case where this is observed is a test that stress >>>> tests allocation in combination with the GC locker. >>>> Specifically, the test is multi-threaded which pounds on >>>> java.util.zip.Deflater.deflate, which internally uses the >>>> GetPrimitiveArrayCritical JNI function to temporarily lock out >>>> the GC (using the GC locker). The garbage collector used is in >>>> this case the parallel scavenger and the the counter that >>>> overflows is _avg_pretenured. _avg_pretenured is >>>> incremented/sampled every time an allocation is made directly >>>> in the old gen, which I believe is more likely when the GC >>>> locker is active. >>>> >>>> >>>> The suggested fix is to only perform the division in >>>> compute_adaptive_average when it is relevant, which currently >>>> is for the first 100 values. Once there are more than 100 >>>> samples there is no longer a need to scale the weight. >>>> >>>> This problem is tracked in 7158457 (stress: jdk7 u4 core dumps >>>> during megacart stress test run). >>>> >>>> Please review and comment on the webrev below: >>>> >>>> http://cr.openjdk.java.net/~mikael/7158457/webrev.00 >>>> >>>> >>>> Thanks, >>>> Mikael >>>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Fri May 11 22:37:21 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 11 May 2012 15:37:21 -0700 Subject: RFR(XXXS): 7168294: G1: Some Full GCs incorrectly report GC cause as "No GC" Message-ID: <4FAD94A1.5000608@oracle.com> Hi Everyone, Can I have a couple of volunteers review this code change? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7168294/webrev.0/ Summary: Basically the VM_G1CollectForAllocation VM operation was not setting the GC cause in the heap structure and so the cause would come out as "No GC". This one line change makes VM_G1CollectForAllocation match the other 'leaf' G1 VM operations. Testing: GCOld Before: 9.239: [Full GC (No GC) 128M->125M(128M), 9.0804393 secs] 18.837: [Full GC (No GC) 127M->127M(128M), 7.9413652 secs] 26.778: [Full GC (No GC) 127M->127M(128M), 7.9419157 secs] 34.731: [Full GC (No GC) 127M->127M(128M), 8.0385112 secs] 42.770: [Full GC (No GC) 127M->127M(128M), 7.9215393 secs] 50.702: [Full GC (No GC) 127M->127M(128M), 9.0424004 secs] 59.744: [Full GC (No GC) 127M->127M(128M), 7.9409172 secs] After: 9.357: [Full GC (Allocation Failure) 128M->125M(128M), 9.1094425 secs] 18.976: [Full GC (Allocation Failure) 127M->127M(128M), 7.9846687 secs] 26.961: [Full GC (Allocation Failure) 127M->127M(128M), 7.9409885 secs] 34.913: [Full GC (Allocation Failure) 127M->127M(128M), 8.0551207 secs] 42.968: [Full GC (Allocation Failure) 127M->127M(128M), 7.9402328 secs] 50.919: [Full GC (Allocation Failure) 127M->127M(128M), 9.0121452 secs] 59.932: [Full GC (Allocation Failure) 127M->127M(128M), 7.9184263 secs] Thanks, JohnC From ysr1729 at gmail.com Sat May 12 06:08:49 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 11 May 2012 23:08:49 -0700 Subject: RFR(XXXS): 7168294: G1: Some Full GCs incorrectly report GC cause as "No GC" In-Reply-To: <4FAD94A1.5000608@oracle.com> References: <4FAD94A1.5000608@oracle.com> Message-ID: <4BA8FF76-5EBF-4705-A7A7-A0B768BF06C2@gmail.com> Looks good to me. -- ramki Sent from my iPhone On May 11, 2012, at 3:37 PM, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers review this code change? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7168294/webrev.0/ > > Summary: > Basically the VM_G1CollectForAllocation VM operation was not setting the GC cause in the heap structure and so the cause would come out as "No GC". This one line change makes VM_G1CollectForAllocation match the other 'leaf' G1 VM operations. > > Testing: GCOld > > Before: > > 9.239: [Full GC (No GC) 128M->125M(128M), 9.0804393 secs] > 18.837: [Full GC (No GC) 127M->127M(128M), 7.9413652 secs] > 26.778: [Full GC (No GC) 127M->127M(128M), 7.9419157 secs] > 34.731: [Full GC (No GC) 127M->127M(128M), 8.0385112 secs] > 42.770: [Full GC (No GC) 127M->127M(128M), 7.9215393 secs] > 50.702: [Full GC (No GC) 127M->127M(128M), 9.0424004 secs] > 59.744: [Full GC (No GC) 127M->127M(128M), 7.9409172 secs] > > After: > > 9.357: [Full GC (Allocation Failure) 128M->125M(128M), 9.1094425 secs] > 18.976: [Full GC (Allocation Failure) 127M->127M(128M), 7.9846687 secs] > 26.961: [Full GC (Allocation Failure) 127M->127M(128M), 7.9409885 secs] > 34.913: [Full GC (Allocation Failure) 127M->127M(128M), 8.0551207 secs] > 42.968: [Full GC (Allocation Failure) 127M->127M(128M), 7.9402328 secs] > 50.919: [Full GC (Allocation Failure) 127M->127M(128M), 9.0121452 secs] > 59.932: [Full GC (Allocation Failure) 127M->127M(128M), 7.9184263 secs] > > Thanks, > > JohnC From alejandro.murillo at oracle.com Sun May 13 01:31:37 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sun, 13 May 2012 01:31:37 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 17 new changesets Message-ID: <20120513013213.4F923472C9@hg.openjdk.java.net> Changeset: 4ee58fcab520 Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4ee58fcab520 Added tag jdk8-b37 for changeset bfcf92bfefb8 ! .hgtags Changeset: 637c3f5f068f Author: amurillo Date: 2012-05-09 14:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/637c3f5f068f Merge ! .hgtags Changeset: 3c394919ca69 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3c394919ca69 Added tag jdk8-b38 for changeset 637c3f5f068f ! .hgtags Changeset: 8bafad97cd26 Author: jiangli Date: 2012-05-02 13:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8bafad97cd26 7158552: The instanceKlsss::_host_klass is only needed for anonymous class for JSR 292 support. Summary: Change the _host_klass to be conditionally created embedded instanceKlass field. Reviewed-by: jrose, coleenp, dholmes ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp Changeset: 38b4116b6766 Author: jprovino Date: 2012-05-05 10:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/38b4116b6766 Merge Changeset: c7ed11779ce8 Author: jiangli Date: 2012-04-10 09:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c7ed11779ce8 7159772: instanceKlass::all_fields_count() returns incorrect total field count Summary: Fix instanceKlass::all_fields_count() bug. Reviewed-by: kvn, never Contributed-by: Jiangli Zhou ! src/share/vm/oops/instanceKlass.hpp Changeset: 3576af4cb939 Author: iveresov Date: 2012-04-11 19:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3576af4cb939 7160539: JDeveloper crashes on 64-bit Windows Summary: x64 C1 needs to zero upper 32bits when doing l2i conversion Reviewed-by: never, kvn ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 847da049d62f Author: never Date: 2012-04-17 11:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/847da049d62f 7162094: LateInlineCallGenerator::do_late_inline crashed on uninitialized _call_node Reviewed-by: never, twisti Contributed-by: nils.eliasson at oracle.com ! src/share/vm/opto/callGenerator.cpp Changeset: df3d4a91f7f6 Author: never Date: 2012-04-18 16:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/df3d4a91f7f6 7161796: PhaseStringOpts::fetch_static_field tries to fetch field from the Klass instead of the mirror Reviewed-by: twisti ! src/share/vm/opto/stringopts.cpp Changeset: ec15e8f6e4f1 Author: twisti Date: 2012-04-24 12:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ec15e8f6e4f1 7157695: Add windows implementation of socket interface Reviewed-by: kvn, dholmes, twisti Contributed-by: Nils Eliasson ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/os_windows.cpp Changeset: dc682d9431f3 Author: kvn Date: 2012-05-07 12:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/dc682d9431f3 7160610: Unknown Native Code compilation issue Summary: When constructing input vector use type of vector's operation which use it since element's sizes should match. Reviewed-by: never, twisti ! src/share/vm/opto/superword.cpp + test/compiler/7160610/Test7160610.java Changeset: 3a97daec1b34 Author: kvn Date: 2012-05-08 15:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3a97daec1b34 7167266: missing copyright notes in 3rd party code Summary: add missing copyright notes to the regression test file. Reviewed-by: twisti, johnc ! test/compiler/7070134/Stemmer.java Changeset: 2766551175a0 Author: kvn Date: 2012-05-09 10:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2766551175a0 Merge ! src/share/vm/oops/instanceKlass.hpp Changeset: 5799726c54d7 Author: jcoomes Date: 2012-05-11 06:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5799726c54d7 Merge Changeset: 73147e6c4881 Author: amurillo Date: 2012-05-11 14:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/73147e6c4881 Merge Changeset: 96a403721094 Author: amurillo Date: 2012-05-11 14:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/96a403721094 Added tag hs24-b10 for changeset 73147e6c4881 ! .hgtags Changeset: 56d1af561395 Author: amurillo Date: 2012-05-11 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/56d1af561395 7168247: new hotspot build - hs24-b11 Reviewed-by: jcoomes ! make/hotspot_version From bengt.rutisson at oracle.com Mon May 14 06:20:37 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 14 May 2012 08:20:37 +0200 Subject: RFR(XXXS): 7168294: G1: Some Full GCs incorrectly report GC cause as "No GC" In-Reply-To: <4FAD94A1.5000608@oracle.com> References: <4FAD94A1.5000608@oracle.com> Message-ID: <4FB0A435.3070004@oracle.com> Hi John, Looks good! Thanks for finding out where the No GC came from! I know I had seen it in some log output. Bengt On 2012-05-12 00:37, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers review this code change? The webrev > can be found at: http://cr.openjdk.java.net/~johnc/7168294/webrev.0/ > > Summary: > Basically the VM_G1CollectForAllocation VM operation was not setting > the GC cause in the heap structure and so the cause would come out as > "No GC". This one line change makes VM_G1CollectForAllocation match > the other 'leaf' G1 VM operations. > > Testing: GCOld > > Before: > > 9.239: [Full GC (No GC) 128M->125M(128M), 9.0804393 secs] > 18.837: [Full GC (No GC) 127M->127M(128M), 7.9413652 secs] > 26.778: [Full GC (No GC) 127M->127M(128M), 7.9419157 secs] > 34.731: [Full GC (No GC) 127M->127M(128M), 8.0385112 secs] > 42.770: [Full GC (No GC) 127M->127M(128M), 7.9215393 secs] > 50.702: [Full GC (No GC) 127M->127M(128M), 9.0424004 secs] > 59.744: [Full GC (No GC) 127M->127M(128M), 7.9409172 secs] > > After: > > 9.357: [Full GC (Allocation Failure) 128M->125M(128M), 9.1094425 secs] > 18.976: [Full GC (Allocation Failure) 127M->127M(128M), 7.9846687 secs] > 26.961: [Full GC (Allocation Failure) 127M->127M(128M), 7.9409885 secs] > 34.913: [Full GC (Allocation Failure) 127M->127M(128M), 8.0551207 secs] > 42.968: [Full GC (Allocation Failure) 127M->127M(128M), 7.9402328 secs] > 50.919: [Full GC (Allocation Failure) 127M->127M(128M), 9.0121452 secs] > 59.932: [Full GC (Allocation Failure) 127M->127M(128M), 7.9184263 secs] > > Thanks, > > JohnC From bengt.rutisson at oracle.com Mon May 14 07:46:39 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 14 May 2012 09:46:39 +0200 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: References: <4FA7C0B4.40905@oracle.com> <4FA83A28.1040504@oracle.com> <4FA92B1F.6000804@oracle.com> <4FACF848.5030805@oracle.com> <4FAD499C.5070108@oracle.com> Message-ID: <4FB0B85F.9060400@oracle.com> Hi again, :-) Here is an updated webrev where PrintGCCause is off by default in JDK7 but on by default in JDK8: http://cr.openjdk.java.net/~brutisso/7166894/webrev.05/ The relevant change is in arguments.cpp: http://cr.openjdk.java.net/~brutisso/7166894/webrev.05/src/share/vm/runtime/arguments.cpp.udiff.html With this proposal there is still one slight change in JDK7 logging. For full GCs that were triggered by System.gc() calls we used to log the cause. Now this will not happen unless you add -XX:+PrintGCCause. This will not break any parsers, but it might make some parsers miss System.gc() calls. I think we are getting closer to wrapping this change up. It is a little unclear to me who would like to be listed as reviewers. Could those that would like to be reviewers please take a look at the latest webrev and let me know. Thanks, Bengt On 2012-05-11 19:51, Srinivas Ramakrishna wrote: > Mikael, thanks for sounding that note of caution... what you say makes > sense. > > -- ramki > > On Fri, May 11, 2012 at 10:17 AM, Mikael Vidstedt > > wrote: > > > I'm all for improving the information in the log messages, great > work! However, I'm not sure I'm warm and fuzzy about potentially > breaking users' log parsers in a minor update. My preference would > be to have the PrintGCCause flag be default false in jdk7 and > default true in jdk8+. In general I'd prefer to only change the > log messages in major releases. > > Reasonable? > > Cheers, > Mikael > > > On 2012-05-11 07:30, Bengt Rutisson wrote: >> >> Hi Kris, >> >> Thanks again for looking at this. >> >> I had to make some minor changes make it compile on all >> platforms. Mostly some explicit casts to const char*. Here is an >> updated webrev: >> http://cr.openjdk.java.net/~brutisso/7166894/webrev.04/ >> >> >> More comments inline. >> >> On 2012-05-08 16:43, Krystal Mok wrote: >>> Hi Bengt, >>> >>> The current factoring looks nice and uniform. Thanks :-) >>> >>> But for most minor GCs and both CMS pause phases, the extra >>> logging doesn't really give additional information. >>> Most minor GCs are going to say "Allocation Failure", and the >>> two CMS phases would change from, e.g. >>> >>> [GC [1 CMS-initial-mark >>> >>> to something like >>> >>> [GC (CMS Initial Mark) [1 CMS-initial-mark >>> >>> which is probably reasonable given the scope of the change, but >>> not really helpful. >>> The "real cause", such as which generation (or perhaps >>> System.gc() with ExplicitGCInvokesConcurrent, or even GC locker) >>> is triggering this collection cycle, may be more useful, but >>> it's hard to fit into the current form. >> >> Yes, I think you are correct in both cases. The gc cause that we >> have available does not always add a lot of information. This is >> relevant to fix but it is a slightly different issue than what >> this patch sets out to fix. Let's try to get this in first and >> then evaluate how the GC causes should be set. >> >> Thanks, >> Bengt >> >>> >>> - Kris >>> >>> On Tue, May 8, 2012 at 10:18 PM, Bengt Rutisson >>> > >>> wrote: >>> >>> >>> Hi again everyone, >>> >>> It seems like the feedback on hotspot-gc-use is that we >>> should add the GC cause to all collectors but also provide a >>> switch to turn this logging off. >>> >>> Here is an updated webrev: >>> http://cr.openjdk.java.net/~brutisso/7166894/webrev.03/ >>> >>> >>> Changes: >>> * GC cause logged for all collectors >>> * Added the flag -XX:-PrintGCCause to turn the new >>> information off >>> * Refactored the string concatenation code into a helper class >>> >>> I guess I will also have to update the CR to now reflect the >>> fact that this does not just concern full GCs anymore. >>> >>> Thanks, >>> Bengt >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Mon May 14 10:34:02 2012 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 14 May 2012 12:34:02 +0200 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: <4FB0B85F.9060400@oracle.com> References: <4FA7C0B4.40905@oracle.com> <4FA83A28.1040504@oracle.com> <4FA92B1F.6000804@oracle.com> <4FACF848.5030805@oracle.com> <4FAD499C.5070108@oracle.com> <4FB0B85F.9060400@oracle.com> Message-ID: <4FB0DF9A.3010609@oracle.com> Bengt, On 2012-05-14 09:46, Bengt Rutisson wrote: > > Hi again, :-) > > Here is an updated webrev where PrintGCCause is off by default in JDK7 > but on by default in JDK8: > http://cr.openjdk.java.net/~brutisso/7166894/webrev.05/ > > The relevant change is in arguments.cpp: > http://cr.openjdk.java.net/~brutisso/7166894/webrev.05/src/share/vm/runtime/arguments.cpp.udiff.html > > With this proposal there is still one slight change in JDK7 logging. For > full GCs that were triggered by System.gc() calls we used to log the > cause. Now this will not happen unless you add -XX:+PrintGCCause. This > will not break any parsers, but it might make some parsers miss > System.gc() calls. I think this is a fair compromise. If you had to keep the exact existing semantics for when to print "System" or "System.gc" then the code would have been a lot more ugly. This looks good to me. /mg > > I think we are getting closer to wrapping this change up. It is a little > unclear to me who would like to be listed as reviewers. Could those that > would like to be reviewers please take a look at the latest webrev and > let me know. > > Thanks, > Bengt > > > On 2012-05-11 19:51, Srinivas Ramakrishna wrote: >> Mikael, thanks for sounding that note of caution... what you say makes >> sense. >> >> -- ramki >> >> On Fri, May 11, 2012 at 10:17 AM, Mikael Vidstedt >> > wrote: >> >> >> I'm all for improving the information in the log messages, great >> work! However, I'm not sure I'm warm and fuzzy about potentially >> breaking users' log parsers in a minor update. My preference would >> be to have the PrintGCCause flag be default false in jdk7 and >> default true in jdk8+. In general I'd prefer to only change the >> log messages in major releases. >> >> Reasonable? >> >> Cheers, >> Mikael >> >> >> On 2012-05-11 07:30, Bengt Rutisson wrote: >>> >>> Hi Kris, >>> >>> Thanks again for looking at this. >>> >>> I had to make some minor changes make it compile on all >>> platforms. Mostly some explicit casts to const char*. Here is an >>> updated webrev: >>> http://cr.openjdk.java.net/~brutisso/7166894/webrev.04/ >>> >>> >>> More comments inline. >>> >>> On 2012-05-08 16:43, Krystal Mok wrote: >>>> Hi Bengt, >>>> >>>> The current factoring looks nice and uniform. Thanks :-) >>>> >>>> But for most minor GCs and both CMS pause phases, the extra >>>> logging doesn't really give additional information. >>>> Most minor GCs are going to say "Allocation Failure", and the >>>> two CMS phases would change from, e.g. >>>> >>>> [GC [1 CMS-initial-mark >>>> >>>> to something like >>>> >>>> [GC (CMS Initial Mark) [1 CMS-initial-mark >>>> >>>> which is probably reasonable given the scope of the change, but >>>> not really helpful. >>>> The "real cause", such as which generation (or perhaps >>>> System.gc() with ExplicitGCInvokesConcurrent, or even GC locker) >>>> is triggering this collection cycle, may be more useful, but >>>> it's hard to fit into the current form. >>> >>> Yes, I think you are correct in both cases. The gc cause that we >>> have available does not always add a lot of information. This is >>> relevant to fix but it is a slightly different issue than what >>> this patch sets out to fix. Let's try to get this in first and >>> then evaluate how the GC causes should be set. >>> >>> Thanks, >>> Bengt >>> >>>> >>>> - Kris >>>> >>>> On Tue, May 8, 2012 at 10:18 PM, Bengt Rutisson >>>> > >>>> wrote: >>>> >>>> >>>> Hi again everyone, >>>> >>>> It seems like the feedback on hotspot-gc-use is that we >>>> should add the GC cause to all collectors but also provide a >>>> switch to turn this logging off. >>>> >>>> Here is an updated webrev: >>>> http://cr.openjdk.java.net/~brutisso/7166894/webrev.03/ >>>> >>>> >>>> Changes: >>>> * GC cause logged for all collectors >>>> * Added the flag -XX:-PrintGCCause to turn the new >>>> information off >>>> * Refactored the string concatenation code into a helper class >>>> >>>> I guess I will also have to update the CR to now reflect the >>>> fact that this does not just concern full GCs anymore. >>>> >>>> Thanks, >>>> Bengt >>>> >>> >> >> > From bengt.rutisson at oracle.com Mon May 14 11:32:46 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 14 May 2012 13:32:46 +0200 Subject: Request for review (S): 7161545: G1: Minor cleanups to the G1 logging In-Reply-To: <4F99C274.5020208@oracle.com> References: <4F8BE739.7000306@oracle.com> <4F95E797.80508@oracle.com> <4F97F132.8050707@oracle.com> <4F99C274.5020208@oracle.com> Message-ID: <4FB0ED5E.2010301@oracle.com> Hi all, I still only have one reviewer (Thanks John Cu!) for this change. Anyone else feel like taking a look? Bengt On 2012-04-26 23:47, John Cuthbertson wrote: > Hi Bengt, > > Thanks for making the changes - looks good to me. And converting > no_of_workers etc to an unsigned as a separate CR is fine. > > JohnC > > On 04/25/12 05:42, Bengt Rutisson wrote: >> >> Hi John, >> >> Thanks for looking at this! >> >> Here's an updated webrev based on your comments: >> http://cr.openjdk.java.net/~brutisso/7161545/webrev.01/ >> >> I did not fix all of your comment. See my comments inline. >> >> On 2012-04-24 01:36, John Cuthbertson wrote: >>> Hi Bengt, >>> >>> This looks good to me. A couple of suggestions for your consideration: >>> >>> * Looking at the code, it occurred to me that >>> G1CollectorPolicy::print_par_stats() and >>> G1CollectorPolicy::print_par_sizes() are very similar. If you >>> passed the format string in as a parameter and permitted the order >>> in print_par_sizes() to match that in print_par_stats() (which it >>> probably should) then they could be coalesced into a single routine >>> (or a base routine and two callers). >> >> It is not really enough to just pass the format string since we also >> need to cast the values. Also, it is kind of strange to me to have >> the format string specified in one place and passing values to it in >> another place. >> >> However, you are definitely correct about the code duplication. I >> tried a different solution and added a parameter to the >> print_par_stats() to allow it to choose between the two format >> strings. What do you think about that? >> >>> * Did you consider extending the current version of >>> G1CollectorPolicy::print_stats() to take an additional, optional >>> (with a default value of NULL) extra_info parameter? >> >> Don't think this adds much value. The print_stats() methods are one >> liners so I don't think the code would be much simpler by doing this. >> >>> * Shouldn't 'workers' be an unsigned? Simlarly for no_of_gc_threads >>> (parameter and field of G1CollectorPolicy), and active_workers at >>> the call site of G1CollectorPolicy::record_collection_pause_end()? >> >> You are right, but g1CollectorPolicy is full of "int workers" so I >> don't think we should change that as part of this checkin. Should I >> file a separate CR to change all occurrences of "int workers" to >> "uint workers" in g1CollectorPolicy? >> >>> * Did you consider templatizing bytesize_in_proper_unit()? >> >> Good idea! I did that. >> >> Thanks again for looking at this! >> Bengt >> >> >>> >>> JohnC >>> >>> On 04/16/12 02:32, Bengt Rutisson wrote: >>>> >>>> Hi all, >>>> >>>> Could I have a couple of reviews for this? >>>> http://cr.openjdk.java.net/~brutisso/7161545/webrev.00 >>>> >>>> This includes four minor cleanups of the G1 logging: >>>> >>>> * Rename "to-space-overflow" to "to-space-exhausted" >>>> * Introduce one decimal point in the size format >>>> * Add Sum to the aggregate and re-order the entries >>>> * Add number of GC workers to the log output >>>> >>>> I also added gigabyte conversion to proper_unit_for_byte_size() and >>>> byte_size_in_proper_unit(). I hope that makes sense. It is not >>>> strictly necessary for this change, but I think it makes sense. I'm >>>> fine with leaving it out or pushing it as a separate change. >>>> >>>> >>>> After the change logging on the finest level will look like this: >>>> >>>> [GC pause (young), 0.00447433 secs] >>>> [Parallel Time: 3.3 ms, GC Workers: 4] >>>> [GC Worker Start (ms): 31098.2 31098.2 31098.3 31098.3 >>>> Min: 31098.2, Avg: 31098.2, Max: 31098.3, Diff: 0.1, Sum: >>>> 124392.9] >>>> [Ext Root Scanning (ms): 2.2 2.4 2.0 2.5 >>>> Min: 2.0, Avg: 2.3, Max: 2.5, Diff: 0.6, Sum: 9.1] >>>> [Update RS (ms): 0.2 0.0 0.3 0.0 >>>> Min: 0.0, Avg: 0.1, Max: 0.3, Diff: 0.3, Sum: 0.5] >>>> [Processed Buffers : 1 0 4 0 >>>> Sum: 5, Avg: 1, Min: 0, Max: 4, Diff: 4] >>>> [Scan RS (ms): 0.1 0.1 0.2 0.0 >>>> Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 0.3] >>>> [Object Copy (ms): 0.7 0.7 0.6 0.5 >>>> Min: 0.5, Avg: 0.6, Max: 0.7, Diff: 0.2, Sum: 2.5] >>>> [Termination (ms): 0.0 0.0 0.0 0.0 >>>> Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] >>>> [Termination Attempts : 1 1 1 1 >>>> Sum: 4, Avg: 1, Min: 1, Max: 1, Diff: 0] >>>> [GC Worker Other (ms): 0.1 0.0 0.1 0.1 >>>> Min: 0.0, Avg: 0.1, Max: 0.1, Diff: 0.0, Sum: 0.2] >>>> [GC Worker Total (ms): 3.2 3.2 3.2 3.1 >>>> Min: 3.1, Avg: 3.2, Max: 3.2, Diff: 0.1, Sum: 12.7] >>>> [GC Worker End (ms): 31101.4 31101.4 31101.4 31101.4 >>>> Min: 31101.4, Avg: 31101.4, Max: 31101.4, Diff: 0.0, Sum: >>>> 124405.6] >>>> [Code Root Fixup: 0.0 ms] >>>> [Clear CT: 0.1 ms] >>>> [Cur Clear CC: 0.0 ms] >>>> [Cum Clear CC: 0.1 ms] >>>> [Min Clear CC: 0.0 ms] >>>> [Max Clear CC: 0.0 ms] >>>> [Avg Clear CC: 0.0 ms] >>>> [Other: 1.1 ms] >>>> [Choose CSet: 0.0 ms] >>>> [Ref Proc: 0.1 ms] >>>> [Ref Enq: 0.0 ms] >>>> [Free CSet: 0.6 ms] >>>> [Eden: 79.0M(79.0M)->0.0B(79.0M) Survivors: 1024.0K->1024.0K >>>> Heap: 80.2M(100.0M)->1261.0K(100.0M)] >>>> [Times: user=0.06 sys=0.00, real=0.04 secs] >>>> >>>> >>>> Thanks, >>>> Bengt >>> >> > From jesper.wilhelmsson at oracle.com Mon May 14 11:54:31 2012 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 14 May 2012 13:54:31 +0200 Subject: Request for review (S): 7161545: G1: Minor cleanups to the G1 logging In-Reply-To: <4FB0ED5E.2010301@oracle.com> References: <4F8BE739.7000306@oracle.com> <4F95E797.80508@oracle.com> <4F97F132.8050707@oracle.com> <4F99C274.5020208@oracle.com> <4FB0ED5E.2010301@oracle.com> Message-ID: <4FB0F277.1000206@oracle.com> Looks good. Ship it! /Jesper On 2012-05-14 13:32, Bengt Rutisson wrote: > > Hi all, > > I still only have one reviewer (Thanks John Cu!) for this change. Anyone else > feel like taking a look? > > Bengt > > > On 2012-04-26 23:47, John Cuthbertson wrote: >> Hi Bengt, >> >> Thanks for making the changes - looks good to me. And converting >> no_of_workers etc to an unsigned as a separate CR is fine. >> >> JohnC >> >> On 04/25/12 05:42, Bengt Rutisson wrote: >>> >>> Hi John, >>> >>> Thanks for looking at this! >>> >>> Here's an updated webrev based on your comments: >>> http://cr.openjdk.java.net/~brutisso/7161545/webrev.01/ >>> >>> I did not fix all of your comment. See my comments inline. >>> >>> On 2012-04-24 01:36, John Cuthbertson wrote: >>>> Hi Bengt, >>>> >>>> This looks good to me. A couple of suggestions for your consideration: >>>> >>>> * Looking at the code, it occurred to me that >>>> G1CollectorPolicy::print_par_stats() and >>>> G1CollectorPolicy::print_par_sizes() are very similar. If you passed the >>>> format string in as a parameter and permitted the order in >>>> print_par_sizes() to match that in print_par_stats() (which it probably >>>> should) then they could be coalesced into a single routine (or a base >>>> routine and two callers). >>> >>> It is not really enough to just pass the format string since we also need >>> to cast the values. Also, it is kind of strange to me to have the format >>> string specified in one place and passing values to it in another place. >>> >>> However, you are definitely correct about the code duplication. I tried a >>> different solution and added a parameter to the print_par_stats() to allow >>> it to choose between the two format strings. What do you think about that? >>> >>>> * Did you consider extending the current version of >>>> G1CollectorPolicy::print_stats() to take an additional, optional (with a >>>> default value of NULL) extra_info parameter? >>> >>> Don't think this adds much value. The print_stats() methods are one liners >>> so I don't think the code would be much simpler by doing this. >>> >>>> * Shouldn't 'workers' be an unsigned? Simlarly for no_of_gc_threads >>>> (parameter and field of G1CollectorPolicy), and active_workers at the call >>>> site of G1CollectorPolicy::record_collection_pause_end()? >>> >>> You are right, but g1CollectorPolicy is full of "int workers" so I don't >>> think we should change that as part of this checkin. Should I file a >>> separate CR to change all occurrences of "int workers" to "uint workers" in >>> g1CollectorPolicy? >>> >>>> * Did you consider templatizing bytesize_in_proper_unit()? >>> >>> Good idea! I did that. >>> >>> Thanks again for looking at this! >>> Bengt >>> >>> >>>> >>>> JohnC >>>> >>>> On 04/16/12 02:32, Bengt Rutisson wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Could I have a couple of reviews for this? >>>>> http://cr.openjdk.java.net/~brutisso/7161545/webrev.00 >>>>> >>>>> This includes four minor cleanups of the G1 logging: >>>>> >>>>> * Rename "to-space-overflow" to "to-space-exhausted" >>>>> * Introduce one decimal point in the size format >>>>> * Add Sum to the aggregate and re-order the entries >>>>> * Add number of GC workers to the log output >>>>> >>>>> I also added gigabyte conversion to proper_unit_for_byte_size() and >>>>> byte_size_in_proper_unit(). I hope that makes sense. It is not strictly >>>>> necessary for this change, but I think it makes sense. I'm fine with >>>>> leaving it out or pushing it as a separate change. >>>>> >>>>> >>>>> After the change logging on the finest level will look like this: >>>>> >>>>> [GC pause (young), 0.00447433 secs] >>>>> [Parallel Time: 3.3 ms, GC Workers: 4] >>>>> [GC Worker Start (ms): 31098.2 31098.2 31098.3 31098.3 >>>>> Min: 31098.2, Avg: 31098.2, Max: 31098.3, Diff: 0.1, Sum: 124392.9] >>>>> [Ext Root Scanning (ms): 2.2 2.4 2.0 2.5 >>>>> Min: 2.0, Avg: 2.3, Max: 2.5, Diff: 0.6, Sum: 9.1] >>>>> [Update RS (ms): 0.2 0.0 0.3 0.0 >>>>> Min: 0.0, Avg: 0.1, Max: 0.3, Diff: 0.3, Sum: 0.5] >>>>> [Processed Buffers : 1 0 4 0 >>>>> Sum: 5, Avg: 1, Min: 0, Max: 4, Diff: 4] >>>>> [Scan RS (ms): 0.1 0.1 0.2 0.0 >>>>> Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 0.3] >>>>> [Object Copy (ms): 0.7 0.7 0.6 0.5 >>>>> Min: 0.5, Avg: 0.6, Max: 0.7, Diff: 0.2, Sum: 2.5] >>>>> [Termination (ms): 0.0 0.0 0.0 0.0 >>>>> Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] >>>>> [Termination Attempts : 1 1 1 1 >>>>> Sum: 4, Avg: 1, Min: 1, Max: 1, Diff: 0] >>>>> [GC Worker Other (ms): 0.1 0.0 0.1 0.1 >>>>> Min: 0.0, Avg: 0.1, Max: 0.1, Diff: 0.0, Sum: 0.2] >>>>> [GC Worker Total (ms): 3.2 3.2 3.2 3.1 >>>>> Min: 3.1, Avg: 3.2, Max: 3.2, Diff: 0.1, Sum: 12.7] >>>>> [GC Worker End (ms): 31101.4 31101.4 31101.4 31101.4 >>>>> Min: 31101.4, Avg: 31101.4, Max: 31101.4, Diff: 0.0, Sum: 124405.6] >>>>> [Code Root Fixup: 0.0 ms] >>>>> [Clear CT: 0.1 ms] >>>>> [Cur Clear CC: 0.0 ms] >>>>> [Cum Clear CC: 0.1 ms] >>>>> [Min Clear CC: 0.0 ms] >>>>> [Max Clear CC: 0.0 ms] >>>>> [Avg Clear CC: 0.0 ms] >>>>> [Other: 1.1 ms] >>>>> [Choose CSet: 0.0 ms] >>>>> [Ref Proc: 0.1 ms] >>>>> [Ref Enq: 0.0 ms] >>>>> [Free CSet: 0.6 ms] >>>>> [Eden: 79.0M(79.0M)->0.0B(79.0M) Survivors: 1024.0K->1024.0K Heap: >>>>> 80.2M(100.0M)->1261.0K(100.0M)] >>>>> [Times: user=0.06 sys=0.00, real=0.04 secs] >>>>> >>>>> >>>>> Thanks, >>>>> Bengt >>>> >>> >> > From bengt.rutisson at oracle.com Mon May 14 11:58:00 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 14 May 2012 13:58:00 +0200 Subject: Request for review (S): 7161545: G1: Minor cleanups to the G1 logging In-Reply-To: <4FB0F277.1000206@oracle.com> References: <4F8BE739.7000306@oracle.com> <4F95E797.80508@oracle.com> <4F97F132.8050707@oracle.com> <4F99C274.5020208@oracle.com> <4FB0ED5E.2010301@oracle.com> <4FB0F277.1000206@oracle.com> Message-ID: <4FB0F348.6000307@oracle.com> Thanks Jesper and John! All set to pus this now. Bengt On 2012-05-14 13:54, Jesper Wilhelmsson wrote: > Looks good. Ship it! > /Jesper > > On 2012-05-14 13:32, Bengt Rutisson wrote: >> >> Hi all, >> >> I still only have one reviewer (Thanks John Cu!) for this change. >> Anyone else >> feel like taking a look? >> >> Bengt >> >> >> On 2012-04-26 23:47, John Cuthbertson wrote: >>> Hi Bengt, >>> >>> Thanks for making the changes - looks good to me. And converting >>> no_of_workers etc to an unsigned as a separate CR is fine. >>> >>> JohnC >>> >>> On 04/25/12 05:42, Bengt Rutisson wrote: >>>> >>>> Hi John, >>>> >>>> Thanks for looking at this! >>>> >>>> Here's an updated webrev based on your comments: >>>> http://cr.openjdk.java.net/~brutisso/7161545/webrev.01/ >>>> >>>> I did not fix all of your comment. See my comments inline. >>>> >>>> On 2012-04-24 01:36, John Cuthbertson wrote: >>>>> Hi Bengt, >>>>> >>>>> This looks good to me. A couple of suggestions for your >>>>> consideration: >>>>> >>>>> * Looking at the code, it occurred to me that >>>>> G1CollectorPolicy::print_par_stats() and >>>>> G1CollectorPolicy::print_par_sizes() are very similar. If you >>>>> passed the >>>>> format string in as a parameter and permitted the order in >>>>> print_par_sizes() to match that in print_par_stats() (which it >>>>> probably >>>>> should) then they could be coalesced into a single routine (or a base >>>>> routine and two callers). >>>> >>>> It is not really enough to just pass the format string since we >>>> also need >>>> to cast the values. Also, it is kind of strange to me to have the >>>> format >>>> string specified in one place and passing values to it in another >>>> place. >>>> >>>> However, you are definitely correct about the code duplication. I >>>> tried a >>>> different solution and added a parameter to the print_par_stats() >>>> to allow >>>> it to choose between the two format strings. What do you think >>>> about that? >>>> >>>>> * Did you consider extending the current version of >>>>> G1CollectorPolicy::print_stats() to take an additional, optional >>>>> (with a >>>>> default value of NULL) extra_info parameter? >>>> >>>> Don't think this adds much value. The print_stats() methods are one >>>> liners >>>> so I don't think the code would be much simpler by doing this. >>>> >>>>> * Shouldn't 'workers' be an unsigned? Simlarly for no_of_gc_threads >>>>> (parameter and field of G1CollectorPolicy), and active_workers at >>>>> the call >>>>> site of G1CollectorPolicy::record_collection_pause_end()? >>>> >>>> You are right, but g1CollectorPolicy is full of "int workers" so I >>>> don't >>>> think we should change that as part of this checkin. Should I file a >>>> separate CR to change all occurrences of "int workers" to "uint >>>> workers" in >>>> g1CollectorPolicy? >>>> >>>>> * Did you consider templatizing bytesize_in_proper_unit()? >>>> >>>> Good idea! I did that. >>>> >>>> Thanks again for looking at this! >>>> Bengt >>>> >>>> >>>>> >>>>> JohnC >>>>> >>>>> On 04/16/12 02:32, Bengt Rutisson wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Could I have a couple of reviews for this? >>>>>> http://cr.openjdk.java.net/~brutisso/7161545/webrev.00 >>>>>> >>>>>> This includes four minor cleanups of the G1 logging: >>>>>> >>>>>> * Rename "to-space-overflow" to "to-space-exhausted" >>>>>> * Introduce one decimal point in the size format >>>>>> * Add Sum to the aggregate and re-order the entries >>>>>> * Add number of GC workers to the log output >>>>>> >>>>>> I also added gigabyte conversion to proper_unit_for_byte_size() and >>>>>> byte_size_in_proper_unit(). I hope that makes sense. It is not >>>>>> strictly >>>>>> necessary for this change, but I think it makes sense. I'm fine with >>>>>> leaving it out or pushing it as a separate change. >>>>>> >>>>>> >>>>>> After the change logging on the finest level will look like this: >>>>>> >>>>>> [GC pause (young), 0.00447433 secs] >>>>>> [Parallel Time: 3.3 ms, GC Workers: 4] >>>>>> [GC Worker Start (ms): 31098.2 31098.2 31098.3 31098.3 >>>>>> Min: 31098.2, Avg: 31098.2, Max: 31098.3, Diff: 0.1, Sum: 124392.9] >>>>>> [Ext Root Scanning (ms): 2.2 2.4 2.0 2.5 >>>>>> Min: 2.0, Avg: 2.3, Max: 2.5, Diff: 0.6, Sum: 9.1] >>>>>> [Update RS (ms): 0.2 0.0 0.3 0.0 >>>>>> Min: 0.0, Avg: 0.1, Max: 0.3, Diff: 0.3, Sum: 0.5] >>>>>> [Processed Buffers : 1 0 4 0 >>>>>> Sum: 5, Avg: 1, Min: 0, Max: 4, Diff: 4] >>>>>> [Scan RS (ms): 0.1 0.1 0.2 0.0 >>>>>> Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 0.3] >>>>>> [Object Copy (ms): 0.7 0.7 0.6 0.5 >>>>>> Min: 0.5, Avg: 0.6, Max: 0.7, Diff: 0.2, Sum: 2.5] >>>>>> [Termination (ms): 0.0 0.0 0.0 0.0 >>>>>> Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] >>>>>> [Termination Attempts : 1 1 1 1 >>>>>> Sum: 4, Avg: 1, Min: 1, Max: 1, Diff: 0] >>>>>> [GC Worker Other (ms): 0.1 0.0 0.1 0.1 >>>>>> Min: 0.0, Avg: 0.1, Max: 0.1, Diff: 0.0, Sum: 0.2] >>>>>> [GC Worker Total (ms): 3.2 3.2 3.2 3.1 >>>>>> Min: 3.1, Avg: 3.2, Max: 3.2, Diff: 0.1, Sum: 12.7] >>>>>> [GC Worker End (ms): 31101.4 31101.4 31101.4 31101.4 >>>>>> Min: 31101.4, Avg: 31101.4, Max: 31101.4, Diff: 0.0, Sum: 124405.6] >>>>>> [Code Root Fixup: 0.0 ms] >>>>>> [Clear CT: 0.1 ms] >>>>>> [Cur Clear CC: 0.0 ms] >>>>>> [Cum Clear CC: 0.1 ms] >>>>>> [Min Clear CC: 0.0 ms] >>>>>> [Max Clear CC: 0.0 ms] >>>>>> [Avg Clear CC: 0.0 ms] >>>>>> [Other: 1.1 ms] >>>>>> [Choose CSet: 0.0 ms] >>>>>> [Ref Proc: 0.1 ms] >>>>>> [Ref Enq: 0.0 ms] >>>>>> [Free CSet: 0.6 ms] >>>>>> [Eden: 79.0M(79.0M)->0.0B(79.0M) Survivors: 1024.0K->1024.0K Heap: >>>>>> 80.2M(100.0M)->1261.0K(100.0M)] >>>>>> [Times: user=0.06 sys=0.00, real=0.04 secs] >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>> >>>> >>> >> From john.cuthbertson at oracle.com Mon May 14 19:00:10 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 14 May 2012 12:00:10 -0700 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: <4FB0B85F.9060400@oracle.com> References: <4FA7C0B4.40905@oracle.com> <4FA83A28.1040504@oracle.com> <4FA92B1F.6000804@oracle.com> <4FACF848.5030805@oracle.com> <4FAD499C.5070108@oracle.com> <4FB0B85F.9060400@oracle.com> Message-ID: <4FB1563A.4070708@oracle.com> Hi Bengt, Overall this looks good to me, but I do have a couple of minor comments and questions.... arguments.cpp - Typo @ line 3096 gcCause.hpp - fields in the new class should have a leading underscore. g1CollectedHeap.cpp - @ line 3600. IMO using a local to hold the GC string and pass that into the TraceTime constructor would improve the readability significantly. g1CollectorPolicy.cpp - @ line 888. If you have a log level == finer, where is the print of the date/timestamp prefix now? Other than that, it looks good? JohnC On 05/14/12 00:46, Bengt Rutisson wrote: > > Hi again, :-) > > Here is an updated webrev where PrintGCCause is off by default in JDK7 > but on by default in JDK8: > http://cr.openjdk.java.net/~brutisso/7166894/webrev.05/ > > The relevant change is in arguments.cpp: > http://cr.openjdk.java.net/~brutisso/7166894/webrev.05/src/share/vm/runtime/arguments.cpp.udiff.html > > With this proposal there is still one slight change in JDK7 logging. > For full GCs that were triggered by System.gc() calls we used to log > the cause. Now this will not happen unless you add -XX:+PrintGCCause. > This will not break any parsers, but it might make some parsers miss > System.gc() calls. > > I think we are getting closer to wrapping this change up. It is a > little unclear to me who would like to be listed as reviewers. Could > those that would like to be reviewers please take a look at the latest > webrev and let me know. > > Thanks, > Bengt > > > On 2012-05-11 19:51, Srinivas Ramakrishna wrote: >> Mikael, thanks for sounding that note of caution... what you say >> makes sense. >> >> -- ramki >> >> On Fri, May 11, 2012 at 10:17 AM, Mikael Vidstedt >> > wrote: >> >> >> I'm all for improving the information in the log messages, great >> work! However, I'm not sure I'm warm and fuzzy about potentially >> breaking users' log parsers in a minor update. My preference >> would be to have the PrintGCCause flag be default false in jdk7 >> and default true in jdk8+. In general I'd prefer to only change >> the log messages in major releases. >> >> Reasonable? >> >> Cheers, >> Mikael >> >> >> On 2012-05-11 07:30, Bengt Rutisson wrote: >>> >>> Hi Kris, >>> >>> Thanks again for looking at this. >>> >>> I had to make some minor changes make it compile on all >>> platforms. Mostly some explicit casts to const char*. Here is an >>> updated webrev: >>> http://cr.openjdk.java.net/~brutisso/7166894/webrev.04/ >>> >>> >>> More comments inline. >>> >>> On 2012-05-08 16:43, Krystal Mok wrote: >>>> Hi Bengt, >>>> >>>> The current factoring looks nice and uniform. Thanks :-) >>>> >>>> But for most minor GCs and both CMS pause phases, the extra >>>> logging doesn't really give additional information. >>>> Most minor GCs are going to say "Allocation Failure", and the >>>> two CMS phases would change from, e.g. >>>> >>>> [GC [1 CMS-initial-mark >>>> >>>> to something like >>>> >>>> [GC (CMS Initial Mark) [1 CMS-initial-mark >>>> >>>> which is probably reasonable given the scope of the change, but >>>> not really helpful. >>>> The "real cause", such as which generation (or perhaps >>>> System.gc() with ExplicitGCInvokesConcurrent, or even GC >>>> locker) is triggering this collection cycle, may be more >>>> useful, but it's hard to fit into the current form. >>> >>> Yes, I think you are correct in both cases. The gc cause that we >>> have available does not always add a lot of information. This is >>> relevant to fix but it is a slightly different issue than what >>> this patch sets out to fix. Let's try to get this in first and >>> then evaluate how the GC causes should be set. >>> >>> Thanks, >>> Bengt >>> >>>> >>>> - Kris >>>> >>>> On Tue, May 8, 2012 at 10:18 PM, Bengt Rutisson >>>> > >>>> wrote: >>>> >>>> >>>> Hi again everyone, >>>> >>>> It seems like the feedback on hotspot-gc-use is that we >>>> should add the GC cause to all collectors but also provide >>>> a switch to turn this logging off. >>>> >>>> Here is an updated webrev: >>>> http://cr.openjdk.java.net/~brutisso/7166894/webrev.03/ >>>> >>>> >>>> Changes: >>>> * GC cause logged for all collectors >>>> * Added the flag -XX:-PrintGCCause to turn the new >>>> information off >>>> * Refactored the string concatenation code into a helper class >>>> >>>> I guess I will also have to update the CR to now reflect >>>> the fact that this does not just concern full GCs anymore. >>>> >>>> Thanks, >>>> Bengt >>>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Mon May 14 19:22:58 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 14 May 2012 12:22:58 -0700 Subject: RFR (XXS): 7158682: G1: Handle leak when running nsk.sysdict tests In-Reply-To: <4F983D88.7050708@oracle.com> References: <4F983D88.7050708@oracle.com> Message-ID: <4FB15B92.5030500@oracle.com> Hi Everyone, I have a new webrev based upon a suggestion from Bengt and Mikael Gerdin which can be found here: http://cr.openjdk.java.net/~johnc/7158682/webrev.1/ Testing: * GC test suite with G1 and CM (both with and without biased locking enabled). JohnC On 04/25/12 11:08, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers to review this fairly small change? > The webrev can be found at: > http://cr.openjdk.java.net/~johnc/7158682/webrev/ > > Summary: > This issue was mainly caused by the excessively high number of GC > retry attempts seen (and fixed) in 7147724. Each time we retry the GC > we allocate a handle to hold the pending list lock and there is no > HandleMark around the code that retries the GC. As a result of the > combination of these two factors, we ran out of C heap and couldn't > allocate a new HandleArea. The fixes for 7147724 address the excessive > retry attempts - but we can still retry the GC if the prologue > operations are not successful and we still don't free the handles > allocated in the prologues of the attempted GC operations. The changes > for this CR address this last issue. > > Many thanks to Mikael Gerdin for his initial diagnosis of the issue. > > Testing: > The failing test cases (with the changes for 7147724 removed and > instrumentation in the HandleMark class); GC test suite with > +ExplicitGCInvokesConcurrent; jprt > > Thanks, > > JohnC From bengt.rutisson at oracle.com Tue May 15 04:03:52 2012 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Tue, 15 May 2012 04:03:52 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7161545: G1: Minor cleanups to the G1 logging Message-ID: <20120515040356.B6C1047305@hg.openjdk.java.net> Changeset: 3a22b77e755a Author: brutisso Date: 2012-05-14 17:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3a22b77e755a 7161545: G1: Minor cleanups to the G1 logging Summary: Rename "to-space-overflow" to "to-space-exhausted", Introduce one decimal point in the size format, Add Sum to the aggregate and re-order the entries, Add number of GC workers to the log output Reviewed-by: johnc, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/utilities/globalDefinitions.hpp From john.cuthbertson at oracle.com Tue May 15 06:04:40 2012 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Tue, 15 May 2012 06:04:40 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 2 new changesets Message-ID: <20120515060447.86D5847309@hg.openjdk.java.net> Changeset: 78a1b285cda8 Author: mikael Date: 2012-05-15 00:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/78a1b285cda8 7158457: division by zero in adaptiveweightedaverage Summary: Add ceiling to AdaptiveWeightedAverage Reviewed-by: ysr, iveresov ! src/share/vm/gc_implementation/shared/gcUtil.cpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp Changeset: 33e366609904 Author: johnc Date: 2012-05-14 21:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/33e366609904 Merge From bengt.rutisson at oracle.com Tue May 15 06:14:56 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 15 May 2012 08:14:56 +0200 Subject: RFR (XXS): 7158682: G1: Handle leak when running nsk.sysdict tests In-Reply-To: <4FB15B92.5030500@oracle.com> References: <4F983D88.7050708@oracle.com> <4FB15B92.5030500@oracle.com> Message-ID: <4FB1F460.9050301@oracle.com> John, Looks good! Thanks for doing this change. It should solve the memory leak for CMS as well. Bengt On 2012-05-14 21:22, John Cuthbertson wrote: > Hi Everyone, > > I have a new webrev based upon a suggestion from Bengt and Mikael > Gerdin which can be found here: > http://cr.openjdk.java.net/~johnc/7158682/webrev.1/ > > Testing: > * GC test suite with G1 and CM (both with and without biased locking > enabled). > > JohnC > > On 04/25/12 11:08, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers to review this fairly small change? >> The webrev can be found at: >> http://cr.openjdk.java.net/~johnc/7158682/webrev/ >> >> Summary: >> This issue was mainly caused by the excessively high number of GC >> retry attempts seen (and fixed) in 7147724. Each time we retry the GC >> we allocate a handle to hold the pending list lock and there is no >> HandleMark around the code that retries the GC. As a result of the >> combination of these two factors, we ran out of C heap and couldn't >> allocate a new HandleArea. The fixes for 7147724 address the >> excessive retry attempts - but we can still retry the GC if the >> prologue operations are not successful and we still don't free the >> handles allocated in the prologues of the attempted GC operations. >> The changes for this CR address this last issue. >> >> Many thanks to Mikael Gerdin for his initial diagnosis of the issue. >> >> Testing: >> The failing test cases (with the changes for 7147724 removed and >> instrumentation in the HandleMark class); GC test suite with >> +ExplicitGCInvokesConcurrent; jprt >> >> Thanks, >> >> JohnC > From bengt.rutisson at oracle.com Tue May 15 07:51:34 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 15 May 2012 09:51:34 +0200 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: <4FB1563A.4070708@oracle.com> References: <4FA7C0B4.40905@oracle.com> <4FA83A28.1040504@oracle.com> <4FA92B1F.6000804@oracle.com> <4FACF848.5030805@oracle.com> <4FAD499C.5070108@oracle.com> <4FB0B85F.9060400@oracle.com> <4FB1563A.4070708@oracle.com> Message-ID: <4FB20B06.4070304@oracle.com> Hi John, Thanks for looking at this! On 2012-05-14 21:00, John Cuthbertson wrote: > Hi Bengt, > > Overall this looks good to me, but I do have a couple of minor > comments and questions.... > > arguments.cpp - Typo @ line 3096 Fixed. > > gcCause.hpp - fields in the new class should have a leading underscore. Of course! I keep missing that when I create new classes. Thanks for finding it! Fixed. > g1CollectedHeap.cpp - @ line 3600. IMO using a local to hold the GC > string and pass that into the TraceTime constructor would improve the > readability significantly. Fixed. > > g1CollectorPolicy.cpp - @ line 888. If you have a log level == finer, > where is the print of the date/timestamp prefix now? Good catch! I clearly removed one line too much. Added it back. Here is an updated webrev: http://cr.openjdk.java.net/~brutisso/7166894/webrev.06/ Thanks again for looking at this! Bengt > > Other than that, it looks good? > > JohnC > > On 05/14/12 00:46, Bengt Rutisson wrote: >> >> Hi again, :-) >> >> Here is an updated webrev where PrintGCCause is off by default in >> JDK7 but on by default in JDK8: >> http://cr.openjdk.java.net/~brutisso/7166894/webrev.05/ >> >> The relevant change is in arguments.cpp: >> http://cr.openjdk.java.net/~brutisso/7166894/webrev.05/src/share/vm/runtime/arguments.cpp.udiff.html >> >> With this proposal there is still one slight change in JDK7 logging. >> For full GCs that were triggered by System.gc() calls we used to log >> the cause. Now this will not happen unless you add -XX:+PrintGCCause. >> This will not break any parsers, but it might make some parsers miss >> System.gc() calls. >> >> I think we are getting closer to wrapping this change up. It is a >> little unclear to me who would like to be listed as reviewers. Could >> those that would like to be reviewers please take a look at the >> latest webrev and let me know. >> >> Thanks, >> Bengt >> >> >> On 2012-05-11 19:51, Srinivas Ramakrishna wrote: >>> Mikael, thanks for sounding that note of caution... what you say >>> makes sense. >>> >>> -- ramki >>> >>> On Fri, May 11, 2012 at 10:17 AM, Mikael Vidstedt >>> > wrote: >>> >>> >>> I'm all for improving the information in the log messages, great >>> work! However, I'm not sure I'm warm and fuzzy about potentially >>> breaking users' log parsers in a minor update. My preference >>> would be to have the PrintGCCause flag be default false in jdk7 >>> and default true in jdk8+. In general I'd prefer to only change >>> the log messages in major releases. >>> >>> Reasonable? >>> >>> Cheers, >>> Mikael >>> >>> >>> On 2012-05-11 07:30, Bengt Rutisson wrote: >>>> >>>> Hi Kris, >>>> >>>> Thanks again for looking at this. >>>> >>>> I had to make some minor changes make it compile on all >>>> platforms. Mostly some explicit casts to const char*. Here is >>>> an updated webrev: >>>> http://cr.openjdk.java.net/~brutisso/7166894/webrev.04/ >>>> >>>> >>>> More comments inline. >>>> >>>> On 2012-05-08 16:43, Krystal Mok wrote: >>>>> Hi Bengt, >>>>> >>>>> The current factoring looks nice and uniform. Thanks :-) >>>>> >>>>> But for most minor GCs and both CMS pause phases, the extra >>>>> logging doesn't really give additional information. >>>>> Most minor GCs are going to say "Allocation Failure", and the >>>>> two CMS phases would change from, e.g. >>>>> >>>>> [GC [1 CMS-initial-mark >>>>> >>>>> to something like >>>>> >>>>> [GC (CMS Initial Mark) [1 CMS-initial-mark >>>>> >>>>> which is probably reasonable given the scope of the change, >>>>> but not really helpful. >>>>> The "real cause", such as which generation (or perhaps >>>>> System.gc() with ExplicitGCInvokesConcurrent, or even GC >>>>> locker) is triggering this collection cycle, may be more >>>>> useful, but it's hard to fit into the current form. >>>> >>>> Yes, I think you are correct in both cases. The gc cause that >>>> we have available does not always add a lot of information. >>>> This is relevant to fix but it is a slightly different issue >>>> than what this patch sets out to fix. Let's try to get this in >>>> first and then evaluate how the GC causes should be set. >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> >>>>> - Kris >>>>> >>>>> On Tue, May 8, 2012 at 10:18 PM, Bengt Rutisson >>>>> > >>>>> wrote: >>>>> >>>>> >>>>> Hi again everyone, >>>>> >>>>> It seems like the feedback on hotspot-gc-use is that we >>>>> should add the GC cause to all collectors but also provide >>>>> a switch to turn this logging off. >>>>> >>>>> Here is an updated webrev: >>>>> http://cr.openjdk.java.net/~brutisso/7166894/webrev.03/ >>>>> >>>>> >>>>> Changes: >>>>> * GC cause logged for all collectors >>>>> * Added the flag -XX:-PrintGCCause to turn the new >>>>> information off >>>>> * Refactored the string concatenation code into a helper class >>>>> >>>>> I guess I will also have to update the CR to now reflect >>>>> the fact that this does not just concern full GCs anymore. >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Tue May 15 19:41:02 2012 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Tue, 15 May 2012 19:41:02 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7168294: G1: Some Full GCs incorrectly report GC cause as "No GC" Message-ID: <20120515194111.2FD3D47327@hg.openjdk.java.net> Changeset: 1096fc5a52eb Author: johnc Date: 2012-05-15 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1096fc5a52eb 7168294: G1: Some Full GCs incorrectly report GC cause as "No GC" Summary: GC cause was not being set by the VM_G1CollectForAllocation VM operation. Reviewed-by: jmasa, ysr, brutisso ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp From john.cuthbertson at oracle.com Wed May 16 00:14:48 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 15 May 2012 17:14:48 -0700 Subject: Request for review (S): 7166894 Add gc cause to Full GC logging for all collectors In-Reply-To: <4FB20B06.4070304@oracle.com> References: <4FA7C0B4.40905@oracle.com> <4FA83A28.1040504@oracle.com> <4FA92B1F.6000804@oracle.com> <4FACF848.5030805@oracle.com> <4FAD499C.5070108@oracle.com> <4FB0B85F.9060400@oracle.com> <4FB1563A.4070708@oracle.com> <4FB20B06.4070304@oracle.com> Message-ID: <4FB2F178.7040403@oracle.com> Hi Bengt, Looks good to me. Ship it. JohnC On 05/15/12 00:51, Bengt Rutisson wrote: > > Hi John, > > Thanks for looking at this! > > On 2012-05-14 21:00, John Cuthbertson wrote: >> Hi Bengt, >> >> Overall this looks good to me, but I do have a couple of minor >> comments and questions.... >> >> arguments.cpp - Typo @ line 3096 > > Fixed. > >> >> gcCause.hpp - fields in the new class should have a leading underscore. > > Of course! I keep missing that when I create new classes. Thanks for > finding it! Fixed. > >> g1CollectedHeap.cpp - @ line 3600. IMO using a local to hold the GC >> string and pass that into the TraceTime constructor would improve the >> readability significantly. > > Fixed. > >> >> g1CollectorPolicy.cpp - @ line 888. If you have a log level == finer, >> where is the print of the date/timestamp prefix now? > > Good catch! I clearly removed one line too much. Added it back. > > Here is an updated webrev: > http://cr.openjdk.java.net/~brutisso/7166894/webrev.06/ > > Thanks again for looking at this! > Bengt > > > >> >> Other than that, it looks good? >> >> JohnC >> >> On 05/14/12 00:46, Bengt Rutisson wrote: >>> >>> Hi again, :-) >>> >>> Here is an updated webrev where PrintGCCause is off by default in >>> JDK7 but on by default in JDK8: >>> http://cr.openjdk.java.net/~brutisso/7166894/webrev.05/ >>> >>> The relevant change is in arguments.cpp: >>> http://cr.openjdk.java.net/~brutisso/7166894/webrev.05/src/share/vm/runtime/arguments.cpp.udiff.html >>> >>> With this proposal there is still one slight change in JDK7 logging. >>> For full GCs that were triggered by System.gc() calls we used to log >>> the cause. Now this will not happen unless you add >>> -XX:+PrintGCCause. This will not break any parsers, but it might >>> make some parsers miss System.gc() calls. >>> >>> I think we are getting closer to wrapping this change up. It is a >>> little unclear to me who would like to be listed as reviewers. Could >>> those that would like to be reviewers please take a look at the >>> latest webrev and let me know. >>> >>> Thanks, >>> Bengt >>> >>> >>> On 2012-05-11 19:51, Srinivas Ramakrishna wrote: >>>> Mikael, thanks for sounding that note of caution... what you say >>>> makes sense. >>>> >>>> -- ramki >>>> >>>> On Fri, May 11, 2012 at 10:17 AM, Mikael Vidstedt >>>> > wrote: >>>> >>>> >>>> I'm all for improving the information in the log messages, >>>> great work! However, I'm not sure I'm warm and fuzzy about >>>> potentially breaking users' log parsers in a minor update. My >>>> preference would be to have the PrintGCCause flag be default >>>> false in jdk7 and default true in jdk8+. In general I'd prefer >>>> to only change the log messages in major releases. >>>> >>>> Reasonable? >>>> >>>> Cheers, >>>> Mikael >>>> >>>> >>>> On 2012-05-11 07:30, Bengt Rutisson wrote: >>>>> >>>>> Hi Kris, >>>>> >>>>> Thanks again for looking at this. >>>>> >>>>> I had to make some minor changes make it compile on all >>>>> platforms. Mostly some explicit casts to const char*. Here is >>>>> an updated webrev: >>>>> http://cr.openjdk.java.net/~brutisso/7166894/webrev.04/ >>>>> >>>>> >>>>> More comments inline. >>>>> >>>>> On 2012-05-08 16:43, Krystal Mok wrote: >>>>>> Hi Bengt, >>>>>> >>>>>> The current factoring looks nice and uniform. Thanks :-) >>>>>> >>>>>> But for most minor GCs and both CMS pause phases, the extra >>>>>> logging doesn't really give additional information. >>>>>> Most minor GCs are going to say "Allocation Failure", and the >>>>>> two CMS phases would change from, e.g. >>>>>> >>>>>> [GC [1 CMS-initial-mark >>>>>> >>>>>> to something like >>>>>> >>>>>> [GC (CMS Initial Mark) [1 CMS-initial-mark >>>>>> >>>>>> which is probably reasonable given the scope of the change, >>>>>> but not really helpful. >>>>>> The "real cause", such as which generation (or perhaps >>>>>> System.gc() with ExplicitGCInvokesConcurrent, or even GC >>>>>> locker) is triggering this collection cycle, may be more >>>>>> useful, but it's hard to fit into the current form. >>>>> >>>>> Yes, I think you are correct in both cases. The gc cause that >>>>> we have available does not always add a lot of information. >>>>> This is relevant to fix but it is a slightly different issue >>>>> than what this patch sets out to fix. Let's try to get this in >>>>> first and then evaluate how the GC causes should be set. >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>>> >>>>>> - Kris >>>>>> >>>>>> On Tue, May 8, 2012 at 10:18 PM, Bengt Rutisson >>>>>> >>>>> > wrote: >>>>>> >>>>>> >>>>>> Hi again everyone, >>>>>> >>>>>> It seems like the feedback on hotspot-gc-use is that we >>>>>> should add the GC cause to all collectors but also >>>>>> provide a switch to turn this logging off. >>>>>> >>>>>> Here is an updated webrev: >>>>>> http://cr.openjdk.java.net/~brutisso/7166894/webrev.03/ >>>>>> >>>>>> >>>>>> Changes: >>>>>> * GC cause logged for all collectors >>>>>> * Added the flag -XX:-PrintGCCause to turn the new >>>>>> information off >>>>>> * Refactored the string concatenation code into a helper >>>>>> class >>>>>> >>>>>> I guess I will also have to update the CR to now reflect >>>>>> the fact that this does not just concern full GCs anymore. >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Wed May 16 07:38:27 2012 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Wed, 16 May 2012 07:38:27 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7169056: Add gigabyte unit to proper_unit_for_byte_size() and byte_size_in_proper_unit() Message-ID: <20120516073829.BCEDA47344@hg.openjdk.java.net> Changeset: cdfa5139bd58 Author: brutisso Date: 2012-05-15 22:26 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cdfa5139bd58 7169056: Add gigabyte unit to proper_unit_for_byte_size() and byte_size_in_proper_unit() Reviewed-by: jwilhelm, johnc, dholmes ! src/share/vm/utilities/globalDefinitions.hpp From bengt.rutisson at oracle.com Wed May 16 09:48:59 2012 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Wed, 16 May 2012 09:48:59 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7166894: Add gc cause to GC logging for all collectors Message-ID: <20120516094910.0893147347@hg.openjdk.java.net> Changeset: 9d679effd28c Author: brutisso Date: 2012-05-15 10:25 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9d679effd28c 7166894: Add gc cause to GC logging for all collectors Reviewed-by: mgerdin, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.hpp From bengt.rutisson at oracle.com Thu May 17 20:25:39 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 17 May 2012 22:25:39 +0200 Subject: Request for review (S): 7169062 CMS: Assertion failed with -XX:+ObjectAlignmentInBytes=64 Message-ID: <4FB55EC3.4040805@oracle.com> Hi all, Can I have a couple of reviews for this change? http://cr.openjdk.java.net/~brutisso/7169062/webrev.00/ Background In CompactibleFreeListSpace::check_free_list_consistency() there were some asserts to verify that the instance variables IndexSetStart, IndexSetStart and IndexSetSize were set up correctly. These asserts were too strong and did not handle different object alignments. The asserts are also not necessary to do everytime we call check_free_list_consistency(). It makes more sense to only check it when we updated the values in CompactibleFreeListSpace::set_cms_values(). I replaced the asserts in check_free_list_consistency() with two asserts to verify that have set the values up at all. Instead I intended to add some asserts to set_cms_values(), but after simplifying (at least in my mind) the calculations there I don't think any asserts are needed. Thanks Stefan for helping out with the setup code. Testing Ran 64 bit VM with an assert comparing the old calculation of MinChunkSize with the new one. Tried all values of ObjectAlignmentInBytes (8, 16, 32, 64, 128 and 256). Also ran the 32 bit VM with the assert that compared old and new value in place. Ran JPRT (the Stockholm queue :-) ). Coding Style The instance variables IndexSetStride and IndexSetStart should probably be _index_set_stride and _index_set_start. I'll try to keep my change small, so I would like to avoid changing naming style etc right now. From John.Coomes at oracle.com Thu May 17 23:07:00 2012 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 17 May 2012 16:07:00 -0700 Subject: Request for review (S): 7169062 CMS: Assertion failed with -XX:+ObjectAlignmentInBytes=64 In-Reply-To: <4FB55EC3.4040805@oracle.com> References: <4FB55EC3.4040805@oracle.com> Message-ID: <20405.33940.555799.703384@oracle.com> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: > > Hi all, > > Can I have a couple of reviews for this change? > http://cr.openjdk.java.net/~brutisso/7169062/webrev.00/ > ... Looks good to me. -John From john.coomes at oracle.com Fri May 18 03:53:49 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 May 2012 03:53:49 +0000 Subject: hg: hsx/hotspot-gc: 4 new changesets Message-ID: <20120518035349.788B8473C1@hg.openjdk.java.net> Changeset: 955a3e8ed4f0 Author: ohair Date: 2012-05-10 08:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/955a3e8ed4f0 7167593: Changed get_source.sh to allow for getting full oracle jdk repo forest Reviewed-by: erikj, asaha, chegar, sla, dholmes, mbykov, coleenp ! get_source.sh ! make/scripts/hgforest.sh Changeset: 8a4e92c10a9a Author: ohair Date: 2012-05-11 17:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/8a4e92c10a9a 7167976: Fix broken get_source.sh script Reviewed-by: tbell ! make/scripts/hgforest.sh Changeset: 8927dd68aee3 Author: katleman Date: 2012-05-16 22:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/8927dd68aee3 Merge Changeset: a2b2d435f1d2 Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/a2b2d435f1d2 Added tag jdk8-b39 for changeset 8927dd68aee3 ! .hgtags From john.coomes at oracle.com Fri May 18 03:53:54 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 May 2012 03:53:54 +0000 Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b39 for changeset 785af00e2827 Message-ID: <20120518035356.4AD30473C2@hg.openjdk.java.net> Changeset: 56d030e5035f Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/56d030e5035f Added tag jdk8-b39 for changeset 785af00e2827 ! .hgtags From john.coomes at oracle.com Fri May 18 03:54:01 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 May 2012 03:54:01 +0000 Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b39 for changeset f95fdbe525c8 Message-ID: <20120518035408.54EE4473C3@hg.openjdk.java.net> Changeset: 9ecfdbd6aed4 Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/9ecfdbd6aed4 Added tag jdk8-b39 for changeset f95fdbe525c8 ! .hgtags From john.coomes at oracle.com Fri May 18 03:54:14 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 May 2012 03:54:14 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b39 for changeset 7f6b44fd3034 Message-ID: <20120518035419.0BCE3473C4@hg.openjdk.java.net> Changeset: 09a0ddda03cb Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/09a0ddda03cb Added tag jdk8-b39 for changeset 7f6b44fd3034 ! .hgtags From john.coomes at oracle.com Fri May 18 03:54:28 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 May 2012 03:54:28 +0000 Subject: hg: hsx/hotspot-gc/jdk: 4 new changesets Message-ID: <20120518035539.36C59473C5@hg.openjdk.java.net> Changeset: c2d9166f3284 Author: ihse Date: 2012-05-11 08:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c2d9166f3284 7168208: Change use of @ in one sed command involving paths to different character Reviewed-by: ohair ! make/common/Release.gmk Changeset: 8d665b69ebf1 Author: mfang Date: 2012-05-15 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8d665b69ebf1 7157855: jvisualvm.1 not included in binaries Reviewed-by: katleman, thurka ! make/common/Release.gmk Changeset: b6f529117521 Author: katleman Date: 2012-05-16 22:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b6f529117521 Merge Changeset: 47cd90bf0f66 Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/47cd90bf0f66 Added tag jdk8-b39 for changeset b6f529117521 ! .hgtags From john.coomes at oracle.com Fri May 18 03:57:03 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 May 2012 03:57:03 +0000 Subject: hg: hsx/hotspot-gc/langtools: Added tag jdk8-b39 for changeset a9f547c218d9 Message-ID: <20120518035710.46290473C6@hg.openjdk.java.net> Changeset: 8b869afd2eb4 Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/8b869afd2eb4 Added tag jdk8-b39 for changeset a9f547c218d9 ! .hgtags From bengt.rutisson at oracle.com Fri May 18 08:24:02 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 18 May 2012 10:24:02 +0200 Subject: Request for review (S): 7169062 CMS: Assertion failed with -XX:+ObjectAlignmentInBytes=64 In-Reply-To: <20405.33940.555799.703384@oracle.com> References: <4FB55EC3.4040805@oracle.com> <20405.33940.555799.703384@oracle.com> Message-ID: <4FB60722.1010400@oracle.com> John, Thanks for the review! Stefan also looked at this, so I'm all set to push. Thanks! Bentg On 2012-05-18 01:07, John Coomes wrote: > Bengt Rutisson (bengt.rutisson at oracle.com) wrote: >> Hi all, >> >> Can I have a couple of reviews for this change? >> http://cr.openjdk.java.net/~brutisso/7169062/webrev.00/ >> ... > Looks good to me. > > -John From alejandro.murillo at oracle.com Sat May 19 07:30:42 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 19 May 2012 07:30:42 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 9 new changesets Message-ID: <20120519073100.D867C47406@hg.openjdk.java.net> Changeset: 26423ef693ac Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/26423ef693ac Added tag jdk8-b39 for changeset 96a403721094 ! .hgtags Changeset: 35e504cb49a6 Author: collins Date: 2012-05-11 11:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/35e504cb49a6 7167625: Adjustments for SE-Embedded build process Summary: Simple change to the SE-Embedded build rules that should not affect any other OpenJDK users. Reviewed-by: kvn, dholmes ! make/linux/makefiles/vm.make ! src/share/vm/runtime/arguments.cpp Changeset: fada85d11d92 Author: jprovino Date: 2012-05-16 13:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fada85d11d92 Merge Changeset: 8f972594effc Author: kvn Date: 2012-05-14 09:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8f972594effc 6924259: Remove String.count/String.offset Summary: Allow a version of String class that doesn't have count and offset fields. Reviewed-by: never, coleenp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/stringopts.hpp Changeset: de0cc3dd9f10 Author: kvn Date: 2012-05-17 09:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/de0cc3dd9f10 Merge Changeset: cdeda3fd141e Author: jcoomes Date: 2012-05-18 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cdeda3fd141e Merge ! src/share/vm/runtime/arguments.cpp Changeset: 14b0e07ab9a6 Author: amurillo Date: 2012-05-18 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/14b0e07ab9a6 Merge Changeset: ff9decc8235d Author: amurillo Date: 2012-05-18 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ff9decc8235d Added tag hs24-b11 for changeset 14b0e07ab9a6 ! .hgtags Changeset: 03d61caacd1e Author: amurillo Date: 2012-05-18 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/03d61caacd1e 7170006: new hotspot build - hs24-b12 Reviewed-by: jcoomes ! make/hotspot_version From bengt.rutisson at oracle.com Mon May 21 05:18:40 2012 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Mon, 21 May 2012 05:18:40 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7169062: CMS: Assertion failed with -XX:+ObjectAlignmentInBytes=64 Message-ID: <20120521051844.35E2C47421@hg.openjdk.java.net> Changeset: c92a79900986 Author: brutisso Date: 2012-05-17 21:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c92a79900986 7169062: CMS: Assertion failed with -XX:+ObjectAlignmentInBytes=64 Summary: Removed the assert in CompactibleFreeListSpace::check_free_list_consistency() since it was too strict. Simplified CompactibleFreeListSpace::set_cms_values() to reducde the need for asserts. Reviewed-by: jcoomes, stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp From bengt.rutisson at oracle.com Mon May 21 16:04:11 2012 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Mon, 21 May 2012 16:04:11 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7168848: Add test to check that humongous object allocation path also checks the heap occupancy. Message-ID: <20120521160417.83DD047441@hg.openjdk.java.net> Changeset: 9a344d88dc22 Author: mnunez Date: 2012-05-21 14:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9a344d88dc22 7168848: Add test to check that humongous object allocation path also checks the heap occupancy. Summary: Added test that checks humongous object allocation path also check the heap occupancy and initiate a marking cycle when / if needed. Reviewed-by: brutisso, jwilhelm + test/gc/7168848/HumongousAlloc.java From john.cuthbertson at oracle.com Mon May 21 23:12:36 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 21 May 2012 16:12:36 -0700 Subject: RFR(XS): 7143858: G1: Back to back young GCs with the second GC having a minimally sized eden Message-ID: <4FBACBE4.3060907@oracle.com> Hi Everyone, Can I have a couple of volunteers review the fix for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7143858/webrev.0/ Description: In some recent G1 logs we have seen some evacuation pauses that looked premature, i.e. the eden occupancy was much less than the target capacity - usually only one or two regions. These premature pauses always (almost immediately) followed a normal evacuation pause with little or no application activity in-between. Bengt's recent changes to display the GC cause indicated that the premature pauses were always GCLocker Initiated GCs. What seemed to have been happening was that as the last left a JNI critical region, before it scheduled the GCLocker Initiated GC, another thread would attempt an allocation. The allocating thread would see that GCLocker was no longer active and successfully schedule the evacuation pause. As part of this GC operation, a mutator alloc region would get allocated and the object allocation request would be satisfied. After, the thread initating the GCLocker GC would schedule its GC and the eden occupancy would be fairly minimal. Inserting a 500ms sleep just before scheduling the GCLocker initated GC was able to reproduce the problem with Dacapo fairly frequently. The solution implemented in this webrev is to stall the allocating thread until the GCLocker Initiated GC is performed and then retry the allocation. Testing: GC Test Suite and Kitchensink with the additional sleep call and verify that no pauses occurred during the sleep, GC Test suite and jprt with the additional sleep. I have been unable to reproduce the issue with the other Hotspot collectors but I can't see why they wouldn't be vulnerable. I changed the G1 slow case allocation code to match the other collectors and still saw the issue. Thanks, JohnC From bengt.rutisson at oracle.com Wed May 23 14:28:30 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 23 May 2012 16:28:30 +0200 Subject: RFR(XS): 7143858: G1: Back to back young GCs with the second GC having a minimally sized eden In-Reply-To: <4FBACBE4.3060907@oracle.com> References: <4FBACBE4.3060907@oracle.com> Message-ID: <636767F5-7C04-4944-8613-6778D791051C@oracle.com> John, Looks good! Nice catch. Bengt 22 maj 2012 kl. 01:12 skrev John Cuthbertson : > Hi Everyone, > > Can I have a couple of volunteers review the fix for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7143858/webrev.0/ > > Description: > > In some recent G1 logs we have seen some evacuation pauses that looked premature, i.e. the eden occupancy was much less than the target capacity - usually only one or two regions. These premature pauses always (almost immediately) followed a normal evacuation pause with little or no application activity in-between. Bengt's recent changes to display the GC cause indicated that the premature pauses were always GCLocker Initiated GCs. > > What seemed to have been happening was that as the last left a JNI critical region, before it scheduled the GCLocker Initiated GC, another thread would attempt an allocation. The allocating thread would see that GCLocker was no longer active and successfully schedule the evacuation pause. As part of this GC operation, a mutator alloc region would get allocated and the object allocation request would be satisfied. After, the thread initating the GCLocker GC would schedule its GC and the eden occupancy would be fairly minimal. > > Inserting a 500ms sleep just before scheduling the GCLocker initated GC was able to reproduce the problem with Dacapo fairly frequently. > > The solution implemented in this webrev is to stall the allocating thread until the GCLocker Initiated GC is performed and then retry the allocation. > > Testing: GC Test Suite and Kitchensink with the additional sleep call and verify that no pauses occurred during the sleep, GC Test suite and jprt with the additional sleep. > > I have been unable to reproduce the issue with the other Hotspot collectors but I can't see why they wouldn't be vulnerable. I changed the G1 slow case allocation code to match the other collectors and still saw the issue. > > Thanks, > > JohnC > > > From charlesjhunt at gmail.com Wed May 23 17:17:27 2012 From: charlesjhunt at gmail.com (Charlie Hunt) Date: Wed, 23 May 2012 12:17:27 -0500 Subject: RFR(XS): 7143858: G1: Back to back young GCs with the second GC having a minimally sized eden In-Reply-To: <4FBACBE4.3060907@oracle.com> References: <4FBACBE4.3060907@oracle.com> Message-ID: Looks great John! I knew you'd get this (annoying behavior) figured out. charlie ... On May 21, 2012, at 6:12 PM, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers review the fix for this CR? The webrev > can be found at: http://cr.openjdk.java.net/~johnc/7143858/webrev.0/ > > Description: > > In some recent G1 logs we have seen some evacuation pauses that looked > premature, i.e. the eden occupancy was much less than the target > capacity - usually only one or two regions. These premature pauses > always (almost immediately) followed a normal evacuation pause with > little or no application activity in-between. Bengt's recent changes to > display the GC cause indicated that the premature pauses were always > GCLocker Initiated GCs. > > What seemed to have been happening was that as the last left a JNI > critical region, before it scheduled the GCLocker Initiated GC, another > thread would attempt an allocation. The allocating thread would see that > GCLocker was no longer active and successfully schedule the evacuation > pause. As part of this GC operation, a mutator alloc region would get > allocated and the object allocation request would be satisfied. After, > the thread initating the GCLocker GC would schedule its GC and the eden > occupancy would be fairly minimal. > > Inserting a 500ms sleep just before scheduling the GCLocker initated GC > was able to reproduce the problem with Dacapo fairly frequently. > > The solution implemented in this webrev is to stall the allocating > thread until the GCLocker Initiated GC is performed and then retry the > allocation. > > Testing: GC Test Suite and Kitchensink with the additional sleep call > and verify that no pauses occurred during the sleep, GC Test suite and > jprt with the additional sleep. > > I have been unable to reproduce the issue with the other Hotspot > collectors but I can't see why they wouldn't be vulnerable. I changed > the G1 slow case allocation code to match the other collectors and still > saw the issue. > > Thanks, > > JohnC > > > From john.coomes at oracle.com Fri May 25 03:47:54 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 May 2012 03:47:54 +0000 Subject: hg: hsx/hotspot-gc: Added tag jdk8-b40 for changeset a2b2d435f1d2 Message-ID: <20120525034754.5981D474F3@hg.openjdk.java.net> Changeset: 1a8c7c530f8a Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/1a8c7c530f8a Added tag jdk8-b40 for changeset a2b2d435f1d2 ! .hgtags From john.coomes at oracle.com Fri May 25 03:48:00 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 May 2012 03:48:00 +0000 Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b40 for changeset 56d030e5035f Message-ID: <20120525034803.45E63474F4@hg.openjdk.java.net> Changeset: 113f0d5f0a08 Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/113f0d5f0a08 Added tag jdk8-b40 for changeset 56d030e5035f ! .hgtags From john.coomes at oracle.com Fri May 25 03:48:09 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 May 2012 03:48:09 +0000 Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b40 for changeset 9ecfdbd6aed4 Message-ID: <20120525034817.54182474F5@hg.openjdk.java.net> Changeset: 6f5c0e17415d Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/6f5c0e17415d Added tag jdk8-b40 for changeset 9ecfdbd6aed4 ! .hgtags From john.coomes at oracle.com Fri May 25 03:48:25 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 May 2012 03:48:25 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b40 for changeset 09a0ddda03cb Message-ID: <20120525034830.3ABE7474F6@hg.openjdk.java.net> Changeset: f2072b164b05 Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/f2072b164b05 Added tag jdk8-b40 for changeset 09a0ddda03cb ! .hgtags From john.coomes at oracle.com Fri May 25 03:49:35 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 May 2012 03:49:35 +0000 Subject: hg: hsx/hotspot-gc/jdk: 71 new changesets Message-ID: <20120525040335.AA489474FE@hg.openjdk.java.net> Changeset: 7c4eed4b6c19 Author: bae Date: 2012-05-21 14:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7c4eed4b6c19 7124400: [macosx] CGraphicsDevice.getConfigurations() returns reference to member (does not copy configs) Reviewed-by: anthony, kizune ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! test/java/awt/GraphicsDevice/CloneConfigsTest.java Changeset: 416b3a498e71 Author: bae Date: 2012-05-21 14:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/416b3a498e71 7154088: [macosx] Regression: Component.createImage do not inherits component attributes Reviewed-by: art, kizune ! src/macosx/classes/sun/lwawt/LWComponentPeer.java Changeset: 1b90a0113359 Author: lana Date: 2012-05-21 11:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1b90a0113359 Merge Changeset: c31eeeda3ed1 Author: serb Date: 2012-05-03 18:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c31eeeda3ed1 7160623: [macosx] Editable TextArea/TextField are blocking GUI applications from exit Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java Changeset: a420895ee2c3 Author: leonidr Date: 2012-05-03 19:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a420895ee2c3 7124376: [macosx] Modal dialog lost focus Reviewed-by: anthony ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 95c8b63a3c47 Author: kizune Date: 2012-05-03 21:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/95c8b63a3c47 7148289: [macosx] Deadlock in sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame Reviewed-by: leonidr ! src/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/LWCToolkit.m Changeset: a714e2e2b257 Author: alexsch Date: 2012-05-04 13:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a714e2e2b257 7024963: Notepad demo: remove non-translatable resources from Notepad.properties file Reviewed-by: rupashka ! src/share/demo/jfc/Notepad/Notepad.java ! src/share/demo/jfc/Notepad/resources/Notepad.properties + src/share/demo/jfc/Notepad/resources/system.properties Changeset: 4cc873e28c78 Author: bagiras Date: 2012-05-04 18:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4cc873e28c78 7146237: closed/java/awt/Focus/SetFocusTraversalKeysTest/SetFocusTraversalTest.html failed since 1.8.0b19 Reviewed-by: art, anthony ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/javax/swing/JComponent.java Changeset: 0feee4541f67 Author: serb Date: 2012-05-04 21:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0feee4541f67 7147055: [macosx] Cursors are changing over a blocked window; also blinking Reviewed-by: art, kizune ! src/macosx/classes/sun/lwawt/LWCursorManager.java Changeset: 912e666b4e1d Author: serb Date: 2012-05-10 20:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/912e666b4e1d 7080109: Dialog.show() lacks doPrivileged() to access system event queue Reviewed-by: art, anthony ! src/share/classes/java/awt/Dialog.java + test/java/awt/Dialog/ModalDialogPermission/ModalDialogPermission.java + test/java/awt/Dialog/ModalDialogPermission/java.policy Changeset: 18842bb6676a Author: lana Date: 2012-05-10 11:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/18842bb6676a Merge - src/macosx/bin/amd64/jvm.cfg - src/share/classes/sun/security/action/LoadLibraryAction.java - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: 4f39a13e74c6 Author: anthony Date: 2012-05-11 16:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4f39a13e74c6 7166437: [macosx] Support for Window.Type.UTILITY on the Mac Summary: Apply the native UTILITY style for UTILITY Java windows Reviewed-by: art ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: 689c0cd214e8 Author: anthony Date: 2012-05-11 20:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/689c0cd214e8 7149062: [macosx] dock menu don't show available frames Summary: Inherit from either NSWindow for normal windows or NSPanel for utility windows Reviewed-by: skovatch, swingler ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 3b8635e357e9 Author: alexsch Date: 2012-05-12 12:01 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3b8635e357e9 7024965: Stylepad demo: remove non-translatable resources from Stylepad.properties file Reviewed-by: alexp ! src/share/demo/jfc/Notepad/Notepad.java + src/share/demo/jfc/Notepad/resources/NotepadSystem.properties - src/share/demo/jfc/Notepad/resources/system.properties Changeset: cc8d1cc533bf Author: alexp Date: 2012-05-12 17:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cc8d1cc533bf 7149005: [macosx] Java Control Panel's UI controls are distorted when draging scroll bar. Reviewed-by: serb ! src/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java Changeset: 69301efaac91 Author: ant Date: 2012-05-12 18:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/69301efaac91 7110683: Issues with some KeyboardFocusManager method Reviewed-by: ahgross ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/Window.java Changeset: 28ec5b811aa2 Author: dcherepanov Date: 2012-05-15 15:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/28ec5b811aa2 7168550: [macosx] duplicate OGL context state changes related to vertex cache Reviewed-by: bae, swingler ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m ! src/share/native/sun/java2d/opengl/OGLContext.h ! src/share/native/sun/java2d/opengl/OGLTextRenderer.c ! src/share/native/sun/java2d/opengl/OGLVertexCache.c ! src/share/native/sun/java2d/opengl/OGLVertexCache.h Changeset: cad0bb1a9bdb Author: dcherepanov Date: 2012-05-16 13:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cad0bb1a9bdb 7124337: [macosx] FileDialog fails to select multiple files Reviewed-by: anthony, swingler ! src/macosx/classes/sun/lwawt/macosx/CFileDialog.java ! src/macosx/native/sun/awt/CFileDialog.h ! src/macosx/native/sun/awt/CFileDialog.m ! src/share/classes/java/awt/FileDialog.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java Changeset: 7c0b390ab5f9 Author: anthony Date: 2012-05-16 14:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7c0b390ab5f9 7168851: [macosx] Netbeans crashes in CImage.nativeCreateNSImageFromArray Summary: Eliminate unnecessary -release call Reviewed-by: dcherepanov ! src/macosx/native/sun/awt/CImage.m Changeset: 3c819d638e36 Author: alexsch Date: 2012-05-16 16:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3c819d638e36 7169226: NLS: Please change the mnemonic assignment system for windows and motif properties Reviewed-by: rupashka ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_es.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_fr.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ja.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_sv.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_de.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_es.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_fr.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_it.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ja.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_sv.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties Changeset: 19edcc438203 Author: alexsch Date: 2012-05-16 18:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/19edcc438203 7158928: [macosx] NLS: Please change the mnemonic assignment system Reviewed-by: rupashka, serb ! make/com/apple/osxui/Makefile ! make/common/internal/Resources.gmk ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/com/apple/laf/resources/aqua.properties Changeset: 731ee59c6ba2 Author: alexsch Date: 2012-05-17 14:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/731ee59c6ba2 7148281: [macosx] JTabbedPane tabs with HTML text do not render correctly Reviewed-by: kizune ! src/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java Changeset: f9217bd87199 Author: rupashka Date: 2012-05-17 15:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f9217bd87199 7166322: closed/javax/swing/text/html/HTMLEditorKit/4242228/bug4242228.java failed since 1.8.0b36 Reviewed-by: alexsch + test/javax/swing/text/html/HTMLEditorKit/4242228/bug4242228.java Changeset: c00d6508afce Author: ant Date: 2012-05-17 21:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c00d6508afce 7142565: [macosx] Many special keys processed twice in text fields Summary: forward port from 7u4 Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTView.m Changeset: 17c5e1a12965 Author: ant Date: 2012-05-17 21:31 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/17c5e1a12965 7154072: [macosx] swallowing key events Summary: forward posrt from 7u4 Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTView.m Changeset: ef77fa799b34 Author: ant Date: 2012-05-17 21:48 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ef77fa799b34 7125044: [macosx] Test failure because Component.transferFocus() works differently in applet and application. Summary: forward port from 7u4 Reviewed-by: art ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/Window.java ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/sun/awt/SunToolkit.java + test/java/awt/Focus/FocusTraversalPolicy/InitialFTP.java + test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_AWT.java + test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_Swing.java + test/java/awt/event/KeyEvent/SwallowKeyEvents/SwallowKeyEvents.java Changeset: 5976b5848554 Author: ant Date: 2012-05-17 22:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5976b5848554 7145768: [macosx] Regression: failure in b11 of ModalDialogInFocusEventTest Summary: forward port from 7u4 Reviewed-by: art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java Changeset: 1d75ff45586e Author: ant Date: 2012-05-17 22:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1d75ff45586e 7145827: [macosx] JCK failure in b11: FocusableWindow3 Summary: forward posrt from 7u4 Reviewed-by: art ! src/macosx/classes/sun/lwawt/LWWindowPeer.java Changeset: 2eca75e0a063 Author: dcherepanov Date: 2012-05-18 19:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2eca75e0a063 7156191: [macosx] Can't type into applet demos in Pivot Reviewed-by: art ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: 1ee12bca4823 Author: rupashka Date: 2012-05-21 18:55 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1ee12bca4823 7168144: No appropriate CCC request for changes introduced by 7154030 Reviewed-by: alexsch ! src/share/classes/javax/swing/JComponent.java Changeset: 967b38bfd5c1 Author: ant Date: 2012-05-22 01:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/967b38bfd5c1 7170427: setGlobalCurrentFocusCycleRoot unexpectedly throws SecurityException Reviewed-by: art ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/KeyboardFocusManager.java Changeset: 5b2095d7a60b Author: lana Date: 2012-05-21 11:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5b2095d7a60b Merge ! src/macosx/classes/sun/lwawt/LWComponentPeer.java Changeset: bb2cefc89bc0 Author: forax Date: 2012-05-02 20:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bb2cefc89bc0 7165102: Only run assertion on Integer autoboxing cache size once Reviewed-by: darcy, alanb ! src/share/classes/java/lang/Integer.java Changeset: 531ebfd8eb65 Author: jgish Date: 2012-05-02 21:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/531ebfd8eb65 7160714: Strange or obsolete @see tags in some exception java.util javadoc Reviewed-by: mduigou, dholmes, alanb ! src/share/classes/java/util/NoSuchElementException.java Changeset: 4580652d9828 Author: lancea Date: 2012-05-04 16:00 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4580652d9828 7166598: FilteredRowSetImpl can result in Invalid Cursor Position Reviewed-by: lancea Contributed-by: Knut Anders Hatlen ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java Changeset: 41d3f7509e00 Author: xuelei Date: 2012-05-04 17:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/41d3f7509e00 7153184: NullPointerException when calling SSLEngineImpl.getSupportedCipherSuites Reviewed-by: weijun ! src/share/classes/sun/security/ssl/SSLContextImpl.java Changeset: 62557a1336c0 Author: zhouyx Date: 2012-05-07 16:43 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/62557a1336c0 7166048: Remove the embeded epoll data structure. Reviewed-by: alanb ! src/solaris/native/sun/nio/ch/EPollArrayWrapper.c Changeset: b26c04717735 Author: robm Date: 2012-05-07 13:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b26c04717735 7166687: InetAddress.getLocalHost().getHostName() returns FQDN Reviewed-by: chegar ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: 48513d156965 Author: dholmes Date: 2012-05-08 02:59 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/48513d156965 7103570: AtomicIntegerFieldUpdater does not work when SecurityManager is installed Summary: Perform class.getField inside a doPrivileged block Reviewed-by: chegar, psandoz ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java + test/java/util/concurrent/atomic/AtomicUpdaters.java Changeset: af209a223b6b Author: sherman Date: 2012-05-08 10:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/af209a223b6b 7014640: To add a metachar \R for line ending and character classes for vertical/horizontal ws \v \V \h \H Summary: added propsoed constructs Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java Changeset: 1ece20885be4 Author: sherman Date: 2012-05-08 11:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1ece20885be4 7157656: (zipfs) SeekableByteChannel to entry in zip file always reports its position as 0 Summary: updated SeekableByteChannel.read() to count the bytes read correctly Reviewed-by: sherman Contributed-by: paul.sandoz at oracle.com ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh Changeset: fbf98cbd2e6b Author: xuelei Date: 2012-05-08 17:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fbf98cbd2e6b 7167092: Need to put the return clause in the synchronized block Summary: a regression fix for bug 7153184 Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/SSLContextImpl.java Changeset: 0f63f3390ac9 Author: xuelei Date: 2012-05-08 18:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0f63f3390ac9 7166570: JSSE certificate validation has started to fail for certificate chains Reviewed-by: wetmore ! src/share/classes/sun/security/validator/SimpleValidator.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java Changeset: abb63b7357a1 Author: luchsh Date: 2012-05-09 11:19 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/abb63b7357a1 7165722: Invalid path in MemoryMonitor demo's README.txt Reviewed-by: alanb, sla ! src/share/demo/management/MemoryMonitor/README.txt Changeset: 5e8caf6984f5 Author: ksrini Date: 2012-05-09 07:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5e8caf6984f5 7166955: (pack200) JNI_GetCreatedJavaVMs needs additional checking Reviewed-by: alanb, dholmes, ksrini Contributed-by: youdwei at linux.vnet.ibm.com ! src/share/native/com/sun/java/util/jar/pack/jni.cpp Changeset: 59121a4c71c6 Author: khazra Date: 2012-05-09 11:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/59121a4c71c6 7165118: (prefs) AbstractPreferences.remove(null) does not throw NPE Summary: Insert null argument check in AbstractPreferences.remove() Reviewed-by: dholmes, chegar, alanb ! src/share/classes/java/util/prefs/AbstractPreferences.java ! test/java/util/prefs/RemoveNullKeyCheck.java Changeset: 6438f1277df6 Author: wetmore Date: 2012-05-09 16:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6438f1277df6 7167362: SecureRandom.init should be converted, amendment to 7084245 Reviewed-by: sherman ! src/share/classes/sun/security/provider/SecureRandom.java Changeset: 5152c832745a Author: khazra Date: 2012-05-09 16:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5152c832745a 7096436: (sc) SocketChannel.connect fails on Windows 8 when channel configured non-blocking Summary: Set localAddress only when connection is established Reviewed-by: alanb ! src/share/classes/sun/nio/ch/SocketChannelImpl.java Changeset: fdf5e15293e6 Author: coffeys Date: 2012-05-10 10:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fdf5e15293e6 7163470: Build fails if javax.crypto src files not present Reviewed-by: valeriep ! make/com/oracle/security/ucrypto/Makefile ! make/common/shared/Defs-java.gmk ! make/sun/security/ec/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! makefiles/com/oracle/security/ucrypto/Makefile ! makefiles/common/shared/Defs-java.gmk ! makefiles/sun/security/ec/Makefile ! makefiles/sun/security/mscapi/Makefile ! makefiles/sun/security/pkcs11/Makefile Changeset: 3e3017eba8ac Author: valeriep Date: 2012-05-08 17:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3e3017eba8ac 4963723: Implement SHA-224 Summary: Add support for SHA-224, SHA224withRSA, SHA224withECDSA, HmacSHA224 and OAEPwithSHA-224AndMGF1Padding. Reviewed-by: vinnie ! src/share/classes/com/sun/crypto/provider/HmacCore.java ! src/share/classes/com/sun/crypto/provider/HmacMD5.java ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1.java ! src/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java ! src/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/java/security/spec/MGF1ParameterSpec.java ! src/share/classes/java/security/spec/PSSParameterSpec.java ! src/share/classes/sun/security/ec/ECDSASignature.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/P11Mac.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/classes/sun/security/pkcs11/wrapper/Functions.java ! src/share/classes/sun/security/provider/DigestBase.java ! src/share/classes/sun/security/provider/MD2.java ! src/share/classes/sun/security/provider/MD4.java ! src/share/classes/sun/security/provider/MD5.java ! src/share/classes/sun/security/provider/SHA.java ! src/share/classes/sun/security/provider/SHA2.java ! src/share/classes/sun/security/provider/SHA5.java ! src/share/classes/sun/security/provider/SunEntries.java ! src/share/classes/sun/security/rsa/RSASignature.java ! src/share/classes/sun/security/rsa/SunRsaSignEntries.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEP.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPParameterSpec.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPWithParams.java ! test/com/sun/crypto/provider/KeyGenerator/Test4628062.java ! test/com/sun/crypto/provider/Mac/MacClone.java ! test/com/sun/crypto/provider/Mac/MacKAT.java ! test/sun/security/mscapi/SignUsingNONEwithRSA.java ! test/sun/security/mscapi/SignUsingSHA2withRSA.java ! test/sun/security/pkcs11/MessageDigest/DigestKAT.java ! test/sun/security/pkcs11/MessageDigest/TestCloning.java ! test/sun/security/pkcs11/Signature/TestRSAKeyLength.java ! test/sun/security/pkcs11/ec/TestCurves.java ! test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java ! test/sun/security/pkcs11/rsa/TestSignatures.java ! test/sun/security/provider/MessageDigest/DigestKAT.java ! test/sun/security/provider/MessageDigest/Offsets.java ! test/sun/security/provider/MessageDigest/TestSHAClone.java ! test/sun/security/rsa/TestKeyPairGenerator.java ! test/sun/security/rsa/TestSignatures.java Changeset: dfce31760a2f Author: valeriep Date: 2012-05-08 18:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/dfce31760a2f Merge Changeset: 9f8210f23773 Author: valeriep Date: 2012-05-10 11:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9f8210f23773 Merge Changeset: c5a07e3dca63 Author: youdwei Date: 2012-05-11 16:20 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c5a07e3dca63 7163874: InetAddress.isReachable should support pinging 0.0.0.0 Reviewed-by: alanb, chegar ! src/share/native/java/net/net_util.h ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/net_util_md.c + test/java/net/Inet4Address/PingThis.java Changeset: 3e83229a3779 Author: coffeys Date: 2012-05-11 10:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3e83229a3779 7167359: (tz) SEGV on solaris if TZ variable not set Reviewed-by: okutsu ! src/solaris/native/java/util/TimeZone_md.c Changeset: 944676ef3c58 Author: mduigou Date: 2012-05-11 11:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/944676ef3c58 7071826: Avoid benign race condition in initialization of UUID Summary: Avoids mostly benign but sometimes expensive race condition on initialization of UUID.numberGenerator which is used by UUID.randomUUID() Reviewed-by: alanb, chegar ! src/share/classes/java/util/UUID.java ! test/java/util/UUID/UUIDTest.java Changeset: 85d7677a75bf Author: lana Date: 2012-05-11 12:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/85d7677a75bf Merge Changeset: f131d4361faf Author: olagneau Date: 2012-05-11 14:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f131d4361faf 7144861: speed up RMI activation tests Reviewed-by: alanb, smarks, dholmes, dmocek ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/testlibrary/ActivationLibrary.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/RMID.java ! test/java/rmi/testlibrary/StreamPipe.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java Changeset: df3152beef2f Author: xuelei Date: 2012-05-14 07:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/df3152beef2f 7167988: PKIX CertPathBuilder in reverse mode doesn't work if more than one trust anchor is specified Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java + test/sun/security/provider/certpath/ReverseBuilder/ReverseBuild.java Changeset: df33f5f750ec Author: dsamersoff Date: 2012-05-15 16:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/df33f5f750ec 7164191: properties.putAll API may fail with ConcurrentModifcationException on multi-thread scenario Reviewed-by: dholmes, sla Contributed-by: Deven You ! src/share/classes/sun/management/Agent.java + test/sun/management/AgentCMETest.java Changeset: 9a18e318f95a Author: khazra Date: 2012-05-15 11:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9a18e318f95a 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs Summary: Remove rawtype usages and other code cleanup Reviewed-by: chegar, briangoetz ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFactory.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java Changeset: 332bebb463d1 Author: alanb Date: 2012-05-16 12:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/332bebb463d1 7168505: (bf) MappedByteBuffer.load does not load buffer's content into memory Reviewed-by: mduigou, forax ! src/share/classes/java/nio/MappedByteBuffer.java Changeset: ce165aa48dcb Author: dcubed Date: 2012-05-17 06:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ce165aa48dcb 7168520: No jdk8 TL Nightly linux builds due to broken link in b39-2012-05-13_231 Summary: ZIP libjsig.debuginfo links into libjsig.diz files since aurora doesn't like dangling symlinks Reviewed-by: katleman ! make/java/redist/Makefile Changeset: 178c480998b1 Author: robm Date: 2012-05-17 22:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/178c480998b1 7168110: Misleading jstack error message Reviewed-by: alanb, dsamersoff ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c Changeset: 9fe6ebbe5895 Author: xuelei Date: 2012-05-17 21:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9fe6ebbe5895 7145960: sun/security/mscapi/ShortRSAKey1024.sh failing on windows Reviewed-by: vinnie, wetmore ! test/sun/security/mscapi/ShortRSAKey1024.sh ! test/sun/security/mscapi/ShortRSAKey512.sh ! test/sun/security/mscapi/ShortRSAKey768.sh Changeset: af1030be726a Author: valeriep Date: 2012-05-18 12:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/af1030be726a 7169496: Problem with the SHA-224 support for SunMSCAPI provider Summary: Remove SHA224withRSA signature from SunMSCAPI provider due to lack of windows support. Reviewed-by: vinnie ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java ! test/sun/security/mscapi/SignUsingNONEwithRSA.java ! test/sun/security/mscapi/SignUsingSHA2withRSA.java Changeset: 72af24348b2b Author: weijun Date: 2012-05-21 15:40 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/72af24348b2b 7170308: timing error in the krb5 test SSL.java Reviewed-by: xuelei ! test/sun/security/krb5/auto/SSL.java Changeset: 9cb304dd71d4 Author: alanb Date: 2012-05-21 10:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9cb304dd71d4 7170203: TEST_BUG: test/java/nio/MappedByteBuffer/Truncate.java failing intermittently Reviewed-by: chegar ! test/java/nio/MappedByteBuffer/Truncate.java Changeset: f109feb13698 Author: ksrini Date: 2012-05-21 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f109feb13698 7170087: tools/launcher/Arrghs.java test has wrong bugID for 7151434 Reviewed-by: ohair ! test/tools/launcher/Arrrghs.java Changeset: 0a1ef7e07e01 Author: sla Date: 2012-05-21 19:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0a1ef7e07e01 7167157: jcmd command file parsing does not respect the "stop" command Reviewed-by: alanb, dsamersoff, nloodin ! src/share/classes/sun/tools/jcmd/JCmd.java Changeset: b88fc3359dc7 Author: lana Date: 2012-05-21 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b88fc3359dc7 Merge Changeset: 7def50698e78 Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7def50698e78 Added tag jdk8-b40 for changeset b88fc3359dc7 ! .hgtags From bengt.rutisson at oracle.com Fri May 25 20:47:27 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 25 May 2012 22:47:27 +0200 Subject: Request for review (XXS): 7171936: LOG_G incorrectly defined in globalDefinitions.hpp Message-ID: <4FBFEFDF.1090903@oracle.com> Hi all, Can I have a couple of reviews for this really small change: http://cr.openjdk.java.net/~brutisso/7171936-LOG_G/webrev.00/ Background: The constant LOG_G in globalDefinitions.hpp is incorrectly definied as 40. It should be 30. LOG_G is not being used anywhere, so rather than fixing it we should remove it. LOG_K is also not used and LOG_M is only used in one single place. I suggest that we remove LOG_K and move LOG_M to where it is being used. Thanks Ulf Zibis for catching the wrongly defined constant. Bengt From john.coomes at oracle.com Fri May 25 23:19:27 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 May 2012 23:19:27 +0000 Subject: hg: hsx/hotspot-gc/langtools: 6 new changesets Message-ID: <20120525231944.C385F4752F@hg.openjdk.java.net> Changeset: d10db3576c08 Author: ksrini Date: 2012-05-04 07:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d10db3576c08 7166010: (javac) JavacMessager incorrectly restores log source file Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/processing/JavacMessager.java + test/tools/javac/processing/messager/MessagerDiags.java Changeset: 833bab705918 Author: ksrini Date: 2012-05-10 12:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/833bab705918 7159445: (javac) emits inaccurate diagnostics for enhanced for-loops Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/ForeachBadInitialization.java ! test/tools/javac/parser/JavacParserTest.java Changeset: 96a8278e323c Author: sundar Date: 2012-05-11 20:06 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/96a8278e323c 7166990: java/compiler Inherited interfaces using generics sometimes looses the generic type Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/TryWithResources/T7164542.java Changeset: 885806e74240 Author: lana Date: 2012-05-11 12:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/885806e74240 Merge Changeset: 86e0dad6aadf Author: lana Date: 2012-05-21 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/86e0dad6aadf Merge Changeset: 179fa85aeefa Author: katleman Date: 2012-05-24 16:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/179fa85aeefa Added tag jdk8-b40 for changeset 86e0dad6aadf ! .hgtags From bengt.rutisson at oracle.com Mon May 28 20:37:07 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 28 May 2012 22:37:07 +0200 Subject: Request for review (M): 7172279: G1: Clean up TraceGen0Time and TraceGen1Time data gathering Message-ID: <4FC3E1F3.1070906@oracle.com> Hi all, Can I have a couple of code reviews for this change? http://cr.openjdk.java.net/~brutisso/7172279/webrev.01/ Background I am preparing a change to remove the special treatment of the single threaded case for G1 PrintGCDetails output. We should be able to use the same code for both ParallelGCThreads = 0 and PrallelGCThreads >= 1. This will hopefully simplify the logging code. In preparation for that change I would like to clean up the TraceGen0Time and TraceGen1Time data gathering code a bit. It is currently kind of difficult to follow the code and there is no clear distinction between the data gathered for these two cases compared to the data gathered for PrintGCDetails output. Here is what I tried to do: - Remove the unnecessary define_num_seq macro and the multiple inheritance of the Summary class. - Replaced the above with two classes, TraceGen0TimeData and TraceGen1TimeData, that will encapsulate the data needed. - Made sure that the data is only updated if the corresponding flags are turned on. - Removed the separate "non-parallel" case. All data is available even with ParallelGCThreads = 0. - Removed the ExitAfterGCNum flag. I hardly think this is an appropriate product flag to have in the code. - Removed some unused methods. - Removed 7 year old assert(true) with accompanying comments. - Removed the unused aux time concept. There was one thing that I was hesitant to remove, but finally decided to remove anyway. It was the G1CollectorPolicy::check_other_times() method. First I added the same method to TraceGen0TimeData. But it is a lot of code and I am not sure it is very useful. It can't do any exact checks and it seems unlikely to me that it will detect any issues. Also, it seems to me like the code was in the wrong place. I would have preferred it in some kind of verify method rather than in a print method. Thanks, Bengt From bengt.rutisson at oracle.com Tue May 29 06:58:18 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 29 May 2012 08:58:18 +0200 Subject: Request for review (M): 7172279: G1: Clean up TraceGen0Time and TraceGen1Time data gathering In-Reply-To: <4FC3E1F3.1070906@oracle.com> References: <4FC3E1F3.1070906@oracle.com> Message-ID: <4FC4738A.50102@oracle.com> Hi again, I should also have mentioned that this change should not alter the log output. (Except for the ParallelGCThreads = 0 case which now will look the same as PrallelGCThreads >= 1 case.) I tested this by leaving the old code in and comparing the output from the old code with the new code. In my tests they look exactly the same. Bengt On 2012-05-28 22:37, Bengt Rutisson wrote: > > Hi all, > > Can I have a couple of code reviews for this change? > http://cr.openjdk.java.net/~brutisso/7172279/webrev.01/ > > Background > I am preparing a change to remove the special treatment of the single > threaded case for G1 PrintGCDetails output. We should be able to use > the same code for both ParallelGCThreads = 0 and PrallelGCThreads >= > 1. This will hopefully simplify the logging code. > > In preparation for that change I would like to clean up the > TraceGen0Time and TraceGen1Time data gathering code a bit. It is > currently kind of difficult to follow the code and there is no clear > distinction between the data gathered for these two cases compared to > the data gathered for PrintGCDetails output. > > Here is what I tried to do: > > - Remove the unnecessary define_num_seq macro and the multiple > inheritance of the Summary class. > - Replaced the above with two classes, TraceGen0TimeData and > TraceGen1TimeData, that will encapsulate the data needed. > - Made sure that the data is only updated if the corresponding flags > are turned on. > - Removed the separate "non-parallel" case. All data is available even > with ParallelGCThreads = 0. > - Removed the ExitAfterGCNum flag. I hardly think this is an > appropriate product flag to have in the code. > - Removed some unused methods. > - Removed 7 year old assert(true) with accompanying comments. > - Removed the unused aux time concept. > > There was one thing that I was hesitant to remove, but finally decided > to remove anyway. It was the G1CollectorPolicy::check_other_times() > method. First I added the same method to TraceGen0TimeData. But it is > a lot of code and I am not sure it is very useful. It can't do any > exact checks and it seems unlikely to me that it will detect any > issues. Also, it seems to me like the code was in the wrong place. I > would have preferred it in some kind of verify method rather than in a > print method. > > Thanks, > Bengt From bengt.rutisson at oracle.com Tue May 29 11:48:25 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 29 May 2012 13:48:25 +0200 Subject: Request for review (M): 7172388: G1: _total_full_collections should not be incremented for concurrent cycles Message-ID: <4FC4B789.90407@oracle.com> Hi all, Can I have a couple of reviews for this change? http://cr.openjdk.java.net/~brutisso/7172388/webrev.00/ Background: CollectedHeap::total_full_collections() should keep track of the number of full GCs. At least that is what all collectors except G1 does. G1 also counts the concurrent marking cycles as full collections. This change will make G1 behave like the other collectors with regards to CollectedHeap::total_full_collections(). Testing: - JPRT - UTE on a Linux x64 host using these test lists: nsk.monitoring.testlist vm.tmtools.testlist java/lang/management com/sun/management sun/management Also, Matherey had written a Whitebox API test that used CollectedHeap::total_full_collections() to find out how many full GCs that were performed. This test always failed with G1. With my proposed change that test works fine with G1 as well. Thanks, Bengt From christian.thalinger at oracle.com Tue May 29 16:32:02 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 29 May 2012 09:32:02 -0700 Subject: Request for review (XXS): 7171936: LOG_G incorrectly defined in globalDefinitions.hpp In-Reply-To: <4FBFEFDF.1090903@oracle.com> References: <4FBFEFDF.1090903@oracle.com> Message-ID: <6B4CD743-A266-41F9-B28F-4CBBDEE5451D@oracle.com> Looks good to me. -- Chris On May 25, 2012, at 1:47 PM, Bengt Rutisson wrote: > > Hi all, > > Can I have a couple of reviews for this really small change: > http://cr.openjdk.java.net/~brutisso/7171936-LOG_G/webrev.00/ > > Background: > The constant LOG_G in globalDefinitions.hpp is incorrectly definied as 40. It should be 30. LOG_G is not being used anywhere, so rather than fixing it we should remove it. > > LOG_K is also not used and LOG_M is only used in one single place. I suggest that we remove LOG_K and move LOG_M to where it is being used. > > Thanks Ulf Zibis for catching the wrongly defined constant. > > Bengt From mikael.vidstedt at oracle.com Tue May 29 17:47:01 2012 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 29 May 2012 10:47:01 -0700 Subject: Request for review (M): 7172279: G1: Clean up TraceGen0Time and TraceGen1Time data gathering In-Reply-To: <4FC4738A.50102@oracle.com> References: <4FC3E1F3.1070906@oracle.com> <4FC4738A.50102@oracle.com> Message-ID: <4FC50B95.9080707@oracle.com> On 2012-05-28 23:58, Bengt Rutisson wrote: > > Hi again, > > I should also have mentioned that this change should not alter the log > output. (Except for the ParallelGCThreads = 0 case which now will look > the same as PrallelGCThreads >= 1 case.) +1 for not changing the log output in a minor/update release. What does the "except" part mean? Thanks, Mikael > > I tested this by leaving the old code in and comparing the output from > the old code with the new code. In my tests they look exactly the same. > > Bengt > > On 2012-05-28 22:37, Bengt Rutisson wrote: >> >> Hi all, >> >> Can I have a couple of code reviews for this change? >> http://cr.openjdk.java.net/~brutisso/7172279/webrev.01/ >> >> Background >> I am preparing a change to remove the special treatment of the single >> threaded case for G1 PrintGCDetails output. We should be able to use >> the same code for both ParallelGCThreads = 0 and PrallelGCThreads >= >> 1. This will hopefully simplify the logging code. >> >> In preparation for that change I would like to clean up the >> TraceGen0Time and TraceGen1Time data gathering code a bit. It is >> currently kind of difficult to follow the code and there is no clear >> distinction between the data gathered for these two cases compared to >> the data gathered for PrintGCDetails output. >> >> Here is what I tried to do: >> >> - Remove the unnecessary define_num_seq macro and the multiple >> inheritance of the Summary class. >> - Replaced the above with two classes, TraceGen0TimeData and >> TraceGen1TimeData, that will encapsulate the data needed. >> - Made sure that the data is only updated if the corresponding flags >> are turned on. >> - Removed the separate "non-parallel" case. All data is available >> even with ParallelGCThreads = 0. >> - Removed the ExitAfterGCNum flag. I hardly think this is an >> appropriate product flag to have in the code. >> - Removed some unused methods. >> - Removed 7 year old assert(true) with accompanying comments. >> - Removed the unused aux time concept. >> >> There was one thing that I was hesitant to remove, but finally >> decided to remove anyway. It was the >> G1CollectorPolicy::check_other_times() method. First I added the same >> method to TraceGen0TimeData. But it is a lot of code and I am not >> sure it is very useful. It can't do any exact checks and it seems >> unlikely to me that it will detect any issues. Also, it seems to me >> like the code was in the wrong place. I would have preferred it in >> some kind of verify method rather than in a print method. >> >> Thanks, >> Bengt > From eric.caspole at amd.com Tue May 29 18:54:03 2012 From: eric.caspole at amd.com (Eric Caspole) Date: Tue, 29 May 2012 14:54:03 -0400 Subject: Turn on UseNUMA by default when prudent Message-ID: <83C598A8-07DA-4B16-B409-328A326BEA4B@amd.com> Hi Hotspot team, We sometimes notice on multi-socket systems large run to run variation in some benchmarks which seems to be attributed to bad/ unlucky numa behavior. So we would like to add simple checks to turn on +UseNUMA for AMD platforms in the right situations; for example, max heap >= 4GB and we detect a multi-socket system. This should be a useful out-of-box improvement for most customers since UseParallelGC is the default. For benchmarks with a large heap, it helps give better out-of-box performance in many cases. Here is my first webrev to turn on NUMA for AMD systems when it is a numa system and the heap is set >= 4GB. http://cr.openjdk.java.net/~ecaspole/numa_default/ Please let me know your thoughts on the merit of doing this and if it is worthwhile what should be the structure of the change in the shared/os/cpu specific code. Thanks, Eric From john.cuthbertson at oracle.com Tue May 29 19:22:50 2012 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Tue, 29 May 2012 19:22:50 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7143858: G1: Back to back young GCs with the second GC having a minimally sized eden Message-ID: <20120529192255.3239E47599@hg.openjdk.java.net> Changeset: 1d478c993020 Author: johnc Date: 2012-05-29 10:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1d478c993020 7143858: G1: Back to back young GCs with the second GC having a minimally sized eden Summary: Before the last thread to leave a JNI critical region was able to schedule a GCLocker Initiated GC, another thread was attempting an allocation and saw that the GCLocker region was no longer active and successfully scheduled a GC. Stall allocating threads until the GCLocker Initiated GC is performed and then retry the allocation. Reviewed-by: brutisso, huntch ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp From jesper.wilhelmsson at oracle.com Tue May 29 19:56:35 2012 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 29 May 2012 21:56:35 +0200 Subject: Turn on UseNUMA by default when prudent In-Reply-To: <83C598A8-07DA-4B16-B409-328A326BEA4B@amd.com> References: <83C598A8-07DA-4B16-B409-328A326BEA4B@amd.com> Message-ID: <4FC529F3.6040502@oracle.com> Hi Eric, As long as this is based on actual data and not just a hunch, I personally think it is a good idea. I don't know if we have any policies about platform specific optimizations like this though. I have some comments on the code layout and there are a few typos, but I guess this is still a draft so I won't pick on that right now. One thing I wonder though is in os_linux_x86.cpp: if (VM_Version::cpu_family() == 0x15 || VM_Version::cpu_family() == 0x10) { Is this the only way to identify the proper processor family? It doesn't seem very future proof. How often would you have to change this code to keep it up to date with new hardware? Regards, /Jesper On 2012-05-29 20:54, Eric Caspole wrote: > Hi Hotspot team, > > We sometimes notice on multi-socket systems large run to run variation in some > benchmarks which seems to be attributed to bad/unlucky numa behavior. So we > would like to add simple checks to turn on +UseNUMA for AMD platforms in the > right situations; for example, max heap >= 4GB and we detect a multi-socket > system. This should be a useful out-of-box improvement for most customers > since UseParallelGC is the default. > > For benchmarks with a large heap, it helps give better out-of-box performance > in many cases. > > Here is my first webrev to turn on NUMA for AMD systems when it is a numa > system and the heap is set >= 4GB. > > http://cr.openjdk.java.net/~ecaspole/numa_default/ > > Please let me know your thoughts on the merit of doing this and if it is > worthwhile what should be the structure of the change in the shared/os/cpu > specific code. > > Thanks, > Eric > > From vladimir.kozlov at oracle.com Tue May 29 20:09:09 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 May 2012 13:09:09 -0700 Subject: Turn on UseNUMA by default when prudent In-Reply-To: <4FC529F3.6040502@oracle.com> References: <83C598A8-07DA-4B16-B409-328A326BEA4B@amd.com> <4FC529F3.6040502@oracle.com> Message-ID: <4FC52CE5.70902@oracle.com> Jesper Wilhelmsson wrote: > Hi Eric, > > As long as this is based on actual data and not just a hunch, I > personally think it is a good idea. I don't know if we have any policies > about platform specific optimizations like this though. > > I have some comments on the code layout and there are a few typos, but I > guess this is still a draft so I won't pick on that right now. > > One thing I wonder though is in os_linux_x86.cpp: > > if (VM_Version::cpu_family() == 0x15 || VM_Version::cpu_family() == 0x10) { Yes, this code should be in vm_version_x86.cpp file. I also would like to see this more general for all OSes. Thanks, Vladimir > > Is this the only way to identify the proper processor family? It doesn't > seem very future proof. How often would you have to change this code to > keep it up to date with new hardware? > > Regards, > /Jesper > > > On 2012-05-29 20:54, Eric Caspole wrote: >> Hi Hotspot team, >> >> We sometimes notice on multi-socket systems large run to run variation >> in some >> benchmarks which seems to be attributed to bad/unlucky numa behavior. >> So we >> would like to add simple checks to turn on +UseNUMA for AMD platforms >> in the >> right situations; for example, max heap >= 4GB and we detect a >> multi-socket >> system. This should be a useful out-of-box improvement for most customers >> since UseParallelGC is the default. >> >> For benchmarks with a large heap, it helps give better out-of-box >> performance >> in many cases. >> >> Here is my first webrev to turn on NUMA for AMD systems when it is a numa >> system and the heap is set >= 4GB. >> >> http://cr.openjdk.java.net/~ecaspole/numa_default/ >> >> Please let me know your thoughts on the merit of doing this and if it is >> worthwhile what should be the structure of the change in the >> shared/os/cpu >> specific code. >> >> Thanks, >> Eric >> >> From bengt.rutisson at oracle.com Tue May 29 20:32:02 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 29 May 2012 22:32:02 +0200 Subject: Request for review (M): 7172279: G1: Clean up TraceGen0Time and TraceGen1Time data gathering In-Reply-To: <4FC50B95.9080707@oracle.com> References: <4FC3E1F3.1070906@oracle.com> <4FC4738A.50102@oracle.com> <4FC50B95.9080707@oracle.com> Message-ID: <4FC53242.8070200@oracle.com> On 2012-05-29 19:47, Mikael Vidstedt wrote: > > On 2012-05-28 23:58, Bengt Rutisson wrote: >> >> Hi again, >> >> I should also have mentioned that this change should not alter the >> log output. (Except for the ParallelGCThreads = 0 case which now will >> look the same as PrallelGCThreads >= 1 case.) > > +1 for not changing the log output in a minor/update release. What > does the "except" part mean? Good question. It is more or less just a matter of indentation. See the examples below. There are two single threaded cases. One with ParallelGCThreads = 0 and one with ParallelGCThreads = 1. My change make their output the same. Basically the ParallelGCThreads = 1 assumes a parallel state so we indent the different phases under a "Parallel" overall time, and we add a "Termination" phase which will be 0 for single threaded execution. By default we use parallel excution. The ParallelGCThreads = 0 is more or less a debug tool to help eliminate thread issues. It is not worth treating specially in the code and it is unlikely that it is being used by customers. Also, this is a pure G1 change and the output is only printed once during a complete run (when we exit the vm). There is no risk of breaking any customer parsers with this change. The examples below are from before my change. After my change both will look like the -XX:ParallelGCThreads=1 example. Bengt -XX:ParallelGCThreads=0 ALL PAUSES Total = 0.54 s (avg = 41.46 ms) (num = 13, std dev = 40.28 ms, max = 146.02 ms) Young GC Pauses: 13 Mixed GC Pauses: 0 EVACUATION PAUSES Evacuation Pauses = 0.54 s (avg = 41.46 ms) (num = 13, std dev = 40.28 ms, max = 146.02 ms) Root Region Scan Wait = 0.00 s (avg = 0.00 ms) Ext Root Scanning = 0.04 s (avg = 3.28 ms) SATB Filtering = 0.00 s (avg = 0.00 ms) Update RS = 0.02 s (avg = 1.80 ms) Scan RS = 0.04 s (avg = 3.14 ms) Object Copy = 0.42 s (avg = 32.04 ms) Mark Closure = 0.00 s (avg = 0.00 ms) Clear CT = 0.00 s (avg = 0.04 ms) Other = 0.02 s (avg = 1.16 ms) MISC Stop World = 0.00 s (avg = 0.33 ms) (num = 13, std dev = 0.04 ms, max = 0.41 ms) Yields = 0.00 s (avg = 0.00 ms) (num = 0, std dev = 0.00 ms, max = 0.00 ms) 2 full_gcs: total time = 0.06 s (avg = 28.65ms). [std. dev = 11.57 ms, max = 40.22 ms] -XX:ParallelGCThreads=1 ALL PAUSES Total = 0.56 s (avg = 47.03 ms) (num = 12, std dev = 45.22 ms, max = 159.05 ms) Young GC Pauses: 12 Mixed GC Pauses: 0 EVACUATION PAUSES Evacuation Pauses = 0.56 s (avg = 47.03 ms) (num = 12, std dev = 45.22 ms, max = 159.05 ms) Root Region Scan Wait = 0.00 s (avg = 0.00 ms) Parallel Time = 0.55 s (avg = 45.83 ms) Ext Root Scanning = 0.04 s (avg = 3.74 ms) SATB Filtering = 0.00 s (avg = 0.00 ms) Update RS = 0.02 s (avg = 1.95 ms) Scan RS = 0.03 s (avg = 2.73 ms) Object Copy = 0.45 s (avg = 37.17 ms) Termination = 0.00 s (avg = 0.00 ms) Parallel Other = 0.00 s (avg = 0.25 ms) Mark Closure = 0.00 s (avg = 0.00 ms) Clear CT = 0.00 s (avg = 0.06 ms) Other = 0.01 s (avg = 1.14 ms) MISC Stop World = 0.00 s (avg = 0.33 ms) (num = 12, std dev = 0.04 ms, max = 0.44 ms) Yields = 0.00 s (avg = 0.00 ms) (num = 0, std dev = 0.00 ms, max = 0.00 ms) 2 full_gcs: total time = 0.06 s (avg = 29.65ms). [std. dev = 12.58 ms, max = 42.22 ms] > > Thanks, > Mikael > >> >> I tested this by leaving the old code in and comparing the output >> from the old code with the new code. In my tests they look exactly >> the same. >> >> Bengt >> >> On 2012-05-28 22:37, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> Can I have a couple of code reviews for this change? >>> http://cr.openjdk.java.net/~brutisso/7172279/webrev.01/ >>> >>> Background >>> I am preparing a change to remove the special treatment of the >>> single threaded case for G1 PrintGCDetails output. We should be able >>> to use the same code for both ParallelGCThreads = 0 and >>> PrallelGCThreads >= 1. This will hopefully simplify the logging code. >>> >>> In preparation for that change I would like to clean up the >>> TraceGen0Time and TraceGen1Time data gathering code a bit. It is >>> currently kind of difficult to follow the code and there is no clear >>> distinction between the data gathered for these two cases compared >>> to the data gathered for PrintGCDetails output. >>> >>> Here is what I tried to do: >>> >>> - Remove the unnecessary define_num_seq macro and the multiple >>> inheritance of the Summary class. >>> - Replaced the above with two classes, TraceGen0TimeData and >>> TraceGen1TimeData, that will encapsulate the data needed. >>> - Made sure that the data is only updated if the corresponding flags >>> are turned on. >>> - Removed the separate "non-parallel" case. All data is available >>> even with ParallelGCThreads = 0. >>> - Removed the ExitAfterGCNum flag. I hardly think this is an >>> appropriate product flag to have in the code. >>> - Removed some unused methods. >>> - Removed 7 year old assert(true) with accompanying comments. >>> - Removed the unused aux time concept. >>> >>> There was one thing that I was hesitant to remove, but finally >>> decided to remove anyway. It was the >>> G1CollectorPolicy::check_other_times() method. First I added the >>> same method to TraceGen0TimeData. But it is a lot of code and I am >>> not sure it is very useful. It can't do any exact checks and it >>> seems unlikely to me that it will detect any issues. Also, it seems >>> to me like the code was in the wrong place. I would have preferred >>> it in some kind of verify method rather than in a print method. >>> >>> Thanks, >>> Bengt >> > From eric.caspole at amd.com Tue May 29 21:15:17 2012 From: eric.caspole at amd.com (Eric Caspole) Date: Tue, 29 May 2012 17:15:17 -0400 Subject: Turn on UseNUMA by default when prudent In-Reply-To: <4FC529F3.6040502@oracle.com> References: <83C598A8-07DA-4B16-B409-328A326BEA4B@amd.com> <4FC529F3.6040502@oracle.com> Message-ID: <84201DA6-78F1-463E-85BE-267698D29DB1@amd.com> On May 29, 2012, at 3:56 PM, Jesper Wilhelmsson wrote: > Hi Eric, > > As long as this is based on actual data and not just a hunch, I > personally think it is a good idea. I don't know if we have any > policies about platform specific optimizations like this though. > > I have some comments on the code layout and there are a few typos, > but I guess this is still a draft so I won't pick on that right now. > > One thing I wonder though is in os_linux_x86.cpp: > > if (VM_Version::cpu_family() == 0x15 || VM_Version::cpu_family() == > 0x10) { > > Is this the only way to identify the proper processor family? It > doesn't seem very future proof. How often would you have to change > this code to keep it up to date with new hardware? I will check on future plans but from past experience I would say once every 2-3 years or so. Not all families are server parts. > > Regards, > /Jesper > > > On 2012-05-29 20:54, Eric Caspole wrote: >> Hi Hotspot team, >> >> We sometimes notice on multi-socket systems large run to run >> variation in some >> benchmarks which seems to be attributed to bad/unlucky numa >> behavior. So we >> would like to add simple checks to turn on +UseNUMA for AMD >> platforms in the >> right situations; for example, max heap >= 4GB and we detect a >> multi-socket >> system. This should be a useful out-of-box improvement for most >> customers >> since UseParallelGC is the default. >> >> For benchmarks with a large heap, it helps give better out-of-box >> performance >> in many cases. >> >> Here is my first webrev to turn on NUMA for AMD systems when it is >> a numa >> system and the heap is set >= 4GB. >> >> http://cr.openjdk.java.net/~ecaspole/numa_default/ >> >> Please let me know your thoughts on the merit of doing this and if >> it is >> worthwhile what should be the structure of the change in the >> shared/os/cpu >> specific code. >> >> Thanks, >> Eric >> >> > From eric.caspole at amd.com Tue May 29 21:30:56 2012 From: eric.caspole at amd.com (Eric Caspole) Date: Tue, 29 May 2012 17:30:56 -0400 Subject: Turn on UseNUMA by default when prudent In-Reply-To: <4FC52CE5.70902@oracle.com> References: <83C598A8-07DA-4B16-B409-328A326BEA4B@amd.com> <4FC529F3.6040502@oracle.com> <4FC52CE5.70902@oracle.com> Message-ID: On May 29, 2012, at 4:09 PM, Vladimir Kozlov wrote: > Jesper Wilhelmsson wrote: >> Hi Eric, >> As long as this is based on actual data and not just a hunch, I >> personally think it is a good idea. I don't know if we have any >> policies about platform specific optimizations like this though. >> I have some comments on the code layout and there are a few typos, >> but I guess this is still a draft so I won't pick on that right now. >> One thing I wonder though is in os_linux_x86.cpp: >> if (VM_Version::cpu_family() == 0x15 || VM_Version::cpu_family() >> == 0x10) { > > Yes, this code should be in vm_version_x86.cpp file. I also would > like to see this more general for all OSes. Any volunteers to help get this working for Solaris/SPARC? You use this flag, right? Then it will be easier to see where to place is_numa_machine() type methods etc. > > Thanks, > Vladimir > >> Is this the only way to identify the proper processor family? It >> doesn't seem very future proof. How often would you have to change >> this code to keep it up to date with new hardware? >> Regards, >> /Jesper >> On 2012-05-29 20:54, Eric Caspole wrote: >>> Hi Hotspot team, >>> >>> We sometimes notice on multi-socket systems large run to run >>> variation in some >>> benchmarks which seems to be attributed to bad/unlucky numa >>> behavior. So we >>> would like to add simple checks to turn on +UseNUMA for AMD >>> platforms in the >>> right situations; for example, max heap >= 4GB and we detect a >>> multi-socket >>> system. This should be a useful out-of-box improvement for most >>> customers >>> since UseParallelGC is the default. >>> >>> For benchmarks with a large heap, it helps give better out-of-box >>> performance >>> in many cases. >>> >>> Here is my first webrev to turn on NUMA for AMD systems when it >>> is a numa >>> system and the heap is set >= 4GB. >>> >>> http://cr.openjdk.java.net/~ecaspole/numa_default/ >>> >>> Please let me know your thoughts on the merit of doing this and >>> if it is >>> worthwhile what should be the structure of the change in the >>> shared/os/cpu >>> specific code. >>> >>> Thanks, >>> Eric >>> >>> > From mikael.vidstedt at oracle.com Tue May 29 21:56:43 2012 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 29 May 2012 14:56:43 -0700 Subject: Request for review (M): 7172279: G1: Clean up TraceGen0Time and TraceGen1Time data gathering In-Reply-To: <4FC53242.8070200@oracle.com> References: <4FC3E1F3.1070906@oracle.com> <4FC4738A.50102@oracle.com> <4FC50B95.9080707@oracle.com> <4FC53242.8070200@oracle.com> Message-ID: <4FC5461B.2090705@oracle.com> On 2012-05-29 13:32, Bengt Rutisson wrote: > On 2012-05-29 19:47, Mikael Vidstedt wrote: >> >> On 2012-05-28 23:58, Bengt Rutisson wrote: >>> >>> Hi again, >>> >>> I should also have mentioned that this change should not alter the >>> log output. (Except for the ParallelGCThreads = 0 case which now >>> will look the same as PrallelGCThreads >= 1 case.) >> >> +1 for not changing the log output in a minor/update release. What >> does the "except" part mean? > > Good question. It is more or less just a matter of indentation. See > the examples below. > > There are two single threaded cases. One with ParallelGCThreads = 0 > and one with ParallelGCThreads = 1. My change make their output the > same. Basically the ParallelGCThreads = 1 assumes a parallel state so > we indent the different phases under a "Parallel" overall time, and we > add a "Termination" phase which will be 0 for single threaded execution. > > By default we use parallel excution. The ParallelGCThreads = 0 is more > or less a debug tool to help eliminate thread issues. It is not worth > treating specially in the code and it is unlikely that it is being > used by customers. > > Also, this is a pure G1 change and the output is only printed once > during a complete run (when we exit the vm). There is no risk of > breaking any customer parsers with this change. > > The examples below are from before my change. After my change both > will look like the -XX:ParallelGCThreads=1 example. Thanks for the detailed response. This does indeed look like a great consistency improvement! Cheers, Mikael > > Bengt > > > -XX:ParallelGCThreads=0 > > > ALL PAUSES > Total = 0.54 s (avg = 41.46 ms) > (num = 13, std dev = 40.28 ms, max = 146.02 ms) > > > Young GC Pauses: 13 > Mixed GC Pauses: 0 > > EVACUATION PAUSES > Evacuation Pauses = 0.54 s (avg = 41.46 ms) > (num = 13, std dev = 40.28 ms, max = 146.02 ms) > Root Region Scan Wait = 0.00 s (avg = 0.00 ms) > Ext Root Scanning = 0.04 s (avg = 3.28 ms) > SATB Filtering = 0.00 s (avg = 0.00 ms) > Update RS = 0.02 s (avg = 1.80 ms) > Scan RS = 0.04 s (avg = 3.14 ms) > Object Copy = 0.42 s (avg = 32.04 ms) > Mark Closure = 0.00 s (avg = 0.00 ms) > Clear CT = 0.00 s (avg = 0.04 ms) > Other = 0.02 s (avg = 1.16 ms) > > MISC > Stop World = 0.00 s (avg = 0.33 ms) > (num = 13, std dev = 0.04 ms, max = 0.41 ms) > Yields = 0.00 s (avg = 0.00 ms) > (num = 0, std dev = 0.00 ms, max = 0.00 ms) > > 2 full_gcs: total time = 0.06 s (avg = 28.65ms). > [std. dev = 11.57 ms, max = 40.22 ms] > > > > > > > -XX:ParallelGCThreads=1 > > > ALL PAUSES > Total = 0.56 s (avg = 47.03 ms) > (num = 12, std dev = 45.22 ms, max = 159.05 ms) > > > Young GC Pauses: 12 > Mixed GC Pauses: 0 > > EVACUATION PAUSES > Evacuation Pauses = 0.56 s (avg = 47.03 ms) > (num = 12, std dev = 45.22 ms, max = 159.05 ms) > Root Region Scan Wait = 0.00 s (avg = 0.00 ms) > Parallel Time = 0.55 s (avg = 45.83 ms) > Ext Root Scanning = 0.04 s (avg = 3.74 ms) > SATB Filtering = 0.00 s (avg = 0.00 ms) > Update RS = 0.02 s (avg = 1.95 ms) > Scan RS = 0.03 s (avg = 2.73 ms) > Object Copy = 0.45 s (avg = 37.17 ms) > Termination = 0.00 s (avg = 0.00 ms) > Parallel Other = 0.00 s (avg = 0.25 ms) > Mark Closure = 0.00 s (avg = 0.00 ms) > Clear CT = 0.00 s (avg = 0.06 ms) > Other = 0.01 s (avg = 1.14 ms) > > MISC > Stop World = 0.00 s (avg = 0.33 ms) > (num = 12, std dev = 0.04 ms, max = 0.44 ms) > Yields = 0.00 s (avg = 0.00 ms) > (num = 0, std dev = 0.00 ms, max = 0.00 ms) > > 2 full_gcs: total time = 0.06 s (avg = 29.65ms). > [std. dev = 12.58 ms, max = 42.22 ms] > > > > > > >> >> Thanks, >> Mikael >> >>> >>> I tested this by leaving the old code in and comparing the output >>> from the old code with the new code. In my tests they look exactly >>> the same. >>> >>> Bengt >>> >>> On 2012-05-28 22:37, Bengt Rutisson wrote: >>>> >>>> Hi all, >>>> >>>> Can I have a couple of code reviews for this change? >>>> http://cr.openjdk.java.net/~brutisso/7172279/webrev.01/ >>>> >>>> Background >>>> I am preparing a change to remove the special treatment of the >>>> single threaded case for G1 PrintGCDetails output. We should be >>>> able to use the same code for both ParallelGCThreads = 0 and >>>> PrallelGCThreads >= 1. This will hopefully simplify the logging code. >>>> >>>> In preparation for that change I would like to clean up the >>>> TraceGen0Time and TraceGen1Time data gathering code a bit. It is >>>> currently kind of difficult to follow the code and there is no >>>> clear distinction between the data gathered for these two cases >>>> compared to the data gathered for PrintGCDetails output. >>>> >>>> Here is what I tried to do: >>>> >>>> - Remove the unnecessary define_num_seq macro and the multiple >>>> inheritance of the Summary class. >>>> - Replaced the above with two classes, TraceGen0TimeData and >>>> TraceGen1TimeData, that will encapsulate the data needed. >>>> - Made sure that the data is only updated if the corresponding >>>> flags are turned on. >>>> - Removed the separate "non-parallel" case. All data is available >>>> even with ParallelGCThreads = 0. >>>> - Removed the ExitAfterGCNum flag. I hardly think this is an >>>> appropriate product flag to have in the code. >>>> - Removed some unused methods. >>>> - Removed 7 year old assert(true) with accompanying comments. >>>> - Removed the unused aux time concept. >>>> >>>> There was one thing that I was hesitant to remove, but finally >>>> decided to remove anyway. It was the >>>> G1CollectorPolicy::check_other_times() method. First I added the >>>> same method to TraceGen0TimeData. But it is a lot of code and I am >>>> not sure it is very useful. It can't do any exact checks and it >>>> seems unlikely to me that it will detect any issues. Also, it seems >>>> to me like the code was in the wrong place. I would have preferred >>>> it in some kind of verify method rather than in a print method. >>>> >>>> Thanks, >>>> Bengt >>> >> > From john.cuthbertson at oracle.com Tue May 29 23:37:42 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 29 May 2012 16:37:42 -0700 Subject: Request for review (XXS): 7171936: LOG_G incorrectly defined in globalDefinitions.hpp In-Reply-To: <4FBFEFDF.1090903@oracle.com> References: <4FBFEFDF.1090903@oracle.com> Message-ID: <4FC55DC6.3000202@oracle.com> Hi Bengt, Looks good to me. JohnC On 05/25/12 13:47, Bengt Rutisson wrote: > > Hi all, > > Can I have a couple of reviews for this really small change: > http://cr.openjdk.java.net/~brutisso/7171936-LOG_G/webrev.00/ > > Background: > The constant LOG_G in globalDefinitions.hpp is incorrectly definied as > 40. It should be 30. LOG_G is not being used anywhere, so rather than > fixing it we should remove it. > > LOG_K is also not used and LOG_M is only used in one single place. I > suggest that we remove LOG_K and move LOG_M to where it is being used. > > Thanks Ulf Zibis for catching the wrongly defined constant. > > Bengt From chunt at salesforce.com Wed May 30 02:41:16 2012 From: chunt at salesforce.com (Charlie Hunt) Date: Tue, 29 May 2012 19:41:16 -0700 Subject: Request for review (M): 7172279: G1: Clean up TraceGen0Time and TraceGen1Time data gathering In-Reply-To: <4FC4738A.50102@oracle.com> References: <4FC3E1F3.1070906@oracle.com> <4FC4738A.50102@oracle.com> Message-ID: Nice cleanup Bengt. One observation which I found a bit confusing. In g1CollectorPolicy.cpp, line 2285 - 2287 we have the following code: _last_gc_was_young = gcs_are_young() ? true : false; _trace_gen0_time_data.increment_collection_count(!_last_gc_was_young); The !_last_gc_was_young threw me a bit since we were incrementing the collection count on a "trace gen0". Has there been consideration of using an enumerated type for a young GC and mixed GC type rather than using a boolean to represent the two? Or, alternatively introducing a mutator method for incrementing only _young_pause_num and a second mutator method for incrementing _mixed_pause_num ? I didn't see anything incorrect in the implementation ... just found this bit a little confusing. hths, charlie ... On May 29, 2012, at 1:58 AM, Bengt Rutisson wrote: Hi again, I should also have mentioned that this change should not alter the log output. (Except for the ParallelGCThreads = 0 case which now will look the same as PrallelGCThreads >= 1 case.) I tested this by leaving the old code in and comparing the output from the old code with the new code. In my tests they look exactly the same. Bengt On 2012-05-28 22:37, Bengt Rutisson wrote: Hi all, Can I have a couple of code reviews for this change? http://cr.openjdk.java.net/~brutisso/7172279/webrev.01/ Background I am preparing a change to remove the special treatment of the single threaded case for G1 PrintGCDetails output. We should be able to use the same code for both ParallelGCThreads = 0 and PrallelGCThreads >= 1. This will hopefully simplify the logging code. In preparation for that change I would like to clean up the TraceGen0Time and TraceGen1Time data gathering code a bit. It is currently kind of difficult to follow the code and there is no clear distinction between the data gathered for these two cases compared to the data gathered for PrintGCDetails output. Here is what I tried to do: - Remove the unnecessary define_num_seq macro and the multiple inheritance of the Summary class. - Replaced the above with two classes, TraceGen0TimeData and TraceGen1TimeData, that will encapsulate the data needed. - Made sure that the data is only updated if the corresponding flags are turned on. - Removed the separate "non-parallel" case. All data is available even with ParallelGCThreads = 0. - Removed the ExitAfterGCNum flag. I hardly think this is an appropriate product flag to have in the code. - Removed some unused methods. - Removed 7 year old assert(true) with accompanying comments. - Removed the unused aux time concept. There was one thing that I was hesitant to remove, but finally decided to remove anyway. It was the G1CollectorPolicy::check_other_times() method. First I added the same method to TraceGen0TimeData. But it is a lot of code and I am not sure it is very useful. It can't do any exact checks and it seems unlikely to me that it will detect any issues. Also, it seems to me like the code was in the wrong place. I would have preferred it in some kind of verify method rather than in a print method. Thanks, Bengt -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Wed May 30 09:47:58 2012 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Wed, 30 May 2012 09:47:58 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7171936: LOG_G incorrectly defined in globalDefinitions.hpp Message-ID: <20120530094809.CE490475B3@hg.openjdk.java.net> Changeset: 5c8bd7c16119 Author: brutisso Date: 2012-05-25 22:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5c8bd7c16119 7171936: LOG_G incorrectly defined in globalDefinitions.hpp Summary: Removed LOG_G and LOG_K. Moved LOG_M to where it is being used. Reviewed-by: twisti, johnc ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/utilities/globalDefinitions.hpp From bengt.rutisson at oracle.com Wed May 30 11:14:49 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 30 May 2012 13:14:49 +0200 Subject: Request for review (XXS): 7171936: LOG_G incorrectly defined in globalDefinitions.hpp In-Reply-To: <4FC55DC6.3000202@oracle.com> References: <4FBFEFDF.1090903@oracle.com> <4FC55DC6.3000202@oracle.com> Message-ID: <4FC60129.6060408@oracle.com> John and Christian, Thanks for the reviews! My push job just finished, so this is pushed now. Bengt On 2012-05-30 01:37, John Cuthbertson wrote: > Hi Bengt, > > Looks good to me. > > JohnC > > On 05/25/12 13:47, Bengt Rutisson wrote: >> >> Hi all, >> >> Can I have a couple of reviews for this really small change: >> http://cr.openjdk.java.net/~brutisso/7171936-LOG_G/webrev.00/ >> >> Background: >> The constant LOG_G in globalDefinitions.hpp is incorrectly definied >> as 40. It should be 30. LOG_G is not being used anywhere, so rather >> than fixing it we should remove it. >> >> LOG_K is also not used and LOG_M is only used in one single place. I >> suggest that we remove LOG_K and move LOG_M to where it is being used. >> >> Thanks Ulf Zibis for catching the wrongly defined constant. >> >> Bengt > From bengt.rutisson at oracle.com Wed May 30 12:32:04 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 30 May 2012 14:32:04 +0200 Subject: Request for review (M): 7172279: G1: Clean up TraceGen0Time and TraceGen1Time data gathering In-Reply-To: References: <4FC3E1F3.1070906@oracle.com> <4FC4738A.50102@oracle.com> Message-ID: <4FC61344.7080101@oracle.com> Hi Charlie, Thanks for looking at this! On 2012-05-30 04:41, Charlie Hunt wrote: > Nice cleanup Bengt. > > One observation which I found a bit confusing. > > In g1CollectorPolicy.cpp, line 2285 - 2287 we have the following code: > _last_gc_was_young = gcs_are_young() ? true : false; > _trace_gen0_time_data.increment_collection_count(!_last_gc_was_young); > The !_last_gc_was_young threw me a bit since we were incrementing the > collection count on a "trace gen0". Has there been consideration of > using an enumerated type for a young GC and mixed GC type rather than > using a boolean to represent the two? Or, alternatively introducing a > mutator method for incrementing only _young_pause_num and a second > mutator method for incrementing _mixed_pause_num ? Good point. I went with your last suggestion and added separate mutator methods for mixed and young collections. Here is an updated webrev: http://cr.openjdk.java.net/~brutisso/7172279/webrev.02/ > > I didn't see anything incorrect in the implementation ... just found > this bit a little confusing. Actually there was a mistake in the code too. I had moved the young and mixed counters from G1CollectorPolicy to TraceGen0TimeData. But since I wanted to verify my changes I had left the counters in G1CollectorPolicy and I forgot to remove them before the first webrev. So I removed them now too. Thanks for drawing my attention to this as well! :-) Bengt > > hths, > > charlie ... > > On May 29, 2012, at 1:58 AM, Bengt Rutisson wrote: > >> >> Hi again, >> >> I should also have mentioned that this change should not alter the log >> output. (Except for the ParallelGCThreads = 0 case which now will look >> the same as PrallelGCThreads >= 1 case.) >> >> I tested this by leaving the old code in and comparing the output from >> the old code with the new code. In my tests they look exactly the same. >> >> Bengt >> >> On 2012-05-28 22:37, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> Can I have a couple of code reviews for this change? >>> http://cr.openjdk.java.net/~brutisso/7172279/webrev.01/ >>> >>> >>> Background >>> I am preparing a change to remove the special treatment of the single >>> threaded case for G1 PrintGCDetails output. We should be able to use >>> the same code for both ParallelGCThreads = 0 and PrallelGCThreads >= >>> 1. This will hopefully simplify the logging code. >>> >>> In preparation for that change I would like to clean up the >>> TraceGen0Time and TraceGen1Time data gathering code a bit. It is >>> currently kind of difficult to follow the code and there is no clear >>> distinction between the data gathered for these two cases compared to >>> the data gathered for PrintGCDetails output. >>> >>> Here is what I tried to do: >>> >>> - Remove the unnecessary define_num_seq macro and the multiple >>> inheritance of the Summary class. >>> - Replaced the above with two classes, TraceGen0TimeData and >>> TraceGen1TimeData, that will encapsulate the data needed. >>> - Made sure that the data is only updated if the corresponding flags >>> are turned on. >>> - Removed the separate "non-parallel" case. All data is available even >>> with ParallelGCThreads = 0. >>> - Removed the ExitAfterGCNum flag. I hardly think this is an >>> appropriate product flag to have in the code. >>> - Removed some unused methods. >>> - Removed 7 year old assert(true) with accompanying comments. >>> - Removed the unused aux time concept. >>> >>> There was one thing that I was hesitant to remove, but finally decided >>> to remove anyway. It was the G1CollectorPolicy::check_other_times() >>> method. First I added the same method to TraceGen0TimeData. But it is >>> a lot of code and I am not sure it is very useful. It can't do any >>> exact checks and it seems unlikely to me that it will detect any >>> issues. Also, it seems to me like the code was in the wrong place. I >>> would have preferred it in some kind of verify method rather than in a >>> print method. >>> >>> Thanks, >>> Bengt >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chunt at salesforce.com Wed May 30 12:44:01 2012 From: chunt at salesforce.com (Charlie Hunt) Date: Wed, 30 May 2012 05:44:01 -0700 Subject: Request for review (M): 7172279: G1: Clean up TraceGen0Time and TraceGen1Time data gathering In-Reply-To: <4FC61344.7080101@oracle.com> References: <4FC3E1F3.1070906@oracle.com> <4FC4738A.50102@oracle.com> <4FC61344.7080101@oracle.com> Message-ID: <99012D24-F925-458E-B8C4-996C19A73FB0@salesforce.com> I like it. :-) charlie ... On May 30, 2012, at 7:32 AM, Bengt Rutisson wrote: Hi Charlie, Thanks for looking at this! On 2012-05-30 04:41, Charlie Hunt wrote: Nice cleanup Bengt. One observation which I found a bit confusing. In g1CollectorPolicy.cpp, line 2285 - 2287 we have the following code: _last_gc_was_young = gcs_are_young() ? true : false; _trace_gen0_time_data.increment_collection_count(!_last_gc_was_young); The !_last_gc_was_young threw me a bit since we were incrementing the collection count on a "trace gen0". Has there been consideration of using an enumerated type for a young GC and mixed GC type rather than using a boolean to represent the two? Or, alternatively introducing a mutator method for incrementing only _young_pause_num and a second mutator method for incrementing _mixed_pause_num ? Good point. I went with your last suggestion and added separate mutator methods for mixed and young collections. Here is an updated webrev: http://cr.openjdk.java.net/~brutisso/7172279/webrev.02/ I didn't see anything incorrect in the implementation ... just found this bit a little confusing. Actually there was a mistake in the code too. I had moved the young and mixed counters from G1CollectorPolicy to TraceGen0TimeData. But since I wanted to verify my changes I had left the counters in G1CollectorPolicy and I forgot to remove them before the first webrev. So I removed them now too. Thanks for drawing my attention to this as well! :-) Bengt hths, charlie ... On May 29, 2012, at 1:58 AM, Bengt Rutisson wrote: Hi again, I should also have mentioned that this change should not alter the log output. (Except for the ParallelGCThreads = 0 case which now will look the same as PrallelGCThreads >= 1 case.) I tested this by leaving the old code in and comparing the output from the old code with the new code. In my tests they look exactly the same. Bengt On 2012-05-28 22:37, Bengt Rutisson wrote: Hi all, Can I have a couple of code reviews for this change? http://cr.openjdk.java.net/~brutisso/7172279/webrev.01/ Background I am preparing a change to remove the special treatment of the single threaded case for G1 PrintGCDetails output. We should be able to use the same code for both ParallelGCThreads = 0 and PrallelGCThreads >= 1. This will hopefully simplify the logging code. In preparation for that change I would like to clean up the TraceGen0Time and TraceGen1Time data gathering code a bit. It is currently kind of difficult to follow the code and there is no clear distinction between the data gathered for these two cases compared to the data gathered for PrintGCDetails output. Here is what I tried to do: - Remove the unnecessary define_num_seq macro and the multiple inheritance of the Summary class. - Replaced the above with two classes, TraceGen0TimeData and TraceGen1TimeData, that will encapsulate the data needed. - Made sure that the data is only updated if the corresponding flags are turned on. - Removed the separate "non-parallel" case. All data is available even with ParallelGCThreads = 0. - Removed the ExitAfterGCNum flag. I hardly think this is an appropriate product flag to have in the code. - Removed some unused methods. - Removed 7 year old assert(true) with accompanying comments. - Removed the unused aux time concept. There was one thing that I was hesitant to remove, but finally decided to remove anyway. It was the G1CollectorPolicy::check_other_times() method. First I added the same method to TraceGen0TimeData. But it is a lot of code and I am not sure it is very useful. It can't do any exact checks and it seems unlikely to me that it will detect any issues. Also, it seems to me like the code was in the wrong place. I would have preferred it in some kind of verify method rather than in a print method. Thanks, Bengt -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at jku.at Wed May 30 07:27:21 2012 From: thomas.schatzl at jku.at (Thomas Schatzl) Date: Wed, 30 May 2012 09:27:21 +0200 Subject: Turn on UseNUMA by default when prudent In-Reply-To: <4FC529F3.6040502@oracle.com> References: <83C598A8-07DA-4B16-B409-328A326BEA4B@amd.com> <4FC529F3.6040502@oracle.com> Message-ID: <1338362841.13903.481.camel@gremio> Hi all, On Tue, 2012-05-29 at 21:56 +0200, Jesper Wilhelmsson wrote: > Hi Eric, > > As long as this is based on actual data and not just a hunch, I personally > think it is a good idea. I don't know if we have any policies about platform > specific optimizations like this though. > > I have some comments on the code layout and there are a few typos, but I guess > this is still a draft so I won't pick on that right now. > > One thing I wonder though is in os_linux_x86.cpp: > > if (VM_Version::cpu_family() == 0x15 || VM_Version::cpu_family() == 0x10) { > > Is this the only way to identify the proper processor family? It doesn't seem > very future proof. How often would you have to change this code to keep it up > to date with new hardware? just a question, if this is implemented, wouldn't it more prudent to actually check whether the VM process runs on a NUMA machine, and actually has its computing (or memory) resources distributed across several nodes instead of a check for some arbitrary processors and processor identifiers? This would, given that the OS typically provides this information anyway, also immediately support e.g. sparc setups. It also avoids distributing memory when the user explicitly assigned the VM to a single node... >From memory, on solaris above mentioned detection works approximately as follows: - detect the total amount of leaf locality groups (=nodes on Solaris) in the system, e.g. via lgrp_nlgrps() - from the root node (retrieved via lgrp_root()), iterate over its children and leaf lgroups via lgrp_children(). - for each of the leaf lgroups found, check whether there is an active cpu for this process in it using lgrp_cpus(); if so, increment counter Maybe there is a better way to do that though. On Linux, numa_get_run_node_mask() may provide the same information when called during initialization. On Windows, it seems that a combination of GetProcessAffinityMask() and GetNUMAProcessorNode() may be useful. (From a cursory web search for the latter two; not sure about other OSes, but you could simply provide a dummy for those) I'd guess that some of the needed functionality to implement this is already provided by the current Hotspot code base. Ergonomics stuff is typically handled in runtime/arguments.?pp, so it might be a better place as a location for updating globals than putting this detection in some os-specific initialization code. Eg. if (FLAG_IS_DEFAULT(UseNUMA)) { UseNUMA := [maybe some other conditions &&] (os::get_num_active_numa_nodes() > 1); } in e.g. Arguments::set_ergonomics_flags() or similar. Seems a lot nicer than an explicit check for some processor family. Maybe a little more work though. Hth, Thomas From iggy.veresov at gmail.com Wed May 30 18:41:06 2012 From: iggy.veresov at gmail.com (Igor Veresov) Date: Wed, 30 May 2012 11:41:06 -0700 Subject: Turn on UseNUMA by default when prudent In-Reply-To: <1338362841.13903.481.camel@gremio> References: <83C598A8-07DA-4B16-B409-328A326BEA4B@amd.com> <4FC529F3.6040502@oracle.com> <1338362841.13903.481.camel@gremio> Message-ID: <34186718-5415-4606-B942-95E9CF544816@gmail.com> Actually UseNUMA should already do what you want. Even if specified on the command line it will switch itself off if there's only one node present. igor On May 30, 2012, at 12:27 AM, Thomas Schatzl wrote: > Hi all, > > On Tue, 2012-05-29 at 21:56 +0200, Jesper Wilhelmsson wrote: >> Hi Eric, >> >> As long as this is based on actual data and not just a hunch, I personally >> think it is a good idea. I don't know if we have any policies about platform >> specific optimizations like this though. >> >> I have some comments on the code layout and there are a few typos, but I guess >> this is still a draft so I won't pick on that right now. >> >> One thing I wonder though is in os_linux_x86.cpp: >> >> if (VM_Version::cpu_family() == 0x15 || VM_Version::cpu_family() == 0x10) { >> >> Is this the only way to identify the proper processor family? It doesn't seem >> very future proof. How often would you have to change this code to keep it up >> to date with new hardware? > > just a question, if this is implemented, wouldn't it more prudent to > actually check whether the VM process runs on a NUMA machine, and > actually has its computing (or memory) resources distributed across > several nodes instead of a check for some arbitrary processors and > processor identifiers? > > This would, given that the OS typically provides this information > anyway, also immediately support e.g. sparc setups. It also avoids > distributing memory when the user explicitly assigned the VM to a single > node... > >> From memory, on solaris above mentioned detection works approximately as > follows: > > - detect the total amount of leaf locality groups (=nodes on Solaris) > in the system, e.g. via lgrp_nlgrps() > - from the root node (retrieved via lgrp_root()), iterate over its > children and leaf lgroups via lgrp_children(). > - for each of the leaf lgroups found, check whether there is an > active cpu for this process in it using lgrp_cpus(); if so, increment > counter > > Maybe there is a better way to do that though. > > On Linux, numa_get_run_node_mask() may provide the same information when > called during initialization. > On Windows, it seems that a combination of GetProcessAffinityMask() and > GetNUMAProcessorNode() may be useful. > (From a cursory web search for the latter two; not sure about other > OSes, but you could simply provide a dummy for those) > > I'd guess that some of the needed functionality to implement this is > already provided by the current Hotspot code base. > > > Ergonomics stuff is typically handled in runtime/arguments.?pp, so it > might be a better place as a location for updating globals than putting > this detection in some os-specific initialization code. > > Eg. > > if (FLAG_IS_DEFAULT(UseNUMA)) { > UseNUMA := [maybe some other conditions &&] > (os::get_num_active_numa_nodes() > 1); > } > > in e.g. Arguments::set_ergonomics_flags() or similar. > > Seems a lot nicer than an explicit check for some processor family. > Maybe a little more work though. > > Hth, > Thomas > > From jesper.wilhelmsson at oracle.com Wed May 30 20:14:54 2012 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 30 May 2012 22:14:54 +0200 Subject: Turn on UseNUMA by default when prudent In-Reply-To: <34186718-5415-4606-B942-95E9CF544816@gmail.com> References: <83C598A8-07DA-4B16-B409-328A326BEA4B@amd.com> <4FC529F3.6040502@oracle.com> <1338362841.13903.481.camel@gremio> <34186718-5415-4606-B942-95E9CF544816@gmail.com> Message-ID: <4FC67FBE.60309@oracle.com> On 2012-05-30 20:41, Igor Veresov wrote: > Actually UseNUMA should already do what you want. Even if specified on the command line it will switch itself off if there's only one node present. So, will setting UseNUMA to true as default be a platform independent way of solving this? /Jesper > > igor > > On May 30, 2012, at 12:27 AM, Thomas Schatzl wrote: > >> Hi all, >> >> On Tue, 2012-05-29 at 21:56 +0200, Jesper Wilhelmsson wrote: >>> Hi Eric, >>> >>> As long as this is based on actual data and not just a hunch, I personally >>> think it is a good idea. I don't know if we have any policies about platform >>> specific optimizations like this though. >>> >>> I have some comments on the code layout and there are a few typos, but I guess >>> this is still a draft so I won't pick on that right now. >>> >>> One thing I wonder though is in os_linux_x86.cpp: >>> >>> if (VM_Version::cpu_family() == 0x15 || VM_Version::cpu_family() == 0x10) { >>> >>> Is this the only way to identify the proper processor family? It doesn't seem >>> very future proof. How often would you have to change this code to keep it up >>> to date with new hardware? >> just a question, if this is implemented, wouldn't it more prudent to >> actually check whether the VM process runs on a NUMA machine, and >> actually has its computing (or memory) resources distributed across >> several nodes instead of a check for some arbitrary processors and >> processor identifiers? >> >> This would, given that the OS typically provides this information >> anyway, also immediately support e.g. sparc setups. It also avoids >> distributing memory when the user explicitly assigned the VM to a single >> node... >> >>> From memory, on solaris above mentioned detection works approximately as >> follows: >> >> - detect the total amount of leaf locality groups (=nodes on Solaris) >> in the system, e.g. via lgrp_nlgrps() >> - from the root node (retrieved via lgrp_root()), iterate over its >> children and leaf lgroups via lgrp_children(). >> - for each of the leaf lgroups found, check whether there is an >> active cpu for this process in it using lgrp_cpus(); if so, increment >> counter >> >> Maybe there is a better way to do that though. >> >> On Linux, numa_get_run_node_mask() may provide the same information when >> called during initialization. >> On Windows, it seems that a combination of GetProcessAffinityMask() and >> GetNUMAProcessorNode() may be useful. >> (From a cursory web search for the latter two; not sure about other >> OSes, but you could simply provide a dummy for those) >> >> I'd guess that some of the needed functionality to implement this is >> already provided by the current Hotspot code base. >> >> >> Ergonomics stuff is typically handled in runtime/arguments.?pp, so it >> might be a better place as a location for updating globals than putting >> this detection in some os-specific initialization code. >> >> Eg. >> >> if (FLAG_IS_DEFAULT(UseNUMA)) { >> UseNUMA := [maybe some other conditions&&] >> (os::get_num_active_numa_nodes()> 1); >> } >> >> in e.g. Arguments::set_ergonomics_flags() or similar. >> >> Seems a lot nicer than an explicit check for some processor family. >> Maybe a little more work though. >> >> Hth, >> Thomas >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: jesper_wilhelmsson.vcf Type: text/x-vcard Size: 251 bytes Desc: not available URL: From eric.caspole at amd.com Wed May 30 20:31:56 2012 From: eric.caspole at amd.com (Eric Caspole) Date: Wed, 30 May 2012 16:31:56 -0400 Subject: Turn on UseNUMA by default when prudent In-Reply-To: <4FC67FBE.60309@oracle.com> References: <83C598A8-07DA-4B16-B409-328A326BEA4B@amd.com> <4FC529F3.6040502@oracle.com> <1338362841.13903.481.camel@gremio> <34186718-5415-4606-B942-95E9CF544816@gmail.com> <4FC67FBE.60309@oracle.com> Message-ID: I put a much simpler, still linux only rev at http://cr.openjdk.java.net/~ecaspole/numa_default_2/ Simply doing UseNUMA on by default might work but there are so many os/platforms to consider it's more than I can try to test. Eric On May 30, 2012, at 4:14 PM, Jesper Wilhelmsson wrote: > On 2012-05-30 20:41, Igor Veresov wrote: >> Actually UseNUMA should already do what you want. Even if >> specified on the command line it will switch itself off if there's >> only one node present. > > So, will setting UseNUMA to true as default be a platform > independent way of solving this? > /Jesper > >> >> igor >> >> On May 30, 2012, at 12:27 AM, Thomas Schatzl wrote: >> >>> Hi all, >>> >>> On Tue, 2012-05-29 at 21:56 +0200, Jesper Wilhelmsson wrote: >>>> Hi Eric, >>>> >>>> As long as this is based on actual data and not just a hunch, I >>>> personally >>>> think it is a good idea. I don't know if we have any policies >>>> about platform >>>> specific optimizations like this though. >>>> >>>> I have some comments on the code layout and there are a few >>>> typos, but I guess >>>> this is still a draft so I won't pick on that right now. >>>> >>>> One thing I wonder though is in os_linux_x86.cpp: >>>> >>>> if (VM_Version::cpu_family() == 0x15 || VM_Version::cpu_family() >>>> == 0x10) { >>>> >>>> Is this the only way to identify the proper processor family? It >>>> doesn't seem >>>> very future proof. How often would you have to change this code >>>> to keep it up >>>> to date with new hardware? >>> just a question, if this is implemented, wouldn't it more prudent to >>> actually check whether the VM process runs on a NUMA machine, and >>> actually has its computing (or memory) resources distributed across >>> several nodes instead of a check for some arbitrary processors and >>> processor identifiers? >>> >>> This would, given that the OS typically provides this information >>> anyway, also immediately support e.g. sparc setups. It also avoids >>> distributing memory when the user explicitly assigned the VM to a >>> single >>> node... >>> >>>> From memory, on solaris above mentioned detection works >>>> approximately as >>> follows: >>> >>> - detect the total amount of leaf locality groups (=nodes on >>> Solaris) >>> in the system, e.g. via lgrp_nlgrps() >>> - from the root node (retrieved via lgrp_root()), iterate over its >>> children and leaf lgroups via lgrp_children(). >>> - for each of the leaf lgroups found, check whether there is an >>> active cpu for this process in it using lgrp_cpus(); if so, >>> increment >>> counter >>> >>> Maybe there is a better way to do that though. >>> >>> On Linux, numa_get_run_node_mask() may provide the same >>> information when >>> called during initialization. >>> On Windows, it seems that a combination of GetProcessAffinityMask >>> () and >>> GetNUMAProcessorNode() may be useful. >>> (From a cursory web search for the latter two; not sure about other >>> OSes, but you could simply provide a dummy for those) >>> >>> I'd guess that some of the needed functionality to implement this is >>> already provided by the current Hotspot code base. >>> >>> >>> Ergonomics stuff is typically handled in runtime/arguments.?pp, >>> so it >>> might be a better place as a location for updating globals than >>> putting >>> this detection in some os-specific initialization code. >>> >>> Eg. >>> >>> if (FLAG_IS_DEFAULT(UseNUMA)) { >>> UseNUMA := [maybe some other conditions&&] >>> (os::get_num_active_numa_nodes()> 1); >>> } >>> >>> in e.g. Arguments::set_ergonomics_flags() or similar. >>> >>> Seems a lot nicer than an explicit check for some processor family. >>> Maybe a little more work though. >>> >>> Hth, >>> Thomas >>> >>> >>> From vladimir.kozlov at oracle.com Wed May 30 20:58:08 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 May 2012 13:58:08 -0700 Subject: Turn on UseNUMA by default when prudent In-Reply-To: References: <83C598A8-07DA-4B16-B409-328A326BEA4B@amd.com> <4FC529F3.6040502@oracle.com> <1338362841.13903.481.camel@gremio> <34186718-5415-4606-B942-95E9CF544816@gmail.com> <4FC67FBE.60309@oracle.com> Message-ID: <4FC689E0.3090809@oracle.com> We issue a warning only if something is not right which not the case here: + warning("Turned on UseNUMA in os::init_2"); otherwise looks good. Vladimir Eric Caspole wrote: > I put a much simpler, still linux only rev at > > http://cr.openjdk.java.net/~ecaspole/numa_default_2/ > > Simply doing UseNUMA on by default might work but there are so many > os/platforms to consider it's more than I can try to test. > Eric > > > On May 30, 2012, at 4:14 PM, Jesper Wilhelmsson wrote: > >> On 2012-05-30 20:41, Igor Veresov wrote: >>> Actually UseNUMA should already do what you want. Even if specified >>> on the command line it will switch itself off if there's only one >>> node present. >> >> So, will setting UseNUMA to true as default be a platform independent >> way of solving this? >> /Jesper >> >>> >>> igor >>> >>> On May 30, 2012, at 12:27 AM, Thomas Schatzl wrote: >>> >>>> Hi all, >>>> >>>> On Tue, 2012-05-29 at 21:56 +0200, Jesper Wilhelmsson wrote: >>>>> Hi Eric, >>>>> >>>>> As long as this is based on actual data and not just a hunch, I >>>>> personally >>>>> think it is a good idea. I don't know if we have any policies about >>>>> platform >>>>> specific optimizations like this though. >>>>> >>>>> I have some comments on the code layout and there are a few typos, >>>>> but I guess >>>>> this is still a draft so I won't pick on that right now. >>>>> >>>>> One thing I wonder though is in os_linux_x86.cpp: >>>>> >>>>> if (VM_Version::cpu_family() == 0x15 || VM_Version::cpu_family() == >>>>> 0x10) { >>>>> >>>>> Is this the only way to identify the proper processor family? It >>>>> doesn't seem >>>>> very future proof. How often would you have to change this code to >>>>> keep it up >>>>> to date with new hardware? >>>> just a question, if this is implemented, wouldn't it more prudent to >>>> actually check whether the VM process runs on a NUMA machine, and >>>> actually has its computing (or memory) resources distributed across >>>> several nodes instead of a check for some arbitrary processors and >>>> processor identifiers? >>>> >>>> This would, given that the OS typically provides this information >>>> anyway, also immediately support e.g. sparc setups. It also avoids >>>> distributing memory when the user explicitly assigned the VM to a >>>> single >>>> node... >>>> >>>>> From memory, on solaris above mentioned detection works >>>>> approximately as >>>> follows: >>>> >>>> - detect the total amount of leaf locality groups (=nodes on Solaris) >>>> in the system, e.g. via lgrp_nlgrps() >>>> - from the root node (retrieved via lgrp_root()), iterate over its >>>> children and leaf lgroups via lgrp_children(). >>>> - for each of the leaf lgroups found, check whether there is an >>>> active cpu for this process in it using lgrp_cpus(); if so, increment >>>> counter >>>> >>>> Maybe there is a better way to do that though. >>>> >>>> On Linux, numa_get_run_node_mask() may provide the same information >>>> when >>>> called during initialization. >>>> On Windows, it seems that a combination of GetProcessAffinityMask() and >>>> GetNUMAProcessorNode() may be useful. >>>> (From a cursory web search for the latter two; not sure about other >>>> OSes, but you could simply provide a dummy for those) >>>> >>>> I'd guess that some of the needed functionality to implement this is >>>> already provided by the current Hotspot code base. >>>> >>>> >>>> Ergonomics stuff is typically handled in runtime/arguments.?pp, so it >>>> might be a better place as a location for updating globals than putting >>>> this detection in some os-specific initialization code. >>>> >>>> Eg. >>>> >>>> if (FLAG_IS_DEFAULT(UseNUMA)) { >>>> UseNUMA := [maybe some other conditions&&] >>>> (os::get_num_active_numa_nodes()> 1); >>>> } >>>> >>>> in e.g. Arguments::set_ergonomics_flags() or similar. >>>> >>>> Seems a lot nicer than an explicit check for some processor family. >>>> Maybe a little more work though. >>>> >>>> Hth, >>>> Thomas >>>> >>>> >>>> > > From john.cuthbertson at oracle.com Thu May 31 00:16:36 2012 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Thu, 31 May 2012 00:16:36 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7158682: G1: Handle leak when running nsk.sysdict tests Message-ID: <20120531001641.3E5D547635@hg.openjdk.java.net> Changeset: c52a6a39546c Author: johnc Date: 2012-05-30 10:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c52a6a39546c 7158682: G1: Handle leak when running nsk.sysdict tests Summary: Place HandleMarks in the code that allocates handles for the pending list lock so that the handles are freed and multiple, unsuccessful, attempts to schedule a GC do not cause an OOM. Reviewed-by: brutisso ! src/share/vm/oops/instanceRefKlass.cpp From eric.caspole at amd.com Thu May 31 15:05:50 2012 From: eric.caspole at amd.com (Eric Caspole) Date: Thu, 31 May 2012 11:05:50 -0400 Subject: Turn on UseNUMA by default when prudent In-Reply-To: <4FC689E0.3090809@oracle.com> References: <83C598A8-07DA-4B16-B409-328A326BEA4B@amd.com> <4FC529F3.6040502@oracle.com> <1338362841.13903.481.camel@gremio> <34186718-5415-4606-B942-95E9CF544816@gmail.com> <4FC67FBE.60309@oracle.com> <4FC689E0.3090809@oracle.com> Message-ID: OK, I removed the warning, see http://cr.openjdk.java.net/~ecaspole/numa_default_3/ Thanks, Eric On May 30, 2012, at 4:58 PM, Vladimir Kozlov wrote: > We issue a warning only if something is not right which not the > case here: > > + warning("Turned on UseNUMA in os::init_2"); > > otherwise looks good. > > Vladimir > > Eric Caspole wrote: >> I put a much simpler, still linux only rev at >> http://cr.openjdk.java.net/~ecaspole/numa_default_2/ >> Simply doing UseNUMA on by default might work but there are so >> many os/platforms to consider it's more than I can try to test. >> Eric >> On May 30, 2012, at 4:14 PM, Jesper Wilhelmsson wrote: >>> On 2012-05-30 20:41, Igor Veresov wrote: >>>> Actually UseNUMA should already do what you want. Even if >>>> specified on the command line it will switch itself off if >>>> there's only one node present. >>> >>> So, will setting UseNUMA to true as default be a platform >>> independent way of solving this? >>> /Jesper >>> >>>> >>>> igor >>>> >>>> On May 30, 2012, at 12:27 AM, Thomas Schatzl wrote: >>>> >>>>> Hi all, >>>>> >>>>> On Tue, 2012-05-29 at 21:56 +0200, Jesper Wilhelmsson wrote: >>>>>> Hi Eric, >>>>>> >>>>>> As long as this is based on actual data and not just a hunch, >>>>>> I personally >>>>>> think it is a good idea. I don't know if we have any policies >>>>>> about platform >>>>>> specific optimizations like this though. >>>>>> >>>>>> I have some comments on the code layout and there are a few >>>>>> typos, but I guess >>>>>> this is still a draft so I won't pick on that right now. >>>>>> >>>>>> One thing I wonder though is in os_linux_x86.cpp: >>>>>> >>>>>> if (VM_Version::cpu_family() == 0x15 || VM_Version::cpu_family >>>>>> () == 0x10) { >>>>>> >>>>>> Is this the only way to identify the proper processor family? >>>>>> It doesn't seem >>>>>> very future proof. How often would you have to change this >>>>>> code to keep it up >>>>>> to date with new hardware? >>>>> just a question, if this is implemented, wouldn't it more >>>>> prudent to >>>>> actually check whether the VM process runs on a NUMA machine, and >>>>> actually has its computing (or memory) resources distributed >>>>> across >>>>> several nodes instead of a check for some arbitrary processors and >>>>> processor identifiers? >>>>> >>>>> This would, given that the OS typically provides this information >>>>> anyway, also immediately support e.g. sparc setups. It also avoids >>>>> distributing memory when the user explicitly assigned the VM to >>>>> a single >>>>> node... >>>>> >>>>>> From memory, on solaris above mentioned detection works >>>>>> approximately as >>>>> follows: >>>>> >>>>> - detect the total amount of leaf locality groups (=nodes on >>>>> Solaris) >>>>> in the system, e.g. via lgrp_nlgrps() >>>>> - from the root node (retrieved via lgrp_root()), iterate >>>>> over its >>>>> children and leaf lgroups via lgrp_children(). >>>>> - for each of the leaf lgroups found, check whether there >>>>> is an >>>>> active cpu for this process in it using lgrp_cpus(); if so, >>>>> increment >>>>> counter >>>>> >>>>> Maybe there is a better way to do that though. >>>>> >>>>> On Linux, numa_get_run_node_mask() may provide the same >>>>> information when >>>>> called during initialization. >>>>> On Windows, it seems that a combination of >>>>> GetProcessAffinityMask() and >>>>> GetNUMAProcessorNode() may be useful. >>>>> (From a cursory web search for the latter two; not sure about >>>>> other >>>>> OSes, but you could simply provide a dummy for those) >>>>> >>>>> I'd guess that some of the needed functionality to implement >>>>> this is >>>>> already provided by the current Hotspot code base. >>>>> >>>>> >>>>> Ergonomics stuff is typically handled in runtime/arguments.?pp, >>>>> so it >>>>> might be a better place as a location for updating globals than >>>>> putting >>>>> this detection in some os-specific initialization code. >>>>> >>>>> Eg. >>>>> >>>>> if (FLAG_IS_DEFAULT(UseNUMA)) { >>>>> UseNUMA := [maybe some other conditions&&] >>>>> (os::get_num_active_numa_nodes()> 1); >>>>> } >>>>> >>>>> in e.g. Arguments::set_ergonomics_flags() or similar. >>>>> >>>>> Seems a lot nicer than an explicit check for some processor >>>>> family. >>>>> Maybe a little more work though. >>>>> >>>>> Hth, >>>>> Thomas >>>>> >>>>> >>>>> > From john.cuthbertson at oracle.com Thu May 31 16:42:04 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 31 May 2012 09:42:04 -0700 Subject: Request for review (M): 7172279: G1: Clean up TraceGen0Time and TraceGen1Time data gathering In-Reply-To: <4FC61344.7080101@oracle.com> References: <4FC3E1F3.1070906@oracle.com> <4FC4738A.50102@oracle.com> <4FC61344.7080101@oracle.com> Message-ID: <4FC79F5C.60805@oracle.com> Hi Bengt, I think this looks really good. Great clean up. One suggestion (but it's completely optional): * Could you add a comment saying that TraceGen0Time actually collects data on _both_ young and mixed evacuation pauses (the latter may contain non-young regions - i.e. regions that are technically in Gen1) while TraceGen1Time collects data about full GCs? JohnC On 05/30/12 05:32, Bengt Rutisson wrote: > > Hi Charlie, > > Thanks for looking at this! > > On 2012-05-30 04:41, Charlie Hunt wrote: >> Nice cleanup Bengt. >> >> One observation which I found a bit confusing. >> >> In g1CollectorPolicy.cpp, line 2285 - 2287 we have the following code: >> _last_gc_was_young = gcs_are_young() ? true : false; >> _trace_gen0_time_data.increment_collection_count(!_last_gc_was_young); >> The !_last_gc_was_young threw me a bit since we were incrementing the >> collection count on a "trace gen0". Has there been consideration of >> using an enumerated type for a young GC and mixed GC type rather than >> using a boolean to represent the two? Or, alternatively introducing >> a mutator method for incrementing only _young_pause_num and a second >> mutator method for incrementing _mixed_pause_num ? > > Good point. I went with your last suggestion and added separate > mutator methods for mixed and young collections. Here is an updated > webrev: > > http://cr.openjdk.java.net/~brutisso/7172279/webrev.02/ > >> >> I didn't see anything incorrect in the implementation ... just found >> this bit a little confusing. > > Actually there was a mistake in the code too. I had moved the young > and mixed counters from G1CollectorPolicy to TraceGen0TimeData. But > since I wanted to verify my changes I had left the counters in > G1CollectorPolicy and I forgot to remove them before the first webrev. > So I removed them now too. > > Thanks for drawing my attention to this as well! :-) > Bengt > > > >> >> hths, >> >> charlie ... >> >> On May 29, 2012, at 1:58 AM, Bengt Rutisson wrote: >> >>> >>> Hi again, >>> >>> I should also have mentioned that this change should not alter the log >>> output. (Except for the ParallelGCThreads = 0 case which now will look >>> the same as PrallelGCThreads >= 1 case.) >>> >>> I tested this by leaving the old code in and comparing the output from >>> the old code with the new code. In my tests they look exactly the same. >>> >>> Bengt >>> >>> On 2012-05-28 22:37, Bengt Rutisson wrote: >>>> >>>> Hi all, >>>> >>>> Can I have a couple of code reviews for this change? >>>> http://cr.openjdk.java.net/~brutisso/7172279/webrev.01/ >>>> >>>> >>>> Background >>>> I am preparing a change to remove the special treatment of the single >>>> threaded case for G1 PrintGCDetails output. We should be able to use >>>> the same code for both ParallelGCThreads = 0 and PrallelGCThreads >= >>>> 1. This will hopefully simplify the logging code. >>>> >>>> In preparation for that change I would like to clean up the >>>> TraceGen0Time and TraceGen1Time data gathering code a bit. It is >>>> currently kind of difficult to follow the code and there is no clear >>>> distinction between the data gathered for these two cases compared to >>>> the data gathered for PrintGCDetails output. >>>> >>>> Here is what I tried to do: >>>> >>>> - Remove the unnecessary define_num_seq macro and the multiple >>>> inheritance of the Summary class. >>>> - Replaced the above with two classes, TraceGen0TimeData and >>>> TraceGen1TimeData, that will encapsulate the data needed. >>>> - Made sure that the data is only updated if the corresponding flags >>>> are turned on. >>>> - Removed the separate "non-parallel" case. All data is available even >>>> with ParallelGCThreads = 0. >>>> - Removed the ExitAfterGCNum flag. I hardly think this is an >>>> appropriate product flag to have in the code. >>>> - Removed some unused methods. >>>> - Removed 7 year old assert(true) with accompanying comments. >>>> - Removed the unused aux time concept. >>>> >>>> There was one thing that I was hesitant to remove, but finally decided >>>> to remove anyway. It was the G1CollectorPolicy::check_other_times() >>>> method. First I added the same method to TraceGen0TimeData. But it is >>>> a lot of code and I am not sure it is very useful. It can't do any >>>> exact checks and it seems unlikely to me that it will detect any >>>> issues. Also, it seems to me like the code was in the wrong place. I >>>> would have preferred it in some kind of verify method rather than in a >>>> print method. >>>> >>>> Thanks, >>>> Bengt >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Thu May 31 19:21:18 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 31 May 2012 21:21:18 +0200 Subject: Request for review (M): 7172279: G1: Clean up TraceGen0Time and TraceGen1Time data gathering In-Reply-To: <4FC79F5C.60805@oracle.com> References: <4FC3E1F3.1070906@oracle.com> <4FC4738A.50102@oracle.com> <4FC61344.7080101@oracle.com> <4FC79F5C.60805@oracle.com> Message-ID: <4FC7C4AE.4030005@oracle.com> Hi John, Thanks for reviewing this! On 2012-05-31 18:42, John Cuthbertson wrote: > Hi Bengt, > > I think this looks really good. Great clean up. > > One suggestion (but it's completely optional): > > * Could you add a comment saying that TraceGen0Time actually collects > data on _both_ young and mixed evacuation pauses (the latter may > contain non-young regions - i.e. regions that are technically in Gen1) > while TraceGen1Time collects data about full GCs? Good idea! I added this comment to the TraceGen0TimeData class: // TraceGen0Time collects data on _both_ young and mixed evacuation pauses // (the latter may contain non-young regions - i.e. regions that are // technically in Gen1) while TraceGen1Time collects data about full GCs. class TraceGen0TimeData : public CHeapObj { All set to push this now. Thanks again for the review! Bengt > > JohnC > > On 05/30/12 05:32, Bengt Rutisson wrote: >> >> Hi Charlie, >> >> Thanks for looking at this! >> >> On 2012-05-30 04:41, Charlie Hunt wrote: >>> Nice cleanup Bengt. >>> >>> One observation which I found a bit confusing. >>> >>> In g1CollectorPolicy.cpp, line 2285 - 2287 we have the following code: >>> _last_gc_was_young = gcs_are_young() ? true : false; >>> _trace_gen0_time_data.increment_collection_count(!_last_gc_was_young); >>> The !_last_gc_was_young threw me a bit since we were incrementing >>> the collection count on a "trace gen0". Has there been >>> consideration of using an enumerated type for a young GC and mixed >>> GC type rather than using a boolean to represent the two? Or, >>> alternatively introducing a mutator method for incrementing only >>> _young_pause_num and a second mutator method for incrementing >>> _mixed_pause_num ? >> >> Good point. I went with your last suggestion and added separate >> mutator methods for mixed and young collections. Here is an updated >> webrev: >> >> http://cr.openjdk.java.net/~brutisso/7172279/webrev.02/ >> >>> >>> I didn't see anything incorrect in the implementation ... just found >>> this bit a little confusing. >> >> Actually there was a mistake in the code too. I had moved the young >> and mixed counters from G1CollectorPolicy to TraceGen0TimeData. But >> since I wanted to verify my changes I had left the counters in >> G1CollectorPolicy and I forgot to remove them before the first >> webrev. So I removed them now too. >> >> Thanks for drawing my attention to this as well! :-) >> Bengt >> >> >> >>> >>> hths, >>> >>> charlie ... >>> >>> On May 29, 2012, at 1:58 AM, Bengt Rutisson wrote: >>> >>>> >>>> Hi again, >>>> >>>> I should also have mentioned that this change should not alter the log >>>> output. (Except for the ParallelGCThreads = 0 case which now will look >>>> the same as PrallelGCThreads >= 1 case.) >>>> >>>> I tested this by leaving the old code in and comparing the output from >>>> the old code with the new code. In my tests they look exactly the same. >>>> >>>> Bengt >>>> >>>> On 2012-05-28 22:37, Bengt Rutisson wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Can I have a couple of code reviews for this change? >>>>> http://cr.openjdk.java.net/~brutisso/7172279/webrev.01/ >>>>> >>>>> >>>>> Background >>>>> I am preparing a change to remove the special treatment of the single >>>>> threaded case for G1 PrintGCDetails output. We should be able to use >>>>> the same code for both ParallelGCThreads = 0 and PrallelGCThreads >= >>>>> 1. This will hopefully simplify the logging code. >>>>> >>>>> In preparation for that change I would like to clean up the >>>>> TraceGen0Time and TraceGen1Time data gathering code a bit. It is >>>>> currently kind of difficult to follow the code and there is no clear >>>>> distinction between the data gathered for these two cases compared to >>>>> the data gathered for PrintGCDetails output. >>>>> >>>>> Here is what I tried to do: >>>>> >>>>> - Remove the unnecessary define_num_seq macro and the multiple >>>>> inheritance of the Summary class. >>>>> - Replaced the above with two classes, TraceGen0TimeData and >>>>> TraceGen1TimeData, that will encapsulate the data needed. >>>>> - Made sure that the data is only updated if the corresponding flags >>>>> are turned on. >>>>> - Removed the separate "non-parallel" case. All data is available >>>>> even >>>>> with ParallelGCThreads = 0. >>>>> - Removed the ExitAfterGCNum flag. I hardly think this is an >>>>> appropriate product flag to have in the code. >>>>> - Removed some unused methods. >>>>> - Removed 7 year old assert(true) with accompanying comments. >>>>> - Removed the unused aux time concept. >>>>> >>>>> There was one thing that I was hesitant to remove, but finally >>>>> decided >>>>> to remove anyway. It was the G1CollectorPolicy::check_other_times() >>>>> method. First I added the same method to TraceGen0TimeData. But it is >>>>> a lot of code and I am not sure it is very useful. It can't do any >>>>> exact checks and it seems unlikely to me that it will detect any >>>>> issues. Also, it seems to me like the code was in the wrong place. I >>>>> would have preferred it in some kind of verify method rather than >>>>> in a >>>>> print method. >>>>> >>>>> Thanks, >>>>> Bengt >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Thu May 31 19:21:53 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 31 May 2012 21:21:53 +0200 Subject: Request for review (M): 7172279: G1: Clean up TraceGen0Time and TraceGen1Time data gathering In-Reply-To: <99012D24-F925-458E-B8C4-996C19A73FB0@salesforce.com> References: <4FC3E1F3.1070906@oracle.com> <4FC4738A.50102@oracle.com> <4FC61344.7080101@oracle.com> <99012D24-F925-458E-B8C4-996C19A73FB0@salesforce.com> Message-ID: <4FC7C4D1.9080008@oracle.com> On 2012-05-30 14:44, Charlie Hunt wrote: > I like it. :-) Thanks, Charlie! Bengt > > charlie ... > > On May 30, 2012, at 7:32 AM, Bengt Rutisson wrote: > >> >> Hi Charlie, >> >> Thanks for looking at this! >> >> On 2012-05-30 04:41, Charlie Hunt wrote: >>> Nice cleanup Bengt. >>> >>> One observation which I found a bit confusing. >>> >>> In g1CollectorPolicy.cpp, line 2285 - 2287 we have the following code: >>> _last_gc_was_young = gcs_are_young() ? true : false; >>> _trace_gen0_time_data.increment_collection_count(!_last_gc_was_young); >>> The !_last_gc_was_young threw me a bit since we were incrementing >>> the collection count on a "trace gen0". Has there been >>> consideration of using an enumerated type for a young GC and mixed >>> GC type rather than using a boolean to represent the two? Or, >>> alternatively introducing a mutator method for incrementing only >>> _young_pause_num and a second mutator method for incrementing >>> _mixed_pause_num ? >> >> Good point. I went with your last suggestion and added separate >> mutator methods for mixed and young collections. Here is an updated >> webrev: >> >> http://cr.openjdk.java.net/~brutisso/7172279/webrev.02/ >> >>> >>> I didn't see anything incorrect in the implementation ... just found >>> this bit a little confusing. >> >> Actually there was a mistake in the code too. I had moved the young >> and mixed counters from G1CollectorPolicy to TraceGen0TimeData. But >> since I wanted to verify my changes I had left the counters in >> G1CollectorPolicy and I forgot to remove them before the first >> webrev. So I removed them now too. >> >> Thanks for drawing my attention to this as well! :-) >> Bengt >> >> >> >>> >>> hths, >>> >>> charlie ... >>> >>> On May 29, 2012, at 1:58 AM, Bengt Rutisson wrote: >>> >>>> >>>> Hi again, >>>> >>>> I should also have mentioned that this change should not alter the log >>>> output. (Except for the ParallelGCThreads = 0 case which now will look >>>> the same as PrallelGCThreads >= 1 case.) >>>> >>>> I tested this by leaving the old code in and comparing the output from >>>> the old code with the new code. In my tests they look exactly the same. >>>> >>>> Bengt >>>> >>>> On 2012-05-28 22:37, Bengt Rutisson wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Can I have a couple of code reviews for this change? >>>>> http://cr.openjdk.java.net/~brutisso/7172279/webrev.01/ >>>>> >>>>> >>>>> Background >>>>> I am preparing a change to remove the special treatment of the single >>>>> threaded case for G1 PrintGCDetails output. We should be able to use >>>>> the same code for both ParallelGCThreads = 0 and PrallelGCThreads >= >>>>> 1. This will hopefully simplify the logging code. >>>>> >>>>> In preparation for that change I would like to clean up the >>>>> TraceGen0Time and TraceGen1Time data gathering code a bit. It is >>>>> currently kind of difficult to follow the code and there is no clear >>>>> distinction between the data gathered for these two cases compared to >>>>> the data gathered for PrintGCDetails output. >>>>> >>>>> Here is what I tried to do: >>>>> >>>>> - Remove the unnecessary define_num_seq macro and the multiple >>>>> inheritance of the Summary class. >>>>> - Replaced the above with two classes, TraceGen0TimeData and >>>>> TraceGen1TimeData, that will encapsulate the data needed. >>>>> - Made sure that the data is only updated if the corresponding flags >>>>> are turned on. >>>>> - Removed the separate "non-parallel" case. All data is available >>>>> even >>>>> with ParallelGCThreads = 0. >>>>> - Removed the ExitAfterGCNum flag. I hardly think this is an >>>>> appropriate product flag to have in the code. >>>>> - Removed some unused methods. >>>>> - Removed 7 year old assert(true) with accompanying comments. >>>>> - Removed the unused aux time concept. >>>>> >>>>> There was one thing that I was hesitant to remove, but finally >>>>> decided >>>>> to remove anyway. It was the G1CollectorPolicy::check_other_times() >>>>> method. First I added the same method to TraceGen0TimeData. But it is >>>>> a lot of code and I am not sure it is very useful. It can't do any >>>>> exact checks and it seems unlikely to me that it will detect any >>>>> issues. Also, it seems to me like the code was in the wrong place. I >>>>> would have preferred it in some kind of verify method rather than >>>>> in a >>>>> print method. >>>>> >>>>> Thanks, >>>>> Bengt >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Thu May 31 20:04:17 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 31 May 2012 22:04:17 +0200 Subject: Request for review (XXS): 7067973: test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java hanging intermittently Message-ID: <4FC7CEC1.8060308@oracle.com> Hi all, Can I have a couple of reviews for this really small change? http://cr.openjdk.java.net/~brutisso/7067973/webrev.00/ Background: The CollectionUsageThreshold test fails with G1. The test lowers the notification threshold for the G1 old gen memory pool and expects to get a notification after a full GC. The problem in G1 is that the decision to send the notification is done in TraceMemoryManagerStats::~TraceMemoryManagerStats(). This eventually does pool->get_memory_usage() to get the memory usage after a collection. The problem is that we update this information in G1MonitoringSupport::update_sizes() which is called in G1CollectedHeap::do_collection() _after_ the TraceMemoryManagerStats scope had been exited. Extending the scope to cover the call to G1MonitoringSupport::update_sizes() solves the issue. Testing: Before this change the CollectionUsageThreshold failed every time I ran it. After this change it passes every time I ran it. Thanks, Bengt From bengt.rutisson at oracle.com Thu May 31 22:45:48 2012 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Thu, 31 May 2012 22:45:48 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7172279: G1: Clean up TraceGen0Time and TraceGen1Time data gathering Message-ID: <20120531224552.A763447670@hg.openjdk.java.net> Changeset: bbc900c2482a Author: brutisso Date: 2012-05-31 21:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bbc900c2482a 7172279: G1: Clean up TraceGen0Time and TraceGen1Time data gathering Summary: Simplify code, remove unused code, remove ExitAfterGCNum Reviewed-by: huntch, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/numberSeq.cpp ! src/share/vm/utilities/numberSeq.hpp From thomas.schatzl at jku.at Wed May 30 20:14:09 2012 From: thomas.schatzl at jku.at (Thomas Schatzl) Date: Wed, 30 May 2012 22:14:09 +0200 Subject: Turn on UseNUMA by default when prudent In-Reply-To: <34186718-5415-4606-B942-95E9CF544816@gmail.com> References: <83C598A8-07DA-4B16-B409-328A326BEA4B@amd.com> <4FC529F3.6040502@oracle.com> <1338362841.13903.481.camel@gremio> <34186718-5415-4606-B942-95E9CF544816@gmail.com> Message-ID: <1338408849.28001.53.camel@gremio> Hi, On Wed, 2012-05-30 at 11:41 -0700, Igor Veresov wrote: > Actually UseNUMA should already do what you want. Even if specified on the > command line it will switch itself off if there's only one node > present. This is another way of doing that, i.e. always enabling UseNUMA anyway in some way. I have one question about this: UseNUMA is not disabled if I assign the VM process to cpus of only one node in a NUMA system. Is this intentional? Sure, this process may benefit from using memory from other nodes still (e.g. before going out-of-memory), but is it a good idea to do an madvise(MADV_ADVISE_MANY)/interleave memory across nodes in this situation by default? So the recommended VM options would probably leave UseNUMA intentionally off in that case? I do not know if there is a way to restrict node memory resources of a process... Thomas