From stefan.johansson at oracle.com Wed Jun 1 07:06:48 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 1 Jun 2016 09:06:48 +0200 Subject: RFR: 8152239: hotspot/test/gc/TestSmallHeap.java failed in jdk9 Message-ID: <574E8988.1030601@oracle.com> Hi, Please review this test fix for: https://bugs.openjdk.java.net/browse/JDK-8152239 Webrev: http://cr.openjdk.java.net/~sjohanss/8152239/hotspot.00/ Summary: The test has been excluded since it fails with an OOME. With Jigsaw and indify string concatenation turned on, the test ended up allocating to much and hit the OOME. I've re-written the test to do as little as possible in the VM with the small heap, instead the driver VM verifies that the sizes are correct. As before, the test verifies that the MaxHeapSize flag is set as expected, but I also added a check on the actual heap size to make sure it is below this limit. Testing: * RBT with the new version of the test. Thanks, Stefan From mikael.gerdin at oracle.com Wed Jun 1 07:57:13 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 1 Jun 2016 09:57:13 +0200 Subject: RFR: 8152239: hotspot/test/gc/TestSmallHeap.java failed in jdk9 In-Reply-To: <574E8988.1030601@oracle.com> References: <574E8988.1030601@oracle.com> Message-ID: <574E9559.2090707@oracle.com> Hi Stefan, On 2016-06-01 09:06, Stefan Johansson wrote: > Hi, > > Please review this test fix for: > https://bugs.openjdk.java.net/browse/JDK-8152239 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8152239/hotspot.00/ Looks good. /Mikael > > Summary: > The test has been excluded since it fails with an OOME. With Jigsaw and > indify string concatenation turned on, the test ended up allocating to > much and hit the OOME. I've re-written the test to do as little as > possible in the VM with the small heap, instead the driver VM verifies > that the sizes are correct. As before, the test verifies that the > MaxHeapSize flag is set as expected, but I also added a check on the > actual heap size to make sure it is below this limit. > > Testing: > * RBT with the new version of the test. > > Thanks, > Stefan From dmitry.fazunenko at oracle.com Wed Jun 1 08:02:50 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 1 Jun 2016 11:02:50 +0300 Subject: RFR: 8152239: hotspot/test/gc/TestSmallHeap.java failed in jdk9 In-Reply-To: <574E8988.1030601@oracle.com> References: <574E8988.1030601@oracle.com> Message-ID: Stefan, New version of the test looks very good! Thanks, Dima On 01.06.2016 10:06, Stefan Johansson wrote: > Hi, > > Please review this test fix for: > https://bugs.openjdk.java.net/browse/JDK-8152239 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8152239/hotspot.00/ > > Summary: > The test has been excluded since it fails with an OOME. With Jigsaw > and indify string concatenation turned on, the test ended up > allocating to much and hit the OOME. I've re-written the test to do as > little as possible in the VM with the small heap, instead the driver > VM verifies that the sizes are correct. As before, the test verifies > that the MaxHeapSize flag is set as expected, but I also added a check > on the actual heap size to make sure it is below this limit. > > Testing: > * RBT with the new version of the test. > > Thanks, > Stefan From stefan.johansson at oracle.com Wed Jun 1 13:59:19 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 1 Jun 2016 15:59:19 +0200 Subject: RFR: 8152239: hotspot/test/gc/TestSmallHeap.java failed in jdk9 In-Reply-To: References: <574E8988.1030601@oracle.com> Message-ID: <574EEA37.3070605@oracle.com> Thanks for the reviews Mikael and Dima, Stefan On 2016-06-01 10:02, Dmitry Fazunenko wrote: > Stefan, > > New version of the test looks very good! > > Thanks, > Dima > > On 01.06.2016 10:06, Stefan Johansson wrote: >> Hi, >> >> Please review this test fix for: >> https://bugs.openjdk.java.net/browse/JDK-8152239 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8152239/hotspot.00/ >> >> Summary: >> The test has been excluded since it fails with an OOME. With Jigsaw >> and indify string concatenation turned on, the test ended up >> allocating to much and hit the OOME. I've re-written the test to do >> as little as possible in the VM with the small heap, instead the >> driver VM verifies that the sizes are correct. As before, the test >> verifies that the MaxHeapSize flag is set as expected, but I also >> added a check on the actual heap size to make sure it is below this >> limit. >> >> Testing: >> * RBT with the new version of the test. >> >> Thanks, >> Stefan > From michail.chernov at oracle.com Wed Jun 1 14:03:37 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Wed, 1 Jun 2016 17:03:37 +0300 Subject: RFR: 8152239: hotspot/test/gc/TestSmallHeap.java failed in jdk9 In-Reply-To: <574E8988.1030601@oracle.com> References: <574E8988.1030601@oracle.com> Message-ID: <574EEB39.2010804@oracle.com> Hi Stefan, Looks good to me. Could you please update the copyrights before pushing (no additional review is needed). Thanks Michail On 06/01/2016 10:06 AM, Stefan Johansson wrote: > Hi, > > Please review this test fix for: > https://bugs.openjdk.java.net/browse/JDK-8152239 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8152239/hotspot.00/ > > Summary: > The test has been excluded since it fails with an OOME. With Jigsaw > and indify string concatenation turned on, the test ended up > allocating to much and hit the OOME. I've re-written the test to do as > little as possible in the VM with the small heap, instead the driver > VM verifies that the sizes are correct. As before, the test verifies > that the MaxHeapSize flag is set as expected, but I also added a check > on the actual heap size to make sure it is below this limit. > > Testing: > * RBT with the new version of the test. > > Thanks, > Stefan > From kim.barrett at oracle.com Wed Jun 1 21:28:41 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 1 Jun 2016 17:28:41 -0400 Subject: RFR: 8149128: Add tests for G1MMUTracker In-Reply-To: <20160524150958.GA23701@ehelin.jrpg.bea.com> References: <20160524150958.GA23701@ehelin.jrpg.bea.com> Message-ID: > On May 24, 2016, at 11:09 AM, Erik Helin wrote: > > Hi all, > > we have a new shiny unit test framework so I figured I would take it for > a spin. I added some new tests for G1MMUTracker, see below. If you want > to try out the new test runner, just apply the patch, then: > > $ make test-hotspot-gtest > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8149128 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8149128/00/ > > Testing: > - JPRT > - Running locally on Linux x86-64 > > Thanks, > Erik > > PS. I don't really how if the feature complete applies to tests? ------------------------------------------------------------------------------ I find it quite confusing to have a class called ms that constructs from a millisecond time, but implicitly converts to double seconds. ------------------------------------------------------------------------------ The following (convenience) functions are untested. when_max_gc_sec when_max_gc_ms when_ms ------------------------------------------------------------------------------ From jesper.wilhelmsson at oracle.com Thu Jun 2 13:23:42 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 2 Jun 2016 15:23:42 +0200 Subject: RFR: JDK-8114823 - G1 doesn't honor request to disable class unloading In-Reply-To: <57277672.7030709@oracle.com> References: <56FD2B4F.9040806@oracle.com> <105bcd03-ccb4-b89b-4237-7d1abd3f8248@oracle.com> <57277672.7030709@oracle.com> Message-ID: Hi, I finally got back to looking at this. The last change had an issue as noted by Derek below, and by StefanK offline, we didn't handle nmethod scanning in the same way in the different collectors. Both approaches are most likely OK, but we should use the same approach in all GCs. The way we did it in G1, to treat all nmethods as strong roots, is the way we chose to implement right now. This is a safer/smaller step than to perform nmethod unloading even though class unloading is disabled. In the future we may want to perform nmethod unloading as is done in the other approach, but this should be done in a separate change. A new webrev is available here: http://cr.openjdk.java.net/~jwilhelm/8114823/webrev.03/ I have run this through JPRT and GCBasher with all collectors and ClassUnloading set to false. It seems to hold together. Thanks, /Jesper Den 2/5/16 kl. 17:46, skrev Derek White: > Hi Jesper, > > On 5/2/16 11:22 AM, Jesper Wilhelmsson wrote: >> Hi, >> >> A new version of the patch is now available: >> >> http://cr.openjdk.java.net/~jwilhelm/8114823/webrev.02/ >> >> Based on comments from Mikael, Derek, and Stefan K I have made the following >> changes: >> >> * CMSClassUnloadingEnabled is removed for real and made an alias of >> ClassUnloadingWithConcurrentMark. This removes the questionable code when >> initializing the flags. >> >> * A new call to unload nmethods if class unloading is disabled in psMarkSweep, >> psParallelCompact, and genMarkSweep. It turned out that in some cases the call >> to unload nmethods is needed even if we do not perform class unloading. > My only question is why don't we need to do that for G1 also? We used to, but > change at g1MarkSweep.cpp:Line 165 means we don't anymore? > > The rest looks good to me. > > - Derek >> >> Thanks, >> /Jesper >> >> >> Den 31/3/16 kl. 15:51, skrev Jesper Wilhelmsson: >>> Hi, >>> >>> Please review this change to make the GCs disable class unloading if disabled on >>> the command line. >>> >>> There are a few parts in this change: >>> >>> 1. The flag ClassUnloadingWithConcurrentMark was not set to false if >>> ClassUnloading was disabled on the command line. This is now done. >>> >>> 2. CMS was using CMSClassUnloadingEnabled instead of the more generic >>> ClassUnloadingWithConcurrentMark. I changed so that >>> ClassUnloadingWithConcurrentMark is used all over and CMSClassUnloadingEnabled >>> is only used as an alias when initializing the arguments. At some point it would >>> be nice to deprecate CMSClassUnloadingEnabled but it is a fairly well known flag >>> so that's not part of this change. >>> >>> 3. CMS, Serial, and PS did correctly disable class unloading when told so, but >>> the outermost code witch included some logging was still enabled making class >>> unloading output present in the log file. I changed so that this code is also >>> disabled. >>> >>> 4. G1 did not disable class unloading during full GCs at all. This is now done. >>> >>> Testing: I used SecureDBBTest.java as suggested in the bug while fixing to >>> verify that class unloading was happening before the fix and not after. I also >>> ran it through JPRT. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8114823 >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8114823/webrev.00/ >>> >>> Thanks, >>> /Jesper > From yasuenag at gmail.com Thu Jun 2 13:36:27 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 2 Jun 2016 22:36:27 +0900 Subject: PING: RFR: JDK-8155730: HeapInfoDCmd should get Heap_lock In-Reply-To: <7881a764-1ac2-116e-da54-e57e043a930f@gmail.com> References: <955b8a22-d35c-60dc-e202-991b5a5e432d@gmail.com> <5583e9c0-8f16-72d0-ee55-a30246ab5bc8@oracle.com> <0b5bbf95-c871-f504-d96c-a08ae5277240@gmail.com> <0fccf86b-5ba8-cb3c-f253-d56cc7d1684d@oracle.com> <90b138a9-f67e-4141-fa63-71942c30e91d@gmail.com> <73d13ea4-7d0a-8bb5-6dea-be6c22d08066@oracle.com> <7881a764-1ac2-116e-da54-e57e043a930f@gmail.com> Message-ID: <4ffc0582-f2c0-4724-f21e-2a6510c4da95@gmail.com> PING: Could you review it? >> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ Yasumasa On 2016/05/17 19:19, Yasumasa Suenaga wrote: > PING: Could you review it? > I need review from GC folks. > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ > > > Thanks, > > Yasumasa > > > On 2016/05/10 22:25, Yasumasa Suenaga wrote: >> On 2016/05/10 16:48, David Holmes wrote: >>> On 9/05/2016 10:34 PM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>>> Taking locks during VMError handling is problematic - we're executing >>>>> from a signal handler and the VM is crashing. Much of what we do from >>>>> VMError is "best effort". >>>> >>>> I will remove MutexLocker from VMError::report(). >>>> But I added assert_locked_or_safepoint(Heap_lock) in each CollectedHeap. >>>> If we remove Heap_lock from VMError::report(), fastdebug HotSpot is failed >>>> when it prints heap info to hs_err log. >>>> Should I remove assert_locked_or_safepoint()? >>> >>> Yes I think you need to do this. >> >> I removed them in new webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ >> >>>> VMError::print_vm_info() calls from VMInfoDCmd::execute() only. >>>> So I think we should take Heap_lock at this function. >>>> Or should we take Heap_lock at VMInfoDCmd::execute() ? >>> >>> If this is called from a DCmd only then I think the lock can be taken in print_vm_info(). >> >> I grep'ed HotSpot source, print_vm_info() is called from DCmd only. >> >>> Need GC folk to add their weight here. >> >> I'm waiting reviewer from GC folks :-) >> >> >> Thanks, >> >> Yasumasa >> >> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/05/09 21:26, David Holmes wrote: >>>>> On 9/05/2016 10:20 PM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> I've sent review request for JDK-8155730. >>>>>> However, I found caller of Universe::heap()->print_*() in vmError.cpp . >>>>>> Thus I added MutexLocker(Ex) for Heap_lock to VMError::report() and >>>>>> VMError::print_vm_info(). >>>>> >>>>> Taking locks during VMError handling is problematic - we're executing >>>>> from a signal handler and the VM is crashing. Much of what we do from >>>>> VMError is "best effort". >>>>> >>>>> David >>>>> >>>>>> Could you review again? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.01/ >>>>>> >>>>>> >>>>>>> This needs to be reviewed by the GC folk not runtime. Please direct >>>>>>> followups to hotspot-gc-dev. >>>>>> >>>>>> Thanks, David! >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/05/06 13:11, David Holmes wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> This needs to be reviewed by the GC folk not runtime. Please direct >>>>>>> followups to hotspot-gc-dev. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 30/04/2016 12:05 AM, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> This review request is related to [1]. >>>>>>>> >>>>>>>> HeapInfoDCmd calls CollectedHeap::print_on(). >>>>>>>> However, its call does not get Heap_lock. >>>>>>>> >>>>>>>> Heap_lock should be gotten from all heap operations. >>>>>>>> >>>>>>>> I uploaded webrev for this issue. >>>>>>>> Could you review it? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.00/ >>>>>>>> >>>>>>>> I cannot access JPRT. >>>>>>>> So I need a sponsor. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019257.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From jon.masamitsu at oracle.com Fri Jun 3 21:04:51 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 3 Jun 2016 14:04:51 -0700 Subject: Request for Review (s) - 8157620: Guarantee in run_task(task, num_workers) fails Message-ID: https://bugs.openjdk.java.net/browse/JDK-8157620 A phase of a G1 collection chooses its own number of GC workers but doesn't add more workers if more are needed than have been created. Add additional workers as needed. Also changed the guarantee to check the number of workers against the total number of workers since the number of GC workers used to execute the task may be different than active_workers (as in this case). Added an execution of TestGCOld with parameters that evoked the failure. http://cr.openjdk.java.net/~jmasa/8157620/webrev.00/ Tested fix with TestGCOld. Stability tested with gc_test_suite Thanks. Jon From kishor.kharbas at intel.com Sat Jun 4 01:45:45 2016 From: kishor.kharbas at intel.com (Kharbas, Kishor) Date: Sat, 4 Jun 2016 01:45:45 +0000 Subject: Supporting allocation of Java object heap on NV-DIMMS In-Reply-To: References: <570251D5.8090402@oracle.com> <570E31E9.1080706@oracle.com> Message-ID: Hello all, I have an update to the patch, adding support for Windows. It uses the Windows APIs described in https://channel9.msdn.com/Events/Build/2016/P470 to map Java heap to NV-DIMM memory. Link to webrev: http://cr.openjdk.java.net/~vdeshpande/8153327/webrev.02/ JBS entry : https://bugs.openjdk.java.net/browse/JDK-8153327 Will like to hear your feedback!! Thanks Kishor > -----Original Message----- > From: Kharbas, Kishor > Sent: Tuesday, May 24, 2016 3:03 PM > To: Per Liden; hotspot-gc-dev at openjdk.java.net > Cc: Kharbas, Kishor > Subject: RE: Supporting allocation of Java object heap on NV-DIMMS > > Oops.. forgot to insert the link to the new webrev. > > http://cr.openjdk.java.net/~vdeshpande/8153327/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8153327 > > - Kishor > > > -----Original Message----- > > From: Kharbas, Kishor > > Sent: Tuesday, May 24, 2016 2:39 PM > > To: Per Liden; hotspot-gc-dev at openjdk.java.net > > Cc: Kharbas, Kishor > > Subject: RE: Supporting allocation of Java object heap on NV-DIMMS > > > > Sorry for the long hiatus on this thread. > > As it was apparent that it would have been difficult to integrate the > > patch in JDK9, I took some time to re-implement the feature. > > > > In the new patch, I do not change the existing functions in 'os' class > > which reserve memory for the heap. > > The existing logic in ReservedSpace::initialize() and > > ReservedHeapSpace::try_reserve_heap() to reserve a virtual address is > > untouched. Only after a virtual address range is successfully > > allocated, I call a newly added function which maps this address range > > to physical memory on the NV-DIMM > > > > The new call is os::map_memory_to_file() and its implemented for Linux > > at this point. > > I wanted to know your thoughts before I implement the function for > > windows and other OS'es. > > > > Thank you > > Kishor > > > > > -----Original Message----- > > > From: Kharbas, Kishor > > > Sent: Wednesday, April 13, 2016 4:43 PM > > > To: Per Liden; hotspot-gc-dev at openjdk.java.net > > > Cc: Kharbas, Kishor > > > Subject: RE: Supporting allocation of Java object heap on NV-DIMMS > > > > > > Hi Per, > > > > > > Here are the answers to your questions - 1. You have an interesting > > > point about non-heap memory. The current prototype only allocates > > > object heap on the new memory. We do not have plans to allocate > > > other JVM structures like cardtables, bitmaps on the new memory > > > device. In the future we will look into it. > > > For now we are very interested in getting this patch in JDK9 > > > atleast as an experimental feature. > > > > > > 2. The 3D XPoint memory has the same semantics as DRAM, and no > > > special handling is required from the user/JVM perspective. > > > With regards to pages sizes, ext4-DAX implicitly tries to allocate > > > largest granularity pages as possible. > > > The mmap() system call I use in the patch passes a 'fd' in the > > > directory provided by the new cmd line option "FSDirForHeap". In > > > this case, UseLargePages flag is ignored and the size of pages > > > allocated is upto to the filesystem. > > > > > > Regards > > > Kishor > > > > > > > > > > > > > -----Original Message----- > > > > From: Per Liden [mailto:per.liden at oracle.com] > > > > Sent: Wednesday, April 13, 2016 4:48 AM > > > > To: Kharbas, Kishor; hotspot-gc-dev at openjdk.java.net > > > > Subject: Re: Supporting allocation of Java object heap on NV-DIMMS > > > > > > > > Hi, > > > > > > > > On 2016-04-12 19:32, Kharbas, Kishor wrote: > > > > > Hi! > > > > > > > > > > In addition to points made in previous email, we have seen > > > > > performance in > > > > application performance by having larger heaps on 3D XPoint. With > > > > proper tuning, the upside of having less GCs outweighs the > > > > negative impact of slower latency. > > > > > Besides that, the patch is implemented so that it has least > > > > > impact on > > > > existing code path, to make sure there is no regression. > > > > > > > > > > Would like to hear your thoughts and also the possibility of > > > > > getting it in JDK > > > > 9. > > > > > > > > First of all, I can just note that JDK 9 Feature Complete date is > > > > getting very close. > > > > > > > > There seems to be at least two layers here: > > > > > > > > 1) The command line flag to direct heap mappings to be backed by a > file. > > > > > > > > Having a flag like this sounds overall reasonable and useful. > > > > > > > > What's your vision going forward here? Is there a reason to > > > > believe we might want to use this of non-Java heap memory in some > future? > > > > Marking bitmaps, malloc(), etc? How this is implemented, > > > > configured, options names, etc might be influenced if we foresee such > a future. > > > > > > > > General testing of these code paths could be done by mapping a > > > > file on tmpfs, or something similar. > > > > > > > > > > > > 2) The specific use case where this flag is used to a map 3D > > > > XPoint backed file. > > > > > > > > Will this memory have the same semantics as RAM, with regards to > > > > ordering, atomics, etc? Will there be a need for white listing > > > > known good types of memory/devices/filesystems which we can safely > > > > use for backing the heap? > > > > > > > > How does this interact with various pages sizes? E.g. mapping 3D > > > > XPoint memory with MAP_HUGETLB works? > > > > > > > > Testing of this obviously requires special hardware. > > > > > > > > > > > > cheers, > > > > Per > > > > > > > > > > > > > > Please do let me know if I need to make any changes and improve > > > > > the > > > > patch in any way. > > > > > > > > > > Regards > > > > > Kishor > > > > > > > > > > -----Original Message----- > > > > > From: Kharbas, Kishor > > > > > Sent: Tuesday, April 5, 2016 10:00 AM > > > > > To: 'Per Liden'; hotspot-gc-dev at openjdk.java.net > > > > > Cc: Kharbas, Kishor > > > > > Subject: RE: Supporting allocation of Java object heap on > > > > > NV-DIMMS > > > > > > > > > > Hi Per, > > > > > > > > > > We see application of this feature in large scale multi-JVM > > > > > deployments to > > > > increase resource utilization. We could run daemon/service JVMs > > > > with heap on slower memory and thus free up DRAM for critical > processes. > > > > > At Intel we have done internal experiments on large middleware > > > > applications and have seen benefit of this feature. > > > > > > > > > > Thanks > > > > > Kishor > > > > > > > > > > -----Original Message----- > > > > > From: Per Liden [mailto:per.liden at oracle.com] > > > > > Sent: Monday, April 4, 2016 4:37 AM > > > > > To: Kharbas, Kishor; hotspot-gc-dev at openjdk.java.net > > > > > Subject: Re: Supporting allocation of Java object heap on > > > > > NV-DIMMS > > > > > > > > > > Hi, > > > > > > > > > > On 2016-04-02 03:13, Kharbas, Kishor wrote: > > > > >> Hello all, > > > > >> > > > > >> I would like to propose adding a capability in the JVM to > > > > >> allocate object heap on new kinds of heterogeneous memories > > > > >> which are > > > > exposed > > > > >> through a file system. This could be achieved by adding a > > > > >> command line option to specify a path in the filesystem which > > > > >> would be used for > > > > >> mmap() system call. > > > > >> > > > > >> Details: > > > > >> > > > > >> Linux kernel 4.0 onwards supports DAX mode[1] in Ext4 file > > > > >> system [2] which is designed to support new heterogeneous > > > > >> memory devices such > > > > as > > > > >> Intel's 3D XPoint memory [3]. DAX mode removes the need for > > > > >> page > > > > cache > > > > >> and provides a direct mapping of process virtual space to > > > > >> storage > > space. > > > > >> > > > > >> We would like to add a command line option called "FSDirForHeap" > > > > >> which will - 1) Enable using a file system as backing store for > > > > >> Java object heap 2) Use the provided path to create a temporary > > > > >> file for mmap() system call. > > > > > > > > > > The new kinds of memories opens up for some new and interesting > > > > possibilities. However, as long as DRAM is faster (which I assume > > > > they will continue be for at least some time), I have a hard time > > > > seeing that you want to place your whole heap onto the NV-DIMMs. I > > > > can see that some applications might want to place some large > > > > subset of their data > > > there (e.g. > > > > an in memory-database), but I'm also guessing that placing the > > > > whole heap there would come with a noticeable impact on > > > > performance? Any thoughts on that? > > > > > > > > > > Do you have any data to share with regards to performance > > > > > difference on > > > > some relevant workloads? That would help in getting a better > > > > understanding of the feasibility of this mode of operation. > > > > > > > > > > cheers, > > > > > Per > > > > > > > > > >> > > > > >> The description of the feature can be found at > > > > >> https://bugs.openjdk.java.net/browse/JDK-8153327 > > > > >> > > > > >> and the webrev is uploaded at > > > > >> http://cr.openjdk.java.net/~vdeshpande/8153327/webrev.00/ > > > > >> > > > > >> References: > > > > >> > > > > >> [1] > > > > >> https://www.kernel.org/doc/Documentation/filesystems/dax.txt > > > > >> > > > > >> [2] > > > > >> https://www.kernel.org/doc/Documentation/filesystems/ext4.txt > > > > >> > > > > >> [3] > > > > >> https://newsroom.intel.com/press-kits/introducing-intel-optane- > > > > >> te > > > > >> ch nol > > > > >> ogy-bringing-3d-xpoint-memory-to-storage-and-memory-products/ > > > > >> > > > > >> Much appreciated! > > > > >> > > > > >> Thanks you. > > > > >> > > > > >> Kishor Kharbas > > > > >> From thomas.stuefe at gmail.com Mon Jun 6 10:22:28 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 6 Jun 2016 12:22:28 +0200 Subject: Supporting allocation of Java object heap on NV-DIMMS In-Reply-To: References: <570251D5.8090402@oracle.com> <570E31E9.1080706@oracle.com> Message-ID: Hi Kishor, short question, would this new memory support mprotect() ? If no, we may run into problems when using compressed oops with implicit null checks, because the base zone of the heap needs to be protected. (I do not know if there would be any other uses of mprotect on the heap memory). Kind Regards, Thomas On Sat, Jun 4, 2016 at 3:45 AM, Kharbas, Kishor wrote: > Hello all, > > I have an update to the patch, adding support for Windows. > It uses the Windows APIs described in > https://channel9.msdn.com/Events/Build/2016/P470 to map Java heap to > NV-DIMM memory. > > Link to webrev: http://cr.openjdk.java.net/~vdeshpande/8153327/webrev.02/ > JBS entry : https://bugs.openjdk.java.net/browse/JDK-8153327 > > Will like to hear your feedback!! > > Thanks > Kishor > > > -----Original Message----- > > From: Kharbas, Kishor > > Sent: Tuesday, May 24, 2016 3:03 PM > > To: Per Liden; hotspot-gc-dev at openjdk.java.net > > Cc: Kharbas, Kishor > > Subject: RE: Supporting allocation of Java object heap on NV-DIMMS > > > > Oops.. forgot to insert the link to the new webrev. > > > > http://cr.openjdk.java.net/~vdeshpande/8153327/webrev.01/ > > https://bugs.openjdk.java.net/browse/JDK-8153327 > > > > - Kishor > > > > > -----Original Message----- > > > From: Kharbas, Kishor > > > Sent: Tuesday, May 24, 2016 2:39 PM > > > To: Per Liden; hotspot-gc-dev at openjdk.java.net > > > Cc: Kharbas, Kishor > > > Subject: RE: Supporting allocation of Java object heap on NV-DIMMS > > > > > > Sorry for the long hiatus on this thread. > > > As it was apparent that it would have been difficult to integrate the > > > patch in JDK9, I took some time to re-implement the feature. > > > > > > In the new patch, I do not change the existing functions in 'os' class > > > which reserve memory for the heap. > > > The existing logic in ReservedSpace::initialize() and > > > ReservedHeapSpace::try_reserve_heap() to reserve a virtual address is > > > untouched. Only after a virtual address range is successfully > > > allocated, I call a newly added function which maps this address range > > > to physical memory on the NV-DIMM > > > > > > The new call is os::map_memory_to_file() and its implemented for Linux > > > at this point. > > > I wanted to know your thoughts before I implement the function for > > > windows and other OS'es. > > > > > > Thank you > > > Kishor > > > > > > > -----Original Message----- > > > > From: Kharbas, Kishor > > > > Sent: Wednesday, April 13, 2016 4:43 PM > > > > To: Per Liden; hotspot-gc-dev at openjdk.java.net > > > > Cc: Kharbas, Kishor > > > > Subject: RE: Supporting allocation of Java object heap on NV-DIMMS > > > > > > > > Hi Per, > > > > > > > > Here are the answers to your questions - 1. You have an interesting > > > > point about non-heap memory. The current prototype only allocates > > > > object heap on the new memory. We do not have plans to allocate > > > > other JVM structures like cardtables, bitmaps on the new memory > > > > device. In the future we will look into it. > > > > For now we are very interested in getting this patch in JDK9 > > > > atleast as an experimental feature. > > > > > > > > 2. The 3D XPoint memory has the same semantics as DRAM, and no > > > > special handling is required from the user/JVM perspective. > > > > With regards to pages sizes, ext4-DAX implicitly tries to allocate > > > > largest granularity pages as possible. > > > > The mmap() system call I use in the patch passes a 'fd' in the > > > > directory provided by the new cmd line option "FSDirForHeap". In > > > > this case, UseLargePages flag is ignored and the size of pages > > > > allocated is upto to the filesystem. > > > > > > > > Regards > > > > Kishor > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Per Liden [mailto:per.liden at oracle.com] > > > > > Sent: Wednesday, April 13, 2016 4:48 AM > > > > > To: Kharbas, Kishor; hotspot-gc-dev at openjdk.java.net > > > > > Subject: Re: Supporting allocation of Java object heap on NV-DIMMS > > > > > > > > > > Hi, > > > > > > > > > > On 2016-04-12 19:32, Kharbas, Kishor wrote: > > > > > > Hi! > > > > > > > > > > > > In addition to points made in previous email, we have seen > > > > > > performance in > > > > > application performance by having larger heaps on 3D XPoint. With > > > > > proper tuning, the upside of having less GCs outweighs the > > > > > negative impact of slower latency. > > > > > > Besides that, the patch is implemented so that it has least > > > > > > impact on > > > > > existing code path, to make sure there is no regression. > > > > > > > > > > > > Would like to hear your thoughts and also the possibility of > > > > > > getting it in JDK > > > > > 9. > > > > > > > > > > First of all, I can just note that JDK 9 Feature Complete date is > > > > > getting very close. > > > > > > > > > > There seems to be at least two layers here: > > > > > > > > > > 1) The command line flag to direct heap mappings to be backed by a > > file. > > > > > > > > > > Having a flag like this sounds overall reasonable and useful. > > > > > > > > > > What's your vision going forward here? Is there a reason to > > > > > believe we might want to use this of non-Java heap memory in some > > future? > > > > > Marking bitmaps, malloc(), etc? How this is implemented, > > > > > configured, options names, etc might be influenced if we foresee > such > > a future. > > > > > > > > > > General testing of these code paths could be done by mapping a > > > > > file on tmpfs, or something similar. > > > > > > > > > > > > > > > 2) The specific use case where this flag is used to a map 3D > > > > > XPoint backed file. > > > > > > > > > > Will this memory have the same semantics as RAM, with regards to > > > > > ordering, atomics, etc? Will there be a need for white listing > > > > > known good types of memory/devices/filesystems which we can safely > > > > > use for backing the heap? > > > > > > > > > > How does this interact with various pages sizes? E.g. mapping 3D > > > > > XPoint memory with MAP_HUGETLB works? > > > > > > > > > > Testing of this obviously requires special hardware. > > > > > > > > > > > > > > > cheers, > > > > > Per > > > > > > > > > > > > > > > > > Please do let me know if I need to make any changes and improve > > > > > > the > > > > > patch in any way. > > > > > > > > > > > > Regards > > > > > > Kishor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Kharbas, Kishor > > > > > > Sent: Tuesday, April 5, 2016 10:00 AM > > > > > > To: 'Per Liden'; hotspot-gc-dev at openjdk.java.net > > > > > > Cc: Kharbas, Kishor > > > > > > Subject: RE: Supporting allocation of Java object heap on > > > > > > NV-DIMMS > > > > > > > > > > > > Hi Per, > > > > > > > > > > > > We see application of this feature in large scale multi-JVM > > > > > > deployments to > > > > > increase resource utilization. We could run daemon/service JVMs > > > > > with heap on slower memory and thus free up DRAM for critical > > processes. > > > > > > At Intel we have done internal experiments on large middleware > > > > > applications and have seen benefit of this feature. > > > > > > > > > > > > Thanks > > > > > > Kishor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Per Liden [mailto:per.liden at oracle.com] > > > > > > Sent: Monday, April 4, 2016 4:37 AM > > > > > > To: Kharbas, Kishor; hotspot-gc-dev at openjdk.java.net > > > > > > Subject: Re: Supporting allocation of Java object heap on > > > > > > NV-DIMMS > > > > > > > > > > > > Hi, > > > > > > > > > > > > On 2016-04-02 03:13, Kharbas, Kishor wrote: > > > > > >> Hello all, > > > > > >> > > > > > >> I would like to propose adding a capability in the JVM to > > > > > >> allocate object heap on new kinds of heterogeneous memories > > > > > >> which are > > > > > exposed > > > > > >> through a file system. This could be achieved by adding a > > > > > >> command line option to specify a path in the filesystem which > > > > > >> would be used for > > > > > >> mmap() system call. > > > > > >> > > > > > >> Details: > > > > > >> > > > > > >> Linux kernel 4.0 onwards supports DAX mode[1] in Ext4 file > > > > > >> system [2] which is designed to support new heterogeneous > > > > > >> memory devices such > > > > > as > > > > > >> Intel's 3D XPoint memory [3]. DAX mode removes the need for > > > > > >> page > > > > > cache > > > > > >> and provides a direct mapping of process virtual space to > > > > > >> storage > > > space. > > > > > >> > > > > > >> We would like to add a command line option called "FSDirForHeap" > > > > > >> which will - 1) Enable using a file system as backing store for > > > > > >> Java object heap 2) Use the provided path to create a temporary > > > > > >> file for mmap() system call. > > > > > > > > > > > > The new kinds of memories opens up for some new and interesting > > > > > possibilities. However, as long as DRAM is faster (which I assume > > > > > they will continue be for at least some time), I have a hard time > > > > > seeing that you want to place your whole heap onto the NV-DIMMs. I > > > > > can see that some applications might want to place some large > > > > > subset of their data > > > > there (e.g. > > > > > an in memory-database), but I'm also guessing that placing the > > > > > whole heap there would come with a noticeable impact on > > > > > performance? Any thoughts on that? > > > > > > > > > > > > Do you have any data to share with regards to performance > > > > > > difference on > > > > > some relevant workloads? That would help in getting a better > > > > > understanding of the feasibility of this mode of operation. > > > > > > > > > > > > cheers, > > > > > > Per > > > > > > > > > > > >> > > > > > >> The description of the feature can be found at > > > > > >> https://bugs.openjdk.java.net/browse/JDK-8153327 > > > > > >> > > > > > >> and the webrev is uploaded at > > > > > >> http://cr.openjdk.java.net/~vdeshpande/8153327/webrev.00/ > > > > > >> > > > > > >> References: > > > > > >> > > > > > >> [1] > > > > > >> https://www.kernel.org/doc/Documentation/filesystems/dax.txt > > > > > >> > > > > > >> [2] > > > > > >> https://www.kernel.org/doc/Documentation/filesystems/ext4.txt > > > > > >> > > > > > >> [3] > > > > > >> https://newsroom.intel.com/press-kits/introducing-intel-optane- > > > > > >> te > > > > > >> ch nol > > > > > >> ogy-bringing-3d-xpoint-memory-to-storage-and-memory-products/ > > > > > >> > > > > > >> Much appreciated! > > > > > >> > > > > > >> Thanks you. > > > > > >> > > > > > >> Kishor Kharbas > > > > > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Mon Jun 6 21:18:59 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 6 Jun 2016 14:18:59 -0700 Subject: Request for Review (xs) - 8157373: Active workers should not be reset in AbstractWorkGang initialize() Message-ID: <5755E8C3.4010207@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8157373 The field _active_workers in AbstractWorkGang is set correctly in the AbstractWorkGang constructor and should not be reset in the initialize() method (where it is currently set incorrectly for concurrent workers). http://cr.openjdk.java.net/~jmasa/8157373/webrev.00/ Tested by hand. This will be integrated after 8157620 (which will allow addtional testing). Thanks. Jon From kim.barrett at oracle.com Tue Jun 7 00:27:10 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 6 Jun 2016 20:27:10 -0400 Subject: Request for Review (xs) - 8157373: Active workers should not be reset in AbstractWorkGang initialize() In-Reply-To: <5755E8C3.4010207@oracle.com> References: <5755E8C3.4010207@oracle.com> Message-ID: <1488788A-FD2B-45FB-8C25-25B3A56F12CA@oracle.com> > On Jun 6, 2016, at 5:18 PM, Jon Masamitsu wrote: > > https://bugs.openjdk.java.net/browse/JDK-8157373 > > The field _active_workers in AbstractWorkGang is set correctly in the AbstractWorkGang constructor and should not be reset in the initialize() method (where it is currently set incorrectly for concurrent workers). > > http://cr.openjdk.java.net/~jmasa/8157373/webrev.00/ > > Tested by hand. This will be integrated after 8157620 (which will allow > addtional testing). > > Thanks. > > Jon Looks good. From thomas.schatzl at oracle.com Tue Jun 7 08:24:46 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 07 Jun 2016 10:24:46 +0200 Subject: Request for Review (xs) - 8157373: Active workers should not be reset in AbstractWorkGang initialize() In-Reply-To: <5755E8C3.4010207@oracle.com> References: <5755E8C3.4010207@oracle.com> Message-ID: <1465287886.2364.3.camel@oracle.com> Hi Jon, On Mon, 2016-06-06 at 14:18 -0700, Jon Masamitsu wrote: > https://bugs.openjdk.java.net/browse/JDK-8157373 > > The field _active_workers in AbstractWorkGang is set correctly in > the? > AbstractWorkGang constructor and should not be reset in the > initialize()? > method (where it is currently set incorrectly for concurrent > workers). > > http://cr.openjdk.java.net/~jmasa/8157373/webrev.00/ > > Tested by hand.??This will be integrated after 8157620 (which will > allow > addtional testing). > ? looks good. Thanks for fixing this. Thomas From thomas.schatzl at oracle.com Tue Jun 7 08:36:54 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 07 Jun 2016 10:36:54 +0200 Subject: Request for Review (s) - 8157620: Guarantee in run_task(task, num_workers) fails In-Reply-To: References: Message-ID: <1465288614.2364.13.camel@oracle.com> Hi Jon, On Fri, 2016-06-03 at 14:04 -0700, Jon Masamitsu wrote: > https://bugs.openjdk.java.net/browse/JDK-8157620 > > A phase of a G1 collection chooses its own number of GC workers > but doesn't add more workers if more are needed than have been > created.???Add additional workers as needed.??Also changed the > guarantee to check the number of workers against the total number > of workers since the number of GC workers used to execute the > task may be different than active_workers (as in this case). > > Added an execution of TestGCOld with parameters that evoked the > failure. > > http://cr.openjdk.java.net/~jmasa/8157620/webrev.00/ > > Tested fix with TestGCOld. > Stability tested with gc_test_suite > ? looks good, with two comments: - I would _prefer_ if run_task(workgang, uint) always called add_workers() itself. Otherwise all of these invocations need to call add_workers() first themselves (if they do not limit themselves to active_workers). The run_task(workgang, uint) method has kind of been implemented as a short/quick way to run a workgang with a given number of threads, so this requirement adds additional boiler plate code again... - in the test, maybe put the -Xmx/-Xms right after the @run main/othervm like in the other tests just for consistency. --------------------- One comment related to the code changed, but unrelated to this CR: the code in?G1ConcurrentMark::calc_parallel_marking_threads() looks (almost?) the same as AdaptiveSizePolicy::calc_active_conc_workers(). Any arguments about cleaning this up at some point? When looking at the calculation of the AdaptiveSizePolicy::calc_default_active_workers() method, wouldn't it be better if instead of using Universe::heap()->capacity(), use something like Universe::heap()->used() (and actually e.g. for g1 one could subtract young gen and areas covered by primitive arrays too). Actually, this calculation should be different for young/old gen gc imho, as for both completely different areas are covered by the collection... (just some random thoughts when looking at this). Thanks, ? Thomas From Leonid.Mesnik at oracle.com Tue Jun 7 09:34:56 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Tue, 7 Jun 2016 12:34:56 +0300 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 In-Reply-To: References: <5746FDF3.3030102@oracle.com> Message-ID: <57569540.9010106@oracle.com> Hi Added jtreg-use at openjdk.java.net I think that you are right. Here is the documentation: http://openjdk.java.net/jtreg/tag-spec.html "@requires Express a dependence on characteristics of the system being tested. Some harnesses allow tests to be selected according to the characteristics of the system being tested. The expression may be composed of the following elements:" "os.arch The operating system architecture, as given by the corresponding system property." So user could expect to have "os.arch" of tested VM. If filed jtreg issues for this: 1. CODETOOLS-7901695 jtreg uses value 'os.arch' property of JDK which executed JDK and not of tested JDK Following fix could be used as a temporary workaround while jtreg fix is not ready. Does it make a sense? I this case it is needed to change linux-arm64 back to linux-aarch64 to minimize changes. Leonid On 31.05.2016 04:26, David Holmes wrote: > Hi Leonid, > > This really strikes me as as a jtreg problem that should be fixed in > jtreg. When writing an @requires clause in a test the test writer > should not have to be thinking "oh wait! Is this going to query the VM > running jtreg or the VM running the test?". It should obviously be the > VM running the test. > > That said we also seem to have a problem with the definition of os.arch: > > os.arch Operating system architecture > > if it is returning the build architecture of the VM and not the OS it > is running on. That in itself argues for two distinct properties. > > David > > On 26/05/2016 11:45 PM, Leonid Mesnik wrote: >> Hi >> >> Could you please review following fix: >> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/ >> >> hotspot http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/ >> >> for bug >> https://bugs.openjdk.java.net/browse/JDK-8157831 >> >> >> The property "os.name" which was used to filter tests depends on the >> arch of jdk which is used to run jtreg. It might differ from arch of >> tested jdk. >> This fix introduce new property "vm.arch" which depends on the arch of >> tested jdk and could be used to filter tests with @requires. >> >> I verified that tests are filtered where it is expected. >> Note: I am going to push this fix in jdk9/hs to fix regular hotspot >> testing. >> >> Leonid >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Leonid.Mesnik at oracle.com Tue Jun 7 13:35:07 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Tue, 7 Jun 2016 16:35:07 +0300 Subject: RFR: 8156032: Clean up parallel GC specific code from vm/gc/shared/preservedMarks.cpp Message-ID: <5756CD8B.90200@oracle.com> Hi Could you please review following patch which remove PS specific code from vm/gc/shared. Webrev: http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8156032 Fix is tested with JPRT. Leonid From jesper.wilhelmsson at oracle.com Tue Jun 7 14:58:03 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 7 Jun 2016 16:58:03 +0200 Subject: Request for Review (xs) - 8157373: Active workers should not be reset in AbstractWorkGang initialize() In-Reply-To: <5755E8C3.4010207@oracle.com> References: <5755E8C3.4010207@oracle.com> Message-ID: <4e76ad8e-2d25-09ac-c688-ae452f808a62@oracle.com> Looks good! /Jesper Den 6/6/16 kl. 23:18, skrev Jon Masamitsu: > https://bugs.openjdk.java.net/browse/JDK-8157373 > > The field _active_workers in AbstractWorkGang is set correctly in the > AbstractWorkGang constructor and should not be reset in the initialize() method > (where it is currently set incorrectly for concurrent workers). > > http://cr.openjdk.java.net/~jmasa/8157373/webrev.00/ > > Tested by hand. This will be integrated after 8157620 (which will allow > addtional testing). > > Thanks. > > Jon From jon.masamitsu at oracle.com Tue Jun 7 17:58:22 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 7 Jun 2016 10:58:22 -0700 Subject: Request for Review (s) - 8157620: Guarantee in run_task(task, num_workers) fails In-Reply-To: <1465288614.2364.13.camel@oracle.com> References: <1465288614.2364.13.camel@oracle.com> Message-ID: <0e71f6e1-b62f-c2b3-ab58-e414644e2e27@oracle.com> Thomas, Thanks for reviewing this. On 6/7/2016 1:36 AM, Thomas Schatzl wrote: > Hi Jon, > > On Fri, 2016-06-03 at 14:04 -0700, Jon Masamitsu wrote: >> https://bugs.openjdk.java.net/browse/JDK-8157620 >> >> A phase of a G1 collection chooses its own number of GC workers >> but doesn't add more workers if more are needed than have been >> created. Add additional workers as needed. Also changed the >> guarantee to check the number of workers against the total number >> of workers since the number of GC workers used to execute the >> task may be different than active_workers (as in this case). >> >> Added an execution of TestGCOld with parameters that evoked the >> failure. >> >> http://cr.openjdk.java.net/~jmasa/8157620/webrev.00/ >> >> Tested fix with TestGCOld. >> Stability tested with gc_test_suite >> > looks good, with two comments: > > - I would _prefer_ if run_task(workgang, uint) always called > add_workers() itself. Otherwise all of these invocations need to call > add_workers() first themselves (if they do not limit themselves to > active_workers). > > The run_task(workgang, uint) method has kind of been implemented as a > short/quick way to run a workgang with a given number of threads, so > this requirement adds additional boiler plate code again... Fixed. > > - in the test, maybe put the -Xmx/-Xms right after the @run > main/othervm like in the other tests just for consistency. Fixed. A new webrev will be coming after a bit of testing. > > --------------------- I'll address these in a second mail (after some thought). Jon > > One comment related to the code changed, but unrelated to this CR: the > code in G1ConcurrentMark::calc_parallel_marking_threads() looks > (almost?) the same as AdaptiveSizePolicy::calc_active_conc_workers(). > Any arguments about cleaning this up at some point? > > When looking at the calculation of the > AdaptiveSizePolicy::calc_default_active_workers() method, wouldn't it > be better if instead of using Universe::heap()->capacity(), use > something like Universe::heap()->used() (and actually e.g. for g1 one > could subtract young gen and areas covered by primitive arrays too). > > Actually, this calculation should be different for young/old gen gc > imho, as for both completely different areas are covered by the > collection... (just some random thoughts when looking at this). > > Thanks, > Thomas > From jon.masamitsu at oracle.com Tue Jun 7 18:46:41 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 7 Jun 2016 11:46:41 -0700 Subject: Request for Review (s) - 8157620: Guarantee in run_task(task, num_workers) fails In-Reply-To: <1465288614.2364.13.camel@oracle.com> References: <1465288614.2364.13.camel@oracle.com> Message-ID: New webrev and delta, respectively, with changes indicated below. http://cr.openjdk.java.net/~jmasa/8157620/webrev.01/ http://cr.openjdk.java.net/~jmasa/8157620/webrev_delta.00_01/ Jon On 6/7/2016 1:36 AM, Thomas Schatzl wrote: > Hi Jon, > > On Fri, 2016-06-03 at 14:04 -0700, Jon Masamitsu wrote: >> https://bugs.openjdk.java.net/browse/JDK-8157620 >> >> A phase of a G1 collection chooses its own number of GC workers >> but doesn't add more workers if more are needed than have been >> created. Add additional workers as needed. Also changed the >> guarantee to check the number of workers against the total number >> of workers since the number of GC workers used to execute the >> task may be different than active_workers (as in this case). >> >> Added an execution of TestGCOld with parameters that evoked the >> failure. >> >> http://cr.openjdk.java.net/~jmasa/8157620/webrev.00/ >> >> Tested fix with TestGCOld. >> Stability tested with gc_test_suite >> > looks good, with two comments: > > - I would _prefer_ if run_task(workgang, uint) always called > add_workers() itself. Otherwise all of these invocations need to call > add_workers() first themselves (if they do not limit themselves to > active_workers). > > The run_task(workgang, uint) method has kind of been implemented as a > short/quick way to run a workgang with a given number of threads, so > this requirement adds additional boiler plate code again... > > - in the test, maybe put the -Xmx/-Xms right after the @run > main/othervm like in the other tests just for consistency. > > --------------------- > > One comment related to the code changed, but unrelated to this CR: the > code in G1ConcurrentMark::calc_parallel_marking_threads() looks > (almost?) the same as AdaptiveSizePolicy::calc_active_conc_workers(). > Any arguments about cleaning this up at some point? > > When looking at the calculation of the > AdaptiveSizePolicy::calc_default_active_workers() method, wouldn't it > be better if instead of using Universe::heap()->capacity(), use > something like Universe::heap()->used() (and actually e.g. for g1 one > could subtract young gen and areas covered by primitive arrays too). > > Actually, this calculation should be different for young/old gen gc > imho, as for both completely different areas are covered by the > collection... (just some random thoughts when looking at this). > > Thanks, > Thomas > From derek.white at oracle.com Tue Jun 7 20:43:29 2016 From: derek.white at oracle.com (Derek White) Date: Tue, 7 Jun 2016 16:43:29 -0400 Subject: Request for Review (s) - 8157620: Guarantee in run_task(task, num_workers) fails In-Reply-To: References: <1465288614.2364.13.camel@oracle.com> Message-ID: <291abb42-2de9-36a3-9e74-dba128394e84@oracle.com> Hi Jon, The new code looks good! While reviewing this I looked over WorkerManager again, and saw a problem in the error handling: - Line 60 checks for errors creating the WorkerThread or OS thread. - Line 66-67 unconditionally update created_workers and tries to start a (possibly non-existent) thread. - And I don't like the spacing of line 61, but that's a nit. I'm not sure if this should get fixed as a separate change or as part of this one, but it looks bad. - Derek On 6/7/16 2:46 PM, Jon Masamitsu wrote: > New webrev and delta, respectively, with changes indicated below. > > http://cr.openjdk.java.net/~jmasa/8157620/webrev.01/ > > http://cr.openjdk.java.net/~jmasa/8157620/webrev_delta.00_01/ > > Jon > > On 6/7/2016 1:36 AM, Thomas Schatzl wrote: >> Hi Jon, >> >> On Fri, 2016-06-03 at 14:04 -0700, Jon Masamitsu wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8157620 >>> >>> A phase of a G1 collection chooses its own number of GC workers >>> but doesn't add more workers if more are needed than have been >>> created. Add additional workers as needed. Also changed the >>> guarantee to check the number of workers against the total number >>> of workers since the number of GC workers used to execute the >>> task may be different than active_workers (as in this case). >>> >>> Added an execution of TestGCOld with parameters that evoked the >>> failure. >>> >>> http://cr.openjdk.java.net/~jmasa/8157620/webrev.00/ >>> >>> Tested fix with TestGCOld. >>> Stability tested with gc_test_suite >>> >> looks good, with two comments: >> >> - I would _prefer_ if run_task(workgang, uint) always called >> add_workers() itself. Otherwise all of these invocations need to call >> add_workers() first themselves (if they do not limit themselves to >> active_workers). >> >> The run_task(workgang, uint) method has kind of been implemented as a >> short/quick way to run a workgang with a given number of threads, so >> this requirement adds additional boiler plate code again... >> >> - in the test, maybe put the -Xmx/-Xms right after the @run >> main/othervm like in the other tests just for consistency. >> >> --------------------- >> >> One comment related to the code changed, but unrelated to this CR: the >> code in G1ConcurrentMark::calc_parallel_marking_threads() looks >> (almost?) the same as AdaptiveSizePolicy::calc_active_conc_workers(). >> Any arguments about cleaning this up at some point? >> >> When looking at the calculation of the >> AdaptiveSizePolicy::calc_default_active_workers() method, wouldn't it >> be better if instead of using Universe::heap()->capacity(), use >> something like Universe::heap()->used() (and actually e.g. for g1 one >> could subtract young gen and areas covered by primitive arrays too). >> >> Actually, this calculation should be different for young/old gen gc >> imho, as for both completely different areas are covered by the >> collection... (just some random thoughts when looking at this). >> >> Thanks, >> Thomas >> > From derek.white at oracle.com Tue Jun 7 21:51:15 2016 From: derek.white at oracle.com (Derek White) Date: Tue, 7 Jun 2016 17:51:15 -0400 Subject: RFR (S): 8142749: HeapRegion cleanup In-Reply-To: References: Message-ID: On 5/30/16 8:05 AM, ???????? ??????????? wrote: > Hi all, > Please review and sponsor this change for JDK-8142749. > Note that not only HeapRegion::_predicted_bytes_to_copy related code > was removed, but also some unused (since the first commit) > method/class parameters and HeapRegion::object_iterate_mem_careful > method. All changed files contain at least several unused includes, > but I'm not sure it's applicable to remove them in this patch. > > CR: https://bugs.openjdk.java.net/browse/JDK-8142749 > Webrev: > http://cr.openjdk.java.net/~fzhinkin/vtolstopyatov/8142749/webrev.00/ > > Testing: hotspot_gc tests > > -- > Best regards, > Tolstopyatov Vsevolod Looks good! - Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Wed Jun 8 02:06:51 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 7 Jun 2016 19:06:51 -0700 Subject: Request for Review (s) 8026752: Cancel MetaspaceGC request for a CMS concurrent collection after GC In-Reply-To: <1fa166df-b646-ead9-50ad-672ce7efc267@oracle.com> References: <574825A8.80706@oracle.com> <1fa166df-b646-ead9-50ad-672ce7efc267@oracle.com> Message-ID: Please find the new versions of the webrevs http://cr.openjdk.java.net/~jmasa/8026752/webrev.01/ http://cr.openjdk.java.net/~jmasa/8026752/top_webrev.01/ There is a delta (but I'd recommend just looking at the complete webrevs). http://cr.openjdk.java.net/~jmasa/8026752/webrev_delta.00_01/ Thanks. Jon On 5/27/2016 8:17 AM, Jon Masamitsu wrote: > Stefan, > > Thanks for looking at this. Please see in-line. > > On 5/27/2016 3:47 AM, Stefan Johansson wrote: >> Hi Jon, >> >> On 2016-05-27 07:46, Jon Masamitsu wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8026752 >>> >>> If a concurrent CMS collection has been scheduled for Metaspace >>> needs, it should be cancelled if a full GC is done. >>> >>> http://cr.openjdk.java.net/~jmasa/8026752/webrev.00/ >>> >>> Fix was verified with the new test TestMetaspaceCMSCancel.java >>> Stability testing was done with gc_test_suite. >>> >> I think the fix is good. Just one question regarding where to do the >> call. Is there a reason that you have put >> MetaspaceGC::set_should_concurrent_collect(false) in >> reset_after_compaction()? To me it would make more sense to have the >> call in CMSCollector::do_compaction_work(...). > > No strong reason other than it is the place that occurred to me. > That reset_after_compaction() was added to take care of work > that needed to be done after a compaction so it seems a good > place to me. If do_compaction_work() is a more obvious place to > you, I can move it there. > >> >> Regarding the test, I think it is a bit unfortunate to have to sleep >> for 20s to verify this, especially since there have been efforts to >> shorten the test-time. What do you think about adding a >> WhiteBox-method for checking the value of >> MetaspaceGC::_should_concurrent_collect and have the test be >> something like: >> assertTrue(WB.metaspaceShouldConcurrentCollect()); >> System.gc(); >> assertFalse(WB.metaspaceShouldConcurrentCollect()); > > Adding -XX:CMSWaitDuration=5000 to the command line makes it less > likely that > a CMS concurrent collections starts and finishes before the call to > System.gc(). > The small MetaspaceSize threshold may have been exceeded during loading of > the systems classes (i.e., before the test program started running). > Adding the > pause() gives CMS time to start and complete a concurrent collection > if the > concurrent collection is not short-circuited by the fix. That is, I > give the > test a better chance of failing. > > I don't think it is quite enough to check MetaspaceGC > _should_concurrent_collect > because the concurrent collection could have already started. > > I could change the test to check the state of the CMS collector. It > should be > in "Resetting" or "Idling". I'll look into that. > > Thanks again. > > Jon > >> >> Doing this you should be able to avoid using the process builder as well. >> >> Thanks, >> Stefan >>> Thanks. >>> >>> Jon >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Wed Jun 8 02:14:59 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 7 Jun 2016 19:14:59 -0700 Subject: Request for Review (s) - 8157620: Guarantee in run_task(task, num_workers) fails In-Reply-To: <291abb42-2de9-36a3-9e74-dba128394e84@oracle.com> References: <1465288614.2364.13.camel@oracle.com> <291abb42-2de9-36a3-9e74-dba128394e84@oracle.com> Message-ID: Derek, Thanks for the review. On 6/7/2016 1:43 PM, Derek White wrote: > Hi Jon, > > The new code looks good! > > While reviewing this I looked over WorkerManager again, and saw a > problem in the error handling: > > - Line 60 checks for errors creating the WorkerThread or OS thread. > - Line 66-67 unconditionally update created_workers and tries to > start a (possibly non-existent) thread. > - And I don't like the spacing of line 61, but that's a nit. > > I'm not sure if this should get fixed as a separate change or as part > of this one, but it looks bad. Yes, that looks bad. I'll fix it as part of a separate change. Jon > > - Derek > > On 6/7/16 2:46 PM, Jon Masamitsu wrote: >> New webrev and delta, respectively, with changes indicated below. >> >> http://cr.openjdk.java.net/~jmasa/8157620/webrev.01/ >> >> http://cr.openjdk.java.net/~jmasa/8157620/webrev_delta.00_01/ >> >> Jon >> >> On 6/7/2016 1:36 AM, Thomas Schatzl wrote: >>> Hi Jon, >>> >>> On Fri, 2016-06-03 at 14:04 -0700, Jon Masamitsu wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8157620 >>>> >>>> A phase of a G1 collection chooses its own number of GC workers >>>> but doesn't add more workers if more are needed than have been >>>> created. Add additional workers as needed. Also changed the >>>> guarantee to check the number of workers against the total number >>>> of workers since the number of GC workers used to execute the >>>> task may be different than active_workers (as in this case). >>>> >>>> Added an execution of TestGCOld with parameters that evoked the >>>> failure. >>>> >>>> http://cr.openjdk.java.net/~jmasa/8157620/webrev.00/ >>>> >>>> Tested fix with TestGCOld. >>>> Stability tested with gc_test_suite >>>> >>> looks good, with two comments: >>> >>> - I would _prefer_ if run_task(workgang, uint) always called >>> add_workers() itself. Otherwise all of these invocations need to call >>> add_workers() first themselves (if they do not limit themselves to >>> active_workers). >>> >>> The run_task(workgang, uint) method has kind of been implemented as a >>> short/quick way to run a workgang with a given number of threads, so >>> this requirement adds additional boiler plate code again... >>> >>> - in the test, maybe put the -Xmx/-Xms right after the @run >>> main/othervm like in the other tests just for consistency. >>> >>> --------------------- >>> >>> One comment related to the code changed, but unrelated to this CR: the >>> code in G1ConcurrentMark::calc_parallel_marking_threads() looks >>> (almost?) the same as AdaptiveSizePolicy::calc_active_conc_workers(). >>> Any arguments about cleaning this up at some point? >>> >>> When looking at the calculation of the >>> AdaptiveSizePolicy::calc_default_active_workers() method, wouldn't it >>> be better if instead of using Universe::heap()->capacity(), use >>> something like Universe::heap()->used() (and actually e.g. for g1 one >>> could subtract young gen and areas covered by primitive arrays too). >>> >>> Actually, this calculation should be different for young/old gen gc >>> imho, as for both completely different areas are covered by the >>> collection... (just some random thoughts when looking at this). >>> >>> Thanks, >>> Thomas >>> >> > From stefan.johansson at oracle.com Wed Jun 8 06:48:14 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 8 Jun 2016 08:48:14 +0200 Subject: Request for Review (s) 8026752: Cancel MetaspaceGC request for a CMS concurrent collection after GC In-Reply-To: References: <574825A8.80706@oracle.com> <1fa166df-b646-ead9-50ad-672ce7efc267@oracle.com> Message-ID: <5757BFAE.60007@oracle.com> Hi Jon, On 2016-06-08 04:06, Jon Masamitsu wrote: > Please find the new versions of the webrevs > > http://cr.openjdk.java.net/~jmasa/8026752/webrev.01/ > http://cr.openjdk.java.net/~jmasa/8026752/top_webrev.01/ > Looks good. I think you could add Asserts.assertTrue(wb.metaspaceShouldConcurrentCollect()) before the call to System.gc() to make sure there was something to clear. No need to see a new webrev if you decide to do that. Reviewed. Thanks, Stefan > There is a delta (but I'd recommend just looking at the complete > webrevs). > > http://cr.openjdk.java.net/~jmasa/8026752/webrev_delta.00_01/ > > Thanks. > > Jon > > On 5/27/2016 8:17 AM, Jon Masamitsu wrote: >> Stefan, >> >> Thanks for looking at this. Please see in-line. >> >> On 5/27/2016 3:47 AM, Stefan Johansson wrote: >>> Hi Jon, >>> >>> On 2016-05-27 07:46, Jon Masamitsu wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8026752 >>>> >>>> If a concurrent CMS collection has been scheduled for Metaspace >>>> needs, it should be cancelled if a full GC is done. >>>> >>>> http://cr.openjdk.java.net/~jmasa/8026752/webrev.00/ >>>> >>>> Fix was verified with the new test TestMetaspaceCMSCancel.java >>>> Stability testing was done with gc_test_suite. >>>> >>> I think the fix is good. Just one question regarding where to do the >>> call. Is there a reason that you have put >>> MetaspaceGC::set_should_concurrent_collect(false) in >>> reset_after_compaction()? To me it would make more sense to have the >>> call in CMSCollector::do_compaction_work(...). >> >> No strong reason other than it is the place that occurred to me. >> That reset_after_compaction() was added to take care of work >> that needed to be done after a compaction so it seems a good >> place to me. If do_compaction_work() is a more obvious place to >> you, I can move it there. >> >>> >>> Regarding the test, I think it is a bit unfortunate to have to sleep >>> for 20s to verify this, especially since there have been efforts to >>> shorten the test-time. What do you think about adding a >>> WhiteBox-method for checking the value of >>> MetaspaceGC::_should_concurrent_collect and have the test be >>> something like: >>> assertTrue(WB.metaspaceShouldConcurrentCollect()); >>> System.gc(); >>> assertFalse(WB.metaspaceShouldConcurrentCollect()); >> >> Adding -XX:CMSWaitDuration=5000 to the command line makes it less >> likely that >> a CMS concurrent collections starts and finishes before the call to >> System.gc(). >> The small MetaspaceSize threshold may have been exceeded during >> loading of >> the systems classes (i.e., before the test program started running). >> Adding the >> pause() gives CMS time to start and complete a concurrent collection >> if the >> concurrent collection is not short-circuited by the fix. That is, I >> give the >> test a better chance of failing. >> >> I don't think it is quite enough to check MetaspaceGC >> _should_concurrent_collect >> because the concurrent collection could have already started. >> >> I could change the test to check the state of the CMS collector. It >> should be >> in "Resetting" or "Idling". I'll look into that. >> >> Thanks again. >> >> Jon >> >>> >>> Doing this you should be able to avoid using the process builder as >>> well. >>> >>> Thanks, >>> Stefan >>>> Thanks. >>>> >>>> Jon >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.helin at oracle.com Wed Jun 8 11:31:31 2016 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 8 Jun 2016 13:31:31 +0200 Subject: RFR: 8159045: Remove const from methods returning size_t in threadLocalAllocBuffer.hpp Message-ID: <20160608113131.GB26799@ehelin.jrpg.bea.com> Hey all, here is a tiny patch that removes the const decorator from two static methods returning size_t. The const decorator doesn't mean anything in this case since a size_t is always copied. Bug: https://bugs.openjdk.java.net/browse/JDK-8159045 Patch: # HG changeset patch # User ehelin # Date 1465385076 -7200 # Wed Jun 08 13:24:36 2016 +0200 # Node ID 7913ba2740284a10754d14df7c6556218eb37051 # Parent a1dc09350fbcd12d858d42903106ae788f77d2d0 8159045: Remove const from methods returning size_t in threadLocalAllocBuffer.hpp diff -r a1dc09350fbc -r 7913ba274028 src/share/vm/gc/shared/threadLocalAllocBuffer.hpp --- a/src/share/vm/gc/shared/threadLocalAllocBuffer.hpp Wed Jun 08 11:15:49 2016 +0200 +++ b/src/share/vm/gc/shared/threadLocalAllocBuffer.hpp Wed Jun 08 13:24:36 2016 +0200 @@ -108,8 +108,8 @@ // do nothing. tlabs must be inited by initialize() calls } - static const size_t min_size() { return align_object_size(MinTLABSize / HeapWordSize) + alignment_reserve(); } - static const size_t max_size() { assert(_max_size != 0, "max_size not set up"); return _max_size; } + static size_t min_size() { return align_object_size(MinTLABSize / HeapWordSize) + alignment_reserve(); } + static size_t max_size() { assert(_max_size != 0, "max_size not set up"); return _max_size; } static void set_max_size(size_t max_size) { _max_size = max_size; } HeapWord* start() const { return _start; } Testing: - Compiled on Linux x86-64 Thanks, Erik From erik.helin at oracle.com Wed Jun 8 11:56:43 2016 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 8 Jun 2016 13:56:43 +0200 Subject: RFR: 8149085: IntegrationTest1.java fails intermittently due to use of semi-initialized TLAB In-Reply-To: <57445DF1.1080400@oracle.com> References: <57445DF1.1080400@oracle.com> Message-ID: <20160608115643.GC26799@ehelin.jrpg.bea.com> On 2016-05-24, Stefan Johansson wrote: > Hi, > > Please review this fix for: > https://bugs.openjdk.java.net/browse/JDK-8149085 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8149085/hotspot.00/ Looks reasonable, it is better than the current check. Reviewed. Thanks, Erik > Summary: > Thread::cooked_allocated_bytes() tries to give a good estimation of how much > has been allocated by a given thread. It does this by adding the stored > _allocated_bytes valued, incremented when a TLAB is retired, with the used > bytes from the currently active TLAB. This works fine when > cooked_allocated_bytes() is called by the current thread, but when called to > query a different thread there is a risk that the thread is in the middle of > retiring its TLAB. In such case there was risk that a bad used_bytes() value > was used and in turn caused the test in question to fail. > > A similar issue seems to have been semi-fixed before, the removed code > suggests that making sure that the signed used bytes size is more than zero > is enough to make it a valid TLAB, but it turns out this is not enough. > Instead making sure that the used bytes value is less than the max allowed > TLAB-size should ensure that the TLAB has been fully initialized. > > As the added comment suggests there is still a race present in this code, > and I don't intend to fix this now because I see this more as a fast > sampling function than something that we should rely on. > > Testing: > Verified fix locally. RBT run for G1 and Parallel is ongoing. > > Thanks, > Stefan > From michail.chernov at oracle.com Wed Jun 8 13:49:35 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Wed, 8 Jun 2016 16:49:35 +0300 Subject: RFR: 8158412: [TESTBUG] TestIHOPErgo and TestStressG1Humongous should not be executed when JFR is enabled Message-ID: <5758226F.3000108@oracle.com> Hi, Could I have a reviews for this small fix? The fix adds new custom JTreg setting for @requires tag - vm.FlightRecorder. New setting is used in all updated tests. Tests will be exclude if JFR is enabled. https://bugs.openjdk.java.net/browse/JDK-8158412 http://cr.openjdk.java.net/~mchernov/8158412/webrev.root.00/ http://cr.openjdk.java.net/~mchernov/8158412/webrev.hotspot.00/ Testing - RBT. Thanks, Michail From mikael.gerdin at oracle.com Wed Jun 8 13:57:53 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 8 Jun 2016 15:57:53 +0200 Subject: RFR: 8149085: IntegrationTest1.java fails intermittently due to use of semi-initialized TLAB In-Reply-To: <20160608115643.GC26799@ehelin.jrpg.bea.com> References: <57445DF1.1080400@oracle.com> <20160608115643.GC26799@ehelin.jrpg.bea.com> Message-ID: <57582461.800@oracle.com> Hi, On 2016-06-08 13:56, Erik Helin wrote: > On 2016-05-24, Stefan Johansson wrote: >> Hi, >> >> Please review this fix for: >> https://bugs.openjdk.java.net/browse/JDK-8149085 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8149085/hotspot.00/ > > Looks reasonable, it is better than the current check. Reviewed. +1 /Mikael > > Thanks, > Erik > >> Summary: >> Thread::cooked_allocated_bytes() tries to give a good estimation of how much >> has been allocated by a given thread. It does this by adding the stored >> _allocated_bytes valued, incremented when a TLAB is retired, with the used >> bytes from the currently active TLAB. This works fine when >> cooked_allocated_bytes() is called by the current thread, but when called to >> query a different thread there is a risk that the thread is in the middle of >> retiring its TLAB. In such case there was risk that a bad used_bytes() value >> was used and in turn caused the test in question to fail. >> >> A similar issue seems to have been semi-fixed before, the removed code >> suggests that making sure that the signed used bytes size is more than zero >> is enough to make it a valid TLAB, but it turns out this is not enough. >> Instead making sure that the used bytes value is less than the max allowed >> TLAB-size should ensure that the TLAB has been fully initialized. >> >> As the added comment suggests there is still a race present in this code, >> and I don't intend to fix this now because I see this more as a fast >> sampling function than something that we should rely on. >> >> Testing: >> Verified fix locally. RBT run for G1 and Parallel is ongoing. >> >> Thanks, >> Stefan >> From stefan.johansson at oracle.com Wed Jun 8 14:22:32 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 8 Jun 2016 16:22:32 +0200 Subject: RFR: 8149085: IntegrationTest1.java fails intermittently due to use of semi-initialized TLAB In-Reply-To: <57582461.800@oracle.com> References: <57445DF1.1080400@oracle.com> <20160608115643.GC26799@ehelin.jrpg.bea.com> <57582461.800@oracle.com> Message-ID: <57582A28.3070405@oracle.com> On 2016-06-08 15:57, Mikael Gerdin wrote: > Hi, > > On 2016-06-08 13:56, Erik Helin wrote: >> On 2016-05-24, Stefan Johansson wrote: >>> Hi, >>> >>> Please review this fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8149085 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sjohanss/8149085/hotspot.00/ >> >> Looks reasonable, it is better than the current check. Reviewed. > > +1 > Thanks guys for being reasonable :) Stefan > /Mikael > >> >> Thanks, >> Erik >> >>> Summary: >>> Thread::cooked_allocated_bytes() tries to give a good estimation of >>> how much >>> has been allocated by a given thread. It does this by adding the stored >>> _allocated_bytes valued, incremented when a TLAB is retired, with >>> the used >>> bytes from the currently active TLAB. This works fine when >>> cooked_allocated_bytes() is called by the current thread, but when >>> called to >>> query a different thread there is a risk that the thread is in the >>> middle of >>> retiring its TLAB. In such case there was risk that a bad >>> used_bytes() value >>> was used and in turn caused the test in question to fail. >>> >>> A similar issue seems to have been semi-fixed before, the removed code >>> suggests that making sure that the signed used bytes size is more >>> than zero >>> is enough to make it a valid TLAB, but it turns out this is not enough. >>> Instead making sure that the used bytes value is less than the max >>> allowed >>> TLAB-size should ensure that the TLAB has been fully initialized. >>> >>> As the added comment suggests there is still a race present in this >>> code, >>> and I don't intend to fix this now because I see this more as a fast >>> sampling function than something that we should rely on. >>> >>> Testing: >>> Verified fix locally. RBT run for G1 and Parallel is ongoing. >>> >>> Thanks, >>> Stefan >>> From stefan.karlsson at oracle.com Wed Jun 8 14:21:54 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 8 Jun 2016 16:21:54 +0200 Subject: RFR: 8156032: Clean up parallel GC specific code from vm/gc/shared/preservedMarks.cpp In-Reply-To: <5756CD8B.90200@oracle.com> References: <5756CD8B.90200@oracle.com> Message-ID: <57582A02.10901@oracle.com> Hi Leonid, Thanks for cleaning this up! See comments inlined: On 2016-06-07 15:35, Leonid Mesnik wrote: > Hi > > Could you please review following patch which remove PS specific code > from vm/gc/shared. > Webrev: http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156032 http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/src/share/vm/gc/parallel/psPromotionManager.cpp.udiff.html http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/src/share/vm/gc/shared/preservedMarks.hpp.udiff.html +class PSPreservedMarksTaskExecutor : public RestorePreservedMarksTaskExecutor +class SharedPreservedMarksTaskExecutor : public RestorePreservedMarksTaskExecutor Should the subclasses also mention the word Restore? ------ http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/src/share/vm/gc/shared/preservedMarks.hpp.udiff.html +public: + WorkGang* workers; + workers should be private and named _workers. --- + void restore(PreservedMarksSet* preserved_marks_set, + volatile size_t* total_size_addr); Would you mind aligning the parameters? --- + // Iterate over all stacks, restore all preserved marks, and reclaim + // the memory taken up by the stack segments. + // Supported executors: WorkerPresevedMarksTaskExecutor (Serial, CMS, G1), + // PSManagerTaskExecutor (PS). The comment refers to the old names of subclasses of RestorePreservedMarksTaskExecutor. Thanks, StefanK > > Fix is tested with JPRT. > > Leonid From dmitry.fazunenko at oracle.com Wed Jun 8 15:02:44 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 8 Jun 2016 18:02:44 +0300 Subject: RFR: 8158412: [TESTBUG] TestIHOPErgo and TestStressG1Humongous should not be executed when JFR is enabled In-Reply-To: <5758226F.3000108@oracle.com> References: <5758226F.3000108@oracle.com> Message-ID: <6d33c2c4-4c67-87e9-df94-5b25011b08d6@oracle.com> Hi Michail, The fix looks good to me. Thanks, Dima On 08.06.2016 16:49, Michail Chernov wrote: > Hi, > > Could I have a reviews for this small fix? The fix adds new custom > JTreg setting for @requires tag - vm.FlightRecorder. New setting is > used in all updated tests. Tests will be exclude if JFR is enabled. > > https://bugs.openjdk.java.net/browse/JDK-8158412 > http://cr.openjdk.java.net/~mchernov/8158412/webrev.root.00/ > http://cr.openjdk.java.net/~mchernov/8158412/webrev.hotspot.00/ > > Testing - RBT. > > Thanks, > Michail > From michail.chernov at oracle.com Wed Jun 8 15:08:15 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Wed, 8 Jun 2016 18:08:15 +0300 Subject: RFR: 8158412: [TESTBUG] TestIHOPErgo and TestStressG1Humongous should not be executed when JFR is enabled In-Reply-To: <6d33c2c4-4c67-87e9-df94-5b25011b08d6@oracle.com> References: <5758226F.3000108@oracle.com> <6d33c2c4-4c67-87e9-df94-5b25011b08d6@oracle.com> Message-ID: <575834DF.4030602@oracle.com> Hi Dima, Thanks a lot! On 06/08/2016 06:02 PM, Dmitry Fazunenko wrote: > Hi Michail, > > The fix looks good to me. > > Thanks, > Dima > > On 08.06.2016 16:49, Michail Chernov wrote: >> Hi, >> >> Could I have a reviews for this small fix? The fix adds new custom >> JTreg setting for @requires tag - vm.FlightRecorder. New setting is >> used in all updated tests. Tests will be exclude if JFR is enabled. >> >> https://bugs.openjdk.java.net/browse/JDK-8158412 >> http://cr.openjdk.java.net/~mchernov/8158412/webrev.root.00/ >> http://cr.openjdk.java.net/~mchernov/8158412/webrev.hotspot.00/ >> >> Testing - RBT. >> >> Thanks, >> Michail >> > > From jon.masamitsu at oracle.com Wed Jun 8 15:43:16 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 8 Jun 2016 08:43:16 -0700 Subject: Request for Review (s) 8026752: Cancel MetaspaceGC request for a CMS concurrent collection after GC In-Reply-To: <5757BFAE.60007@oracle.com> References: <574825A8.80706@oracle.com> <1fa166df-b646-ead9-50ad-672ce7efc267@oracle.com> <5757BFAE.60007@oracle.com> Message-ID: <57583D14.5030403@oracle.com> On 06/07/2016 11:48 PM, Stefan Johansson wrote: > Hi Jon, > > On 2016-06-08 04:06, Jon Masamitsu wrote: >> Please find the new versions of the webrevs >> >> http://cr.openjdk.java.net/~jmasa/8026752/webrev.01/ >> http://cr.openjdk.java.net/~jmasa/8026752/top_webrev.01/ >> > Looks good. I think you could add > Asserts.assertTrue(wb.metaspaceShouldConcurrentCollect()) before the > call to System.gc() to make sure there was something to clear. No need > to see a new webrev if you decide to do that. Reviewed. Thanks for the review. If you don't mind, I would rather not add the check before the System.gc(). I can think of different scenarios (unlikely perhaps) where the should-concurrent-collect flag would not be set for legitimate reasons and would prefer to avoid the assertion failure in those cases. Jon > Thanks, > Stefan > >> There is a delta (but I'd recommend just looking at the complete >> webrevs). >> >> http://cr.openjdk.java.net/~jmasa/8026752/webrev_delta.00_01/ >> >> Thanks. >> >> Jon >> >> On 5/27/2016 8:17 AM, Jon Masamitsu wrote: >>> Stefan, >>> >>> Thanks for looking at this. Please see in-line. >>> >>> On 5/27/2016 3:47 AM, Stefan Johansson wrote: >>>> Hi Jon, >>>> >>>> On 2016-05-27 07:46, Jon Masamitsu wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8026752 >>>>> >>>>> If a concurrent CMS collection has been scheduled for Metaspace >>>>> needs, it should be cancelled if a full GC is done. >>>>> >>>>> http://cr.openjdk.java.net/~jmasa/8026752/webrev.00/ >>>>> >>>>> Fix was verified with the new test TestMetaspaceCMSCancel.java >>>>> Stability testing was done with gc_test_suite. >>>>> >>>> I think the fix is good. Just one question regarding where to do >>>> the call. Is there a reason that you have put >>>> MetaspaceGC::set_should_concurrent_collect(false) in >>>> reset_after_compaction()? To me it would make more sense to have >>>> the call in CMSCollector::do_compaction_work(...). >>> >>> No strong reason other than it is the place that occurred to me. >>> That reset_after_compaction() was added to take care of work >>> that needed to be done after a compaction so it seems a good >>> place to me. If do_compaction_work() is a more obvious place to >>> you, I can move it there. >>> >>>> >>>> Regarding the test, I think it is a bit unfortunate to have to >>>> sleep for 20s to verify this, especially since there have been >>>> efforts to shorten the test-time. What do you think about adding a >>>> WhiteBox-method for checking the value of >>>> MetaspaceGC::_should_concurrent_collect and have the test be >>>> something like: >>>> assertTrue(WB.metaspaceShouldConcurrentCollect()); >>>> System.gc(); >>>> assertFalse(WB.metaspaceShouldConcurrentCollect()); >>> >>> Adding -XX:CMSWaitDuration=5000 to the command line makes it less >>> likely that >>> a CMS concurrent collections starts and finishes before the call to >>> System.gc(). >>> The small MetaspaceSize threshold may have been exceeded during >>> loading of >>> the systems classes (i.e., before the test program started >>> running). Adding the >>> pause() gives CMS time to start and complete a concurrent collection >>> if the >>> concurrent collection is not short-circuited by the fix. That is, I >>> give the >>> test a better chance of failing. >>> >>> I don't think it is quite enough to check MetaspaceGC >>> _should_concurrent_collect >>> because the concurrent collection could have already started. >>> >>> I could change the test to check the state of the CMS collector. It >>> should be >>> in "Resetting" or "Idling". I'll look into that. >>> >>> Thanks again. >>> >>> Jon >>> >>>> >>>> Doing this you should be able to avoid using the process builder as >>>> well. >>>> >>>> Thanks, >>>> Stefan >>>>> Thanks. >>>>> >>>>> Jon >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Wed Jun 8 15:49:36 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 8 Jun 2016 08:49:36 -0700 Subject: RFR: 8159045: Remove const from methods returning size_t in threadLocalAllocBuffer.hpp In-Reply-To: <20160608113131.GB26799@ehelin.jrpg.bea.com> References: <20160608113131.GB26799@ehelin.jrpg.bea.com> Message-ID: <57583E90.3030002@oracle.com> Looks good. Jon On 06/08/2016 04:31 AM, Erik Helin wrote: > Hey all, > > here is a tiny patch that removes the const decorator from two static > methods returning size_t. The const decorator doesn't mean anything in > this case since a size_t is always copied. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8159045 > > Patch: > # HG changeset patch > # User ehelin > # Date 1465385076 -7200 > # Wed Jun 08 13:24:36 2016 +0200 > # Node ID 7913ba2740284a10754d14df7c6556218eb37051 > # Parent a1dc09350fbcd12d858d42903106ae788f77d2d0 > 8159045: Remove const from methods returning size_t in threadLocalAllocBuffer.hpp > > diff -r a1dc09350fbc -r 7913ba274028 src/share/vm/gc/shared/threadLocalAllocBuffer.hpp > --- a/src/share/vm/gc/shared/threadLocalAllocBuffer.hpp Wed Jun 08 11:15:49 2016 +0200 > +++ b/src/share/vm/gc/shared/threadLocalAllocBuffer.hpp Wed Jun 08 13:24:36 2016 +0200 > @@ -108,8 +108,8 @@ > // do nothing. tlabs must be inited by initialize() calls > } > > - static const size_t min_size() { return align_object_size(MinTLABSize / HeapWordSize) + alignment_reserve(); } > - static const size_t max_size() { assert(_max_size != 0, "max_size not set up"); return _max_size; } > + static size_t min_size() { return align_object_size(MinTLABSize / HeapWordSize) + alignment_reserve(); } > + static size_t max_size() { assert(_max_size != 0, "max_size not set up"); return _max_size; } > static void set_max_size(size_t max_size) { _max_size = max_size; } > > HeapWord* start() const { return _start; } > > Testing: > - Compiled on Linux x86-64 > > Thanks, > Erik From dmitry.fazunenko at oracle.com Wed Jun 8 16:06:54 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 8 Jun 2016 19:06:54 +0300 Subject: RFR(S): 8132711: Add tests which check that Humongous objects behave as expected after Mixed GC In-Reply-To: <573315FD.5050109@oracle.com> References: <573315FD.5050109@oracle.com> Message-ID: Kirill, the change looks good to me. Thanks, Dima On 11.05.2016 14:22, Kirill Zhaldbybin wrote: > Dear all, > > Could you please review this fix for 8132711? > > This fix adds Mixed GC scenario to > gc/g1/humongousObjects/objectGraphTest/TestObjectGraphAfterGC.java > which creates different types of object graphs with Object arrays as > nodes (to make them humongous) and checks that after different types > GCs objects' graphs were handled correctly. > > During Mixed GC scenario the test expects that all weakly reachable > nodes should be collected since non-humongous nodes were previously > promoted to old gen and several gc options were specified to guarantee > that mixed gc collects all weakly unreachable objects in old gen. > Softly reachable nodes should not be collected. > > WebRev: > http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132711/webrev.00/ > CR: https://bugs.openjdk.java.net/browse/JDK-8132711 > > Thank you. > > Regards, Kirill From jon.masamitsu at oracle.com Wed Jun 8 17:11:21 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 8 Jun 2016 10:11:21 -0700 Subject: Request for Review (s) - 8157620: Guarantee in run_task(task, num_workers) fails In-Reply-To: <291abb42-2de9-36a3-9e74-dba128394e84@oracle.com> References: <1465288614.2364.13.camel@oracle.com> <291abb42-2de9-36a3-9e74-dba128394e84@oracle.com> Message-ID: <575851B9.2000308@oracle.com> Derek, Does this fix the issues you raised? http://cr.openjdk.java.net/~jmasa/8159073/webrev.00/ Jon On 06/07/2016 01:43 PM, Derek White wrote: > Hi Jon, > > The new code looks good! > > While reviewing this I looked over WorkerManager again, and saw a > problem in the error handling: > > - Line 60 checks for errors creating the WorkerThread or OS thread. > - Line 66-67 unconditionally update created_workers and tries to > start a (possibly non-existent) thread. > - And I don't like the spacing of line 61, but that's a nit. > > I'm not sure if this should get fixed as a separate change or as part > of this one, but it looks bad. > > - Derek > > On 6/7/16 2:46 PM, Jon Masamitsu wrote: >> New webrev and delta, respectively, with changes indicated below. >> >> http://cr.openjdk.java.net/~jmasa/8157620/webrev.01/ >> >> http://cr.openjdk.java.net/~jmasa/8157620/webrev_delta.00_01/ >> >> Jon >> >> On 6/7/2016 1:36 AM, Thomas Schatzl wrote: >>> Hi Jon, >>> >>> On Fri, 2016-06-03 at 14:04 -0700, Jon Masamitsu wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8157620 >>>> >>>> A phase of a G1 collection chooses its own number of GC workers >>>> but doesn't add more workers if more are needed than have been >>>> created. Add additional workers as needed. Also changed the >>>> guarantee to check the number of workers against the total number >>>> of workers since the number of GC workers used to execute the >>>> task may be different than active_workers (as in this case). >>>> >>>> Added an execution of TestGCOld with parameters that evoked the >>>> failure. >>>> >>>> http://cr.openjdk.java.net/~jmasa/8157620/webrev.00/ >>>> >>>> Tested fix with TestGCOld. >>>> Stability tested with gc_test_suite >>>> >>> looks good, with two comments: >>> >>> - I would _prefer_ if run_task(workgang, uint) always called >>> add_workers() itself. Otherwise all of these invocations need to call >>> add_workers() first themselves (if they do not limit themselves to >>> active_workers). >>> >>> The run_task(workgang, uint) method has kind of been implemented as a >>> short/quick way to run a workgang with a given number of threads, so >>> this requirement adds additional boiler plate code again... >>> >>> - in the test, maybe put the -Xmx/-Xms right after the @run >>> main/othervm like in the other tests just for consistency. >>> >>> --------------------- >>> >>> One comment related to the code changed, but unrelated to this CR: the >>> code in G1ConcurrentMark::calc_parallel_marking_threads() looks >>> (almost?) the same as AdaptiveSizePolicy::calc_active_conc_workers(). >>> Any arguments about cleaning this up at some point? >>> >>> When looking at the calculation of the >>> AdaptiveSizePolicy::calc_default_active_workers() method, wouldn't it >>> be better if instead of using Universe::heap()->capacity(), use >>> something like Universe::heap()->used() (and actually e.g. for g1 one >>> could subtract young gen and areas covered by primitive arrays too). >>> >>> Actually, this calculation should be different for young/old gen gc >>> imho, as for both completely different areas are covered by the >>> collection... (just some random thoughts when looking at this). >>> >>> Thanks, >>> Thomas >>> >> > From kirill.zhaldybin at oracle.com Wed Jun 8 18:14:41 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Wed, 8 Jun 2016 21:14:41 +0300 Subject: RFR(S): 8132711: Add tests which check that Humongous objects behave as expected after Mixed GC In-Reply-To: References: <573315FD.5050109@oracle.com> Message-ID: <57586091.7020908@oracle.com> Dmitry, Thank you for review! Regards, Kirill On 08.06.2016 19:06, Dmitry Fazunenko wrote: > Kirill, > > the change looks good to me. > > Thanks, > Dima > > On 11.05.2016 14:22, Kirill Zhaldbybin wrote: >> Dear all, >> >> Could you please review this fix for 8132711? >> >> This fix adds Mixed GC scenario to >> gc/g1/humongousObjects/objectGraphTest/TestObjectGraphAfterGC.java >> which creates different types of object graphs with Object arrays as >> nodes (to make them humongous) and checks that after different types >> GCs objects' graphs were handled correctly. >> >> During Mixed GC scenario the test expects that all weakly reachable >> nodes should be collected since non-humongous nodes were previously >> promoted to old gen and several gc options were specified to guarantee >> that mixed gc collects all weakly unreachable objects in old gen. >> Softly reachable nodes should not be collected. >> >> WebRev: >> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132711/webrev.00/ >> CR: https://bugs.openjdk.java.net/browse/JDK-8132711 >> >> Thank you. >> >> Regards, Kirill > From sangheon.kim at oracle.com Wed Jun 8 18:29:37 2016 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 8 Jun 2016 11:29:37 -0700 Subject: Request for Review (s) 8026752: Cancel MetaspaceGC request for a CMS concurrent collection after GC In-Reply-To: <57583D14.5030403@oracle.com> References: <574825A8.80706@oracle.com> <1fa166df-b646-ead9-50ad-672ce7efc267@oracle.com> <5757BFAE.60007@oracle.com> <57583D14.5030403@oracle.com> Message-ID: <57586411.6060209@oracle.com> Hi Jon, Looks good and using WhiteBox for the test seems better. Thanks, Sangheon On 06/08/2016 08:43 AM, Jon Masamitsu wrote: > > > On 06/07/2016 11:48 PM, Stefan Johansson wrote: >> Hi Jon, >> >> On 2016-06-08 04:06, Jon Masamitsu wrote: >>> Please find the new versions of the webrevs >>> >>> http://cr.openjdk.java.net/~jmasa/8026752/webrev.01/ >>> http://cr.openjdk.java.net/~jmasa/8026752/top_webrev.01/ >>> >> Looks good. I think you could add >> Asserts.assertTrue(wb.metaspaceShouldConcurrentCollect()) before the >> call to System.gc() to make sure there was something to clear. No >> need to see a new webrev if you decide to do that. Reviewed. > > Thanks for the review. > > If you don't mind, I would rather not add the check before the > System.gc(). I > can think of different scenarios (unlikely perhaps) where the > should-concurrent-collect > flag would not be set for legitimate reasons and would prefer to avoid the > assertion failure in those cases. > > Jon > >> Thanks, >> Stefan >> >>> There is a delta (but I'd recommend just looking at the complete >>> webrevs). >>> >>> http://cr.openjdk.java.net/~jmasa/8026752/webrev_delta.00_01/ >>> >>> Thanks. >>> >>> Jon >>> >>> On 5/27/2016 8:17 AM, Jon Masamitsu wrote: >>>> Stefan, >>>> >>>> Thanks for looking at this. Please see in-line. >>>> >>>> On 5/27/2016 3:47 AM, Stefan Johansson wrote: >>>>> Hi Jon, >>>>> >>>>> On 2016-05-27 07:46, Jon Masamitsu wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8026752 >>>>>> >>>>>> If a concurrent CMS collection has been scheduled for Metaspace >>>>>> needs, it should be cancelled if a full GC is done. >>>>>> >>>>>> http://cr.openjdk.java.net/~jmasa/8026752/webrev.00/ >>>>>> >>>>>> Fix was verified with the new test TestMetaspaceCMSCancel.java >>>>>> Stability testing was done with gc_test_suite. >>>>>> >>>>> I think the fix is good. Just one question regarding where to do >>>>> the call. Is there a reason that you have put >>>>> MetaspaceGC::set_should_concurrent_collect(false) in >>>>> reset_after_compaction()? To me it would make more sense to have >>>>> the call in CMSCollector::do_compaction_work(...). >>>> >>>> No strong reason other than it is the place that occurred to me. >>>> That reset_after_compaction() was added to take care of work >>>> that needed to be done after a compaction so it seems a good >>>> place to me. If do_compaction_work() is a more obvious place to >>>> you, I can move it there. >>>> >>>>> >>>>> Regarding the test, I think it is a bit unfortunate to have to >>>>> sleep for 20s to verify this, especially since there have been >>>>> efforts to shorten the test-time. What do you think about adding a >>>>> WhiteBox-method for checking the value of >>>>> MetaspaceGC::_should_concurrent_collect and have the test be >>>>> something like: >>>>> assertTrue(WB.metaspaceShouldConcurrentCollect()); >>>>> System.gc(); >>>>> assertFalse(WB.metaspaceShouldConcurrentCollect()); >>>> >>>> Adding -XX:CMSWaitDuration=5000 to the command line makes it less >>>> likely that >>>> a CMS concurrent collections starts and finishes before the call to >>>> System.gc(). >>>> The small MetaspaceSize threshold may have been exceeded during >>>> loading of >>>> the systems classes (i.e., before the test program started >>>> running). Adding the >>>> pause() gives CMS time to start and complete a concurrent >>>> collection if the >>>> concurrent collection is not short-circuited by the fix. That is, I >>>> give the >>>> test a better chance of failing. >>>> >>>> I don't think it is quite enough to check MetaspaceGC >>>> _should_concurrent_collect >>>> because the concurrent collection could have already started. >>>> >>>> I could change the test to check the state of the CMS collector. >>>> It should be >>>> in "Resetting" or "Idling". I'll look into that. >>>> >>>> Thanks again. >>>> >>>> Jon >>>> >>>>> >>>>> Doing this you should be able to avoid using the process builder >>>>> as well. >>>>> >>>>> Thanks, >>>>> Stefan >>>>>> Thanks. >>>>>> >>>>>> Jon >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek.white at oracle.com Wed Jun 8 20:58:09 2016 From: derek.white at oracle.com (Derek White) Date: Wed, 8 Jun 2016 16:58:09 -0400 Subject: Request for Review (s) - 8157620: Guarantee in run_task(task, num_workers) fails In-Reply-To: <575851B9.2000308@oracle.com> References: <1465288614.2364.13.camel@oracle.com> <291abb42-2de9-36a3-9e74-dba128394e84@oracle.com> <575851B9.2000308@oracle.com> Message-ID: <120d54ab-6c3d-f2bf-1bdb-45a5ae331452@oracle.com> On 6/8/16 1:11 PM, Jon Masamitsu wrote: > Derek, > > Does this fix the issues you raised? > > http://cr.openjdk.java.net/~jmasa/8159073/webrev.00/ > > Jon > Hi Jon, Yes, that looks good! And to be clear, the original 8157620 looks good too. - Derek > > On 06/07/2016 01:43 PM, Derek White wrote: >> Hi Jon, >> >> The new code looks good! >> >> While reviewing this I looked over WorkerManager again, and saw a >> problem in the error handling: >> >> - Line 60 checks for errors creating the WorkerThread or OS thread. >> - Line 66-67 unconditionally update created_workers and tries to >> start a (possibly non-existent) thread. >> - And I don't like the spacing of line 61, but that's a nit. >> >> I'm not sure if this should get fixed as a separate change or as part >> of this one, but it looks bad. >> >> - Derek >> >> On 6/7/16 2:46 PM, Jon Masamitsu wrote: >>> New webrev and delta, respectively, with changes indicated below. >>> >>> http://cr.openjdk.java.net/~jmasa/8157620/webrev.01/ >>> >>> http://cr.openjdk.java.net/~jmasa/8157620/webrev_delta.00_01/ >>> >>> Jon >>> >>> On 6/7/2016 1:36 AM, Thomas Schatzl wrote: >>>> Hi Jon, >>>> >>>> On Fri, 2016-06-03 at 14:04 -0700, Jon Masamitsu wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8157620 >>>>> >>>>> A phase of a G1 collection chooses its own number of GC workers >>>>> but doesn't add more workers if more are needed than have been >>>>> created. Add additional workers as needed. Also changed the >>>>> guarantee to check the number of workers against the total number >>>>> of workers since the number of GC workers used to execute the >>>>> task may be different than active_workers (as in this case). >>>>> >>>>> Added an execution of TestGCOld with parameters that evoked the >>>>> failure. >>>>> >>>>> http://cr.openjdk.java.net/~jmasa/8157620/webrev.00/ >>>>> >>>>> Tested fix with TestGCOld. >>>>> Stability tested with gc_test_suite >>>>> >>>> looks good, with two comments: >>>> >>>> - I would _prefer_ if run_task(workgang, uint) always called >>>> add_workers() itself. Otherwise all of these invocations need to call >>>> add_workers() first themselves (if they do not limit themselves to >>>> active_workers). >>>> >>>> The run_task(workgang, uint) method has kind of been implemented as a >>>> short/quick way to run a workgang with a given number of threads, so >>>> this requirement adds additional boiler plate code again... >>>> >>>> - in the test, maybe put the -Xmx/-Xms right after the @run >>>> main/othervm like in the other tests just for consistency. >>>> >>>> --------------------- >>>> >>>> One comment related to the code changed, but unrelated to this CR: the >>>> code in G1ConcurrentMark::calc_parallel_marking_threads() looks >>>> (almost?) the same as AdaptiveSizePolicy::calc_active_conc_workers(). >>>> Any arguments about cleaning this up at some point? >>>> >>>> When looking at the calculation of the >>>> AdaptiveSizePolicy::calc_default_active_workers() method, wouldn't it >>>> be better if instead of using Universe::heap()->capacity(), use >>>> something like Universe::heap()->used() (and actually e.g. for g1 one >>>> could subtract young gen and areas covered by primitive arrays too). >>>> >>>> Actually, this calculation should be different for young/old gen gc >>>> imho, as for both completely different areas are covered by the >>>> collection... (just some random thoughts when looking at this). >>>> >>>> Thanks, >>>> Thomas >>>> >>> >> > From david.holmes at oracle.com Thu Jun 9 00:43:18 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Jun 2016 10:43:18 +1000 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 In-Reply-To: <57569540.9010106@oracle.com> References: <5746FDF3.3030102@oracle.com> <57569540.9010106@oracle.com> Message-ID: <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com> Hi Leonid, Sorry for the delay. On 7/06/2016 7:34 PM, Leonid Mesnik wrote: > Hi > > Added jtreg-use at openjdk.java.net > > I think that you are right. Here is the documentation: > http://openjdk.java.net/jtreg/tag-spec.html > > > "@requires > > Express a dependence on characteristics of the system being tested. > Some harnesses allow tests to be selected according to the > characteristics of the system being tested. The expression may be > composed of the following elements:" > > "os.arch The operating system architecture, as given by the > corresponding system property." > > So user could expect to have "os.arch" of tested VM. > > If filed jtreg issues for this: > > 1. CODETOOLS-7901695 > jtreg uses > value 'os.arch' property of JDK which executed JDK and not of tested JDK > > > Following fix could be used as a temporary workaround while jtreg fix is > not ready. Does it make a sense? I this case it is needed to change > linux-arm64 back to linux-aarch64 to minimize changes. I still think we have a fundamental problem concerning what os.arch means. This workaround seems to work but I find it all very confusing. We really need a vm.arch property, distinct from os.arch. David ----- > Leonid > > On 31.05.2016 04:26, David Holmes wrote: >> Hi Leonid, >> >> This really strikes me as as a jtreg problem that should be fixed in >> jtreg. When writing an @requires clause in a test the test writer >> should not have to be thinking "oh wait! Is this going to query the VM >> running jtreg or the VM running the test?". It should obviously be the >> VM running the test. >> >> That said we also seem to have a problem with the definition of os.arch: >> >> os.arch Operating system architecture >> >> if it is returning the build architecture of the VM and not the OS it >> is running on. That in itself argues for two distinct properties. >> >> David >> >> On 26/05/2016 11:45 PM, Leonid Mesnik wrote: >>> Hi >>> >>> Could you please review following fix: >>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/ >>> >>> hotspot http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/ >>> >>> for bug >>> https://bugs.openjdk.java.net/browse/JDK-8157831 >>> >>> >>> The property "os.name" which was used to filter tests depends on the >>> arch of jdk which is used to run jtreg. It might differ from arch of >>> tested jdk. >>> This fix introduce new property "vm.arch" which depends on the arch of >>> tested jdk and could be used to filter tests with @requires. >>> >>> I verified that tests are filtered where it is expected. >>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot >>> testing. >>> >>> Leonid >>> > From jon.masamitsu at oracle.com Thu Jun 9 04:02:46 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 8 Jun 2016 21:02:46 -0700 Subject: Request for Review (xs) - 8159073: Error handling incomplete when creating GC threads lazily Message-ID: <1208fcbd-ff75-cbce-1692-225280eeab52@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8159073 The error handling in add_workers() was not treating the non-initializing case correctly. If in the non-initializing case, it is OK to fail the creation of additional threads but the number of created threads should not be incremented nor non-existent thread started. http://cr.openjdk.java.net/~jmasa/8159073/webrev.00/ Tested with gc_test_suite with UseDynamicGCThreads turned on. Thanks. Jon From stefan.johansson at oracle.com Thu Jun 9 08:17:24 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 9 Jun 2016 10:17:24 +0200 Subject: Request for Review (s) 8026752: Cancel MetaspaceGC request for a CMS concurrent collection after GC In-Reply-To: <57583D14.5030403@oracle.com> References: <574825A8.80706@oracle.com> <1fa166df-b646-ead9-50ad-672ce7efc267@oracle.com> <5757BFAE.60007@oracle.com> <57583D14.5030403@oracle.com> Message-ID: <57592614.1070002@oracle.com> On 2016-06-08 17:43, Jon Masamitsu wrote: > > > On 06/07/2016 11:48 PM, Stefan Johansson wrote: >> Hi Jon, >> >> On 2016-06-08 04:06, Jon Masamitsu wrote: >>> Please find the new versions of the webrevs >>> >>> http://cr.openjdk.java.net/~jmasa/8026752/webrev.01/ >>> http://cr.openjdk.java.net/~jmasa/8026752/top_webrev.01/ >>> >> Looks good. I think you could add >> Asserts.assertTrue(wb.metaspaceShouldConcurrentCollect()) before the >> call to System.gc() to make sure there was something to clear. No >> need to see a new webrev if you decide to do that. Reviewed. > > Thanks for the review. > > If you don't mind, I would rather not add the check before the > System.gc(). I > can think of different scenarios (unlikely perhaps) where the > should-concurrent-collect > flag would not be set for legitimate reasons and would prefer to avoid the > assertion failure in those cases. Sounds good, Stefan > > Jon > >> Thanks, >> Stefan >> >>> There is a delta (but I'd recommend just looking at the complete >>> webrevs). >>> >>> http://cr.openjdk.java.net/~jmasa/8026752/webrev_delta.00_01/ >>> >>> Thanks. >>> >>> Jon >>> >>> On 5/27/2016 8:17 AM, Jon Masamitsu wrote: >>>> Stefan, >>>> >>>> Thanks for looking at this. Please see in-line. >>>> >>>> On 5/27/2016 3:47 AM, Stefan Johansson wrote: >>>>> Hi Jon, >>>>> >>>>> On 2016-05-27 07:46, Jon Masamitsu wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8026752 >>>>>> >>>>>> If a concurrent CMS collection has been scheduled for Metaspace >>>>>> needs, it should be cancelled if a full GC is done. >>>>>> >>>>>> http://cr.openjdk.java.net/~jmasa/8026752/webrev.00/ >>>>>> >>>>>> Fix was verified with the new test TestMetaspaceCMSCancel.java >>>>>> Stability testing was done with gc_test_suite. >>>>>> >>>>> I think the fix is good. Just one question regarding where to do >>>>> the call. Is there a reason that you have put >>>>> MetaspaceGC::set_should_concurrent_collect(false) in >>>>> reset_after_compaction()? To me it would make more sense to have >>>>> the call in CMSCollector::do_compaction_work(...). >>>> >>>> No strong reason other than it is the place that occurred to me. >>>> That reset_after_compaction() was added to take care of work >>>> that needed to be done after a compaction so it seems a good >>>> place to me. If do_compaction_work() is a more obvious place to >>>> you, I can move it there. >>>> >>>>> >>>>> Regarding the test, I think it is a bit unfortunate to have to >>>>> sleep for 20s to verify this, especially since there have been >>>>> efforts to shorten the test-time. What do you think about adding a >>>>> WhiteBox-method for checking the value of >>>>> MetaspaceGC::_should_concurrent_collect and have the test be >>>>> something like: >>>>> assertTrue(WB.metaspaceShouldConcurrentCollect()); >>>>> System.gc(); >>>>> assertFalse(WB.metaspaceShouldConcurrentCollect()); >>>> >>>> Adding -XX:CMSWaitDuration=5000 to the command line makes it less >>>> likely that >>>> a CMS concurrent collections starts and finishes before the call to >>>> System.gc(). >>>> The small MetaspaceSize threshold may have been exceeded during >>>> loading of >>>> the systems classes (i.e., before the test program started >>>> running). Adding the >>>> pause() gives CMS time to start and complete a concurrent >>>> collection if the >>>> concurrent collection is not short-circuited by the fix. That is, I >>>> give the >>>> test a better chance of failing. >>>> >>>> I don't think it is quite enough to check MetaspaceGC >>>> _should_concurrent_collect >>>> because the concurrent collection could have already started. >>>> >>>> I could change the test to check the state of the CMS collector. >>>> It should be >>>> in "Resetting" or "Idling". I'll look into that. >>>> >>>> Thanks again. >>>> >>>> Jon >>>> >>>>> >>>>> Doing this you should be able to avoid using the process builder >>>>> as well. >>>>> >>>>> Thanks, >>>>> Stefan >>>>>> Thanks. >>>>>> >>>>>> Jon >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From qwwdfsad at gmail.com Thu Jun 9 08:26:07 2016 From: qwwdfsad at gmail.com (=?UTF-8?B?0JLRgdC10LLQvtC70L7QtCDQotC+0LvRgdGC0L7Qv9GP0YLQvtCy?=) Date: Thu, 9 Jun 2016 11:26:07 +0300 Subject: RFR (S): 8142749: HeapRegion cleanup In-Reply-To: References: Message-ID: Thanks for review and sponsoring! > Note that at the moment are past the JDK9 FC date, and we should not > integrate enhancements right now. There is no process at the moment if > and how these can be integrated. So it may take a while to push the > change. Should I wait until JDK10 forest and ping someone? Should I update webrev with includes cleanup now or wait until new forest? Does it make sense to keep making reviews for simple bugs (e.g. like JDK-8151045) or it's better to wait until new forest (note that I'm not openjdk author yet, so these questions could have obvious answers)? -- Best regards, Tolstopyatov Vsevolod On Wed, Jun 8, 2016 at 12:51 AM, Derek White wrote: > On 5/30/16 8:05 AM, ???????? ??????????? wrote: > > Hi all, > Please review and sponsor this change for JDK-8142749. > Note that not only HeapRegion::_predicted_bytes_to_copy related code was > removed, but also some unused (since the first commit) method/class > parameters and HeapRegion::object_iterate_mem_careful method. All changed > files contain at least several unused includes, but I'm not sure it's > applicable to remove them in this patch. > > CR: https://bugs.openjdk.java.net/browse/JDK-8142749 > Webrev: > http://cr.openjdk.java.net/~fzhinkin/vtolstopyatov/8142749/webrev.00/ > Testing: hotspot_gc tests > > -- > Best regards, > Tolstopyatov Vsevolod > > Looks good! > > > - Derek > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.helin at oracle.com Thu Jun 9 08:33:12 2016 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 9 Jun 2016 10:33:12 +0200 Subject: Request for Review (xs) - 8159073: Error handling incomplete when creating GC threads lazily In-Reply-To: <1208fcbd-ff75-cbce-1692-225280eeab52@oracle.com> References: <1208fcbd-ff75-cbce-1692-225280eeab52@oracle.com> Message-ID: <20160609083312.GI26799@ehelin.jrpg.bea.com> On 2016-06-08, Jon Masamitsu wrote: > https://bugs.openjdk.java.net/browse/JDK-8159073 > > The error handling in add_workers() was not treating the non-initializing > case correctly. If in the non-initializing case, it is OK to fail the > creation > of additional threads but the number of created threads should not be > incremented nor non-existent thread started. > > http://cr.openjdk.java.net/~jmasa/8159073/webrev.00/ Should we add some logging in case the code fail to create a worker thread (in the non initializing case)? Thanks, Erik > Tested with gc_test_suite with UseDynamicGCThreads turned on. > > Thanks. > > Jon From thomas.schatzl at oracle.com Thu Jun 9 09:04:25 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 09 Jun 2016 11:04:25 +0200 Subject: Request for Review (s) - 8157620: Guarantee in run_task(task, num_workers) fails In-Reply-To: References: <1465288614.2364.13.camel@oracle.com> Message-ID: <1465463065.2519.0.camel@oracle.com> Hi, On Tue, 2016-06-07 at 11:46 -0700, Jon Masamitsu wrote: > New webrev and delta, respectively, with changes indicated below. > > http://cr.openjdk.java.net/~jmasa/8157620/webrev.01/ > > http://cr.openjdk.java.net/~jmasa/8157620/webrev_delta.00_01/ > > Jon > ? looks good. Thanks, ? Thomas From Leonid.Mesnik at oracle.com Thu Jun 9 12:30:49 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Thu, 9 Jun 2016 15:30:49 +0300 Subject: RFR: 8156032: Clean up parallel GC specific code from vm/gc/shared/preservedMarks.cpp In-Reply-To: <57582A02.10901@oracle.com> References: <5756CD8B.90200@oracle.com> <57582A02.10901@oracle.com> Message-ID: <57596179.5070407@oracle.com> Hi Thank you for review. Updated webrev is here: http://cr.openjdk.java.net/~lmesnik/8156032/webrev.01/ See comments inline: On 08.06.2016 17:21, Stefan Karlsson wrote: > Hi Leonid, > > Thanks for cleaning this up! > > See comments inlined: > > On 2016-06-07 15:35, Leonid Mesnik wrote: >> Hi >> >> Could you please review following patch which remove PS specific code >> from vm/gc/shared. >> Webrev: http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8156032 > > http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/src/share/vm/gc/parallel/psPromotionManager.cpp.udiff.html > > http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/src/share/vm/gc/shared/preservedMarks.hpp.udiff.html > > > +class PSPreservedMarksTaskExecutor : public > RestorePreservedMarksTaskExecutor > > +class SharedPreservedMarksTaskExecutor : public > RestorePreservedMarksTaskExecutor > > > Should the subclasses also mention the word Restore? Fixed. > > ------ > > http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/src/share/vm/gc/shared/preservedMarks.hpp.udiff.html > > > +public: > + WorkGang* workers; > + > > > workers should be private and named _workers. Fixed. Also PSRestorePreservedMarksTaskExecutor is updated to have _gc_task_manager as a private member. > > --- > > + void restore(PreservedMarksSet* preserved_marks_set, > + volatile size_t* total_size_addr); > > Would you mind aligning the parameters? Done. > > --- > > + // Iterate over all stacks, restore all preserved marks, and reclaim > + // the memory taken up by the stack segments. > + // Supported executors: WorkerPresevedMarksTaskExecutor (Serial, > CMS, G1), > + // PSManagerTaskExecutor (PS). > > > The comment refers to the old names of subclasses of > RestorePreservedMarksTaskExecutor. Comments have been updated with current names. Leonid > > Thanks, > StefanK > >> >> Fix is tested with JPRT. >> >> Leonid > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Thu Jun 9 12:50:42 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 9 Jun 2016 14:50:42 +0200 Subject: RFR: 8156032: Clean up parallel GC specific code from vm/gc/shared/preservedMarks.cpp In-Reply-To: <57596179.5070407@oracle.com> References: <5756CD8B.90200@oracle.com> <57582A02.10901@oracle.com> <57596179.5070407@oracle.com> Message-ID: <57596622.7010300@oracle.com> Hi Leonid, On 2016-06-09 14:30, Leonid Mesnik wrote: > Hi > > Thank you for review. Updated webrev is here: > http://cr.openjdk.java.net/~lmesnik/8156032/webrev.01/ > Looks good. Thanks, StefanK > > See comments inline: > > On 08.06.2016 17:21, Stefan Karlsson wrote: >> Hi Leonid, >> >> Thanks for cleaning this up! >> >> See comments inlined: >> >> On 2016-06-07 15:35, Leonid Mesnik wrote: >>> Hi >>> >>> Could you please review following patch which remove PS specific >>> code from vm/gc/shared. >>> Webrev: http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/ >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156032 >> >> http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/src/share/vm/gc/parallel/psPromotionManager.cpp.udiff.html >> >> http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/src/share/vm/gc/shared/preservedMarks.hpp.udiff.html >> >> >> +class PSPreservedMarksTaskExecutor : public >> RestorePreservedMarksTaskExecutor >> >> +class SharedPreservedMarksTaskExecutor : public >> RestorePreservedMarksTaskExecutor >> >> >> Should the subclasses also mention the word Restore? > Fixed. >> >> ------ >> >> http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/src/share/vm/gc/shared/preservedMarks.hpp.udiff.html >> >> >> +public: >> + WorkGang* workers; >> + >> >> >> workers should be private and named _workers. > Fixed. Also PSRestorePreservedMarksTaskExecutor is updated to have > _gc_task_manager as a private member. >> >> --- >> >> + void restore(PreservedMarksSet* preserved_marks_set, >> + volatile size_t* total_size_addr); >> >> Would you mind aligning the parameters? > Done. >> >> --- >> >> + // Iterate over all stacks, restore all preserved marks, and reclaim >> + // the memory taken up by the stack segments. >> + // Supported executors: WorkerPresevedMarksTaskExecutor (Serial, >> CMS, G1), >> + // PSManagerTaskExecutor (PS). >> >> >> The comment refers to the old names of subclasses of >> RestorePreservedMarksTaskExecutor. > Comments have been updated with current names. > > Leonid >> >> Thanks, >> StefanK >> >>> >>> Fix is tested with JPRT. >>> >>> Leonid >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Leonid.Mesnik at oracle.com Thu Jun 9 13:05:04 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Thu, 9 Jun 2016 16:05:04 +0300 Subject: RFR: 8156032: Clean up parallel GC specific code from vm/gc/shared/preservedMarks.cpp In-Reply-To: <57596622.7010300@oracle.com> References: <5756CD8B.90200@oracle.com> <57582A02.10901@oracle.com> <57596179.5070407@oracle.com> <57596622.7010300@oracle.com> Message-ID: <57596980.9050506@oracle.com> Thank you Leonid On 09.06.2016 15:50, Stefan Karlsson wrote: > Hi Leonid, > > On 2016-06-09 14:30, Leonid Mesnik wrote: >> Hi >> >> Thank you for review. Updated webrev is here: >> http://cr.openjdk.java.net/~lmesnik/8156032/webrev.01/ >> > > Looks good. > > Thanks, > StefanK > >> >> See comments inline: >> >> On 08.06.2016 17:21, Stefan Karlsson wrote: >>> Hi Leonid, >>> >>> Thanks for cleaning this up! >>> >>> See comments inlined: >>> >>> On 2016-06-07 15:35, Leonid Mesnik wrote: >>>> Hi >>>> >>>> Could you please review following patch which remove PS specific >>>> code from vm/gc/shared. >>>> Webrev: http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/ >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156032 >>> >>> http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/src/share/vm/gc/parallel/psPromotionManager.cpp.udiff.html >>> >>> http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/src/share/vm/gc/shared/preservedMarks.hpp.udiff.html >>> >>> >>> +class PSPreservedMarksTaskExecutor : public >>> RestorePreservedMarksTaskExecutor >>> >>> +class SharedPreservedMarksTaskExecutor : public >>> RestorePreservedMarksTaskExecutor >>> >>> >>> Should the subclasses also mention the word Restore? >> Fixed. >>> >>> ------ >>> >>> http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/src/share/vm/gc/shared/preservedMarks.hpp.udiff.html >>> >>> >>> +public: >>> + WorkGang* workers; >>> + >>> >>> >>> workers should be private and named _workers. >> Fixed. Also PSRestorePreservedMarksTaskExecutor is updated to have >> _gc_task_manager as a private member. >>> >>> --- >>> >>> + void restore(PreservedMarksSet* preserved_marks_set, >>> + volatile size_t* total_size_addr); >>> >>> Would you mind aligning the parameters? >> Done. >>> >>> --- >>> >>> + // Iterate over all stacks, restore all preserved marks, and reclaim >>> + // the memory taken up by the stack segments. >>> + // Supported executors: WorkerPresevedMarksTaskExecutor (Serial, >>> CMS, G1), >>> + // PSManagerTaskExecutor (PS). >>> >>> >>> The comment refers to the old names of subclasses of >>> RestorePreservedMarksTaskExecutor. >> Comments have been updated with current names. >> >> Leonid >>> >>> Thanks, >>> StefanK >>> >>>> >>>> Fix is tested with JPRT. >>>> >>>> Leonid >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Leonid.Mesnik at oracle.com Thu Jun 9 13:13:02 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Thu, 9 Jun 2016 16:13:02 +0300 Subject: RFR: 8156032: Clean up parallel GC specific code from vm/gc/shared/preservedMarks.cpp In-Reply-To: <57596980.9050506@oracle.com> References: <5756CD8B.90200@oracle.com> <57582A02.10901@oracle.com> <57596179.5070407@oracle.com> <57596622.7010300@oracle.com> <57596980.9050506@oracle.com> Message-ID: <57596B5E.5070103@oracle.com> It seems that I need one more review for this fix. Could anyone looks on it? Leonid On 09.06.2016 16:05, Leonid Mesnik wrote: > Thank you > > Leonid > > On 09.06.2016 15:50, Stefan Karlsson wrote: >> Hi Leonid, >> >> On 2016-06-09 14:30, Leonid Mesnik wrote: >>> Hi >>> >>> Thank you for review. Updated webrev is here: >>> http://cr.openjdk.java.net/~lmesnik/8156032/webrev.01/ >>> >> >> Looks good. >> >> Thanks, >> StefanK >> >>> >>> See comments inline: >>> >>> On 08.06.2016 17:21, Stefan Karlsson wrote: >>>> Hi Leonid, >>>> >>>> Thanks for cleaning this up! >>>> >>>> See comments inlined: >>>> >>>> On 2016-06-07 15:35, Leonid Mesnik wrote: >>>>> Hi >>>>> >>>>> Could you please review following patch which remove PS specific >>>>> code from vm/gc/shared. >>>>> Webrev: http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/ >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156032 >>>> >>>> http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/src/share/vm/gc/parallel/psPromotionManager.cpp.udiff.html >>>> >>>> http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/src/share/vm/gc/shared/preservedMarks.hpp.udiff.html >>>> >>>> >>>> +class PSPreservedMarksTaskExecutor : public >>>> RestorePreservedMarksTaskExecutor >>>> >>>> +class SharedPreservedMarksTaskExecutor : public >>>> RestorePreservedMarksTaskExecutor >>>> >>>> >>>> Should the subclasses also mention the word Restore? >>> Fixed. >>>> >>>> ------ >>>> >>>> http://cr.openjdk.java.net/~lmesnik/8156032/webrev.00/src/share/vm/gc/shared/preservedMarks.hpp.udiff.html >>>> >>>> >>>> +public: >>>> + WorkGang* workers; >>>> + >>>> >>>> >>>> workers should be private and named _workers. >>> Fixed. Also PSRestorePreservedMarksTaskExecutor is updated to have >>> _gc_task_manager as a private member. >>>> >>>> --- >>>> >>>> + void restore(PreservedMarksSet* preserved_marks_set, >>>> + volatile size_t* total_size_addr); >>>> >>>> Would you mind aligning the parameters? >>> Done. >>>> >>>> --- >>>> >>>> + // Iterate over all stacks, restore all preserved marks, and reclaim >>>> + // the memory taken up by the stack segments. >>>> + // Supported executors: WorkerPresevedMarksTaskExecutor (Serial, >>>> CMS, G1), >>>> + // PSManagerTaskExecutor (PS). >>>> >>>> >>>> The comment refers to the old names of subclasses of >>>> RestorePreservedMarksTaskExecutor. >>> Comments have been updated with current names. >>> >>> Leonid >>>> >>>> Thanks, >>>> StefanK >>>> >>>>> >>>>> Fix is tested with JPRT. >>>>> >>>>> Leonid >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Thu Jun 9 13:44:11 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 09 Jun 2016 15:44:11 +0200 Subject: RFR: 8156032: Clean up parallel GC specific code from vm/gc/shared/preservedMarks.cpp In-Reply-To: <57596179.5070407@oracle.com> References: <5756CD8B.90200@oracle.com> <57582A02.10901@oracle.com> <57596179.5070407@oracle.com> Message-ID: <1465479851.2519.1.camel@oracle.com> Hi, On Thu, 2016-06-09 at 15:30 +0300, Leonid Mesnik wrote: > Hi > > Thank you for review. Updated webrev is here: > http://cr.openjdk.java.net/~lmesnik/8156032/webrev.01/ > ? looks good. Thanks for taking this over. Thomas From Leonid.Mesnik at oracle.com Thu Jun 9 21:35:52 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Fri, 10 Jun 2016 00:35:52 +0300 Subject: RFR: 8156032: Clean up parallel GC specific code from vm/gc/shared/preservedMarks.cpp In-Reply-To: <1465479851.2519.1.camel@oracle.com> References: <5756CD8B.90200@oracle.com> <57582A02.10901@oracle.com> <57596179.5070407@oracle.com> <1465479851.2519.1.camel@oracle.com> Message-ID: <5759E138.5070001@oracle.com> Thank you for review. Leonid On 09.06.2016 16:44, Thomas Schatzl wrote: > Hi, > > On Thu, 2016-06-09 at 15:30 +0300, Leonid Mesnik wrote: >> Hi >> >> Thank you for review. Updated webrev is here: >> http://cr.openjdk.java.net/~lmesnik/8156032/webrev.01/ >> > looks good. Thanks for taking this over. > > Thomas > From thomas.schatzl at oracle.com Fri Jun 10 10:02:33 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 10 Jun 2016 12:02:33 +0200 Subject: PING: RFR: JDK-8155730: HeapInfoDCmd should get Heap_lock In-Reply-To: <4ffc0582-f2c0-4724-f21e-2a6510c4da95@gmail.com> References: <955b8a22-d35c-60dc-e202-991b5a5e432d@gmail.com> <5583e9c0-8f16-72d0-ee55-a30246ab5bc8@oracle.com> <0b5bbf95-c871-f504-d96c-a08ae5277240@gmail.com> <0fccf86b-5ba8-cb3c-f253-d56cc7d1684d@oracle.com> <90b138a9-f67e-4141-fa63-71942c30e91d@gmail.com> <73d13ea4-7d0a-8bb5-6dea-be6c22d08066@oracle.com> <7881a764-1ac2-116e-da54-e57e043a930f@gmail.com> <4ffc0582-f2c0-4724-f21e-2a6510c4da95@gmail.com> Message-ID: <1465552953.2513.1.camel@oracle.com> Hi Yasumasa, On Thu, 2016-06-02 at 22:36 +0900, Yasumasa Suenaga wrote: > PING: Could you review it? >? > >? > > >? > > >???http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ >? > Yasumasa >? ? looks okay to me. I will run the change through some testing. Thanks, ? Thomas From thomas.schatzl at oracle.com Fri Jun 10 10:05:20 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 10 Jun 2016 12:05:20 +0200 Subject: RFR(S): 8132711: Add tests which check that Humongous objects behave as expected after Mixed GC In-Reply-To: <573315FD.5050109@oracle.com> References: <573315FD.5050109@oracle.com> Message-ID: <1465553120.2513.2.camel@oracle.com> Hi, On Wed, 2016-05-11 at 14:22 +0300, Kirill Zhaldbybin wrote: > Dear all, > > Could you please review this fix for 8132711? > > This fix adds Mixed GC scenario to? > gc/g1/humongousObjects/objectGraphTest/TestObjectGraphAfterGC.java > which? > creates different types of object graphs with Object arrays as nodes > (to? > make them humongous) and checks that after different types GCs > objects'? > graphs were handled correctly. > > During Mixed GC scenario the test expects that all weakly reachable? > nodes should be collected since non-humongous nodes were previously? > promoted to old gen and several gc options were specified to > guarantee? > that mixed gc collects all weakly unreachable objects in old gen. > Softly reachable nodes should not be collected. > > WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132711/webr > ev.00/ > CR: https://bugs.openjdk.java.net/browse/JDK-8132711 > ? looks okay. Thomas From yasuenag at gmail.com Fri Jun 10 12:13:48 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 10 Jun 2016 21:13:48 +0900 Subject: PING: RFR: JDK-8155730: HeapInfoDCmd should get Heap_lock In-Reply-To: <1465552953.2513.1.camel@oracle.com> References: <955b8a22-d35c-60dc-e202-991b5a5e432d@gmail.com> <5583e9c0-8f16-72d0-ee55-a30246ab5bc8@oracle.com> <0b5bbf95-c871-f504-d96c-a08ae5277240@gmail.com> <0fccf86b-5ba8-cb3c-f253-d56cc7d1684d@oracle.com> <90b138a9-f67e-4141-fa63-71942c30e91d@gmail.com> <73d13ea4-7d0a-8bb5-6dea-be6c22d08066@oracle.com> <7881a764-1ac2-116e-da54-e57e043a930f@gmail.com> <4ffc0582-f2c0-4724-f21e-2a6510c4da95@gmail.com> <1465552953.2513.1.camel@oracle.com> Message-ID: <3f8b8f56-0149-c490-fed1-b027f509f754@gmail.com> Thanks Thomas! I'm waiting second reviewer. Yasumasa On 2016/06/10 19:02, Thomas Schatzl wrote: > > Hi Yasumasa, > > On Thu, 2016-06-02 at 22:36 +0900, Yasumasa Suenaga wrote: >> PING: Could you review it? >> >>> >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ >> >> Yasumasa >> > > looks okay to me. I will run the change through some testing. > > Thanks, > Thomas > From stefan.karlsson at oracle.com Fri Jun 10 12:18:08 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 10 Jun 2016 14:18:08 +0200 Subject: RFR: 8159237: PreservedMarks verification code fails Message-ID: <575AB000.304@oracle.com> Hi all, Please review this patch to fix a recently introduced bug in the verification code of the preserved marks code: http://cr.openjdk.java.net/~stefank/8159237/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8159237 The bug was introduced when the following code: volatile size_t total_size = 0; ... for (uint i = 0; i < _num; i += 1) { total_size += get(i)->size(); get(i)->restore(); } was moved into a separate function and the address to total_size was passed as an argument to the new function. The new function incorrectly updates the pointer and not the variable that the pointer points to: total_size_addr += preserved_marks_set->get(i)->size(); The suggested fix for the bug is: - total_size_addr += preserved_marks_set->get(i)->size(); + *total_size_addr += preserved_marks_set->get(i)->size(); Thanks, StefanK From Leonid.Mesnik at oracle.com Fri Jun 10 12:27:28 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Fri, 10 Jun 2016 15:27:28 +0300 Subject: RFR: 8159237: PreservedMarks verification code fails In-Reply-To: <575AB000.304@oracle.com> References: <575AB000.304@oracle.com> Message-ID: <575AB230.5090905@oracle.com> Hi Looks good. Thank you fixing this. Please get a 'R'eview from Reviewer. Leonid On 10.06.2016 15:18, Stefan Karlsson wrote: > Hi all, > > Please review this patch to fix a recently introduced bug in the > verification code of the preserved marks code: > > http://cr.openjdk.java.net/~stefank/8159237/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8159237 > > The bug was introduced when the following code: > > volatile size_t total_size = 0; ... for (uint i = 0; i < _num; i += 1) { > total_size += get(i)->size(); > get(i)->restore(); > } > > was moved into a separate function and the address to total_size was > passed as an argument to the new function. The new function > incorrectly updates the pointer and not the variable that the pointer > points to: > > total_size_addr += preserved_marks_set->get(i)->size(); > > The suggested fix for the bug is: > > - total_size_addr += preserved_marks_set->get(i)->size(); > + *total_size_addr += preserved_marks_set->get(i)->size(); > > > Thanks, > StefanK > From kirill.zhaldybin at oracle.com Fri Jun 10 12:42:18 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Fri, 10 Jun 2016 15:42:18 +0300 Subject: RFR(S): 8132711: Add tests which check that Humongous objects behave as expected after Mixed GC In-Reply-To: <1465553120.2513.2.camel@oracle.com> References: <573315FD.5050109@oracle.com> <1465553120.2513.2.camel@oracle.com> Message-ID: <575AB5AA.1050208@oracle.com> Thomas, Thank you for review! Regards, Kirill On 10.06.2016 13:05, Thomas Schatzl wrote: > Hi, > > On Wed, 2016-05-11 at 14:22 +0300, Kirill Zhaldbybin wrote: >> Dear all, >> >> Could you please review this fix for 8132711? >> >> This fix adds Mixed GC scenario to >> gc/g1/humongousObjects/objectGraphTest/TestObjectGraphAfterGC.java >> which >> creates different types of object graphs with Object arrays as nodes >> (to >> make them humongous) and checks that after different types GCs >> objects' >> graphs were handled correctly. >> >> During Mixed GC scenario the test expects that all weakly reachable >> nodes should be collected since non-humongous nodes were previously >> promoted to old gen and several gc options were specified to >> guarantee >> that mixed gc collects all weakly unreachable objects in old gen. >> Softly reachable nodes should not be collected. >> >> WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132711/webr >> ev.00/ >> CR: https://bugs.openjdk.java.net/browse/JDK-8132711 >> > > looks okay. > > Thomas > From jesper.wilhelmsson at oracle.com Fri Jun 10 13:54:41 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 10 Jun 2016 15:54:41 +0200 Subject: RFR: 8159237: PreservedMarks verification code fails In-Reply-To: <575AB000.304@oracle.com> References: <575AB000.304@oracle.com> Message-ID: Looks good! /Jesper Den 10/6/16 kl. 14:18, skrev Stefan Karlsson: > Hi all, > > Please review this patch to fix a recently introduced bug in the verification > code of the preserved marks code: > > http://cr.openjdk.java.net/~stefank/8159237/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8159237 > > The bug was introduced when the following code: > > volatile size_t total_size = 0; ... for (uint i = 0; i < _num; i += 1) { > total_size += get(i)->size(); > get(i)->restore(); > } > > was moved into a separate function and the address to total_size was passed as > an argument to the new function. The new function incorrectly updates the > pointer and not the variable that the pointer points to: > > total_size_addr += preserved_marks_set->get(i)->size(); > > The suggested fix for the bug is: > > - total_size_addr += preserved_marks_set->get(i)->size(); > + *total_size_addr += preserved_marks_set->get(i)->size(); > > > Thanks, > StefanK > From stefan.karlsson at oracle.com Fri Jun 10 13:54:52 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 10 Jun 2016 15:54:52 +0200 Subject: RFR: 8159237: PreservedMarks verification code fails In-Reply-To: <575AB000.304@oracle.com> References: <575AB000.304@oracle.com> Message-ID: <575AC6AC.5080306@oracle.com> Thanks Leonid and Jesper for reviewing this fix. This is causing failures in our nightly testing so'll push it immediately. StefanK On 2016-06-10 14:18, Stefan Karlsson wrote: > Hi all, > > Please review this patch to fix a recently introduced bug in the > verification code of the preserved marks code: > > http://cr.openjdk.java.net/~stefank/8159237/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8159237 > > The bug was introduced when the following code: > > volatile size_t total_size = 0; ... for (uint i = 0; i < _num; i += 1) { > total_size += get(i)->size(); > get(i)->restore(); > } > > was moved into a separate function and the address to total_size was > passed as an argument to the new function. The new function > incorrectly updates the pointer and not the variable that the pointer > points to: > > total_size_addr += preserved_marks_set->get(i)->size(); > > The suggested fix for the bug is: > > - total_size_addr += preserved_marks_set->get(i)->size(); > + *total_size_addr += preserved_marks_set->get(i)->size(); > > > Thanks, > StefanK > From dmitry.fazunenko at oracle.com Fri Jun 10 16:04:53 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 10 Jun 2016 19:04:53 +0300 Subject: RFR(s): 8151283: Implement setting jtreg @requires property vm.isG1Supported. Message-ID: Hello, I'm looking for a couple of Reviewers for a simple change, which allows to skip tests depending on non supported garbage collectors. http://cr.openjdk.java.net/~dfazunen/8151283/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8151283 The fix introduces four new requires boolean properties: vm.gc.G1.acceptable vm.gc.Serial.acceptable vm.gc.Parallel.acceptable vm.gc.ConcMarkSweep.acceptable Which are set by the jtreg plugin prior the test execution starts. After that fix we will be able to replace in tests: @requires vm.gc == null | vm.gc == "G1" with @requires vm.gc.G1.acceptable 'vm.gc.G1.acceptable' will be evaluated to 'false' not only if other GC is set externally, but also if G1 is not supported. In other words the fix allows not to run GC specific tests in not applicable configurations. Thanks, Dima From jon.masamitsu at oracle.com Sat Jun 11 01:35:54 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 10 Jun 2016 18:35:54 -0700 Subject: Future of CMS In-Reply-To: References: Message-ID: Added hotspot-gc-dev. On 6/10/2016 6:17 PM, Jon Masamitsu wrote: > Jungwoo, Ramki, Tony (and other friends of CMS), > > I wanted to be sure you guys saw this JEP. > > Deprecate the CMS garbage collector (UseConcMarkSweepGC). > http://openjdk.java.net/jeps/8142518 > > I know you do development on CMS and wanted to know if > had thoughts about the future of CMS. > > At some point Oracle is going to stop supporting CMS. > The burden of testing and maintaining the CMS code doesn't > make much sense given that we think G1 is the better > collector. If we deprecate CMS in jdk9, support would be dropped > no earlier than jdk10. > > Have you guys talked about what you would like to do with regard > to continuing CMS development without Oracle's help? > > I've been told that if CMS exists in the Oracle binaries, then > customers will expect it to work. So not supporting CMS > means it is not in the build. > > Jon From kirk at kodewerk.com Sat Jun 11 08:56:31 2016 From: kirk at kodewerk.com (kirk at kodewerk.com) Date: Sat, 11 Jun 2016 10:56:31 +0200 Subject: Future of CMS In-Reply-To: References: Message-ID: <2DC8ADA8-A5C4-4152-9F9C-506D8B565D57@kodewerk.com> Hi Jon, I question that the current implementation of G1 is better than CMS. Though I do try to move my clients to G1, there are still many cases where I can get much less GC interference with CMS than I can with the G1. I can look into sending you side by side GC logs if you are interested in a visualization. At the very least I can send you contrasting Censum screenshot. Kind regards, Kirk Pepperdine > On Jun 11, 2016, at 3:35 AM, Jon Masamitsu wrote: > > Added hotspot-gc-dev. > > On 6/10/2016 6:17 PM, Jon Masamitsu wrote: >> Jungwoo, Ramki, Tony (and other friends of CMS), >> >> I wanted to be sure you guys saw this JEP. >> >> Deprecate the CMS garbage collector (UseConcMarkSweepGC). >> http://openjdk.java.net/jeps/8142518 >> >> I know you do development on CMS and wanted to know if >> had thoughts about the future of CMS. >> >> At some point Oracle is going to stop supporting CMS. >> The burden of testing and maintaining the CMS code doesn't >> make much sense given that we think G1 is the better >> collector. If we deprecate CMS in jdk9, support would be dropped >> no earlier than jdk10. >> >> Have you guys talked about what you would like to do with regard >> to continuing CMS development without Oracle's help? >> >> I've been told that if CMS exists in the Oracle binaries, then >> customers will expect it to work. So not supporting CMS >> means it is not in the build. >> >> Jon > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From volker.simonis at gmail.com Sat Jun 11 13:37:48 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 11 Jun 2016 15:37:48 +0200 Subject: Future of CMS In-Reply-To: References: Message-ID: Hi Jon, I'm a little bit disappointed that you didn't think about SAP when you sent your initial mail ;) But seriously: SAP is supporting CMS and will probably do so for quite a long time (simply because we do support old Java releases for a very long time). Completely removing CMS from the HotSpot code base may increase these support costs considerably for us. Do you plan to really delete the sources from the repos or do you only plan to disable it at build time? I think only disable it at build time would make it easier for us and others to still support it in the future. But in that case we really have to come up with a better development model which would allow external developers to directly push CMS changes (much like ppc64 or aarch64 changes). Everything else would be a real PITA. Thank you and best regards, Volker On Saturday, June 11, 2016, Jon Masamitsu wrote: > Added hotspot-gc-dev. > > On 6/10/2016 6:17 PM, Jon Masamitsu wrote: > >> Jungwoo, Ramki, Tony (and other friends of CMS), >> >> I wanted to be sure you guys saw this JEP. >> >> Deprecate the CMS garbage collector (UseConcMarkSweepGC). >> http://openjdk.java.net/jeps/8142518 >> >> I know you do development on CMS and wanted to know if >> had thoughts about the future of CMS. >> >> At some point Oracle is going to stop supporting CMS. >> The burden of testing and maintaining the CMS code doesn't >> make much sense given that we think G1 is the better >> collector. If we deprecate CMS in jdk9, support would be dropped >> no earlier than jdk10. >> >> Have you guys talked about what you would like to do with regard >> to continuing CMS development without Oracle's help? >> >> I've been told that if CMS exists in the Oracle binaries, then >> customers will expect it to work. So not supporting CMS >> means it is not in the build. >> >> Jon >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Sat Jun 11 15:48:01 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Sat, 11 Jun 2016 08:48:01 -0700 Subject: Future of CMS In-Reply-To: References: Message-ID: <802e0838-59a2-0f6c-4953-3c6bd2ef6f58@oracle.com> Hi Ramki, I added the hotspot-gc-dev mailing list to the CC. It should have been there all the time. On 6/10/2016 6:43 PM, Ramki Ramakrishna wrote: > Hi Jon -- > > How are you? Thanks for the heads-up; we really appreciate it! > > I suspect the right thing to do in that case is to split the CMS code > off into its own subdirectory (which is to a certain degree already > the case), and to allow the possibility of building it or not based on > a build time option or make target. > That way the OpenJDK community can continue to use it while Oracle can > stop worrying about it. I think that would fit our needs. > > May be we can discuss this within our respective teams and then we can > meet to discuss the details of how to make this work? It would be nice to get a list of companies that would like to be involved. Maybe an Openjdk project. Eventually with its own mailing list. > > I haven't been monitoring the gc/openjdk aliases. If this is being > discussed there (and that would be the right place so any othe teams > interested in CMS can have a voice), we'll make sure to join that > discussion. As I said above, I meant to have the hotspot-gc-dev on the CC. Jon > > thanks, and have a good weekend! > -- ramki > > > On Fri, Jun 10, 2016 at 6:17 PM, Jon Masamitsu > > wrote: > > Jungwoo, Ramki, Tony (and other friends of CMS), > > I wanted to be sure you guys saw this JEP. > > Deprecate the CMS garbage collector (UseConcMarkSweepGC). > http://openjdk.java.net/jeps/8142518 > > I know you do development on CMS and wanted to know if > had thoughts about the future of CMS. > > At some point Oracle is going to stop supporting CMS. > The burden of testing and maintaining the CMS code doesn't > make much sense given that we think G1 is the better > collector. If we deprecate CMS in jdk9, support would be dropped > no earlier than jdk10. > > Have you guys talked about what you would like to do with regard > to continuing CMS development without Oracle's help? > > I've been told that if CMS exists in the Oracle binaries, then > customers will expect it to work. So not supporting CMS > means it is not in the build. > > Jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Sat Jun 11 21:42:13 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Sat, 11 Jun 2016 14:42:13 -0700 Subject: Future of CMS In-Reply-To: <2DC8ADA8-A5C4-4152-9F9C-506D8B565D57@kodewerk.com> References: <2DC8ADA8-A5C4-4152-9F9C-506D8B565D57@kodewerk.com> Message-ID: <3dcfaa8f-7128-e4b4-10f0-d055109afbc9@oracle.com> On 6/11/2016 1:56 AM, kirk at kodewerk.com wrote: > Hi Jon, > > I question that the current implementation of G1 is better than CMS. Though I do try to move my clients to G1, there are still many cases where I can get much less GC interference with CMS than I can with the G1. I can look into sending you side by side GC logs if you are interested in a visualization. At the very least I can send you contrasting Censum screenshot. Kirk, We're identified use cases where CMS still out performs G1 and have been working to make G1 better in those cases. As the JEP says G1 might not out perform CMS in every case but G1 is going to get better and better in many different ways whereas CMS will not (at least by Oracle's hand). My expectation is that the weight of all the improvements to G1 will in the end make it the more attractive collector. Jon > > Kind regards, > Kirk Pepperdine > >> On Jun 11, 2016, at 3:35 AM, Jon Masamitsu wrote: >> >> Added hotspot-gc-dev. >> >> On 6/10/2016 6:17 PM, Jon Masamitsu wrote: >>> Jungwoo, Ramki, Tony (and other friends of CMS), >>> >>> I wanted to be sure you guys saw this JEP. >>> >>> Deprecate the CMS garbage collector (UseConcMarkSweepGC). >>> http://openjdk.java.net/jeps/8142518 >>> >>> I know you do development on CMS and wanted to know if >>> had thoughts about the future of CMS. >>> >>> At some point Oracle is going to stop supporting CMS. >>> The burden of testing and maintaining the CMS code doesn't >>> make much sense given that we think G1 is the better >>> collector. If we deprecate CMS in jdk9, support would be dropped >>> no earlier than jdk10. >>> >>> Have you guys talked about what you would like to do with regard >>> to continuing CMS development without Oracle's help? >>> >>> I've been told that if CMS exists in the Oracle binaries, then >>> customers will expect it to work. So not supporting CMS >>> means it is not in the build. >>> >>> Jon From jon.masamitsu at oracle.com Sat Jun 11 22:06:29 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Sat, 11 Jun 2016 15:06:29 -0700 Subject: Future of CMS In-Reply-To: References: Message-ID: <51c70a72-6e43-491d-6de8-f3cb38837ef2@oracle.com> On 6/11/2016 6:37 AM, Volker Simonis wrote: > Hi Jon, > > I'm a little bit disappointed that you didn't think about SAP when you > sent your initial mail ;) Yup, I should have just addressed it to the alias so that everyone's mail filters would have pushed it off to the side for later reading :-) > > But seriously: SAP is supporting CMS and will probably do so for quite > a long time (simply because we do support old Java releases for a very > long time). > > Completely removing CMS from the HotSpot code base may increase these > support costs considerably for us. > > Do you plan to really delete the sources from the repos or do you only > plan to disable it at build time? I just don't know how this is going to play out. I expect that the OpenJDK community will want the sources to stay. In such a case Oracle would want them segregated sufficiently that we don't build the the sources. > I think only disable it at build time would make it easier for us and > others to still support it in the future. But in that case we really > have to come up with a better development model which would allow > external developers to directly push CMS changes (much like ppc64 or > aarch64 changes). Everything else would be a real PITA. I think some model like ppc64/aarch64 would be a good way to go. That would be a nice side effect of this change. You know better than I on how to get there. Jon > > Thank you and best regards, > Volker > > On Saturday, June 11, 2016, Jon Masamitsu > wrote: > > Added hotspot-gc-dev. > > On 6/10/2016 6:17 PM, Jon Masamitsu wrote: > > Jungwoo, Ramki, Tony (and other friends of CMS), > > I wanted to be sure you guys saw this JEP. > > Deprecate the CMS garbage collector (UseConcMarkSweepGC). > http://openjdk.java.net/jeps/8142518 > > I know you do development on CMS and wanted to know if > had thoughts about the future of CMS. > > At some point Oracle is going to stop supporting CMS. > The burden of testing and maintaining the CMS code doesn't > make much sense given that we think G1 is the better > collector. If we deprecate CMS in jdk9, support would be > dropped > no earlier than jdk10. > > Have you guys talked about what you would like to do with regard > to continuing CMS development without Oracle's help? > > I've been told that if CMS exists in the Oracle binaries, then > customers will expect it to work. So not supporting CMS > means it is not in the build. > > Jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.johansson at oracle.com Mon Jun 13 07:46:30 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 13 Jun 2016 09:46:30 +0200 Subject: RFR(s): 8151283: Implement setting jtreg @requires property vm.isG1Supported. In-Reply-To: References: Message-ID: <575E64D6.3070908@oracle.com> Hi Dima, I don't know the code and the way this is invoked good enough to do a proper review, but I have a style comment. Wouldn't it be nice to only call the value "vm.gc.G1", and have: @requires vm.gc.G1 I feel that "acceptable" provide very little information and what we want to @require is that the test is only run with G1 (when supported) and I think that is clear from such syntax. Comments? Thanks, Stefan On 2016-06-10 18:04, Dmitry Fazunenko wrote: > Hello, > > I'm looking for a couple of Reviewers for a simple change, which > allows to skip tests depending on non supported garbage collectors. > > http://cr.openjdk.java.net/~dfazunen/8151283/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8151283 > > The fix introduces four new requires boolean properties: > vm.gc.G1.acceptable > vm.gc.Serial.acceptable > vm.gc.Parallel.acceptable > vm.gc.ConcMarkSweep.acceptable > Which are set by the jtreg plugin prior the test execution starts. > After that fix we will be able to replace in tests: > @requires vm.gc == null | vm.gc == "G1" > with > @requires vm.gc.G1.acceptable > > 'vm.gc.G1.acceptable' will be evaluated to 'false' not only if other > GC is set externally, but also if G1 is not supported. > In other words the fix allows not to run GC specific tests in not > applicable configurations. > > Thanks, > Dima > > > > From thomas.schatzl at oracle.com Mon Jun 13 09:38:09 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 13 Jun 2016 11:38:09 +0200 Subject: PING: RFR: JDK-8155730: HeapInfoDCmd should get Heap_lock In-Reply-To: <1465552953.2513.1.camel@oracle.com> References: <955b8a22-d35c-60dc-e202-991b5a5e432d@gmail.com> <5583e9c0-8f16-72d0-ee55-a30246ab5bc8@oracle.com> <0b5bbf95-c871-f504-d96c-a08ae5277240@gmail.com> <0fccf86b-5ba8-cb3c-f253-d56cc7d1684d@oracle.com> <90b138a9-f67e-4141-fa63-71942c30e91d@gmail.com> <73d13ea4-7d0a-8bb5-6dea-be6c22d08066@oracle.com> <7881a764-1ac2-116e-da54-e57e043a930f@gmail.com> <4ffc0582-f2c0-4724-f21e-2a6510c4da95@gmail.com> <1465552953.2513.1.camel@oracle.com> Message-ID: <1465810689.2564.3.camel@oracle.com> Hi, On Fri, 2016-06-10 at 12:02 +0200, Thomas Schatzl wrote: > Hi Yasumasa, > > On Thu, 2016-06-02 at 22:36 +0900, Yasumasa Suenaga wrote: > > > > PING: Could you review it? > > ? > > > > > > ? > > > > > > > > ? > > > > ???http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ > > ? > > Yasumasa > > ? > ? looks okay to me. I will run the change through some testing. ? just a heads up. Running the nightly testsuite resulted in quite a few new failures. I need to look through them. Thanks, ? Thomas From stefan.johansson at oracle.com Mon Jun 13 10:16:56 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 13 Jun 2016 12:16:56 +0200 Subject: RFR: 8159045: Remove const from methods returning size_t in threadLocalAllocBuffer.hpp In-Reply-To: <20160608113131.GB26799@ehelin.jrpg.bea.com> References: <20160608113131.GB26799@ehelin.jrpg.bea.com> Message-ID: <575E8818.209@oracle.com> Looks good, but please update the patch to include removal of const on max_size_in_bytes() as well. Stefan On 2016-06-08 13:31, Erik Helin wrote: > Hey all, > > here is a tiny patch that removes the const decorator from two static > methods returning size_t. The const decorator doesn't mean anything in > this case since a size_t is always copied. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8159045 > > Patch: > # HG changeset patch > # User ehelin > # Date 1465385076 -7200 > # Wed Jun 08 13:24:36 2016 +0200 > # Node ID 7913ba2740284a10754d14df7c6556218eb37051 > # Parent a1dc09350fbcd12d858d42903106ae788f77d2d0 > 8159045: Remove const from methods returning size_t in threadLocalAllocBuffer.hpp > > diff -r a1dc09350fbc -r 7913ba274028 src/share/vm/gc/shared/threadLocalAllocBuffer.hpp > --- a/src/share/vm/gc/shared/threadLocalAllocBuffer.hpp Wed Jun 08 11:15:49 2016 +0200 > +++ b/src/share/vm/gc/shared/threadLocalAllocBuffer.hpp Wed Jun 08 13:24:36 2016 +0200 > @@ -108,8 +108,8 @@ > // do nothing. tlabs must be inited by initialize() calls > } > > - static const size_t min_size() { return align_object_size(MinTLABSize / HeapWordSize) + alignment_reserve(); } > - static const size_t max_size() { assert(_max_size != 0, "max_size not set up"); return _max_size; } > + static size_t min_size() { return align_object_size(MinTLABSize / HeapWordSize) + alignment_reserve(); } > + static size_t max_size() { assert(_max_size != 0, "max_size not set up"); return _max_size; } > static void set_max_size(size_t max_size) { _max_size = max_size; } > > HeapWord* start() const { return _start; } > > Testing: > - Compiled on Linux x86-64 > > Thanks, > Erik From per.liden at oracle.com Mon Jun 13 10:19:57 2016 From: per.liden at oracle.com (Per Liden) Date: Mon, 13 Jun 2016 12:19:57 +0200 Subject: RFR: 8158871: Long response times with G1 and StringDeduplication Message-ID: <575E88CD.8030803@oracle.com> Hi, Could I please have a couple of reviews in this bug fix. Summary: When entries are pruned from the StringDedupTable, the actual freeing of those entries are done while both holding the StringDedupTable_lock and being joined to the SuspendibleThreadSet. This causes both String.intern() and safepoints to be blocked until the freeing is completed. As described in the bug report, this can cause a very noticeable hick up in application response times when a huge amount (millions) of entries are pruned at once. The patch fixes this by moving all freeing out from the StringDedupTable_lock and the SuspendibleThreadSet is only joined temporarily to bulk-extract the list of entries to free, which is an O(1) operation. Webrev: http://cr.openjdk.java.net/~pliden/8158871/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8158871 Testing: All jtreg string dedup tests pass. Manually provoked the problematic condition and verified that the actual freeing of entries doesn't block safepoints or String.intern(). thanks, Per From per.liden at oracle.com Mon Jun 13 10:32:42 2016 From: per.liden at oracle.com (Per Liden) Date: Mon, 13 Jun 2016 12:32:42 +0200 Subject: RFR: 8159350: G1 String deduplication logging malformed Message-ID: <575E8BCA.2050401@oracle.com> Hi, Summary: The conversion to Unified Logging framework left an unmatched ']' at the end of G1's string deduplication printouts. Like this: [13.742s][info][gc,stringdedup] Concurrent String Deduplication 168.9M->168.9M(31.3K), avg 0.0%, 8.6307965 secs] Webrev: http://cr.openjdk.java.net/~pliden/8159350/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8159350 cheers, Per From erik.helin at oracle.com Mon Jun 13 13:23:24 2016 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 13 Jun 2016 15:23:24 +0200 Subject: PING: RFR: JDK-8155730: HeapInfoDCmd should get Heap_lock In-Reply-To: <4ffc0582-f2c0-4724-f21e-2a6510c4da95@gmail.com> References: <955b8a22-d35c-60dc-e202-991b5a5e432d@gmail.com> <5583e9c0-8f16-72d0-ee55-a30246ab5bc8@oracle.com> <0b5bbf95-c871-f504-d96c-a08ae5277240@gmail.com> <0fccf86b-5ba8-cb3c-f253-d56cc7d1684d@oracle.com> <90b138a9-f67e-4141-fa63-71942c30e91d@gmail.com> <73d13ea4-7d0a-8bb5-6dea-be6c22d08066@oracle.com> <7881a764-1ac2-116e-da54-e57e043a930f@gmail.com> <4ffc0582-f2c0-4724-f21e-2a6510c4da95@gmail.com> Message-ID: <20160613132324.GN26799@ehelin.jrpg.bea.com> On 2016-06-02, Yasumasa Suenaga wrote: > PING: Could you review it? > > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ This will not work - what if the VM crashes while holding the HeapLock? Erik > Yasumasa > > > On 2016/05/17 19:19, Yasumasa Suenaga wrote: > >PING: Could you review it? > >I need review from GC folks. > > > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ > > > > > >Thanks, > > > >Yasumasa > > > > > >On 2016/05/10 22:25, Yasumasa Suenaga wrote: > >>On 2016/05/10 16:48, David Holmes wrote: > >>>On 9/05/2016 10:34 PM, Yasumasa Suenaga wrote: > >>>>Hi David, > >>>> > >>>>>Taking locks during VMError handling is problematic - we're executing > >>>>>from a signal handler and the VM is crashing. Much of what we do from > >>>>>VMError is "best effort". > >>>> > >>>>I will remove MutexLocker from VMError::report(). > >>>>But I added assert_locked_or_safepoint(Heap_lock) in each CollectedHeap. > >>>>If we remove Heap_lock from VMError::report(), fastdebug HotSpot is failed > >>>>when it prints heap info to hs_err log. > >>>>Should I remove assert_locked_or_safepoint()? > >>> > >>>Yes I think you need to do this. > >> > >>I removed them in new webrev: > >> > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ > >> > >>>>VMError::print_vm_info() calls from VMInfoDCmd::execute() only. > >>>>So I think we should take Heap_lock at this function. > >>>>Or should we take Heap_lock at VMInfoDCmd::execute() ? > >>> > >>>If this is called from a DCmd only then I think the lock can be taken in print_vm_info(). > >> > >>I grep'ed HotSpot source, print_vm_info() is called from DCmd only. > >> > >>>Need GC folk to add their weight here. > >> > >>I'm waiting reviewer from GC folks :-) > >> > >> > >>Thanks, > >> > >>Yasumasa > >> > >> > >>>Thanks, > >>>David > >>> > >>>> > >>>>Thanks, > >>>> > >>>>Yasumasa > >>>> > >>>> > >>>>On 2016/05/09 21:26, David Holmes wrote: > >>>>>On 9/05/2016 10:20 PM, Yasumasa Suenaga wrote: > >>>>>>Hi all, > >>>>>> > >>>>>>I've sent review request for JDK-8155730. > >>>>>>However, I found caller of Universe::heap()->print_*() in vmError.cpp . > >>>>>>Thus I added MutexLocker(Ex) for Heap_lock to VMError::report() and > >>>>>>VMError::print_vm_info(). > >>>>> > >>>>>Taking locks during VMError handling is problematic - we're executing > >>>>>from a signal handler and the VM is crashing. Much of what we do from > >>>>>VMError is "best effort". > >>>>> > >>>>>David > >>>>> > >>>>>>Could you review again? > >>>>>> > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.01/ > >>>>>> > >>>>>> > >>>>>>>This needs to be reviewed by the GC folk not runtime. Please direct > >>>>>>>followups to hotspot-gc-dev. > >>>>>> > >>>>>>Thanks, David! > >>>>>> > >>>>>> > >>>>>>Yasumasa > >>>>>> > >>>>>> > >>>>>>On 2016/05/06 13:11, David Holmes wrote: > >>>>>>>Hi Yasumasa, > >>>>>>> > >>>>>>>This needs to be reviewed by the GC folk not runtime. Please direct > >>>>>>>followups to hotspot-gc-dev. > >>>>>>> > >>>>>>>Thanks, > >>>>>>>David > >>>>>>> > >>>>>>>On 30/04/2016 12:05 AM, Yasumasa Suenaga wrote: > >>>>>>>>Hi all, > >>>>>>>> > >>>>>>>>This review request is related to [1]. > >>>>>>>> > >>>>>>>>HeapInfoDCmd calls CollectedHeap::print_on(). > >>>>>>>>However, its call does not get Heap_lock. > >>>>>>>> > >>>>>>>>Heap_lock should be gotten from all heap operations. > >>>>>>>> > >>>>>>>>I uploaded webrev for this issue. > >>>>>>>>Could you review it? > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.00/ > >>>>>>>> > >>>>>>>>I cannot access JPRT. > >>>>>>>>So I need a sponsor. > >>>>>>>> > >>>>>>>> > >>>>>>>>Thanks, > >>>>>>>> > >>>>>>>>Yasumasa > >>>>>>>> > >>>>>>>> > >>>>>>>>[1] > >>>>>>>>http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019257.html > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> From yasuenag at gmail.com Mon Jun 13 15:13:24 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 14 Jun 2016 00:13:24 +0900 Subject: PING: RFR: JDK-8155730: HeapInfoDCmd should get Heap_lock In-Reply-To: <20160613132324.GN26799@ehelin.jrpg.bea.com> References: <955b8a22-d35c-60dc-e202-991b5a5e432d@gmail.com> <5583e9c0-8f16-72d0-ee55-a30246ab5bc8@oracle.com> <0b5bbf95-c871-f504-d96c-a08ae5277240@gmail.com> <0fccf86b-5ba8-cb3c-f253-d56cc7d1684d@oracle.com> <90b138a9-f67e-4141-fa63-71942c30e91d@gmail.com> <73d13ea4-7d0a-8bb5-6dea-be6c22d08066@oracle.com> <7881a764-1ac2-116e-da54-e57e043a930f@gmail.com> <4ffc0582-f2c0-4724-f21e-2a6510c4da95@gmail.com> <20160613132324.GN26799@ehelin.jrpg.bea.com> Message-ID: <22d73f92-612f-5764-5612-7ee6514a6fbe@gmail.com> Hi Thomas, Erik, I ran webrev.02 patch, thread dump (SIGQUIT), VM.info jcmd, and generating hs_err log work fine on my Fedora23 x64 with fastdebug JDK. Please tell me what test(s) failed. Thanks, Yasumasa On 2016/06/13 22:23, Erik Helin wrote: > On 2016-06-02, Yasumasa Suenaga wrote: >> PING: Could you review it? >> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ > > This will not work - what if the VM crashes while holding the HeapLock? > > Erik > >> Yasumasa >> >> >> On 2016/05/17 19:19, Yasumasa Suenaga wrote: >>> PING: Could you review it? >>> I need review from GC folks. >>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/05/10 22:25, Yasumasa Suenaga wrote: >>>> On 2016/05/10 16:48, David Holmes wrote: >>>>> On 9/05/2016 10:34 PM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>>> Taking locks during VMError handling is problematic - we're executing >>>>>> >from a signal handler and the VM is crashing. Much of what we do from >>>>>>> VMError is "best effort". >>>>>> >>>>>> I will remove MutexLocker from VMError::report(). >>>>>> But I added assert_locked_or_safepoint(Heap_lock) in each CollectedHeap. >>>>>> If we remove Heap_lock from VMError::report(), fastdebug HotSpot is failed >>>>>> when it prints heap info to hs_err log. >>>>>> Should I remove assert_locked_or_safepoint()? >>>>> >>>>> Yes I think you need to do this. >>>> >>>> I removed them in new webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ >>>> >>>>>> VMError::print_vm_info() calls from VMInfoDCmd::execute() only. >>>>>> So I think we should take Heap_lock at this function. >>>>>> Or should we take Heap_lock at VMInfoDCmd::execute() ? >>>>> >>>>> If this is called from a DCmd only then I think the lock can be taken in print_vm_info(). >>>> >>>> I grep'ed HotSpot source, print_vm_info() is called from DCmd only. >>>> >>>>> Need GC folk to add their weight here. >>>> >>>> I'm waiting reviewer from GC folks :-) >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/05/09 21:26, David Holmes wrote: >>>>>>> On 9/05/2016 10:20 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I've sent review request for JDK-8155730. >>>>>>>> However, I found caller of Universe::heap()->print_*() in vmError.cpp . >>>>>>>> Thus I added MutexLocker(Ex) for Heap_lock to VMError::report() and >>>>>>>> VMError::print_vm_info(). >>>>>>> >>>>>>> Taking locks during VMError handling is problematic - we're executing >>>>>> >from a signal handler and the VM is crashing. Much of what we do from >>>>>>> VMError is "best effort". >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Could you review again? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>>> This needs to be reviewed by the GC folk not runtime. Please direct >>>>>>>>> followups to hotspot-gc-dev. >>>>>>>> >>>>>>>> Thanks, David! >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/05/06 13:11, David Holmes wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> This needs to be reviewed by the GC folk not runtime. Please direct >>>>>>>>> followups to hotspot-gc-dev. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 30/04/2016 12:05 AM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> This review request is related to [1]. >>>>>>>>>> >>>>>>>>>> HeapInfoDCmd calls CollectedHeap::print_on(). >>>>>>>>>> However, its call does not get Heap_lock. >>>>>>>>>> >>>>>>>>>> Heap_lock should be gotten from all heap operations. >>>>>>>>>> >>>>>>>>>> I uploaded webrev for this issue. >>>>>>>>>> Could you review it? >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.00/ >>>>>>>>>> >>>>>>>>>> I cannot access JPRT. >>>>>>>>>> So I need a sponsor. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019257.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> From david.holmes at oracle.com Mon Jun 13 22:10:58 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jun 2016 08:10:58 +1000 Subject: PING: RFR: JDK-8155730: HeapInfoDCmd should get Heap_lock In-Reply-To: <20160613132324.GN26799@ehelin.jrpg.bea.com> References: <955b8a22-d35c-60dc-e202-991b5a5e432d@gmail.com> <5583e9c0-8f16-72d0-ee55-a30246ab5bc8@oracle.com> <0b5bbf95-c871-f504-d96c-a08ae5277240@gmail.com> <0fccf86b-5ba8-cb3c-f253-d56cc7d1684d@oracle.com> <90b138a9-f67e-4141-fa63-71942c30e91d@gmail.com> <73d13ea4-7d0a-8bb5-6dea-be6c22d08066@oracle.com> <7881a764-1ac2-116e-da54-e57e043a930f@gmail.com> <4ffc0582-f2c0-4724-f21e-2a6510c4da95@gmail.com> <20160613132324.GN26799@ehelin.jrpg.bea.com> Message-ID: Hi Erik, On 13/06/2016 11:23 PM, Erik Helin wrote: > On 2016-06-02, Yasumasa Suenaga wrote: >> PING: Could you review it? >> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ > > This will not work - what if the VM crashes while holding the HeapLock? I assume you are referring to acquiring the HeapLock in vmError.cpp. But that code is not used for actual error reporting only the VMInfo Dcmd. Thanks, David > Erik > >> Yasumasa >> >> >> On 2016/05/17 19:19, Yasumasa Suenaga wrote: >>> PING: Could you review it? >>> I need review from GC folks. >>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/05/10 22:25, Yasumasa Suenaga wrote: >>>> On 2016/05/10 16:48, David Holmes wrote: >>>>> On 9/05/2016 10:34 PM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>>> Taking locks during VMError handling is problematic - we're executing >>>>>> >from a signal handler and the VM is crashing. Much of what we do from >>>>>>> VMError is "best effort". >>>>>> >>>>>> I will remove MutexLocker from VMError::report(). >>>>>> But I added assert_locked_or_safepoint(Heap_lock) in each CollectedHeap. >>>>>> If we remove Heap_lock from VMError::report(), fastdebug HotSpot is failed >>>>>> when it prints heap info to hs_err log. >>>>>> Should I remove assert_locked_or_safepoint()? >>>>> >>>>> Yes I think you need to do this. >>>> >>>> I removed them in new webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ >>>> >>>>>> VMError::print_vm_info() calls from VMInfoDCmd::execute() only. >>>>>> So I think we should take Heap_lock at this function. >>>>>> Or should we take Heap_lock at VMInfoDCmd::execute() ? >>>>> >>>>> If this is called from a DCmd only then I think the lock can be taken in print_vm_info(). >>>> >>>> I grep'ed HotSpot source, print_vm_info() is called from DCmd only. >>>> >>>>> Need GC folk to add their weight here. >>>> >>>> I'm waiting reviewer from GC folks :-) >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/05/09 21:26, David Holmes wrote: >>>>>>> On 9/05/2016 10:20 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I've sent review request for JDK-8155730. >>>>>>>> However, I found caller of Universe::heap()->print_*() in vmError.cpp . >>>>>>>> Thus I added MutexLocker(Ex) for Heap_lock to VMError::report() and >>>>>>>> VMError::print_vm_info(). >>>>>>> >>>>>>> Taking locks during VMError handling is problematic - we're executing >>>>>> >from a signal handler and the VM is crashing. Much of what we do from >>>>>>> VMError is "best effort". >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Could you review again? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>>> This needs to be reviewed by the GC folk not runtime. Please direct >>>>>>>>> followups to hotspot-gc-dev. >>>>>>>> >>>>>>>> Thanks, David! >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/05/06 13:11, David Holmes wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> This needs to be reviewed by the GC folk not runtime. Please direct >>>>>>>>> followups to hotspot-gc-dev. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 30/04/2016 12:05 AM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> This review request is related to [1]. >>>>>>>>>> >>>>>>>>>> HeapInfoDCmd calls CollectedHeap::print_on(). >>>>>>>>>> However, its call does not get Heap_lock. >>>>>>>>>> >>>>>>>>>> Heap_lock should be gotten from all heap operations. >>>>>>>>>> >>>>>>>>>> I uploaded webrev for this issue. >>>>>>>>>> Could you review it? >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.00/ >>>>>>>>>> >>>>>>>>>> I cannot access JPRT. >>>>>>>>>> So I need a sponsor. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019257.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> From jon.masamitsu at oracle.com Mon Jun 13 21:56:16 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 13 Jun 2016 14:56:16 -0700 Subject: Request for Review (xs) - 8024945: Remove check on minimum size of MetaspaceSiz Message-ID: <575F2C00.1020906@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8024945 Previous to this change the smallest MetaspaceSize value allowed was 256k. There is not reason for the restriction so this change removes it. A very small MetaspaceSize (even 0) does not cause a problem because during initialization a GC is not triggered unless the Metaspace needed grows beyond MaxMetaspaceSize. http://cr.openjdk.java.net/~jmasa/8024945/webrev.00/ Tested with -XX:MetaspaceSize=0. General testing with gc_test_suite. Thanks. Jon From kim.barrett at oracle.com Mon Jun 13 22:29:42 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 13 Jun 2016 18:29:42 -0400 Subject: Request for Review (xs) - 8024945: Remove check on minimum size of MetaspaceSiz In-Reply-To: <575F2C00.1020906@oracle.com> References: <575F2C00.1020906@oracle.com> Message-ID: > On Jun 13, 2016, at 5:56 PM, Jon Masamitsu wrote: > > https://bugs.openjdk.java.net/browse/JDK-8024945 > > Previous to this change the smallest MetaspaceSize value allowed > was 256k. There is not reason for the restriction so this change > removes it. A very small MetaspaceSize (even 0) does not cause > a problem because during initialization a GC is not triggered unless > the Metaspace needed grows beyond MaxMetaspaceSize. > > http://cr.openjdk.java.net/~jmasa/8024945/webrev.00/ > > Tested with -XX:MetaspaceSize=0. General testing with gc_test_suite. Looks good. ------------------------------------------------------------------------------ test/gc/metaspace/TestMetaspaceInitialization.java 27 * @bug 8042933 Should this be updated to also mention 8024945? ------------------------------------------------------------------------------ From jon.masamitsu at oracle.com Mon Jun 13 22:43:27 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 13 Jun 2016 15:43:27 -0700 Subject: Request for Review (xs) - 8024945: Remove check on minimum size of MetaspaceSiz In-Reply-To: References: <575F2C00.1020906@oracle.com> Message-ID: <575F370F.2020500@oracle.com> On 06/13/2016 03:29 PM, Kim Barrett wrote: >> On Jun 13, 2016, at 5:56 PM, Jon Masamitsu wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8024945 >> >> Previous to this change the smallest MetaspaceSize value allowed >> was 256k. There is not reason for the restriction so this change >> removes it. A very small MetaspaceSize (even 0) does not cause >> a problem because during initialization a GC is not triggered unless >> the Metaspace needed grows beyond MaxMetaspaceSize. >> >> http://cr.openjdk.java.net/~jmasa/8024945/webrev.00/ >> >> Tested with -XX:MetaspaceSize=0. General testing with gc_test_suite. > Looks good. Thanks. > ------------------------------------------------------------------------------ > test/gc/metaspace/TestMetaspaceInitialization.java > 27 * @bug 8042933 > > Should this be updated to also mention 8024945? Ah, yes. Fixed. Jon > > ------------------------------------------------------------------------------ > From thomas.schatzl at oracle.com Tue Jun 14 07:32:33 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 14 Jun 2016 09:32:33 +0200 Subject: Request for Review (xs) - 8024945: Remove check on minimum size of MetaspaceSiz In-Reply-To: <575F370F.2020500@oracle.com> References: <575F2C00.1020906@oracle.com> <575F370F.2020500@oracle.com> Message-ID: <1465889553.2378.18.camel@oracle.com> Hi, On Mon, 2016-06-13 at 15:43 -0700, Jon Masamitsu wrote: > > On 06/13/2016 03:29 PM, Kim Barrett wrote: > > > > > > > > On Jun 13, 2016, at 5:56 PM, Jon Masamitsu > > com> wrote: > > > > > > https://bugs.openjdk.java.net/browse/JDK-8024945 > > > > > > Previous to this change the smallest MetaspaceSize value allowed > > > was 256k.??There is not reason for the restriction so this change > > > removes it.??A very small MetaspaceSize??(even 0) does not cause > > > a problem because during initialization a GC is not triggered > > > unless > > > the Metaspace needed grows beyond MaxMetaspaceSize. > > > > > > http://cr.openjdk.java.net/~jmasa/8024945/webrev.00/ > > > > > > Tested with -XX:MetaspaceSize=0.??General testing with > > > gc_test_suite. > > Looks good. > Thanks. > > > > > ----------------------------------------------------------------- > > ------------- > > test/gc/metaspace/TestMetaspaceInitialization.java > > 27??* @bug 8042933 > > > > Should this be updated to also mention 8024945? > Ah, yes. > > Fixed. ? looks good to me with this mentioned change. Thanks, ? Thomas From stefan.karlsson at oracle.com Tue Jun 14 09:05:32 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 14 Jun 2016 11:05:32 +0200 Subject: RFR: 8159350: G1 String deduplication logging malformed In-Reply-To: <575E8BCA.2050401@oracle.com> References: <575E8BCA.2050401@oracle.com> Message-ID: <575FC8DC.5090605@oracle.com> Looks good. StefanK On 2016-06-13 12:32, Per Liden wrote: > Hi, > > Summary: The conversion to Unified Logging framework left an unmatched > ']' at the end of G1's string deduplication printouts. > > Like this: > > [13.742s][info][gc,stringdedup] Concurrent String Deduplication > 168.9M->168.9M(31.3K), avg 0.0%, 8.6307965 secs] > > > Webrev: http://cr.openjdk.java.net/~pliden/8159350/webrev.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159350 > > cheers, > Per From stefan.johansson at oracle.com Tue Jun 14 09:17:08 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 14 Jun 2016 11:17:08 +0200 Subject: RFR: 8159350: G1 String deduplication logging malformed In-Reply-To: <575E8BCA.2050401@oracle.com> References: <575E8BCA.2050401@oracle.com> Message-ID: <575FCB94.9050805@oracle.com> Looks good, StefanJ On 2016-06-13 12:32, Per Liden wrote: > Hi, > > Summary: The conversion to Unified Logging framework left an unmatched > ']' at the end of G1's string deduplication printouts. > > Like this: > > [13.742s][info][gc,stringdedup] Concurrent String Deduplication > 168.9M->168.9M(31.3K), avg 0.0%, 8.6307965 secs] > > > Webrev: http://cr.openjdk.java.net/~pliden/8159350/webrev.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159350 > > cheers, > Per From per.liden at oracle.com Tue Jun 14 11:26:32 2016 From: per.liden at oracle.com (Per Liden) Date: Tue, 14 Jun 2016 13:26:32 +0200 Subject: RFR: 8159350: G1 String deduplication logging malformed In-Reply-To: <575FCB94.9050805@oracle.com> References: <575E8BCA.2050401@oracle.com> <575FCB94.9050805@oracle.com> Message-ID: <575FE9E8.1040002@oracle.com> Thanks Stefan & Stefan. /Per On 2016-06-14 11:17, Stefan Johansson wrote: > Looks good, > StefanJ > > On 2016-06-13 12:32, Per Liden wrote: >> Hi, >> >> Summary: The conversion to Unified Logging framework left an unmatched >> ']' at the end of G1's string deduplication printouts. >> >> Like this: >> >> [13.742s][info][gc,stringdedup] Concurrent String Deduplication >> 168.9M->168.9M(31.3K), avg 0.0%, 8.6307965 secs] >> >> >> Webrev: http://cr.openjdk.java.net/~pliden/8159350/webrev.0/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8159350 >> >> cheers, >> Per > From thomas.schatzl at oracle.com Tue Jun 14 12:16:33 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 14 Jun 2016 14:16:33 +0200 Subject: RFR (S): 8142749: HeapRegion cleanup In-Reply-To: References: Message-ID: <1465906593.2378.52.camel@oracle.com> Hi, ? sorry for the somewhat later answer... On Thu, 2016-06-09 at 11:26 +0300, ???????? ??????????? wrote: > Thanks for review and sponsoring! > ? > > Note that at the moment are past the JDK9 FC date, and we should > > not integrate enhancements right now. There is no process at the > > moment if and how these can be integrated. So it may take a while > > to push the change. > Should I wait until JDK10 forest and ping someone? I would appreciate if you pinged me again as soon as there is a jdk10 tree. > Should I update webrev with includes cleanup now or wait until new > forest?? I think the include cleanups could be added. > Does it make sense to keep making reviews for simple bugs (e.g. like > JDK-8151045) or it's better to wait until new forest (note that I'm > not openjdk author yet, so these questions could have obvious > answers)?? I do not know how posting reviews for simple bugs would be different before or after. The only difference is one of convenience: if you have two commits contributed by you, you can apply for authorship, which makes posting contributions easier. Thanks, ? Thomas From per.liden at oracle.com Tue Jun 14 12:18:46 2016 From: per.liden at oracle.com (Per Liden) Date: Tue, 14 Jun 2016 14:18:46 +0200 Subject: RFR: 8158871: Long response times with G1 and StringDeduplication In-Reply-To: <575E88CD.8030803@oracle.com> References: <575E88CD.8030803@oracle.com> Message-ID: <575FF626.6090409@oracle.com> Hi, Received some comments off-line and here's an updated webrev: http://cr.openjdk.java.net/~pliden/8158871/webrev.1/ Main difference is that the overflow list now lives next to the cache list, rather than inside the cache list. thanks, Per On 2016-06-13 12:19, Per Liden wrote: > Hi, > > Could I please have a couple of reviews in this bug fix. > > Summary: When entries are pruned from the StringDedupTable, the actual > freeing of those entries are done while both holding the > StringDedupTable_lock and being joined to the SuspendibleThreadSet. This > causes both String.intern() and safepoints to be blocked until the > freeing is completed. As described in the bug report, this can cause a > very noticeable hick up in application response times when a huge amount > (millions) of entries are pruned at once. The patch fixes this by moving > all freeing out from the StringDedupTable_lock and the > SuspendibleThreadSet is only joined temporarily to bulk-extract the list > of entries to free, which is an O(1) operation. > > Webrev: http://cr.openjdk.java.net/~pliden/8158871/webrev.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158871 > > Testing: All jtreg string dedup tests pass. Manually provoked the > problematic condition and verified that the actual freeing of entries > doesn't block safepoints or String.intern(). > > thanks, > Per > From thomas.schatzl at oracle.com Tue Jun 14 12:22:00 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 14 Jun 2016 14:22:00 +0200 Subject: RFR: 8158412: [TESTBUG] TestIHOPErgo and TestStressG1Humongous should not be executed when JFR is enabled In-Reply-To: <5758226F.3000108@oracle.com> References: <5758226F.3000108@oracle.com> Message-ID: <1465906920.2378.54.camel@oracle.com> Hi Mikael, On Wed, 2016-06-08 at 16:49 +0300, Michail Chernov wrote: > Hi, > > Could I have a reviews for this small fix? The fix adds new custom > JTreg? > setting for @requires tag - vm.FlightRecorder. New setting is used > in? > all updated tests. Tests will be exclude if JFR is enabled. > > https://bugs.openjdk.java.net/browse/JDK-8158412 > http://cr.openjdk.java.net/~mchernov/8158412/webrev.root.00/ > http://cr.openjdk.java.net/~mchernov/8158412/webrev.hotspot.00/ > > Testing - RBT. ? seems okay, however the syntax to use vm.FlightRecorder seems awkward, i.e. "vm.FlighRecorder != true" Isn't there a way to make it something more common like !vm.FlightRecorder? Not insisting on this, just asking. Thanks, ? Thomas From stefan.johansson at oracle.com Tue Jun 14 13:20:44 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 14 Jun 2016 15:20:44 +0200 Subject: RFR: 8158871: Long response times with G1 and StringDeduplication In-Reply-To: <575FF626.6090409@oracle.com> References: <575E88CD.8030803@oracle.com> <575FF626.6090409@oracle.com> Message-ID: <576004AC.6080200@oracle.com> Looks good, StefanJ On 2016-06-14 14:18, Per Liden wrote: > Hi, > > Received some comments off-line and here's an updated webrev: > > http://cr.openjdk.java.net/~pliden/8158871/webrev.1/ > > Main difference is that the overflow list now lives next to the cache > list, rather than inside the cache list. > > thanks, > Per > > On 2016-06-13 12:19, Per Liden wrote: >> Hi, >> >> Could I please have a couple of reviews in this bug fix. >> >> Summary: When entries are pruned from the StringDedupTable, the actual >> freeing of those entries are done while both holding the >> StringDedupTable_lock and being joined to the SuspendibleThreadSet. This >> causes both String.intern() and safepoints to be blocked until the >> freeing is completed. As described in the bug report, this can cause a >> very noticeable hick up in application response times when a huge amount >> (millions) of entries are pruned at once. The patch fixes this by moving >> all freeing out from the StringDedupTable_lock and the >> SuspendibleThreadSet is only joined temporarily to bulk-extract the list >> of entries to free, which is an O(1) operation. >> >> Webrev: http://cr.openjdk.java.net/~pliden/8158871/webrev.0/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158871 >> >> Testing: All jtreg string dedup tests pass. Manually provoked the >> problematic condition and verified that the actual freeing of entries >> doesn't block safepoints or String.intern(). >> >> thanks, >> Per >> From dmitry.fazunenko at oracle.com Tue Jun 14 13:23:31 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Tue, 14 Jun 2016 16:23:31 +0300 Subject: RFR: 8158412: [TESTBUG] TestIHOPErgo and TestStressG1Humongous should not be executed when JFR is enabled In-Reply-To: <1465906920.2378.54.camel@oracle.com> References: <5758226F.3000108@oracle.com> <1465906920.2378.54.camel@oracle.com> Message-ID: <66ef9098-b7a6-bd60-60c2-a1f0becf0b27@oracle.com> Michail, On 14.06.2016 15:22, Thomas Schatzl wrote: > Hi Mikael, > > On Wed, 2016-06-08 at 16:49 +0300, 8038818: Test nsk/jvmti/GetOwnedMonitorInfo/ownmoninf001 fails with wrong number of monitors > 8071659: Name change for functionality exposed as "Loaded Modules" to prepare for Jigsaw ("Modules") > 8138705: Kitchen sink stress test fails > 8150737: jdk.vm.cds.CacheManager should throw NPE when given null loader > 8152239: hotspot/test/gc/TestSmallHeap.java failed in jdk9 > 8152404: Stabilize PackageEntry::package_exports_do > 8154750: Add missing OrderAccess operations to ClassLoaderData lock-free data structures > 8155009: [TESTBUG] jstack subtest of BasicLauncherTest should not be executed under OS X > 8155936: Boolean value should be set 1/0 or true/false via VM.set_flag jcmd > 8156537: Tools using MonitoredVmUtil do not parse module in cmdline correctly > 8156923: [ppc] Implement "JEP 270: Reserved Stack Areas for Critical Sections". > 8157189: 'iload_w' in shared class is not interpreted correctly. > 8157836: A test to verify the default FlightRecorderListener.recordingStateChanged method implementation > 8157954: [TESTBUG] G1 tests fail with defined MaxGCPauseMillis > 8158240: A test for Recording.copy() JFR public API > 8158397: Crash: assert(save_resolved_method == resolved_method()) failed: does this change? > 8158570: missed space in vm options in ATR configuration > 8158579: hs-promotion-l2 task-definition doesn't use different flagsChernov wrote: >> Hi, >> >> Could I have a reviews for this small fix? The fix adds new custom >> JTreg >> setting for @requires tag - vm.FlightRecorder. New setting is used >> in >> all updated tests. Tests will be exclude if JFR is enabled. >> >> https://bugs.openjdk.java.net/browse/JDK-8158412 >> http://cr.openjdk.java.net/~mchernov/8158412/webrev.root.00/ >> http://cr.openjdk.java.net/~mchernov/8158412/webrev.hotspot.00/ >> >> Testing - RBT. > seems okay, however the syntax to use vm.FlightRecorder seems > awkward, i.e. > > "vm.FlighRecorder != true" > > Isn't there a way to make it something more common like > !vm.FlightRecorder? > > Not insisting on this, just asking. Yes, there is no need to use vm.xxx != true anymore, for those properties which are set by our plugin (VMProps). All such properties will never be set to 'null', as it's possible for vm.opt.xxx, which are set by jtreg. So, using !vm.FlightRecored is safe. Thanks, Dima > > Thanks, > Thomas From thomas.schatzl at oracle.com Tue Jun 14 13:33:33 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 14 Jun 2016 15:33:33 +0200 Subject: RFR: 8158412: [TESTBUG] TestIHOPErgo and TestStressG1Humongous should not be executed when JFR is enabled In-Reply-To: <66ef9098-b7a6-bd60-60c2-a1f0becf0b27@oracle.com> References: <5758226F.3000108@oracle.com> <1465906920.2378.54.camel@oracle.com> <66ef9098-b7a6-bd60-60c2-a1f0becf0b27@oracle.com> Message-ID: <1465911213.2378.60.camel@oracle.com> Hi, On Tue, 2016-06-14 at 16:23 +0300, Dmitry Fazunenko wrote: > Michail, > > On 14.06.2016 15:22, Thomas Schatzl wrote: > > > > Hi Mikael, > > > > On Wed, 2016-06-08 at 16:49 +0300, 8038818: Test Chernov wrote: > > > > > > Hi, > > > > > > Could I have a reviews for this small fix? The fix adds new > > > custom JTreg setting for @requires tag - vm.FlightRecorder. New > > > setting is used in all updated tests. Tests will be exclude if > > > JFR is enabled. > > > > > > https://bugs.openjdk.java.net/browse/JDK-8158412 > > > http://cr.openjdk.java.net/~mchernov/8158412/webrev.root.00/ > > > http://cr.openjdk.java.net/~mchernov/8158412/webrev.hotspot.00/ > > > > > > Testing - RBT. > > ???seems okay, however the syntax to use vm.FlightRecorder seems > > awkward, i.e. > > > > "vm.FlighRecorder != true" > > > > Isn't there a way to make it something more common like > > !vm.FlightRecorder? > > > > Not insisting on this, just asking. > Yes, there is no need to use vm.xxx != true anymore, for those? > properties which are set by our plugin (VMProps). > All such properties will never be set to 'null', as it's possible for > vm.opt.xxx, which are set by jtreg. > So, using !vm.FlightRecored is safe. ? then I would prefer to use vm.FlightRecorder this way in the tests. Thanks, ? Thomas From stefan.karlsson at oracle.com Tue Jun 14 13:39:41 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 14 Jun 2016 15:39:41 +0200 Subject: RFR: 8158871: Long response times with G1 and StringDeduplication In-Reply-To: <575E88CD.8030803@oracle.com> References: <575E88CD.8030803@oracle.com> Message-ID: <5760091D.2010502@oracle.com> Looks good. StefanK On 2016-06-13 12:19, Per Liden wrote: > Hi, > > Could I please have a couple of reviews in this bug fix. > > Summary: When entries are pruned from the StringDedupTable, the actual > freeing of those entries are done while both holding the > StringDedupTable_lock and being joined to the SuspendibleThreadSet. > This causes both String.intern() and safepoints to be blocked until > the freeing is completed. As described in the bug report, this can > cause a very noticeable hick up in application response times when a > huge amount (millions) of entries are pruned at once. The patch fixes > this by moving all freeing out from the StringDedupTable_lock and the > SuspendibleThreadSet is only joined temporarily to bulk-extract the > list of entries to free, which is an O(1) operation. > > Webrev: http://cr.openjdk.java.net/~pliden/8158871/webrev.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158871 > > Testing: All jtreg string dedup tests pass. Manually provoked the > problematic condition and verified that the actual freeing of entries > doesn't block safepoints or String.intern(). > > thanks, > Per > From robbin.ehn at oracle.com Tue Jun 14 14:01:07 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 14 Jun 2016 16:01:07 +0200 Subject: RFR: 8149778: serviceability/tmtools/jstat/GcCapacityTest.java causes JVM to hang during GC Message-ID: <41635f61-3ae1-d697-5dbe-ca3d65c813ac@oracle.com> Hi all, In 8152989 "-Xmx128M" was added to this test. This seem to solves timeout issues (describe by Kim in case). So this patch removes the ignore flag from test. It also address the issue raised by Kim by looping over long instead of float. Bug: https://bugs.openjdk.java.net/browse/JDK-8149778 Webrev: http://cr.openjdk.java.net/~rehn/8149778/webrev/ Tested on multiple platforms and hosts. Thanks! /Robbin From thomas.schatzl at oracle.com Tue Jun 14 14:02:53 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 14 Jun 2016 16:02:53 +0200 Subject: RFR: 8158871: Long response times with G1 and StringDeduplication In-Reply-To: <575FF626.6090409@oracle.com> References: <575E88CD.8030803@oracle.com> <575FF626.6090409@oracle.com> Message-ID: <1465912973.2378.70.camel@oracle.com> Hi Per, ? some quick initial comments: On Tue, 2016-06-14 at 14:18 +0200, Per Liden wrote: > Hi, > > Received some comments off-line and here's an updated webrev: > > http://cr.openjdk.java.net/~pliden/8158871/webrev.1/ > > Main difference is that the overflow list now lives next to the cache > list, rather than inside the cache list. ? - did you ever measure how long the deletion of all entries could take? It does not try to synchronize for safepoints, so potentially could delay safepoint for a long time. (in G1StringDedupEntryCache::delete_overflowed) ? - I would kind of prefer if?G1StringDedupEntryCache::G1StringDedupEntryCache() would call set_max_size() to set _max_list_lengths instead of duplicating the code in the initialization list.? ? - any concurrent kind of work should have log message at the beginning and the end of that work, otherwise it may be hard to find out what the process is doing from the log (i.e. delaying the safepoint) at the moment. ? - I am not sure if the default value of max_cache_size are good values. I mean, if you have lots of threads (we are running on machines with 2k+ threads already), the cache size will be zero by default. Thanks, ? Thomas From erik.helin at oracle.com Tue Jun 14 14:14:19 2016 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 14 Jun 2016 16:14:19 +0200 Subject: PING: RFR: JDK-8155730: HeapInfoDCmd should get Heap_lock In-Reply-To: References: <5583e9c0-8f16-72d0-ee55-a30246ab5bc8@oracle.com> <0b5bbf95-c871-f504-d96c-a08ae5277240@gmail.com> <0fccf86b-5ba8-cb3c-f253-d56cc7d1684d@oracle.com> <90b138a9-f67e-4141-fa63-71942c30e91d@gmail.com> <73d13ea4-7d0a-8bb5-6dea-be6c22d08066@oracle.com> <7881a764-1ac2-116e-da54-e57e043a930f@gmail.com> <4ffc0582-f2c0-4724-f21e-2a6510c4da95@gmail.com> <20160613132324.GN26799@ehelin.jrpg.bea.com> Message-ID: <20160614141419.GY26799@ehelin.jrpg.bea.com> On 2016-06-14, David Holmes wrote: > Hi Erik, > > On 13/06/2016 11:23 PM, Erik Helin wrote: > >On 2016-06-02, Yasumasa Suenaga wrote: > >>PING: Could you review it? > >> > >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ > > > >This will not work - what if the VM crashes while holding the HeapLock? > > I assume you are referring to acquiring the HeapLock in vmError.cpp. But > that code is not used for actual error reporting only the VMInfo Dcmd. Ah alright, I didn't get that that (should that code be moved somewhere else?). Thanks, Erik > Thanks, > David > > >Erik > > > >>Yasumasa > >> > >> > >>On 2016/05/17 19:19, Yasumasa Suenaga wrote: > >>>PING: Could you review it? > >>>I need review from GC folks. > >>> > >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ > >>> > >>> > >>>Thanks, > >>> > >>>Yasumasa > >>> > >>> > >>>On 2016/05/10 22:25, Yasumasa Suenaga wrote: > >>>>On 2016/05/10 16:48, David Holmes wrote: > >>>>>On 9/05/2016 10:34 PM, Yasumasa Suenaga wrote: > >>>>>>Hi David, > >>>>>> > >>>>>>>Taking locks during VMError handling is problematic - we're executing > >>>>>>>from a signal handler and the VM is crashing. Much of what we do from > >>>>>>>VMError is "best effort". > >>>>>> > >>>>>>I will remove MutexLocker from VMError::report(). > >>>>>>But I added assert_locked_or_safepoint(Heap_lock) in each CollectedHeap. > >>>>>>If we remove Heap_lock from VMError::report(), fastdebug HotSpot is failed > >>>>>>when it prints heap info to hs_err log. > >>>>>>Should I remove assert_locked_or_safepoint()? > >>>>> > >>>>>Yes I think you need to do this. > >>>> > >>>>I removed them in new webrev: > >>>> > >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ > >>>> > >>>>>>VMError::print_vm_info() calls from VMInfoDCmd::execute() only. > >>>>>>So I think we should take Heap_lock at this function. > >>>>>>Or should we take Heap_lock at VMInfoDCmd::execute() ? > >>>>> > >>>>>If this is called from a DCmd only then I think the lock can be taken in print_vm_info(). > >>>> > >>>>I grep'ed HotSpot source, print_vm_info() is called from DCmd only. > >>>> > >>>>>Need GC folk to add their weight here. > >>>> > >>>>I'm waiting reviewer from GC folks :-) > >>>> > >>>> > >>>>Thanks, > >>>> > >>>>Yasumasa > >>>> > >>>> > >>>>>Thanks, > >>>>>David > >>>>> > >>>>>> > >>>>>>Thanks, > >>>>>> > >>>>>>Yasumasa > >>>>>> > >>>>>> > >>>>>>On 2016/05/09 21:26, David Holmes wrote: > >>>>>>>On 9/05/2016 10:20 PM, Yasumasa Suenaga wrote: > >>>>>>>>Hi all, > >>>>>>>> > >>>>>>>>I've sent review request for JDK-8155730. > >>>>>>>>However, I found caller of Universe::heap()->print_*() in vmError.cpp . > >>>>>>>>Thus I added MutexLocker(Ex) for Heap_lock to VMError::report() and > >>>>>>>>VMError::print_vm_info(). > >>>>>>> > >>>>>>>Taking locks during VMError handling is problematic - we're executing > >>>>>>>from a signal handler and the VM is crashing. Much of what we do from > >>>>>>>VMError is "best effort". > >>>>>>> > >>>>>>>David > >>>>>>> > >>>>>>>>Could you review again? > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.01/ > >>>>>>>> > >>>>>>>> > >>>>>>>>>This needs to be reviewed by the GC folk not runtime. Please direct > >>>>>>>>>followups to hotspot-gc-dev. > >>>>>>>> > >>>>>>>>Thanks, David! > >>>>>>>> > >>>>>>>> > >>>>>>>>Yasumasa > >>>>>>>> > >>>>>>>> > >>>>>>>>On 2016/05/06 13:11, David Holmes wrote: > >>>>>>>>>Hi Yasumasa, > >>>>>>>>> > >>>>>>>>>This needs to be reviewed by the GC folk not runtime. Please direct > >>>>>>>>>followups to hotspot-gc-dev. > >>>>>>>>> > >>>>>>>>>Thanks, > >>>>>>>>>David > >>>>>>>>> > >>>>>>>>>On 30/04/2016 12:05 AM, Yasumasa Suenaga wrote: > >>>>>>>>>>Hi all, > >>>>>>>>>> > >>>>>>>>>>This review request is related to [1]. > >>>>>>>>>> > >>>>>>>>>>HeapInfoDCmd calls CollectedHeap::print_on(). > >>>>>>>>>>However, its call does not get Heap_lock. > >>>>>>>>>> > >>>>>>>>>>Heap_lock should be gotten from all heap operations. > >>>>>>>>>> > >>>>>>>>>>I uploaded webrev for this issue. > >>>>>>>>>>Could you review it? > >>>>>>>>>> > >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.00/ > >>>>>>>>>> > >>>>>>>>>>I cannot access JPRT. > >>>>>>>>>>So I need a sponsor. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>Thanks, > >>>>>>>>>> > >>>>>>>>>>Yasumasa > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>[1] > >>>>>>>>>>http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019257.html > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> From dmitry.fazunenko at oracle.com Tue Jun 14 16:14:07 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Tue, 14 Jun 2016 19:14:07 +0300 Subject: RFR(s): 8151283: Implement setting jtreg @requires property vm.isG1Supported. In-Reply-To: <575E64D6.3070908@oracle.com> References: <575E64D6.3070908@oracle.com> Message-ID: <0d04fb34-8103-9007-e15f-0e04521b6496@oracle.com> Hi Stefan, The idea of 'vm.gc.X.acceptable' was an ability to introduce other GC related properties like 'supported', 'default', 'setByErgonomics', 'deprecated', etc. But setting 'vm.gc.X' won't prevent us from adding 'vm.gc.X.Y' later when needed. I fully agree: @requires vm.gc.G1 looks much nicer and causes less questions. New edition: http://cr.openjdk.java.net/~dfazunen/8151283/webrev.01/ Thanks for suggestion that, Dima On 13.06.2016 10:46, Stefan Johansson wrote: > Hi Dima, > > I don't know the code and the way this is invoked good enough to do a > proper review, but I have a style comment. Wouldn't it be nice to only > call the value "vm.gc.G1", and have: > @requires vm.gc.G1 > > I feel that "acceptable" provide very little information and what we > want to @require is that the test is only run with G1 (when supported) > and I think that is clear from such syntax. Comments? > > Thanks, > Stefan > > On 2016-06-10 18:04, Dmitry Fazunenko wrote: >> Hello, >> >> I'm looking for a couple of Reviewers for a simple change, which >> allows to skip tests depending on non supported garbage collectors. >> >> http://cr.openjdk.java.net/~dfazunen/8151283/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8151283 >> >> The fix introduces four new requires boolean properties: >> vm.gc.G1.acceptable >> vm.gc.Serial.acceptable >> vm.gc.Parallel.acceptable >> vm.gc.ConcMarkSweep.acceptable >> Which are set by the jtreg plugin prior the test execution starts. >> After that fix we will be able to replace in tests: >> @requires vm.gc == null | vm.gc == "G1" >> with >> @requires vm.gc.G1.acceptable >> >> 'vm.gc.G1.acceptable' will be evaluated to 'false' not only if other >> GC is set externally, but also if G1 is not supported. >> In other words the fix allows not to run GC specific tests in not >> applicable configurations. >> >> Thanks, >> Dima >> >> >> >> > From michail.chernov at oracle.com Tue Jun 14 18:50:41 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Tue, 14 Jun 2016 21:50:41 +0300 Subject: RFR: 8158412: [TESTBUG] TestIHOPErgo and TestStressG1Humongous should not be executed when JFR is enabled In-Reply-To: <1465911213.2378.60.camel@oracle.com> References: <5758226F.3000108@oracle.com> <1465906920.2378.54.camel@oracle.com> <66ef9098-b7a6-bd60-60c2-a1f0becf0b27@oracle.com> <1465911213.2378.60.camel@oracle.com> Message-ID: <57605201.8000207@oracle.com> HI Thomas, Dima Thanks for your comments. Properties expression were changed to "!vm.flightRecorder". Updated webrev (hotspot) : http://cr.openjdk.java.net/~mchernov/8158412/webrev.hotspot.01/ Michail On 06/14/2016 04:33 PM, Thomas Schatzl wrote: > Hi, > > On Tue, 2016-06-14 at 16:23 +0300, Dmitry Fazunenko wrote: >> Michail, >> >> On 14.06.2016 15:22, Thomas Schatzl wrote: >>> Hi Mikael, >>> >>> On Wed, 2016-06-08 at 16:49 +0300, 8038818: Test Chernov wrote: >>>> Hi, >>>> >>>> Could I have a reviews for this small fix? The fix adds new >>>> custom JTreg setting for @requires tag - vm.FlightRecorder. New >>>> setting is used in all updated tests. Tests will be exclude if >>>> JFR is enabled. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8158412 >>>> http://cr.openjdk.java.net/~mchernov/8158412/webrev.root.00/ >>>> http://cr.openjdk.java.net/~mchernov/8158412/webrev.hotspot.00/ >>>> >>>> Testing - RBT. >>> seems okay, however the syntax to use vm.FlightRecorder seems >>> awkward, i.e. >>> >>> "vm.FlighRecorder != true" >>> >>> Isn't there a way to make it something more common like >>> !vm.FlightRecorder? >>> >>> Not insisting on this, just asking. >> Yes, there is no need to use vm.xxx != true anymore, for those >> properties which are set by our plugin (VMProps). >> All such properties will never be set to 'null', as it's possible for >> vm.opt.xxx, which are set by jtreg. >> So, using !vm.FlightRecored is safe. > then I would prefer to use vm.FlightRecorder this way in the tests. > > Thanks, > Thomas > > From dmitry.fazunenko at oracle.com Tue Jun 14 18:55:37 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Tue, 14 Jun 2016 21:55:37 +0300 Subject: RFR: 8158412: [TESTBUG] TestIHOPErgo and TestStressG1Humongous should not be executed when JFR is enabled In-Reply-To: <57605201.8000207@oracle.com> References: <5758226F.3000108@oracle.com> <1465906920.2378.54.camel@oracle.com> <66ef9098-b7a6-bd60-60c2-a1f0becf0b27@oracle.com> <1465911213.2378.60.camel@oracle.com> <57605201.8000207@oracle.com> Message-ID: <112f4f8a-bfcd-9a5c-44e5-10a945fbb879@oracle.com> Looks good. Thanks, Dima On 14.06.2016 21:50, Michail Chernov wrote: > HI Thomas, Dima > > Thanks for your comments. > > Properties expression were changed to "!vm.flightRecorder". > > Updated webrev (hotspot) : > http://cr.openjdk.java.net/~mchernov/8158412/webrev.hotspot.01/ > > Michail > > On 06/14/2016 04:33 PM, Thomas Schatzl wrote: >> Hi, >> >> On Tue, 2016-06-14 at 16:23 +0300, Dmitry Fazunenko wrote: >>> Michail, >>> >>> On 14.06.2016 15:22, Thomas Schatzl wrote: >>>> Hi Mikael, >>>> >>>> On Wed, 2016-06-08 at 16:49 +0300, 8038818: Test Chernov wrote: >>>>> Hi, >>>>> >>>>> Could I have a reviews for this small fix? The fix adds new >>>>> custom JTreg setting for @requires tag - vm.FlightRecorder. New >>>>> setting is used in all updated tests. Tests will be exclude if >>>>> JFR is enabled. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8158412 >>>>> http://cr.openjdk.java.net/~mchernov/8158412/webrev.root.00/ >>>>> http://cr.openjdk.java.net/~mchernov/8158412/webrev.hotspot.00/ >>>>> >>>>> Testing - RBT. >>>> seems okay, however the syntax to use vm.FlightRecorder seems >>>> awkward, i.e. >>>> >>>> "vm.FlighRecorder != true" >>>> >>>> Isn't there a way to make it something more common like >>>> !vm.FlightRecorder? >>>> >>>> Not insisting on this, just asking. >>> Yes, there is no need to use vm.xxx != true anymore, for those >>> properties which are set by our plugin (VMProps). >>> All such properties will never be set to 'null', as it's possible for >>> vm.opt.xxx, which are set by jtreg. >>> So, using !vm.FlightRecored is safe. >> then I would prefer to use vm.FlightRecorder this way in the tests. >> >> Thanks, >> Thomas >> >> > From david.holmes at oracle.com Tue Jun 14 21:30:01 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jun 2016 07:30:01 +1000 Subject: PING: RFR: JDK-8155730: HeapInfoDCmd should get Heap_lock In-Reply-To: <20160614141419.GY26799@ehelin.jrpg.bea.com> References: <5583e9c0-8f16-72d0-ee55-a30246ab5bc8@oracle.com> <0b5bbf95-c871-f504-d96c-a08ae5277240@gmail.com> <0fccf86b-5ba8-cb3c-f253-d56cc7d1684d@oracle.com> <90b138a9-f67e-4141-fa63-71942c30e91d@gmail.com> <73d13ea4-7d0a-8bb5-6dea-be6c22d08066@oracle.com> <7881a764-1ac2-116e-da54-e57e043a930f@gmail.com> <4ffc0582-f2c0-4724-f21e-2a6510c4da95@gmail.com> <20160613132324.GN26799@ehelin.jrpg.bea.com> <20160614141419.GY26799@ehelin.jrpg.bea.com> Message-ID: <986f1771-3ae0-be75-404c-4cf79550c453@oracle.com> On 15/06/2016 12:14 AM, Erik Helin wrote: > On 2016-06-14, David Holmes wrote: >> Hi Erik, >> >> On 13/06/2016 11:23 PM, Erik Helin wrote: >>> On 2016-06-02, Yasumasa Suenaga wrote: >>>> PING: Could you review it? >>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ >>> >>> This will not work - what if the VM crashes while holding the HeapLock? >> >> I assume you are referring to acquiring the HeapLock in vmError.cpp. But >> that code is not used for actual error reporting only the VMInfo Dcmd. > > Ah alright, I didn't get that that (should that code be moved somewhere > else?). That debate was held when the code was put there. :) The Dcmd produces the same general info as is in the error report, hence all that code is co-located. Thanks, David > Thanks, > Erik > >> Thanks, >> David >> >>> Erik >>> >>>> Yasumasa >>>> >>>> >>>> On 2016/05/17 19:19, Yasumasa Suenaga wrote: >>>>> PING: Could you review it? >>>>> I need review from GC folks. >>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/05/10 22:25, Yasumasa Suenaga wrote: >>>>>> On 2016/05/10 16:48, David Holmes wrote: >>>>>>> On 9/05/2016 10:34 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>>> Taking locks during VMError handling is problematic - we're executing >>>>>>>> >from a signal handler and the VM is crashing. Much of what we do from >>>>>>>>> VMError is "best effort". >>>>>>>> >>>>>>>> I will remove MutexLocker from VMError::report(). >>>>>>>> But I added assert_locked_or_safepoint(Heap_lock) in each CollectedHeap. >>>>>>>> If we remove Heap_lock from VMError::report(), fastdebug HotSpot is failed >>>>>>>> when it prints heap info to hs_err log. >>>>>>>> Should I remove assert_locked_or_safepoint()? >>>>>>> >>>>>>> Yes I think you need to do this. >>>>>> >>>>>> I removed them in new webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.02/ >>>>>> >>>>>>>> VMError::print_vm_info() calls from VMInfoDCmd::execute() only. >>>>>>>> So I think we should take Heap_lock at this function. >>>>>>>> Or should we take Heap_lock at VMInfoDCmd::execute() ? >>>>>>> >>>>>>> If this is called from a DCmd only then I think the lock can be taken in print_vm_info(). >>>>>> >>>>>> I grep'ed HotSpot source, print_vm_info() is called from DCmd only. >>>>>> >>>>>>> Need GC folk to add their weight here. >>>>>> >>>>>> I'm waiting reviewer from GC folks :-) >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/05/09 21:26, David Holmes wrote: >>>>>>>>> On 9/05/2016 10:20 PM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I've sent review request for JDK-8155730. >>>>>>>>>> However, I found caller of Universe::heap()->print_*() in vmError.cpp . >>>>>>>>>> Thus I added MutexLocker(Ex) for Heap_lock to VMError::report() and >>>>>>>>>> VMError::print_vm_info(). >>>>>>>>> >>>>>>>>> Taking locks during VMError handling is problematic - we're executing >>>>>>>> >from a signal handler and the VM is crashing. Much of what we do from >>>>>>>>> VMError is "best effort". >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Could you review again? >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> This needs to be reviewed by the GC folk not runtime. Please direct >>>>>>>>>>> followups to hotspot-gc-dev. >>>>>>>>>> >>>>>>>>>> Thanks, David! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/05/06 13:11, David Holmes wrote: >>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>> >>>>>>>>>>> This needs to be reviewed by the GC folk not runtime. Please direct >>>>>>>>>>> followups to hotspot-gc-dev. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 30/04/2016 12:05 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> This review request is related to [1]. >>>>>>>>>>>> >>>>>>>>>>>> HeapInfoDCmd calls CollectedHeap::print_on(). >>>>>>>>>>>> However, its call does not get Heap_lock. >>>>>>>>>>>> >>>>>>>>>>>> Heap_lock should be gotten from all heap operations. >>>>>>>>>>>> >>>>>>>>>>>> I uploaded webrev for this issue. >>>>>>>>>>>> Could you review it? >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> I cannot access JPRT. >>>>>>>>>>>> So I need a sponsor. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> [1] >>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019257.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> From jwha at google.com Tue Jun 14 21:50:50 2016 From: jwha at google.com (Jungwoo Ha) Date: Tue, 14 Jun 2016 14:50:50 -0700 Subject: Future of CMS In-Reply-To: <51c70a72-6e43-491d-6de8-f3cb38837ef2@oracle.com> References: <51c70a72-6e43-491d-6de8-f3cb38837ef2@oracle.com> Message-ID: > > > But seriously: SAP is supporting CMS and will probably do so for quite a > long time (simply because we do support old Java releases for a very long > time). > > > Completely removing CMS from the HotSpot code base may increase these > support costs considerably for us. > > Do you plan to really delete the sources from the repos or do you only > plan to disable it at build time? > > > I just don't know how this is going to play out. I expect that the > OpenJDK community > will want the sources to stay. In such a case Oracle would want them > segregated sufficiently > that we don't build the the sources. > > I think only disable it at build time would make it easier for us and > others to still support it in the future. But in that case we really have > to come up with a better development model which would allow external > developers to directly push CMS changes (much like ppc64 or aarch64 > changes). Everything else would be a real PITA. > > > I think some model like ppc64/aarch64 would be a good way to go. That > would be a > nice side effect of this change. You know better than I on how to get > there. > We also need to support CMS perhaps for a long time. I like the idea of segregating it, and have more external developers contribute to it. Is there any document or can anyone explain to me how ppc64/arch64 works? In such case, who is responsible for code review, building, testing, release and so on? -------------- next part -------------- An HTML attachment was scrubbed... URL: From per.liden at oracle.com Wed Jun 15 07:38:17 2016 From: per.liden at oracle.com (Per Liden) Date: Wed, 15 Jun 2016 09:38:17 +0200 Subject: RFR: 8149778: serviceability/tmtools/jstat/GcCapacityTest.java causes JVM to hang during GC In-Reply-To: <41635f61-3ae1-d697-5dbe-ca3d65c813ac@oracle.com> References: <41635f61-3ae1-d697-5dbe-ca3d65c813ac@oracle.com> Message-ID: <576105E9.7030705@oracle.com> Looks good Robbin. Per On 2016-06-14 16:01, Robbin Ehn wrote: > Hi all, > > In 8152989 "-Xmx128M" was added to this test. > This seem to solves timeout issues (describe by Kim in case). > > So this patch removes the ignore flag from test. > > It also address the issue raised by Kim by looping over long instead of > float. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149778 > Webrev: http://cr.openjdk.java.net/~rehn/8149778/webrev/ > > Tested on multiple platforms and hosts. > > Thanks! > > /Robbin From stefan.karlsson at oracle.com Wed Jun 15 07:39:34 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 15 Jun 2016 09:39:34 +0200 Subject: RFR: 8149778: serviceability/tmtools/jstat/GcCapacityTest.java causes JVM to hang during GC In-Reply-To: <41635f61-3ae1-d697-5dbe-ca3d65c813ac@oracle.com> References: <41635f61-3ae1-d697-5dbe-ca3d65c813ac@oracle.com> Message-ID: <57610636.8040506@oracle.com> Looks good. StefanK On 2016-06-14 16:01, Robbin Ehn wrote: > Hi all, > > In 8152989 "-Xmx128M" was added to this test. > This seem to solves timeout issues (describe by Kim in case). > > So this patch removes the ignore flag from test. > > It also address the issue raised by Kim by looping over long instead > of float. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149778 > Webrev: http://cr.openjdk.java.net/~rehn/8149778/webrev/ > > Tested on multiple platforms and hosts. > > Thanks! > > /Robbin From per.liden at oracle.com Wed Jun 15 07:41:26 2016 From: per.liden at oracle.com (Per Liden) Date: Wed, 15 Jun 2016 09:41:26 +0200 Subject: RFR: 8158871: Long response times with G1 and StringDeduplication In-Reply-To: <1465912973.2378.70.camel@oracle.com> References: <575E88CD.8030803@oracle.com> <575FF626.6090409@oracle.com> <1465912973.2378.70.camel@oracle.com> Message-ID: <576106A6.8040205@oracle.com> Hi Thomas, On 2016-06-14 16:02, Thomas Schatzl wrote: > Hi Per, > > some quick initial comments: > > On Tue, 2016-06-14 at 14:18 +0200, Per Liden wrote: >> Hi, >> >> Received some comments off-line and here's an updated webrev: >> >> http://cr.openjdk.java.net/~pliden/8158871/webrev.1/ >> >> Main difference is that the overflow list now lives next to the cache >> list, rather than inside the cache list. > > - did you ever measure how long the deletion of all entries could Yes, for many millions of entries it can take many seconds. It's especially bad on Solaris (where this bug was uncovered). > take? It does not try to synchronize for safepoints, so potentially > could delay safepoint for a long time. > (in G1StringDedupEntryCache::delete_overflowed) I think you might have the STS backwards. You're only blocking (or synchronizing with) safepoints when joined to the STS. The purpose of this fix is to change how deletion works so that the dedup thread isn't joined to the STS and hence doesn't block safepoints. > > - I would kind of prefer > if G1StringDedupEntryCache::G1StringDedupEntryCache() would call > set_max_size() to set _max_list_lengths instead of duplicating the code > in the initialization list. Will fix. > > - any concurrent kind of work should have log message at the > beginning and the end of that work, otherwise it may be hard to find > out what the process is doing from the log (i.e. delaying the > safepoint) at the moment. I agree, strdedup should be more aligned with how logging is done with UL these days. I'd prefer to file a separate bug for that as it's kind of unrelated to this bug (this bug . (and as mentioned above, this doesn't delay safepoints). > > - I am not sure if the default value of max_cache_size are good > values. I mean, if you have lots of threads (we are running on machines > with 2k+ threads already), the cache size will be zero by default. I'm thinking that's ok. The max cache size will be small (or zero) only if you have a tiny dedup table. A tiny dedup table indicates that you aren't doing much inserts into it (if you did it would automatically grow and max_cache_size would grow with it), so a cache will not help you much anyway in that case. It's probably also worth mentioning that the main purpose of the cache is to allow for the delayed/deferred freeing of entries. thanks, Per > > Thanks, > Thomas > From robbin.ehn at oracle.com Wed Jun 15 07:41:37 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 15 Jun 2016 09:41:37 +0200 Subject: RFR: 8149778: serviceability/tmtools/jstat/GcCapacityTest.java causes JVM to hang during GC In-Reply-To: <57610636.8040506@oracle.com> References: <41635f61-3ae1-d697-5dbe-ca3d65c813ac@oracle.com> <57610636.8040506@oracle.com> Message-ID: <69e8400a-0cf3-6f64-993c-443ed2d718f5@oracle.com> Thanks Stefan! /Robbin On 06/15/2016 09:39 AM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2016-06-14 16:01, Robbin Ehn wrote: >> Hi all, >> >> In 8152989 "-Xmx128M" was added to this test. >> This seem to solves timeout issues (describe by Kim in case). >> >> So this patch removes the ignore flag from test. >> >> It also address the issue raised by Kim by looping over long instead of float. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8149778 >> Webrev: http://cr.openjdk.java.net/~rehn/8149778/webrev/ >> >> Tested on multiple platforms and hosts. >> >> Thanks! >> >> /Robbin > From robbin.ehn at oracle.com Wed Jun 15 07:41:53 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 15 Jun 2016 09:41:53 +0200 Subject: RFR: 8149778: serviceability/tmtools/jstat/GcCapacityTest.java causes JVM to hang during GC In-Reply-To: <576105E9.7030705@oracle.com> References: <41635f61-3ae1-d697-5dbe-ca3d65c813ac@oracle.com> <576105E9.7030705@oracle.com> Message-ID: Thanks Per! /Robbin On 06/15/2016 09:38 AM, Per Liden wrote: > Looks good Robbin. > > Per > > On 2016-06-14 16:01, Robbin Ehn wrote: >> Hi all, >> >> In 8152989 "-Xmx128M" was added to this test. >> This seem to solves timeout issues (describe by Kim in case). >> >> So this patch removes the ignore flag from test. >> >> It also address the issue raised by Kim by looping over long instead of >> float. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8149778 >> Webrev: http://cr.openjdk.java.net/~rehn/8149778/webrev/ >> >> Tested on multiple platforms and hosts. >> >> Thanks! >> >> /Robbin From volker.simonis at gmail.com Wed Jun 15 08:43:48 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jun 2016 10:43:48 +0200 Subject: Future of CMS In-Reply-To: References: <51c70a72-6e43-491d-6de8-f3cb38837ef2@oracle.com> Message-ID: On Tue, Jun 14, 2016 at 11:50 PM, Jungwoo Ha wrote: >> >> But seriously: SAP is supporting CMS and will probably do so for quite a >> long time (simply because we do support old Java releases for a very long >> time). >> >> >> Completely removing CMS from the HotSpot code base may increase these >> support costs considerably for us. >> >> Do you plan to really delete the sources from the repos or do you only >> plan to disable it at build time? >> >> >> I just don't know how this is going to play out. I expect that the >> OpenJDK community >> will want the sources to stay. In such a case Oracle would want them >> segregated sufficiently >> that we don't build the the sources. >> >> I think only disable it at build time would make it easier for us and >> others to still support it in the future. But in that case we really have to >> come up with a better development model which would allow external >> developers to directly push CMS changes (much like ppc64 or aarch64 >> changes). Everything else would be a real PITA. >> >> >> I think some model like ppc64/aarch64 would be a good way to go. That >> would be a >> nice side effect of this change. You know better than I on how to get >> there. > > > We also need to support CMS perhaps for a long time. I like the idea of > segregating it, and have more external developers contribute to it. > Is there any document or can anyone explain to me how ppc64/arch64 works? > In such case, who is responsible for code review, building, testing, release > and so on? There's nothing special in the way the ppc64/arch64 projects/ports work. They are integral part of hotspot/openjdk and contributing to them is regulated by the very same rules. The only thing that we've manged to somehow mitigate for ppc64/arch64 is the pain that external (i.e. non-Oracle) committers are still not able to directly push to the hotspot repositories because of Oracles inability/unwillingness to open up their infamous JPRT pre-integration test system. So as an exception to this restriction, we are now allowed to push changes directly, if they only touch files in hotspot/src/cpu/{ppc,aarch64}. This helps a little bit but still not always, because many changes still touch shared code (e.g. if they come with a regression test which is in hotspot/test we already need an Oracle sponsor even if we're committers and the change is fully reviewed). Building and testing the ports is the exclusive duty of the corresponding projects. So for example we at SAP have nightly builds of all relevant OpenJDK repositories on our porting platforms and I'm pretty sure Red Hat has the same for aarch64. Regarding CMS, I think the idea is that the CMS sources should be separated into their own directory with the same relaxed checkin rules like the ones for ppc64/arch64. But again this would only help a little bit, because there will still remain quite some supporting CMS code in shared places (e.g. runtime, compilers, etc..). Also, building CMS will probably be controlled by a build-time/configure option (i.e. --use-cms) which will be switched off by default. So it would be our duty to build with these option turned on and test the resulting builds. Regards, Volker > From erik.helin at oracle.com Wed Jun 15 11:11:24 2016 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 15 Jun 2016 13:11:24 +0200 Subject: RFR (S): 8152438: Threads may do significant work out of the non-shared overflow buffer In-Reply-To: <1462971929.2594.9.camel@oracle.com> References: <1462952100.2448.7.camel@oracle.com> <1462971929.2594.9.camel@oracle.com> Message-ID: <20160615111124.GA26799@ehelin.jrpg.bea.com> On 2016-05-11, Thomas Schatzl wrote: > Hi all, > > On Wed, 2016-05-11 at 09:35 +0200, Thomas Schatzl wrote: > > Hi all, > > > > ? can I have reviews for the following change that fixes signficiant > > imbalance in work performed during GC? > > > > We observed that threads in certain situations put a lot of > > references > > into the thread-private overflow queue. Since this overflow queue is > > thread-local, and other threads may not steal work from this queue, > > it > > happens that sometimes the parallel copying phase is severely > > serialized. > > > > This is particularly problematic on large machines with many threads > > but comparatively little work to do. In one situation on a real world > > application, a 200% overall throughput improvement has been observed > > by > > this change. > > > > The CR mentions a micro-benchmark that exhibits the same problems. > > > > The proposed solution is to, for a particular thread, if it processes > > entries from the overflow queue, first try to just move the work item > > to the shared queue where other threads can steal from. Only process > > the item directly if the shared queue is full already. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8152438 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8152438/webrev/ > > Testing: > > jprt, regular perf testing with no apparent pause time regressions, > > some benchmarks > > ? had some offline discussion with Erik about the change, and the main > gripe with the change has mainly been putting additional policy code > about how the OverflowTaskQueue works somewhere completely unrelated, > in this case G1ParScanThreadState::trim_queue(). > > Looking at other uses, we found that all of these do the same, and it > would be much better to have collector/case specific > "OverflowTaskQueue"s that encapsulate the behavior. This would also > allow potential sharing or at least comparison of them. > > We felt that looking into that is out of scope for this change (apart > from one minor renaming of try_push()), and I filed JDK-8156754?for > this other work. > Another point came up was why not doing bulk-move of the queue elements > from the overflow queue to the task queue. Due to already being late > for FC, we also moved this to an RFE,?JDK-8156739. > > http://cr.openjdk.java.net/~tschatzl/8152438/webrev.1 (full) > http://cr.openjdk.java.net/~tschatzl/8152438/webrev.0_to_1 (diff) Looks good, Reviwed. Thanks, Erik > Thanks, > ? Thomas From michail.chernov at oracle.com Wed Jun 15 11:27:15 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Wed, 15 Jun 2016 14:27:15 +0300 Subject: RFR: 8158412: [TESTBUG] TestIHOPErgo and TestStressG1Humongous should not be executed when JFR is enabled In-Reply-To: <112f4f8a-bfcd-9a5c-44e5-10a945fbb879@oracle.com> References: <5758226F.3000108@oracle.com> <1465906920.2378.54.camel@oracle.com> <66ef9098-b7a6-bd60-60c2-a1f0becf0b27@oracle.com> <1465911213.2378.60.camel@oracle.com> <57605201.8000207@oracle.com> <112f4f8a-bfcd-9a5c-44e5-10a945fbb879@oracle.com> Message-ID: <57613B93.80008@oracle.com> Dima, Thanks a lot for your review! Misha On 06/14/2016 09:55 PM, Dmitry Fazunenko wrote: > Looks good. > > Thanks, > Dima > > On 14.06.2016 21:50, Michail Chernov wrote: >> HI Thomas, Dima >> >> Thanks for your comments. >> >> Properties expression were changed to "!vm.flightRecorder". >> >> Updated webrev (hotspot) : >> http://cr.openjdk.java.net/~mchernov/8158412/webrev.hotspot.01/ >> >> Michail >> >> On 06/14/2016 04:33 PM, Thomas Schatzl wrote: >>> Hi, >>> >>> On Tue, 2016-06-14 at 16:23 +0300, Dmitry Fazunenko wrote: >>>> Michail, >>>> >>>> On 14.06.2016 15:22, Thomas Schatzl wrote: >>>>> Hi Mikael, >>>>> >>>>> On Wed, 2016-06-08 at 16:49 +0300, 8038818: Test Chernov wrote: >>>>>> Hi, >>>>>> >>>>>> Could I have a reviews for this small fix? The fix adds new >>>>>> custom JTreg setting for @requires tag - vm.FlightRecorder. New >>>>>> setting is used in all updated tests. Tests will be exclude if >>>>>> JFR is enabled. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8158412 >>>>>> http://cr.openjdk.java.net/~mchernov/8158412/webrev.root.00/ >>>>>> http://cr.openjdk.java.net/~mchernov/8158412/webrev.hotspot.00/ >>>>>> >>>>>> Testing - RBT. >>>>> seems okay, however the syntax to use vm.FlightRecorder seems >>>>> awkward, i.e. >>>>> >>>>> "vm.FlighRecorder != true" >>>>> >>>>> Isn't there a way to make it something more common like >>>>> !vm.FlightRecorder? >>>>> >>>>> Not insisting on this, just asking. >>>> Yes, there is no need to use vm.xxx != true anymore, for those >>>> properties which are set by our plugin (VMProps). >>>> All such properties will never be set to 'null', as it's possible for >>>> vm.opt.xxx, which are set by jtreg. >>>> So, using !vm.FlightRecored is safe. >>> then I would prefer to use vm.FlightRecorder this way in the tests. >>> >>> Thanks, >>> Thomas >>> >>> >> > > From jon.masamitsu at oracle.com Wed Jun 15 16:28:01 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 15 Jun 2016 09:28:01 -0700 Subject: RFR (S): 8152438: Threads may do significant work out of the non-shared overflow buffer In-Reply-To: <1462971929.2594.9.camel@oracle.com> References: <1462952100.2448.7.camel@oracle.com> <1462971929.2594.9.camel@oracle.com> Message-ID: <57618211.50008@oracle.com> Thomas, Looks good. Jon On 05/11/2016 06:05 AM, Thomas Schatzl wrote: > Hi all, > > On Wed, 2016-05-11 at 09:35 +0200, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for the following change that fixes signficiant >> imbalance in work performed during GC? >> >> We observed that threads in certain situations put a lot of >> references >> into the thread-private overflow queue. Since this overflow queue is >> thread-local, and other threads may not steal work from this queue, >> it >> happens that sometimes the parallel copying phase is severely >> serialized. >> >> This is particularly problematic on large machines with many threads >> but comparatively little work to do. In one situation on a real world >> application, a 200% overall throughput improvement has been observed >> by >> this change. >> >> The CR mentions a micro-benchmark that exhibits the same problems. >> >> The proposed solution is to, for a particular thread, if it processes >> entries from the overflow queue, first try to just move the work item >> to the shared queue where other threads can steal from. Only process >> the item directly if the shared queue is full already. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8152438 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8152438/webrev/ >> Testing: >> jprt, regular perf testing with no apparent pause time regressions, >> some benchmarks > had some offline discussion with Erik about the change, and the main > gripe with the change has mainly been putting additional policy code > about how the OverflowTaskQueue works somewhere completely unrelated, > in this case G1ParScanThreadState::trim_queue(). > > Looking at other uses, we found that all of these do the same, and it > would be much better to have collector/case specific > "OverflowTaskQueue"s that encapsulate the behavior. This would also > allow potential sharing or at least comparison of them. > > We felt that looking into that is out of scope for this change (apart > from one minor renaming of try_push()), and I filed JDK-8156754 for > this other work. > Another point came up was why not doing bulk-move of the queue elements > from the overflow queue to the task queue. Due to already being late > for FC, we also moved this to an RFE, JDK-8156739. > > http://cr.openjdk.java.net/~tschatzl/8152438/webrev.1 (full) > http://cr.openjdk.java.net/~tschatzl/8152438/webrev.0_to_1 (diff) > > Thanks, > Thomas From jwha at google.com Wed Jun 15 18:29:26 2016 From: jwha at google.com (Jungwoo Ha) Date: Wed, 15 Jun 2016 11:29:26 -0700 Subject: Future of CMS In-Reply-To: References: <51c70a72-6e43-491d-6de8-f3cb38837ef2@oracle.com> Message-ID: Sounds reasonable to me. CMS uses quite a bit of common code (ParNew, DefNew, CardTable..., JIT for wb) If we have the build flag, that means we have a macro (e.g. INCLUDE_CMS_GC). It would be great if the common part code is wrapped with the macro, external contributor can submit without the pre-integration test. On Wed, Jun 15, 2016 at 1:43 AM, Volker Simonis wrote: > On Tue, Jun 14, 2016 at 11:50 PM, Jungwoo Ha wrote: > >> > >> But seriously: SAP is supporting CMS and will probably do so for quite a > >> long time (simply because we do support old Java releases for a very > long > >> time). > >> > >> > >> Completely removing CMS from the HotSpot code base may increase these > >> support costs considerably for us. > >> > >> Do you plan to really delete the sources from the repos or do you only > >> plan to disable it at build time? > >> > >> > >> I just don't know how this is going to play out. I expect that the > >> OpenJDK community > >> will want the sources to stay. In such a case Oracle would want them > >> segregated sufficiently > >> that we don't build the the sources. > >> > >> I think only disable it at build time would make it easier for us and > >> others to still support it in the future. But in that case we really > have to > >> come up with a better development model which would allow external > >> developers to directly push CMS changes (much like ppc64 or aarch64 > >> changes). Everything else would be a real PITA. > >> > >> > >> I think some model like ppc64/aarch64 would be a good way to go. That > >> would be a > >> nice side effect of this change. You know better than I on how to get > >> there. > > > > > > We also need to support CMS perhaps for a long time. I like the idea of > > segregating it, and have more external developers contribute to it. > > Is there any document or can anyone explain to me how ppc64/arch64 works? > > In such case, who is responsible for code review, building, testing, > release > > and so on? > > There's nothing special in the way the ppc64/arch64 projects/ports > work. They are integral part of hotspot/openjdk and contributing to > them is regulated by the very same rules. > > The only thing that we've manged to somehow mitigate for ppc64/arch64 > is the pain that external (i.e. non-Oracle) committers are still not > able to directly push to the hotspot repositories because of Oracles > inability/unwillingness to open up their infamous JPRT pre-integration > test system. So as an exception to this restriction, we are now > allowed to push changes directly, if they only touch files in > hotspot/src/cpu/{ppc,aarch64}. This helps a little bit but still not > always, because many changes still touch shared code (e.g. if they > come with a regression test which is in hotspot/test we already need > an Oracle sponsor even if we're committers and the change is fully > reviewed). > > Building and testing the ports is the exclusive duty of the > corresponding projects. So for example we at SAP have nightly builds > of all relevant OpenJDK repositories on our porting platforms and I'm > pretty sure Red Hat has the same for aarch64. > > Regarding CMS, I think the idea is that the CMS sources should be > separated into their own directory with the same relaxed checkin rules > like the ones for ppc64/arch64. But again this would only help a > little bit, because there will still remain quite some supporting CMS > code in shared places (e.g. runtime, compilers, etc..). > > Also, building CMS will probably be controlled by a > build-time/configure option (i.e. --use-cms) which will be switched > off by default. So it would be our duty to build with these option > turned on and test the resulting builds. > > Regards, > Volker > > > > > -- Jungwoo Ha | Java Platform Team | jwha at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Wed Jun 15 21:00:02 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 15 Jun 2016 14:00:02 -0700 Subject: Future of CMS In-Reply-To: References: <51c70a72-6e43-491d-6de8-f3cb38837ef2@oracle.com> Message-ID: <5761C1D2.2070704@oracle.com> Jungwoo, Could you send an example of something that would go under INCLUDE_CMS_GC? We might suggest an alternative. Having macros in the sources sometimes make it harder to read. Thanks. Jon On 06/15/2016 11:29 AM, Jungwoo Ha wrote: > Sounds reasonable to me. > CMS uses quite a bit of common code (ParNew, DefNew, CardTable..., JIT > for wb) > If we have the build flag, that means we have a macro (e.g. > INCLUDE_CMS_GC). > It would be great if the common part code is wrapped with the macro, > external contributor can submit without the pre-integration test. > > > On Wed, Jun 15, 2016 at 1:43 AM, Volker Simonis > > wrote: > > On Tue, Jun 14, 2016 at 11:50 PM, Jungwoo Ha > wrote: > >> > >> But seriously: SAP is supporting CMS and will probably do so > for quite a > >> long time (simply because we do support old Java releases for a > very long > >> time). > >> > >> > >> Completely removing CMS from the HotSpot code base may increase > these > >> support costs considerably for us. > >> > >> Do you plan to really delete the sources from the repos or do > you only > >> plan to disable it at build time? > >> > >> > >> I just don't know how this is going to play out. I expect that the > >> OpenJDK community > >> will want the sources to stay. In such a case Oracle would > want them > >> segregated sufficiently > >> that we don't build the the sources. > >> > >> I think only disable it at build time would make it easier for > us and > >> others to still support it in the future. But in that case we > really have to > >> come up with a better development model which would allow external > >> developers to directly push CMS changes (much like ppc64 or aarch64 > >> changes). Everything else would be a real PITA. > >> > >> > >> I think some model like ppc64/aarch64 would be a good way to > go. That > >> would be a > >> nice side effect of this change. You know better than I on how > to get > >> there. > > > > > > We also need to support CMS perhaps for a long time. I like the > idea of > > segregating it, and have more external developers contribute to it. > > Is there any document or can anyone explain to me how > ppc64/arch64 works? > > In such case, who is responsible for code review, building, > testing, release > > and so on? > > There's nothing special in the way the ppc64/arch64 projects/ports > work. They are integral part of hotspot/openjdk and contributing to > them is regulated by the very same rules. > > The only thing that we've manged to somehow mitigate for ppc64/arch64 > is the pain that external (i.e. non-Oracle) committers are still not > able to directly push to the hotspot repositories because of Oracles > inability/unwillingness to open up their infamous JPRT pre-integration > test system. So as an exception to this restriction, we are now > allowed to push changes directly, if they only touch files in > hotspot/src/cpu/{ppc,aarch64}. This helps a little bit but still not > always, because many changes still touch shared code (e.g. if they > come with a regression test which is in hotspot/test we already need > an Oracle sponsor even if we're committers and the change is fully > reviewed). > > Building and testing the ports is the exclusive duty of the > corresponding projects. So for example we at SAP have nightly builds > of all relevant OpenJDK repositories on our porting platforms and I'm > pretty sure Red Hat has the same for aarch64. > > Regarding CMS, I think the idea is that the CMS sources should be > separated into their own directory with the same relaxed checkin rules > like the ones for ppc64/arch64. But again this would only help a > little bit, because there will still remain quite some supporting CMS > code in shared places (e.g. runtime, compilers, etc..). > > Also, building CMS will probably be controlled by a > build-time/configure option (i.e. --use-cms) which will be switched > off by default. So it would be our duty to build with these option > turned on and test the resulting builds. > > Regards, > Volker > > > > > > > > > -- > Jungwoo Ha | Java Platform Team | jwha at google.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From per.liden at oracle.com Thu Jun 16 07:16:52 2016 From: per.liden at oracle.com (Per Liden) Date: Thu, 16 Jun 2016 09:16:52 +0200 Subject: RFR: 8158871: Long response times with G1 and StringDeduplication In-Reply-To: <576106A6.8040205@oracle.com> References: <575E88CD.8030803@oracle.com> <575FF626.6090409@oracle.com> <1465912973.2378.70.camel@oracle.com> <576106A6.8040205@oracle.com> Message-ID: <57625264.9020805@oracle.com> Thanks StefanK/StefanJ/Dima/Thomas for reviewing. Updated webrev: http://cr.openjdk.java.net/~pliden/8158871/webrev.2/ Diff: http://cr.openjdk.java.net/~pliden/8158871/webrev.2.diff/ thanks, Per On 2016-06-15 09:41, Per Liden wrote: > Hi Thomas, > > On 2016-06-14 16:02, Thomas Schatzl wrote: >> Hi Per, >> >> some quick initial comments: >> >> On Tue, 2016-06-14 at 14:18 +0200, Per Liden wrote: >>> Hi, >>> >>> Received some comments off-line and here's an updated webrev: >>> >>> http://cr.openjdk.java.net/~pliden/8158871/webrev.1/ >>> >>> Main difference is that the overflow list now lives next to the cache >>> list, rather than inside the cache list. >> >> - did you ever measure how long the deletion of all entries could > > Yes, for many millions of entries it can take many seconds. It's > especially bad on Solaris (where this bug was uncovered). > >> take? It does not try to synchronize for safepoints, so potentially >> could delay safepoint for a long time. >> (in G1StringDedupEntryCache::delete_overflowed) > > I think you might have the STS backwards. You're only blocking (or > synchronizing with) safepoints when joined to the STS. The purpose of > this fix is to change how deletion works so that the dedup thread isn't > joined to the STS and hence doesn't block safepoints. > >> >> - I would kind of prefer >> if G1StringDedupEntryCache::G1StringDedupEntryCache() would call >> set_max_size() to set _max_list_lengths instead of duplicating the code >> in the initialization list. > > Will fix. > >> >> - any concurrent kind of work should have log message at the >> beginning and the end of that work, otherwise it may be hard to find >> out what the process is doing from the log (i.e. delaying the >> safepoint) at the moment. > > I agree, strdedup should be more aligned with how logging is done with > UL these days. I'd prefer to file a separate bug for that as it's kind > of unrelated to this bug (this bug . > > (and as mentioned above, this doesn't delay safepoints). > >> >> - I am not sure if the default value of max_cache_size are good >> values. I mean, if you have lots of threads (we are running on machines >> with 2k+ threads already), the cache size will be zero by default. > > I'm thinking that's ok. The max cache size will be small (or zero) only > if you have a tiny dedup table. A tiny dedup table indicates that you > aren't doing much inserts into it (if you did it would automatically > grow and max_cache_size would grow with it), so a cache will not help > you much anyway in that case. > > It's probably also worth mentioning that the main purpose of the cache > is to allow for the delayed/deferred freeing of entries. > > thanks, > Per > >> >> Thanks, >> Thomas >> From volker.simonis at gmail.com Thu Jun 16 08:52:23 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 16 Jun 2016 10:52:23 +0200 Subject: Future of CMS In-Reply-To: References: <51c70a72-6e43-491d-6de8-f3cb38837ef2@oracle.com> Message-ID: On Wed, Jun 15, 2016 at 8:29 PM, Jungwoo Ha wrote: > Sounds reasonable to me. > CMS uses quite a bit of common code (ParNew, DefNew, CardTable..., JIT for > wb) > If we have the build flag, that means we have a macro (e.g. INCLUDE_CMS_GC). > It would be great if the common part code is wrapped with the macro, > external contributor can submit without the pre-integration test. Unfortunately, exclusion from JPRT currently only works on file level. In general we should really get rid of this restriction at all and I think this project is another good argument in favor of removing it. > > > On Wed, Jun 15, 2016 at 1:43 AM, Volker Simonis > wrote: >> >> On Tue, Jun 14, 2016 at 11:50 PM, Jungwoo Ha wrote: >> >> >> >> But seriously: SAP is supporting CMS and will probably do so for quite >> >> a >> >> long time (simply because we do support old Java releases for a very >> >> long >> >> time). >> >> >> >> >> >> Completely removing CMS from the HotSpot code base may increase these >> >> support costs considerably for us. >> >> >> >> Do you plan to really delete the sources from the repos or do you only >> >> plan to disable it at build time? >> >> >> >> >> >> I just don't know how this is going to play out. I expect that the >> >> OpenJDK community >> >> will want the sources to stay. In such a case Oracle would want them >> >> segregated sufficiently >> >> that we don't build the the sources. >> >> >> >> I think only disable it at build time would make it easier for us and >> >> others to still support it in the future. But in that case we really >> >> have to >> >> come up with a better development model which would allow external >> >> developers to directly push CMS changes (much like ppc64 or aarch64 >> >> changes). Everything else would be a real PITA. >> >> >> >> >> >> I think some model like ppc64/aarch64 would be a good way to go. That >> >> would be a >> >> nice side effect of this change. You know better than I on how to get >> >> there. >> > >> > >> > We also need to support CMS perhaps for a long time. I like the idea of >> > segregating it, and have more external developers contribute to it. >> > Is there any document or can anyone explain to me how ppc64/arch64 >> > works? >> > In such case, who is responsible for code review, building, testing, >> > release >> > and so on? >> >> There's nothing special in the way the ppc64/arch64 projects/ports >> work. They are integral part of hotspot/openjdk and contributing to >> them is regulated by the very same rules. >> >> The only thing that we've manged to somehow mitigate for ppc64/arch64 >> is the pain that external (i.e. non-Oracle) committers are still not >> able to directly push to the hotspot repositories because of Oracles >> inability/unwillingness to open up their infamous JPRT pre-integration >> test system. So as an exception to this restriction, we are now >> allowed to push changes directly, if they only touch files in >> hotspot/src/cpu/{ppc,aarch64}. This helps a little bit but still not >> always, because many changes still touch shared code (e.g. if they >> come with a regression test which is in hotspot/test we already need >> an Oracle sponsor even if we're committers and the change is fully >> reviewed). >> >> Building and testing the ports is the exclusive duty of the >> corresponding projects. So for example we at SAP have nightly builds >> of all relevant OpenJDK repositories on our porting platforms and I'm >> pretty sure Red Hat has the same for aarch64. >> >> Regarding CMS, I think the idea is that the CMS sources should be >> separated into their own directory with the same relaxed checkin rules >> like the ones for ppc64/arch64. But again this would only help a >> little bit, because there will still remain quite some supporting CMS >> code in shared places (e.g. runtime, compilers, etc..). >> >> Also, building CMS will probably be controlled by a >> build-time/configure option (i.e. --use-cms) which will be switched >> off by default. So it would be our duty to build with these option >> turned on and test the resulting builds. >> >> Regards, >> Volker >> >> >> > > > > > > -- > Jungwoo Ha | Java Platform Team | jwha at google.com > From thomas.schatzl at oracle.com Thu Jun 16 10:35:34 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 16 Jun 2016 12:35:34 +0200 Subject: RFR (S): 8152438: Threads may do significant work out of the non-shared overflow buffer In-Reply-To: <57618211.50008@oracle.com> References: <1462952100.2448.7.camel@oracle.com> <1462971929.2594.9.camel@oracle.com> <57618211.50008@oracle.com> Message-ID: <1466073334.2443.19.camel@oracle.com> Hi Jon, Erik, Stefan, On Wed, 2016-06-15 at 09:28 -0700, Jon Masamitsu wrote: > Thomas, > > Looks good. ? thanks for your reviews. Thomas From leonid.mesnik at oracle.com Thu Jun 16 10:47:32 2016 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 16 Jun 2016 13:47:32 +0300 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 In-Reply-To: <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com> References: <5746FDF3.3030102@oracle.com> <57569540.9010106@oracle.com> <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com> Message-ID: <576283C4.4050008@oracle.com> Hi On 09.06.2016 03:43, David Holmes wrote: > Hi Leonid, > > Sorry for the delay. > > On 7/06/2016 7:34 PM, Leonid Mesnik wrote: >> Hi >> >> Added jtreg-use at openjdk.java.net >> >> I think that you are right. Here is the documentation: >> http://openjdk.java.net/jtreg/tag-spec.html >> >> >> "@requires >> >> Express a dependence on characteristics of the system being tested. >> Some harnesses allow tests to be selected according to the >> characteristics of the system being tested. The expression may be >> composed of the following elements:" >> >> "os.arch The operating system architecture, as given by the >> corresponding system property." >> >> So user could expect to have "os.arch" of tested VM. >> >> If filed jtreg issues for this: >> >> 1. CODETOOLS-7901695 >> jtreg uses >> value 'os.arch' property of JDK which executed JDK and not of >> tested JDK >> >> >> Following fix could be used as a temporary workaround while jtreg fix is >> not ready. Does it make a sense? I this case it is needed to change >> linux-arm64 back to linux-aarch64 to minimize changes. > > I still think we have a fundamental problem concerning what os.arch > means. This workaround seems to work but I find it all very confusing. > We really need a vm.arch property, distinct from os.arch. I see that CODETOOLS-7901695 is going to be fixed. After it is implemented the 'os.arch' property will point to 'os.arch' of tested JDK as it described in jtreg documentation. However there are 64 failures in nightly are caused by failures of JVMCI tests. Does it make a sense to implement this fix as a workaround to remove noise until jtreg is fixed? Leonid > > David > ----- > > > >> Leonid >> >> On 31.05.2016 04:26, David Holmes wrote: >>> Hi Leonid, >>> >>> This really strikes me as as a jtreg problem that should be fixed in >>> jtreg. When writing an @requires clause in a test the test writer >>> should not have to be thinking "oh wait! Is this going to query the VM >>> running jtreg or the VM running the test?". It should obviously be the >>> VM running the test. >>> >>> That said we also seem to have a problem with the definition of >>> os.arch: >>> >>> os.arch Operating system architecture >>> >>> if it is returning the build architecture of the VM and not the OS it >>> is running on. That in itself argues for two distinct properties. >>> >>> David >>> >>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote: >>>> Hi >>>> >>>> Could you please review following fix: >>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/ >>>> >>>> hotspot http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/ >>>> >>>> for bug >>>> https://bugs.openjdk.java.net/browse/JDK-8157831 >>>> >>>> >>>> The property "os.name" which was used to filter tests depends on the >>>> arch of jdk which is used to run jtreg. It might differ from arch of >>>> tested jdk. >>>> This fix introduce new property "vm.arch" which depends on the arch of >>>> tested jdk and could be used to filter tests with @requires. >>>> >>>> I verified that tests are filtered where it is expected. >>>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot >>>> testing. >>>> >>>> Leonid >>>> >> From david.holmes at oracle.com Thu Jun 16 10:55:30 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jun 2016 20:55:30 +1000 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 In-Reply-To: <576283C4.4050008@oracle.com> References: <5746FDF3.3030102@oracle.com> <57569540.9010106@oracle.com> <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com> <576283C4.4050008@oracle.com> Message-ID: On 16/06/2016 8:47 PM, Leonid Mesnik wrote: > Hi > > On 09.06.2016 03:43, David Holmes wrote: >> Hi Leonid, >> >> Sorry for the delay. >> >> On 7/06/2016 7:34 PM, Leonid Mesnik wrote: >>> Hi >>> >>> Added jtreg-use at openjdk.java.net >>> >>> I think that you are right. Here is the documentation: >>> http://openjdk.java.net/jtreg/tag-spec.html >>> >>> >>> "@requires >>> >>> Express a dependence on characteristics of the system being tested. >>> Some harnesses allow tests to be selected according to the >>> characteristics of the system being tested. The expression may be >>> composed of the following elements:" >>> >>> "os.arch The operating system architecture, as given by the >>> corresponding system property." >>> >>> So user could expect to have "os.arch" of tested VM. >>> >>> If filed jtreg issues for this: >>> >>> 1. CODETOOLS-7901695 >>> jtreg uses >>> value 'os.arch' property of JDK which executed JDK and not of >>> tested JDK >>> >>> >>> Following fix could be used as a temporary workaround while jtreg fix is >>> not ready. Does it make a sense? I this case it is needed to change >>> linux-arm64 back to linux-aarch64 to minimize changes. >> >> I still think we have a fundamental problem concerning what os.arch >> means. This workaround seems to work but I find it all very confusing. >> We really need a vm.arch property, distinct from os.arch. > I see that CODETOOLS-7901695 is going to be fixed. After it is > implemented the 'os.arch' property will point to 'os.arch' of tested JDK > as it described in jtreg documentation. > However there are 64 failures in nightly are caused by failures of JVMCI > tests. Does it make a sense to implement this fix as a workaround to > remove noise until jtreg is fixed? There may be some delay between jtreg being fixed and the updated version being put in to use. Implementing the workaround seems reasonable. Thanks, David > Leonid >> >> David >> ----- >> >> >> >>> Leonid >>> >>> On 31.05.2016 04:26, David Holmes wrote: >>>> Hi Leonid, >>>> >>>> This really strikes me as as a jtreg problem that should be fixed in >>>> jtreg. When writing an @requires clause in a test the test writer >>>> should not have to be thinking "oh wait! Is this going to query the VM >>>> running jtreg or the VM running the test?". It should obviously be the >>>> VM running the test. >>>> >>>> That said we also seem to have a problem with the definition of >>>> os.arch: >>>> >>>> os.arch Operating system architecture >>>> >>>> if it is returning the build architecture of the VM and not the OS it >>>> is running on. That in itself argues for two distinct properties. >>>> >>>> David >>>> >>>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote: >>>>> Hi >>>>> >>>>> Could you please review following fix: >>>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/ >>>>> >>>>> hotspot http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/ >>>>> >>>>> for bug >>>>> https://bugs.openjdk.java.net/browse/JDK-8157831 >>>>> >>>>> >>>>> The property "os.name" which was used to filter tests depends on the >>>>> arch of jdk which is used to run jtreg. It might differ from arch of >>>>> tested jdk. >>>>> This fix introduce new property "vm.arch" which depends on the arch of >>>>> tested jdk and could be used to filter tests with @requires. >>>>> >>>>> I verified that tests are filtered where it is expected. >>>>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot >>>>> testing. >>>>> >>>>> Leonid >>>>> >>> > From thomas.schatzl at oracle.com Thu Jun 16 12:15:46 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 16 Jun 2016 14:15:46 +0200 Subject: PING: RFR: JDK-8155730: HeapInfoDCmd should get Heap_lock In-Reply-To: <22d73f92-612f-5764-5612-7ee6514a6fbe@gmail.com> References: <955b8a22-d35c-60dc-e202-991b5a5e432d@gmail.com> <5583e9c0-8f16-72d0-ee55-a30246ab5bc8@oracle.com> <0b5bbf95-c871-f504-d96c-a08ae5277240@gmail.com> <0fccf86b-5ba8-cb3c-f253-d56cc7d1684d@oracle.com> <90b138a9-f67e-4141-fa63-71942c30e91d@gmail.com> <73d13ea4-7d0a-8bb5-6dea-be6c22d08066@oracle.com> <7881a764-1ac2-116e-da54-e57e043a930f@gmail.com> <4ffc0582-f2c0-4724-f21e-2a6510c4da95@gmail.com> <20160613132324.GN26799@ehelin.jrpg.bea.com> <22d73f92-612f-5764-5612-7ee6514a6fbe@gmail.com> Message-ID: <1466079346.2443.29.camel@oracle.com> Hi Yasumasa, On Tue, 2016-06-14 at 00:13 +0900, Yasumasa Suenaga wrote: > Hi Thomas, Erik, > > I ran webrev.02 patch, thread dump (SIGQUIT), VM.info jcmd, and > generating hs_err log work fine > on my Fedora23 x64 with fastdebug JDK. > > Please tell me what test(s) failed. > ? (new) test failures do not necessarily mean that there is something wrong with your patch. It only means that the system had some new unrecognized failure modes of some tests :) There is some automated failure matching with existing bugs, but that is not always correct. So in case of new failures we need to look through the failure logs and try to find out which of these failures are actually new failures. In this case, I could, with very high certainty rule out this change as the cause for all these failures. So, the change looks good after all. Thanks, ? Thomas From leonid.mesnik at oracle.com Thu Jun 16 12:34:33 2016 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 16 Jun 2016 15:34:33 +0300 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 In-Reply-To: References: <5746FDF3.3030102@oracle.com> <57569540.9010106@oracle.com> <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com> <576283C4.4050008@oracle.com> Message-ID: <57629CD9.40609@oracle.com> Hi I've updated fix The vm.simpleArch variable has been added which corresponds to os.simpleArch of tested platform. All hotspot tests have been updated to use vm.simpleArch instead of os.simpleArch. Once jtreg is fixed to read 'os.arch' from tested JDK then it would be possible just revert this fix and preserver same behavior (See CODETOOLS-7901695 ) . Updated webrev: http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/root/ http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/hotspot/ Testing is still in progress. Leonid On 16.06.2016 13:55, David Holmes wrote: > On 16/06/2016 8:47 PM, Leonid Mesnik wrote: >> Hi >> >> On 09.06.2016 03:43, David Holmes wrote: >>> Hi Leonid, >>> >>> Sorry for the delay. >>> >>> On 7/06/2016 7:34 PM, Leonid Mesnik wrote: >>>> Hi >>>> >>>> Added jtreg-use at openjdk.java.net >>>> >>>> I think that you are right. Here is the documentation: >>>> http://openjdk.java.net/jtreg/tag-spec.html >>>> >>>> >>>> "@requires >>>> >>>> Express a dependence on characteristics of the system being >>>> tested. >>>> Some harnesses allow tests to be selected according to the >>>> characteristics of the system being tested. The expression may be >>>> composed of the following elements:" >>>> >>>> "os.arch The operating system architecture, as given by the >>>> corresponding system property." >>>> >>>> So user could expect to have "os.arch" of tested VM. >>>> >>>> If filed jtreg issues for this: >>>> >>>> 1. CODETOOLS-7901695 >>>> jtreg uses >>>> value 'os.arch' property of JDK which executed JDK and not of >>>> tested JDK >>>> >>>> >>>> Following fix could be used as a temporary workaround while jtreg >>>> fix is >>>> not ready. Does it make a sense? I this case it is needed to change >>>> linux-arm64 back to linux-aarch64 to minimize changes. >>> >>> I still think we have a fundamental problem concerning what os.arch >>> means. This workaround seems to work but I find it all very confusing. >>> We really need a vm.arch property, distinct from os.arch. >> I see that CODETOOLS-7901695 is going to be fixed. After it is >> implemented the 'os.arch' property will point to 'os.arch' of tested JDK >> as it described in jtreg documentation. >> However there are 64 failures in nightly are caused by failures of JVMCI >> tests. Does it make a sense to implement this fix as a workaround to >> remove noise until jtreg is fixed? > > There may be some delay between jtreg being fixed and the updated > version being put in to use. > > Implementing the workaround seems reasonable. > > Thanks, > David > >> Leonid >>> >>> David >>> ----- >>> >>> >>> >>>> Leonid >>>> >>>> On 31.05.2016 04:26, David Holmes wrote: >>>>> Hi Leonid, >>>>> >>>>> This really strikes me as as a jtreg problem that should be fixed in >>>>> jtreg. When writing an @requires clause in a test the test writer >>>>> should not have to be thinking "oh wait! Is this going to query >>>>> the VM >>>>> running jtreg or the VM running the test?". It should obviously be >>>>> the >>>>> VM running the test. >>>>> >>>>> That said we also seem to have a problem with the definition of >>>>> os.arch: >>>>> >>>>> os.arch Operating system architecture >>>>> >>>>> if it is returning the build architecture of the VM and not the OS it >>>>> is running on. That in itself argues for two distinct properties. >>>>> >>>>> David >>>>> >>>>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote: >>>>>> Hi >>>>>> >>>>>> Could you please review following fix: >>>>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/ >>>>>> >>>>>> hotspot >>>>>> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/ >>>>>> >>>>>> for bug >>>>>> https://bugs.openjdk.java.net/browse/JDK-8157831 >>>>>> >>>>>> >>>>>> The property "os.name" which was used to filter tests depends on the >>>>>> arch of jdk which is used to run jtreg. It might differ from arch of >>>>>> tested jdk. >>>>>> This fix introduce new property "vm.arch" which depends on the >>>>>> arch of >>>>>> tested jdk and could be used to filter tests with @requires. >>>>>> >>>>>> I verified that tests are filtered where it is expected. >>>>>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot >>>>>> testing. >>>>>> >>>>>> Leonid >>>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From michail.chernov at oracle.com Thu Jun 16 12:57:53 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Thu, 16 Jun 2016 15:57:53 +0300 Subject: RFR: 8158412: [TESTBUG] TestIHOPErgo and TestStressG1Humongous should not be executed when JFR is enabled In-Reply-To: <57613B93.80008@oracle.com> References: <5758226F.3000108@oracle.com> <1465906920.2378.54.camel@oracle.com> <66ef9098-b7a6-bd60-60c2-a1f0becf0b27@oracle.com> <1465911213.2378.60.camel@oracle.com> <57605201.8000207@oracle.com> <112f4f8a-bfcd-9a5c-44e5-10a945fbb879@oracle.com> <57613B93.80008@oracle.com> Message-ID: <5762A251.6030904@oracle.com> Hi, Could I get a review from reviewer please? This fix blocks other changes which depends on it. Thanks, Michail On 06/15/2016 02:27 PM, Michail Chernov wrote: > Dima, > > Thanks a lot for your review! > > Misha > > On 06/14/2016 09:55 PM, Dmitry Fazunenko wrote: >> Looks good. >> >> Thanks, >> Dima >> >> On 14.06.2016 21:50, Michail Chernov wrote: >>> HI Thomas, Dima >>> >>> Thanks for your comments. >>> >>> Properties expression were changed to "!vm.flightRecorder". >>> >>> Updated webrev (hotspot) : >>> http://cr.openjdk.java.net/~mchernov/8158412/webrev.hotspot.01/ >>> >>> Michail >>> >>> On 06/14/2016 04:33 PM, Thomas Schatzl wrote: >>>> Hi, >>>> >>>> On Tue, 2016-06-14 at 16:23 +0300, Dmitry Fazunenko wrote: >>>>> Michail, >>>>> >>>>> On 14.06.2016 15:22, Thomas Schatzl wrote: >>>>>> Hi Mikael, >>>>>> >>>>>> On Wed, 2016-06-08 at 16:49 +0300, 8038818: Test Chernov wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Could I have a reviews for this small fix? The fix adds new >>>>>>> custom JTreg setting for @requires tag - vm.FlightRecorder. New >>>>>>> setting is used in all updated tests. Tests will be exclude if >>>>>>> JFR is enabled. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158412 >>>>>>> http://cr.openjdk.java.net/~mchernov/8158412/webrev.root.00/ >>>>>>> http://cr.openjdk.java.net/~mchernov/8158412/webrev.hotspot.00/ >>>>>>> >>>>>>> Testing - RBT. >>>>>> seems okay, however the syntax to use vm.FlightRecorder seems >>>>>> awkward, i.e. >>>>>> >>>>>> "vm.FlighRecorder != true" >>>>>> >>>>>> Isn't there a way to make it something more common like >>>>>> !vm.FlightRecorder? >>>>>> >>>>>> Not insisting on this, just asking. >>>>> Yes, there is no need to use vm.xxx != true anymore, for those >>>>> properties which are set by our plugin (VMProps). >>>>> All such properties will never be set to 'null', as it's possible for >>>>> vm.opt.xxx, which are set by jtreg. >>>>> So, using !vm.FlightRecored is safe. >>>> then I would prefer to use vm.FlightRecorder this way in the tests. >>>> >>>> Thanks, >>>> Thomas >>>> >>>> >>> >> >> > > From thomas.schatzl at oracle.com Thu Jun 16 13:19:43 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 16 Jun 2016 15:19:43 +0200 Subject: RFR: 8158412: [TESTBUG] TestIHOPErgo and TestStressG1Humongous should not be executed when JFR is enabled In-Reply-To: <5762A251.6030904@oracle.com> References: <5758226F.3000108@oracle.com> <1465906920.2378.54.camel@oracle.com> <66ef9098-b7a6-bd60-60c2-a1f0becf0b27@oracle.com> <1465911213.2378.60.camel@oracle.com> <57605201.8000207@oracle.com> <112f4f8a-bfcd-9a5c-44e5-10a945fbb879@oracle.com> <57613B93.80008@oracle.com> <5762A251.6030904@oracle.com> Message-ID: <1466083183.2443.34.camel@oracle.com> Hi Michail, On Thu, 2016-06-16 at 15:57 +0300, Michail Chernov wrote: > Hi, > > Could I get a review from reviewer please? This fix blocks other > changes? > which depends on it. > ? looks good. Sorry for the delay. Thomas From michail.chernov at oracle.com Thu Jun 16 13:20:38 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Thu, 16 Jun 2016 16:20:38 +0300 Subject: RFR(s): 8151283: Implement setting jtreg @requires property vm.isG1Supported. In-Reply-To: <0d04fb34-8103-9007-e15f-0e04521b6496@oracle.com> References: <575E64D6.3070908@oracle.com> <0d04fb34-8103-9007-e15f-0e04521b6496@oracle.com> Message-ID: <5762A7A6.5050506@oracle.com> Hi Dima, I have a question about paths: requires.extraPropDefns = ../../test/jtreg-ext/requires/VMProps.java -requires.properties=sun.arch.data.model +requires.extraPropDefns.bootlibs = ../../test/lib/sun Do we need to use relative paths instead of full? We use full path in tests: TestSmallHeap.java: * @library /testlibrary /test/lib /test/lib/share/classes Thanks, Michail On 06/14/2016 07:14 PM, Dmitry Fazunenko wrote: > Hi Stefan, > > The idea of 'vm.gc.X.acceptable' was an ability to introduce other GC > related properties like 'supported', 'default', 'setByErgonomics', > 'deprecated', etc. > But setting 'vm.gc.X' won't prevent us from adding 'vm.gc.X.Y' later > when needed. > > I fully agree: @requires vm.gc.G1 looks much nicer and causes less > questions. > > New edition: > http://cr.openjdk.java.net/~dfazunen/8151283/webrev.01/ > > Thanks for suggestion that, > Dima > > > On 13.06.2016 10:46, Stefan Johansson wrote: >> Hi Dima, >> >> I don't know the code and the way this is invoked good enough to do a >> proper review, but I have a style comment. Wouldn't it be nice to >> only call the value "vm.gc.G1", and have: >> @requires vm.gc.G1 >> >> I feel that "acceptable" provide very little information and what we >> want to @require is that the test is only run with G1 (when >> supported) and I think that is clear from such syntax. Comments? >> >> Thanks, >> Stefan >> >> On 2016-06-10 18:04, Dmitry Fazunenko wrote: >>> Hello, >>> >>> I'm looking for a couple of Reviewers for a simple change, which >>> allows to skip tests depending on non supported garbage collectors. >>> >>> http://cr.openjdk.java.net/~dfazunen/8151283/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8151283 >>> >>> The fix introduces four new requires boolean properties: >>> vm.gc.G1.acceptable >>> vm.gc.Serial.acceptable >>> vm.gc.Parallel.acceptable >>> vm.gc.ConcMarkSweep.acceptable >>> Which are set by the jtreg plugin prior the test execution starts. >>> After that fix we will be able to replace in tests: >>> @requires vm.gc == null | vm.gc == "G1" >>> with >>> @requires vm.gc.G1.acceptable >>> >>> 'vm.gc.G1.acceptable' will be evaluated to 'false' not only if other >>> GC is set externally, but also if G1 is not supported. >>> In other words the fix allows not to run GC specific tests in not >>> applicable configurations. >>> >>> Thanks, >>> Dima >>> >>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michail.chernov at oracle.com Thu Jun 16 13:21:50 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Thu, 16 Jun 2016 16:21:50 +0300 Subject: RFR: 8158412: [TESTBUG] TestIHOPErgo and TestStressG1Humongous should not be executed when JFR is enabled In-Reply-To: <1466083183.2443.34.camel@oracle.com> References: <5758226F.3000108@oracle.com> <1465906920.2378.54.camel@oracle.com> <66ef9098-b7a6-bd60-60c2-a1f0becf0b27@oracle.com> <1465911213.2378.60.camel@oracle.com> <57605201.8000207@oracle.com> <112f4f8a-bfcd-9a5c-44e5-10a945fbb879@oracle.com> <57613B93.80008@oracle.com> <5762A251.6030904@oracle.com> <1466083183.2443.34.camel@oracle.com> Message-ID: <5762A7EE.3040201@oracle.com> Hi Thomas, Thanks a lot! Misha On 06/16/2016 04:19 PM, Thomas Schatzl wrote: > Hi Michail, > > On Thu, 2016-06-16 at 15:57 +0300, Michail Chernov wrote: >> Hi, >> >> Could I get a review from reviewer please? This fix blocks other >> changes >> which depends on it. >> > looks good. Sorry for the delay. > > Thomas > > From dmitry.fazunenko at oracle.com Thu Jun 16 13:34:08 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 16 Jun 2016 16:34:08 +0300 Subject: RFR(s): 8151283: Implement setting jtreg @requires property vm.isG1Supported. In-Reply-To: <5762A7A6.5050506@oracle.com> References: <575E64D6.3070908@oracle.com> <0d04fb34-8103-9007-e15f-0e04521b6496@oracle.com> <5762A7A6.5050506@oracle.com> Message-ID: Hi Michail, This is TEST.ROOT file, which defines itself what is the root for libraries: 48 # Path to libraries in the topmost test directory. This is needed so @library 49 # does not need ../../ notation to reach them 50 external.lib.roots = ../../ So, for the stuff like VMProps we need to use "../.." in paths Thanks, Dima On 16.06.2016 16:20, Michail Chernov wrote: > Hi Dima, > > I have a question about paths: > > requires.extraPropDefns = ../../test/jtreg-ext/requires/VMProps.java > -requires.properties=sun.arch.data.model > +requires.extraPropDefns.bootlibs = ../../test/lib/sun > > Do we need to use relative paths instead of full? We use full path in > tests: > > TestSmallHeap.java: * @library /testlibrary /test/lib > /test/lib/share/classes > > Thanks, > Michail > > On 06/14/2016 07:14 PM, Dmitry Fazunenko wrote: >> Hi Stefan, >> >> The idea of 'vm.gc.X.acceptable' was an ability to introduce other GC >> related properties like 'supported', 'default', 'setByErgonomics', >> 'deprecated', etc. >> But setting 'vm.gc.X' won't prevent us from adding 'vm.gc.X.Y' later >> when needed. >> >> I fully agree: @requires vm.gc.G1 looks much nicer and causes less >> questions. >> >> New edition: >> http://cr.openjdk.java.net/~dfazunen/8151283/webrev.01/ >> >> Thanks for suggestion that, >> Dima >> >> >> On 13.06.2016 10:46, Stefan Johansson wrote: >>> Hi Dima, >>> >>> I don't know the code and the way this is invoked good enough to do >>> a proper review, but I have a style comment. Wouldn't it be nice to >>> only call the value "vm.gc.G1", and have: >>> @requires vm.gc.G1 >>> >>> I feel that "acceptable" provide very little information and what we >>> want to @require is that the test is only run with G1 (when >>> supported) and I think that is clear from such syntax. Comments? >>> >>> Thanks, >>> Stefan >>> >>> On 2016-06-10 18:04, Dmitry Fazunenko wrote: >>>> Hello, >>>> >>>> I'm looking for a couple of Reviewers for a simple change, which >>>> allows to skip tests depending on non supported garbage collectors. >>>> >>>> http://cr.openjdk.java.net/~dfazunen/8151283/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8151283 >>>> >>>> The fix introduces four new requires boolean properties: >>>> vm.gc.G1.acceptable >>>> vm.gc.Serial.acceptable >>>> vm.gc.Parallel.acceptable >>>> vm.gc.ConcMarkSweep.acceptable >>>> Which are set by the jtreg plugin prior the test execution starts. >>>> After that fix we will be able to replace in tests: >>>> @requires vm.gc == null | vm.gc == "G1" >>>> with >>>> @requires vm.gc.G1.acceptable >>>> >>>> 'vm.gc.G1.acceptable' will be evaluated to 'false' not only if >>>> other GC is set externally, but also if G1 is not supported. >>>> In other words the fix allows not to run GC specific tests in not >>>> applicable configurations. >>>> >>>> Thanks, >>>> Dima >>>> >>>> >>>> >>>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michail.chernov at oracle.com Thu Jun 16 13:38:21 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Thu, 16 Jun 2016 16:38:21 +0300 Subject: RFR(s): 8151283: Implement setting jtreg @requires property vm.isG1Supported. In-Reply-To: References: <575E64D6.3070908@oracle.com> <0d04fb34-8103-9007-e15f-0e04521b6496@oracle.com> <5762A7A6.5050506@oracle.com> Message-ID: <5762ABCD.5020808@oracle.com> Dima, Thank you for clarification, looks good to me. Misha On 06/16/2016 04:34 PM, Dmitry Fazunenko wrote: > Hi Michail, > > This is TEST.ROOT file, which defines itself what is the root for > libraries: > 48 # Path to libraries in the topmost test directory. This is needed so @library > 49 # does not need ../../ notation to reach them > 50 external.lib.roots = ../../ > So, for the stuff like VMProps we need to use "../.." in paths > > Thanks, > Dima > > On 16.06.2016 16:20, Michail Chernov wrote: >> Hi Dima, >> >> I have a question about paths: >> >> requires.extraPropDefns = ../../test/jtreg-ext/requires/VMProps.java >> -requires.properties=sun.arch.data.model >> +requires.extraPropDefns.bootlibs = ../../test/lib/sun >> >> Do we need to use relative paths instead of full? We use full path in >> tests: >> >> TestSmallHeap.java: * @library /testlibrary /test/lib >> /test/lib/share/classes >> >> Thanks, >> Michail >> >> On 06/14/2016 07:14 PM, Dmitry Fazunenko wrote: >>> Hi Stefan, >>> >>> The idea of 'vm.gc.X.acceptable' was an ability to introduce other >>> GC related properties like 'supported', 'default', >>> 'setByErgonomics', 'deprecated', etc. >>> But setting 'vm.gc.X' won't prevent us from adding 'vm.gc.X.Y' later >>> when needed. >>> >>> I fully agree: @requires vm.gc.G1 looks much nicer and causes less >>> questions. >>> >>> New edition: >>> http://cr.openjdk.java.net/~dfazunen/8151283/webrev.01/ >>> >>> Thanks for suggestion that, >>> Dima >>> >>> >>> On 13.06.2016 10:46, Stefan Johansson wrote: >>>> Hi Dima, >>>> >>>> I don't know the code and the way this is invoked good enough to do >>>> a proper review, but I have a style comment. Wouldn't it be nice to >>>> only call the value "vm.gc.G1", and have: >>>> @requires vm.gc.G1 >>>> >>>> I feel that "acceptable" provide very little information and what >>>> we want to @require is that the test is only run with G1 (when >>>> supported) and I think that is clear from such syntax. Comments? >>>> >>>> Thanks, >>>> Stefan >>>> >>>> On 2016-06-10 18:04, Dmitry Fazunenko wrote: >>>>> Hello, >>>>> >>>>> I'm looking for a couple of Reviewers for a simple change, which >>>>> allows to skip tests depending on non supported garbage collectors. >>>>> >>>>> http://cr.openjdk.java.net/~dfazunen/8151283/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8151283 >>>>> >>>>> The fix introduces four new requires boolean properties: >>>>> vm.gc.G1.acceptable >>>>> vm.gc.Serial.acceptable >>>>> vm.gc.Parallel.acceptable >>>>> vm.gc.ConcMarkSweep.acceptable >>>>> Which are set by the jtreg plugin prior the test execution starts. >>>>> After that fix we will be able to replace in tests: >>>>> @requires vm.gc == null | vm.gc == "G1" >>>>> with >>>>> @requires vm.gc.G1.acceptable >>>>> >>>>> 'vm.gc.G1.acceptable' will be evaluated to 'false' not only if >>>>> other GC is set externally, but also if G1 is not supported. >>>>> In other words the fix allows not to run GC specific tests in not >>>>> applicable configurations. >>>>> >>>>> Thanks, >>>>> Dima >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Thu Jun 16 13:45:23 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Thu, 16 Jun 2016 16:45:23 +0300 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 In-Reply-To: <57629CD9.40609@oracle.com> References: <5746FDF3.3030102@oracle.com> <57569540.9010106@oracle.com> <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com> <576283C4.4050008@oracle.com> <57629CD9.40609@oracle.com> Message-ID: <5762AD73.9030506@oracle.com> Leonid, thank you for taking care of this issue. Looks good to me(not a reviewer). Thanks, Dmitrij > Hi > > I've updated fix > > The vm.simpleArch variable has been added which corresponds to > os.simpleArch of tested platform. All hotspot tests have been updated > to use vm.simpleArch instead of os.simpleArch. Once jtreg is fixed to > read 'os.arch' from tested JDK then it would be possible just revert > this fix and preserver same behavior (See CODETOOLS-7901695 > ) . > > Updated webrev: > http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/root/ > http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/hotspot/ > > Testing is still in progress. > > Leonid > > On 16.06.2016 13:55, David Holmes wrote: >> On 16/06/2016 8:47 PM, Leonid Mesnik wrote: >>> Hi >>> >>> On 09.06.2016 03:43, David Holmes wrote: >>>> Hi Leonid, >>>> >>>> Sorry for the delay. >>>> >>>> On 7/06/2016 7:34 PM, Leonid Mesnik wrote: >>>>> Hi >>>>> >>>>> Added jtreg-use at openjdk.java.net >>>>> >>>>> I think that you are right. Here is the documentation: >>>>> http://openjdk.java.net/jtreg/tag-spec.html >>>>> >>>>> >>>>> "@requires >>>>> >>>>> Express a dependence on characteristics of the system being >>>>> tested. >>>>> Some harnesses allow tests to be selected according to the >>>>> characteristics of the system being tested. The expression may be >>>>> composed of the following elements:" >>>>> >>>>> "os.arch The operating system architecture, as given by the >>>>> corresponding system property." >>>>> >>>>> So user could expect to have "os.arch" of tested VM. >>>>> >>>>> If filed jtreg issues for this: >>>>> >>>>> 1. CODETOOLS-7901695 >>>>> jtreg uses >>>>> value 'os.arch' property of JDK which executed JDK and not of >>>>> tested JDK >>>>> >>>>> >>>>> Following fix could be used as a temporary workaround while jtreg >>>>> fix is >>>>> not ready. Does it make a sense? I this case it is needed to change >>>>> linux-arm64 back to linux-aarch64 to minimize changes. >>>> >>>> I still think we have a fundamental problem concerning what os.arch >>>> means. This workaround seems to work but I find it all very confusing. >>>> We really need a vm.arch property, distinct from os.arch. >>> I see that CODETOOLS-7901695 is going to be fixed. After it is >>> implemented the 'os.arch' property will point to 'os.arch' of tested >>> JDK >>> as it described in jtreg documentation. >>> However there are 64 failures in nightly are caused by failures of >>> JVMCI >>> tests. Does it make a sense to implement this fix as a workaround to >>> remove noise until jtreg is fixed? >> >> There may be some delay between jtreg being fixed and the updated >> version being put in to use. >> >> Implementing the workaround seems reasonable. >> >> Thanks, >> David >> >>> Leonid >>>> >>>> David >>>> ----- >>>> >>>> >>>> >>>>> Leonid >>>>> >>>>> On 31.05.2016 04:26, David Holmes wrote: >>>>>> Hi Leonid, >>>>>> >>>>>> This really strikes me as as a jtreg problem that should be fixed in >>>>>> jtreg. When writing an @requires clause in a test the test writer >>>>>> should not have to be thinking "oh wait! Is this going to query >>>>>> the VM >>>>>> running jtreg or the VM running the test?". It should obviously >>>>>> be the >>>>>> VM running the test. >>>>>> >>>>>> That said we also seem to have a problem with the definition of >>>>>> os.arch: >>>>>> >>>>>> os.arch Operating system architecture >>>>>> >>>>>> if it is returning the build architecture of the VM and not the >>>>>> OS it >>>>>> is running on. That in itself argues for two distinct properties. >>>>>> >>>>>> David >>>>>> >>>>>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote: >>>>>>> Hi >>>>>>> >>>>>>> Could you please review following fix: >>>>>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/ >>>>>>> >>>>>>> hotspot >>>>>>> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/ >>>>>>> >>>>>>> for bug >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8157831 >>>>>>> >>>>>>> >>>>>>> The property "os.name" which was used to filter tests depends on >>>>>>> the >>>>>>> arch of jdk which is used to run jtreg. It might differ from >>>>>>> arch of >>>>>>> tested jdk. >>>>>>> This fix introduce new property "vm.arch" which depends on the >>>>>>> arch of >>>>>>> tested jdk and could be used to filter tests with @requires. >>>>>>> >>>>>>> I verified that tests are filtered where it is expected. >>>>>>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot >>>>>>> testing. >>>>>>> >>>>>>> Leonid >>>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonid.mesnik at oracle.com Thu Jun 16 15:09:36 2016 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 16 Jun 2016 18:09:36 +0300 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 In-Reply-To: <5762AD73.9030506@oracle.com> References: <5746FDF3.3030102@oracle.com> <57569540.9010106@oracle.com> <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com> <576283C4.4050008@oracle.com> <57629CD9.40609@oracle.com> <5762AD73.9030506@oracle.com> Message-ID: <5762C130.5030607@oracle.com> Thanks for reviewing. The testing finished successfully. Still waiting for more reviews. Leonid On 16.06.2016 16:45, Dmitrij Pochepko wrote: > Leonid, > > thank you for taking care of this issue. > Looks good to me(not a reviewer). > > Thanks, > Dmitrij >> Hi >> >> I've updated fix >> >> The vm.simpleArch variable has been added which corresponds to >> os.simpleArch of tested platform. All hotspot tests have been updated >> to use vm.simpleArch instead of os.simpleArch. Once jtreg is fixed >> to read 'os.arch' from tested JDK then it would be possible just >> revert this fix and preserver same behavior (See CODETOOLS-7901695 >> ) . >> >> Updated webrev: >> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/root/ >> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/hotspot/ >> >> Testing is still in progress. >> >> Leonid >> >> On 16.06.2016 13:55, David Holmes wrote: >>> On 16/06/2016 8:47 PM, Leonid Mesnik wrote: >>>> Hi >>>> >>>> On 09.06.2016 03:43, David Holmes wrote: >>>>> Hi Leonid, >>>>> >>>>> Sorry for the delay. >>>>> >>>>> On 7/06/2016 7:34 PM, Leonid Mesnik wrote: >>>>>> Hi >>>>>> >>>>>> Added jtreg-use at openjdk.java.net >>>>>> >>>>>> I think that you are right. Here is the documentation: >>>>>> http://openjdk.java.net/jtreg/tag-spec.html >>>>>> >>>>>> >>>>>> "@requires >>>>>> >>>>>> Express a dependence on characteristics of the system being >>>>>> tested. >>>>>> Some harnesses allow tests to be selected according to the >>>>>> characteristics of the system being tested. The expression >>>>>> may be >>>>>> composed of the following elements:" >>>>>> >>>>>> "os.arch The operating system architecture, as given by the >>>>>> corresponding system property." >>>>>> >>>>>> So user could expect to have "os.arch" of tested VM. >>>>>> >>>>>> If filed jtreg issues for this: >>>>>> >>>>>> 1. CODETOOLS-7901695 >>>>>> jtreg uses >>>>>> value 'os.arch' property of JDK which executed JDK and not of >>>>>> tested JDK >>>>>> >>>>>> >>>>>> Following fix could be used as a temporary workaround while jtreg >>>>>> fix is >>>>>> not ready. Does it make a sense? I this case it is needed to change >>>>>> linux-arm64 back to linux-aarch64 to minimize changes. >>>>> >>>>> I still think we have a fundamental problem concerning what os.arch >>>>> means. This workaround seems to work but I find it all very >>>>> confusing. >>>>> We really need a vm.arch property, distinct from os.arch. >>>> I see that CODETOOLS-7901695 is going to be fixed. After it is >>>> implemented the 'os.arch' property will point to 'os.arch' of >>>> tested JDK >>>> as it described in jtreg documentation. >>>> However there are 64 failures in nightly are caused by failures of >>>> JVMCI >>>> tests. Does it make a sense to implement this fix as a workaround to >>>> remove noise until jtreg is fixed? >>> >>> There may be some delay between jtreg being fixed and the updated >>> version being put in to use. >>> >>> Implementing the workaround seems reasonable. >>> >>> Thanks, >>> David >>> >>>> Leonid >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>> >>>>>> Leonid >>>>>> >>>>>> On 31.05.2016 04:26, David Holmes wrote: >>>>>>> Hi Leonid, >>>>>>> >>>>>>> This really strikes me as as a jtreg problem that should be >>>>>>> fixed in >>>>>>> jtreg. When writing an @requires clause in a test the test writer >>>>>>> should not have to be thinking "oh wait! Is this going to query >>>>>>> the VM >>>>>>> running jtreg or the VM running the test?". It should obviously >>>>>>> be the >>>>>>> VM running the test. >>>>>>> >>>>>>> That said we also seem to have a problem with the definition of >>>>>>> os.arch: >>>>>>> >>>>>>> os.arch Operating system architecture >>>>>>> >>>>>>> if it is returning the build architecture of the VM and not the >>>>>>> OS it >>>>>>> is running on. That in itself argues for two distinct properties. >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> Could you please review following fix: >>>>>>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/ >>>>>>>> >>>>>>>> hotspot >>>>>>>> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/ >>>>>>>> >>>>>>>> for bug >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8157831 >>>>>>>> >>>>>>>> >>>>>>>> The property "os.name" which was used to filter tests depends >>>>>>>> on the >>>>>>>> arch of jdk which is used to run jtreg. It might differ from >>>>>>>> arch of >>>>>>>> tested jdk. >>>>>>>> This fix introduce new property "vm.arch" which depends on the >>>>>>>> arch of >>>>>>>> tested jdk and could be used to filter tests with @requires. >>>>>>>> >>>>>>>> I verified that tests are filtered where it is expected. >>>>>>>> Note: I am going to push this fix in jdk9/hs to fix regular >>>>>>>> hotspot >>>>>>>> testing. >>>>>>>> >>>>>>>> Leonid >>>>>>>> >>>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwha at google.com Thu Jun 16 20:33:47 2016 From: jwha at google.com (Jungwoo Ha) Date: Thu, 16 Jun 2016 13:33:47 -0700 Subject: Future of CMS In-Reply-To: <5761C1D2.2070704@oracle.com> References: <51c70a72-6e43-491d-6de8-f3cb38837ef2@oracle.com> <5761C1D2.2070704@oracle.com> Message-ID: I open to any different ways that is reasonable. What do you have in mind? On Wed, Jun 15, 2016 at 2:00 PM, Jon Masamitsu wrote: > Jungwoo, > > Could you send an example of something that would > go under INCLUDE_CMS_GC? We might suggest an > alternative. Having macros in the sources sometimes > make it harder to read. > > Thanks. > > Jon > > > On 06/15/2016 11:29 AM, Jungwoo Ha wrote: > > Sounds reasonable to me. > CMS uses quite a bit of common code (ParNew, DefNew, CardTable..., JIT for > wb) > If we have the build flag, that means we have a macro (e.g. > INCLUDE_CMS_GC). > It would be great if the common part code is wrapped with the macro, > external contributor can submit without the pre-integration test. > > > On Wed, Jun 15, 2016 at 1:43 AM, Volker Simonis > wrote: > >> On Tue, Jun 14, 2016 at 11:50 PM, Jungwoo Ha wrote: >> >> >> >> But seriously: SAP is supporting CMS and will probably do so for quite >> a >> >> long time (simply because we do support old Java releases for a very >> long >> >> time). >> >> >> >> >> >> Completely removing CMS from the HotSpot code base may increase these >> >> support costs considerably for us. >> >> >> >> Do you plan to really delete the sources from the repos or do you only >> >> plan to disable it at build time? >> >> >> >> >> >> I just don't know how this is going to play out. I expect that the >> >> OpenJDK community >> >> will want the sources to stay. In such a case Oracle would want them >> >> segregated sufficiently >> >> that we don't build the the sources. >> >> >> >> I think only disable it at build time would make it easier for us and >> >> others to still support it in the future. But in that case we really >> have to >> >> come up with a better development model which would allow external >> >> developers to directly push CMS changes (much like ppc64 or aarch64 >> >> changes). Everything else would be a real PITA. >> >> >> >> >> >> I think some model like ppc64/aarch64 would be a good way to go. That >> >> would be a >> >> nice side effect of this change. You know better than I on how to get >> >> there. >> > >> > >> > We also need to support CMS perhaps for a long time. I like the idea of >> > segregating it, and have more external developers contribute to it. >> > Is there any document or can anyone explain to me how ppc64/arch64 >> works? >> > In such case, who is responsible for code review, building, testing, >> release >> > and so on? >> >> There's nothing special in the way the ppc64/arch64 projects/ports >> work. They are integral part of hotspot/openjdk and contributing to >> them is regulated by the very same rules. >> >> The only thing that we've manged to somehow mitigate for ppc64/arch64 >> is the pain that external (i.e. non-Oracle) committers are still not >> able to directly push to the hotspot repositories because of Oracles >> inability/unwillingness to open up their infamous JPRT pre-integration >> test system. So as an exception to this restriction, we are now >> allowed to push changes directly, if they only touch files in >> hotspot/src/cpu/{ppc,aarch64}. This helps a little bit but still not >> always, because many changes still touch shared code (e.g. if they >> come with a regression test which is in hotspot/test we already need >> an Oracle sponsor even if we're committers and the change is fully >> reviewed). >> >> Building and testing the ports is the exclusive duty of the >> corresponding projects. So for example we at SAP have nightly builds >> of all relevant OpenJDK repositories on our porting platforms and I'm >> pretty sure Red Hat has the same for aarch64. >> >> Regarding CMS, I think the idea is that the CMS sources should be >> separated into their own directory with the same relaxed checkin rules >> like the ones for ppc64/arch64. But again this would only help a >> little bit, because there will still remain quite some supporting CMS >> code in shared places (e.g. runtime, compilers, etc..). >> >> Also, building CMS will probably be controlled by a >> build-time/configure option (i.e. --use-cms) which will be switched >> off by default. So it would be our duty to build with these option >> turned on and test the resulting builds. >> >> Regards, >> Volker >> >> >> > >> > > > > -- > Jungwoo Ha | Java Platform Team | jwha at google.com > > > -- Jungwoo Ha | Java Platform Team | jwha at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Jun 16 21:07:41 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Jun 2016 07:07:41 +1000 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 In-Reply-To: <57629CD9.40609@oracle.com> References: <5746FDF3.3030102@oracle.com> <57569540.9010106@oracle.com> <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com> <576283C4.4050008@oracle.com> <57629CD9.40609@oracle.com> Message-ID: <58938c44-3915-9288-d329-481da167b0da@oracle.com> Looks good! Thanks, David On 16/06/2016 10:34 PM, Leonid Mesnik wrote: > Hi > > I've updated fix > > The vm.simpleArch variable has been added which corresponds to > os.simpleArch of tested platform. All hotspot tests have been updated to > use vm.simpleArch instead of os.simpleArch. Once jtreg is fixed to read > 'os.arch' from tested JDK then it would be possible just revert this fix > and preserver same behavior (See CODETOOLS-7901695 > ) . > > Updated webrev: > http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/root/ > http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/hotspot/ > > Testing is still in progress. > > Leonid > > On 16.06.2016 13:55, David Holmes wrote: >> On 16/06/2016 8:47 PM, Leonid Mesnik wrote: >>> Hi >>> >>> On 09.06.2016 03:43, David Holmes wrote: >>>> Hi Leonid, >>>> >>>> Sorry for the delay. >>>> >>>> On 7/06/2016 7:34 PM, Leonid Mesnik wrote: >>>>> Hi >>>>> >>>>> Added jtreg-use at openjdk.java.net >>>>> >>>>> I think that you are right. Here is the documentation: >>>>> http://openjdk.java.net/jtreg/tag-spec.html >>>>> >>>>> >>>>> "@requires >>>>> >>>>> Express a dependence on characteristics of the system being >>>>> tested. >>>>> Some harnesses allow tests to be selected according to the >>>>> characteristics of the system being tested. The expression may be >>>>> composed of the following elements:" >>>>> >>>>> "os.arch The operating system architecture, as given by the >>>>> corresponding system property." >>>>> >>>>> So user could expect to have "os.arch" of tested VM. >>>>> >>>>> If filed jtreg issues for this: >>>>> >>>>> 1. CODETOOLS-7901695 >>>>> jtreg uses >>>>> value 'os.arch' property of JDK which executed JDK and not of >>>>> tested JDK >>>>> >>>>> >>>>> Following fix could be used as a temporary workaround while jtreg >>>>> fix is >>>>> not ready. Does it make a sense? I this case it is needed to change >>>>> linux-arm64 back to linux-aarch64 to minimize changes. >>>> >>>> I still think we have a fundamental problem concerning what os.arch >>>> means. This workaround seems to work but I find it all very confusing. >>>> We really need a vm.arch property, distinct from os.arch. >>> I see that CODETOOLS-7901695 is going to be fixed. After it is >>> implemented the 'os.arch' property will point to 'os.arch' of tested JDK >>> as it described in jtreg documentation. >>> However there are 64 failures in nightly are caused by failures of JVMCI >>> tests. Does it make a sense to implement this fix as a workaround to >>> remove noise until jtreg is fixed? >> >> There may be some delay between jtreg being fixed and the updated >> version being put in to use. >> >> Implementing the workaround seems reasonable. >> >> Thanks, >> David >> >>> Leonid >>>> >>>> David >>>> ----- >>>> >>>> >>>> >>>>> Leonid >>>>> >>>>> On 31.05.2016 04:26, David Holmes wrote: >>>>>> Hi Leonid, >>>>>> >>>>>> This really strikes me as as a jtreg problem that should be fixed in >>>>>> jtreg. When writing an @requires clause in a test the test writer >>>>>> should not have to be thinking "oh wait! Is this going to query >>>>>> the VM >>>>>> running jtreg or the VM running the test?". It should obviously be >>>>>> the >>>>>> VM running the test. >>>>>> >>>>>> That said we also seem to have a problem with the definition of >>>>>> os.arch: >>>>>> >>>>>> os.arch Operating system architecture >>>>>> >>>>>> if it is returning the build architecture of the VM and not the OS it >>>>>> is running on. That in itself argues for two distinct properties. >>>>>> >>>>>> David >>>>>> >>>>>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote: >>>>>>> Hi >>>>>>> >>>>>>> Could you please review following fix: >>>>>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/ >>>>>>> >>>>>>> hotspot >>>>>>> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/ >>>>>>> >>>>>>> for bug >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8157831 >>>>>>> >>>>>>> >>>>>>> The property "os.name" which was used to filter tests depends on the >>>>>>> arch of jdk which is used to run jtreg. It might differ from arch of >>>>>>> tested jdk. >>>>>>> This fix introduce new property "vm.arch" which depends on the >>>>>>> arch of >>>>>>> tested jdk and could be used to filter tests with @requires. >>>>>>> >>>>>>> I verified that tests are filtered where it is expected. >>>>>>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot >>>>>>> testing. >>>>>>> >>>>>>> Leonid >>>>>>> >>>>> >>> > From erik.helin at oracle.com Fri Jun 17 10:15:25 2016 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 17 Jun 2016 12:15:25 +0200 Subject: RFR: 8149128: Add tests for G1MMUTracker In-Reply-To: References: <20160524150958.GA23701@ehelin.jrpg.bea.com> Message-ID: <20160617101525.GA22330@ehelin.jrpg.bea.com> On 2016-06-01, Kim Barrett wrote: > > On May 24, 2016, at 11:09 AM, Erik Helin wrote: > > > > Hi all, > > > > we have a new shiny unit test framework so I figured I would take it for > > a spin. I added some new tests for G1MMUTracker, see below. If you want > > to try out the new test runner, just apply the patch, then: > > > > $ make test-hotspot-gtest > > > > Enhancement: > > https://bugs.openjdk.java.net/browse/JDK-8149128 > > > > Webrev: > > http://cr.openjdk.java.net/~ehelin/8149128/00/ > > > > Testing: > > - JPRT > > - Running locally on Linux x86-64 > > > > Thanks, > > Erik > > > > PS. I don't really how if the feature complete applies to tests? > > ------------------------------------------------------------------------------ > I find it quite confusing to have a class called ms that constructs > from a millisecond time, but implicitly converts to double seconds. Yeah, that was a bit too magical :) I changed the test to use an ordinary function: - incremental: http://cr.openjdk.java.net/~ehelin/8149128/00-01/webrev/ - full: http://cr.openjdk.java.net/~ehelin/8149128/01/webrev/ > ------------------------------------------------------------------------------ > The following (convenience) functions are untested. > when_max_gc_sec > when_max_gc_ms > when_ms I plan to remove most of these, since they are barely used. For now I would like to not test them. Thanks, Erik From jesper.wilhelmsson at oracle.com Fri Jun 17 11:37:16 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 17 Jun 2016 13:37:16 +0200 Subject: RFR: 8149128: Add tests for G1MMUTracker In-Reply-To: <20160617101525.GA22330@ehelin.jrpg.bea.com> References: <20160524150958.GA23701@ehelin.jrpg.bea.com> <20160617101525.GA22330@ehelin.jrpg.bea.com> Message-ID: <8cf3ee37-77aa-3f1e-5a83-344ccaa8214d@oracle.com> Looks good! /Jesper Den 17/6/16 kl. 12:15, skrev Erik Helin: > On 2016-06-01, Kim Barrett wrote: >>> On May 24, 2016, at 11:09 AM, Erik Helin wrote: >>> >>> Hi all, >>> >>> we have a new shiny unit test framework so I figured I would take it for >>> a spin. I added some new tests for G1MMUTracker, see below. If you want >>> to try out the new test runner, just apply the patch, then: >>> >>> $ make test-hotspot-gtest >>> >>> Enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8149128 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8149128/00/ >>> >>> Testing: >>> - JPRT >>> - Running locally on Linux x86-64 >>> >>> Thanks, >>> Erik >>> >>> PS. I don't really how if the feature complete applies to tests? >> >> ------------------------------------------------------------------------------ >> I find it quite confusing to have a class called ms that constructs >> from a millisecond time, but implicitly converts to double seconds. > > Yeah, that was a bit too magical :) I changed the test to use an > ordinary function: > > - incremental: http://cr.openjdk.java.net/~ehelin/8149128/00-01/webrev/ > - full: http://cr.openjdk.java.net/~ehelin/8149128/01/webrev/ > >> ------------------------------------------------------------------------------ >> The following (convenience) functions are untested. >> when_max_gc_sec >> when_max_gc_ms >> when_ms > > I plan to remove most of these, since they are barely used. For now I > would like to not test them. > > Thanks, > Erik > From yasuenag at gmail.com Fri Jun 17 13:08:49 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 17 Jun 2016 22:08:49 +0900 Subject: PING: RFR: JDK-8155730: HeapInfoDCmd should get Heap_lock In-Reply-To: <1466079346.2443.29.camel@oracle.com> References: <955b8a22-d35c-60dc-e202-991b5a5e432d@gmail.com> <5583e9c0-8f16-72d0-ee55-a30246ab5bc8@oracle.com> <0b5bbf95-c871-f504-d96c-a08ae5277240@gmail.com> <0fccf86b-5ba8-cb3c-f253-d56cc7d1684d@oracle.com> <90b138a9-f67e-4141-fa63-71942c30e91d@gmail.com> <73d13ea4-7d0a-8bb5-6dea-be6c22d08066@oracle.com> <7881a764-1ac2-116e-da54-e57e043a930f@gmail.com> <4ffc0582-f2c0-4724-f21e-2a6510c4da95@gmail.com> <20160613132324.GN26799@ehelin.jrpg.bea.com> <22d73f92-612f-5764-5612-7ee6514a6fbe@gmail.com> <1466079346.2443.29.camel@oracle.com> Message-ID: <09048e15-3f96-0f9f-4967-634c1033800a@gmail.com> Thanks Thomas! Can you push this change (after resolving new failure) ? I want to ask to you what should I do. Yasumasa On 2016/06/16 21:15, Thomas Schatzl wrote: > Hi Yasumasa, > > On Tue, 2016-06-14 at 00:13 +0900, Yasumasa Suenaga wrote: >> Hi Thomas, Erik, >> >> I ran webrev.02 patch, thread dump (SIGQUIT), VM.info jcmd, and >> generating hs_err log work fine >> on my Fedora23 x64 with fastdebug JDK. >> >> Please tell me what test(s) failed. >> > > (new) test failures do not necessarily mean that there is something > wrong with your patch. It only means that the system had some new > unrecognized failure modes of some tests :) > > There is some automated failure matching with existing bugs, but that > is not always correct. > > So in case of new failures we need to look through the failure logs and > try to find out which of these failures are actually new failures. > In this case, I could, with very high certainty rule out this change as > the cause for all these failures. So, the change looks good after all. > > Thanks, > Thomas > From jon.masamitsu at oracle.com Fri Jun 17 16:21:23 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 17 Jun 2016 09:21:23 -0700 Subject: Future of CMS In-Reply-To: References: <51c70a72-6e43-491d-6de8-f3cb38837ef2@oracle.com> <5761C1D2.2070704@oracle.com> Message-ID: On 6/16/2016 1:33 PM, Jungwoo Ha wrote: > I open to any different ways that is reasonable. > What do you have in mind? I wanted to look at a specific example because different solutions would apply to different situations. Generally, readability is important to us for a change like this. Just put yourself in our position. If you didn't work with CMS code, why have to look at it. Some cases, of course, will be unavoidable. Jon > > On Wed, Jun 15, 2016 at 2:00 PM, Jon Masamitsu > > wrote: > > Jungwoo, > > Could you send an example of something that would > go under INCLUDE_CMS_GC? We might suggest an > alternative. Having macros in the sources sometimes > make it harder to read. > > Thanks. > > Jon > > > On 06/15/2016 11:29 AM, Jungwoo Ha wrote: >> Sounds reasonable to me. >> CMS uses quite a bit of common code (ParNew, DefNew, >> CardTable..., JIT for wb) >> If we have the build flag, that means we have a macro (e.g. >> INCLUDE_CMS_GC). >> It would be great if the common part code is wrapped with the >> macro, external contributor can submit without the >> pre-integration test. >> >> >> On Wed, Jun 15, 2016 at 1:43 AM, Volker Simonis >> > wrote: >> >> On Tue, Jun 14, 2016 at 11:50 PM, Jungwoo Ha > > wrote: >> >> >> >> But seriously: SAP is supporting CMS and will probably do >> so for quite a >> >> long time (simply because we do support old Java releases >> for a very long >> >> time). >> >> >> >> >> >> Completely removing CMS from the HotSpot code base may >> increase these >> >> support costs considerably for us. >> >> >> >> Do you plan to really delete the sources from the repos or >> do you only >> >> plan to disable it at build time? >> >> >> >> >> >> I just don't know how this is going to play out. I expect >> that the >> >> OpenJDK community >> >> will want the sources to stay. In such a case Oracle would >> want them >> >> segregated sufficiently >> >> that we don't build the the sources. >> >> >> >> I think only disable it at build time would make it easier >> for us and >> >> others to still support it in the future. But in that case >> we really have to >> >> come up with a better development model which would allow >> external >> >> developers to directly push CMS changes (much like ppc64 >> or aarch64 >> >> changes). Everything else would be a real PITA. >> >> >> >> >> >> I think some model like ppc64/aarch64 would be a good way >> to go. That >> >> would be a >> >> nice side effect of this change. You know better than I on >> how to get >> >> there. >> > >> > >> > We also need to support CMS perhaps for a long time. I like >> the idea of >> > segregating it, and have more external developers >> contribute to it. >> > Is there any document or can anyone explain to me how >> ppc64/arch64 works? >> > In such case, who is responsible for code review, building, >> testing, release >> > and so on? >> >> There's nothing special in the way the ppc64/arch64 >> projects/ports >> work. They are integral part of hotspot/openjdk and >> contributing to >> them is regulated by the very same rules. >> >> The only thing that we've manged to somehow mitigate for >> ppc64/arch64 >> is the pain that external (i.e. non-Oracle) committers are >> still not >> able to directly push to the hotspot repositories because of >> Oracles >> inability/unwillingness to open up their infamous JPRT >> pre-integration >> test system. So as an exception to this restriction, we are now >> allowed to push changes directly, if they only touch files in >> hotspot/src/cpu/{ppc,aarch64}. This helps a little bit but >> still not >> always, because many changes still touch shared code (e.g. if >> they >> come with a regression test which is in hotspot/test we >> already need >> an Oracle sponsor even if we're committers and the change is >> fully >> reviewed). >> >> Building and testing the ports is the exclusive duty of the >> corresponding projects. So for example we at SAP have nightly >> builds >> of all relevant OpenJDK repositories on our porting platforms >> and I'm >> pretty sure Red Hat has the same for aarch64. >> >> Regarding CMS, I think the idea is that the CMS sources should be >> separated into their own directory with the same relaxed >> checkin rules >> like the ones for ppc64/arch64. But again this would only help a >> little bit, because there will still remain quite some >> supporting CMS >> code in shared places (e.g. runtime, compilers, etc..). >> >> Also, building CMS will probably be controlled by a >> build-time/configure option (i.e. --use-cms) which will be >> switched >> off by default. So it would be our duty to build with these >> option >> turned on and test the resulting builds. >> >> Regards, >> Volker >> >> >> > >> >> >> >> >> -- >> Jungwoo Ha | Java Platform Team | jwha at google.com >> >> > > > > > -- > Jungwoo Ha | Java Platform Team | jwha at google.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Fri Jun 17 19:43:21 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 17 Jun 2016 21:43:21 +0200 Subject: PING: RFR: JDK-8155730: HeapInfoDCmd should get Heap_lock In-Reply-To: <09048e15-3f96-0f9f-4967-634c1033800a@gmail.com> References: <955b8a22-d35c-60dc-e202-991b5a5e432d@gmail.com> <5583e9c0-8f16-72d0-ee55-a30246ab5bc8@oracle.com> <0b5bbf95-c871-f504-d96c-a08ae5277240@gmail.com> <0fccf86b-5ba8-cb3c-f253-d56cc7d1684d@oracle.com> <90b138a9-f67e-4141-fa63-71942c30e91d@gmail.com> <73d13ea4-7d0a-8bb5-6dea-be6c22d08066@oracle.com> <7881a764-1ac2-116e-da54-e57e043a930f@gmail.com> <4ffc0582-f2c0-4724-f21e-2a6510c4da95@gmail.com> <20160613132324.GN26799@ehelin.jrpg.bea.com> <22d73f92-612f-5764-5612-7ee6514a6fbe@gmail.com> <1466079346.2443.29.camel@oracle.com> <09048e15-3f96-0f9f-4967-634c1033800a@gmail.com> Message-ID: <1466192601.2804.2.camel@oracle.com> Hi Yasumasa, On Fri, 2016-06-17 at 22:08 +0900, Yasumasa Suenaga wrote: > Thanks Thomas! > > Can you push this change (after resolving new failure) ? > I want to ask to you what should I do. ? nothing. The change seems fine, nothing needs to be fixed in this change. In my first email I just mentioned that testing showed errors (a few), and I did not have time to look through them for false positives. The second just mentioned that everything is fine. I will push this change in the beginning of next week. Thanks, ? Thomas From kim.barrett at oracle.com Sat Jun 18 20:10:52 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 18 Jun 2016 16:10:52 -0400 Subject: RFR: 8149128: Add tests for G1MMUTracker In-Reply-To: <20160617101525.GA22330@ehelin.jrpg.bea.com> References: <20160524150958.GA23701@ehelin.jrpg.bea.com> <20160617101525.GA22330@ehelin.jrpg.bea.com> Message-ID: > On Jun 17, 2016, at 6:15 AM, Erik Helin wrote: > - incremental: http://cr.openjdk.java.net/~ehelin/8149128/00-01/webrev/ > - full: http://cr.openjdk.java.net/~ehelin/8149128/01/webrev/ Looks good. >> ----------------------------------------------------------------------------- >> The following (convenience) functions are untested. >> when_max_gc_sec >> when_max_gc_ms >> when_ms > > I plan to remove most of these, since they are barely used. For now I > would like to not test them. OK. From ahmetmircik at gmail.com Sat Jun 18 22:21:04 2016 From: ahmetmircik at gmail.com (=?UTF-8?B?YWhtZXQgbcSxcsOnxLFr?=) Date: Sun, 19 Jun 2016 01:21:04 +0300 Subject: Runtime.getRuntime().freeMemory() can report wrong values when collector is CMS? Message-ID: Hi, I am running a test which is trying to log memory info. when free-heap-percentage is under a certain threshold. But noticed that when heap is around `-XX:CMSInitiatingOccupancyFraction`, Runtime.getRuntime().freeMemory() can report wrong values when compared to memory info from GC logs. It reports as if whole heap is nearly occupied, but actually there exists lots of free-memory. Issue is observable for a short-time period. Later it starts to report expected values. (Also tried my test with G1 defaults and Runtime.getRuntime().freeMemory() reported as expected) Issue is easily visible on large heaps. Is my assumption correct? Can Runtime.getRuntime().freeMemory() report wrong free-memory info for a while? Or how can we explain this situation? Here is my test and how i run it from command line: [PROBLEMATIC RUN WITH CMS]--> java -verbose:gc -Xms60G -Xmx60G -XX:CMSInitiatingOccupancyFraction=2 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -cp target/free-memory-issue-1.0-SNAPSHOT.jar FreeMemory [OK RUN WITH G1]--> java -verbose:gc -Xms60G -Xmx60G -XX:+UseG1GC -cp target/free-memory-issue-1.0-SNAPSHOT.jar FreeMemory public class FreeMemory { static final int MB = 1024 * 1024; static final String MESSAGE = "runtime.maxMemory=%d%s, runtime.totalMemory=%d%s, runtime.freeMemory=%d%s," + " runtime.usedMemory=%d%s, runTime.availableMemory=%d%s, freeHeapPercentage=%.2f"; public static void main(String[] args) throws InterruptedException { final ConcurrentHashMap map = new ConcurrentHashMap(); Runtime runtime = Runtime.getRuntime(); int availableProcessors = runtime.availableProcessors(); int threadCount = availableProcessors * 4; ArrayList threads = new ArrayList(); for (int i = 0; i < threadCount; i++) { threads.add(new Thread(new Runnable() { @Override public void run() { Random random = new Random(); while (true) { byte[] value = new byte[1024]; random.nextBytes(value); map.put(random.nextInt(), value); if (hasReachedMinFreeHeapPercentage(12)) { break; } } } })); } for (Thread thread : threads) { thread.start(); } for (Thread thread : threads) { thread.join(); } out.print("\n\n\nEnd of run...now we expect to see actual used-memory value\n"); while (true) { printCurrentMemoryInfo(); parkNanos(SECONDS.toNanos(5)); } } static boolean hasReachedMinFreeHeapPercentage(int minFreeHeapPercentage) { Runtime runtime = Runtime.getRuntime(); long maxMemory = runtime.maxMemory(); long totalMemory = runtime.totalMemory(); long freeMemory = runtime.freeMemory(); long availableMemory = freeMemory + (maxMemory - totalMemory); double freeHeapPercentage = 100D * availableMemory / maxMemory; if (freeHeapPercentage < minFreeHeapPercentage) { String unit = "M"; out.println(format(MESSAGE, toMB(maxMemory), unit, toMB(totalMemory), unit, toMB(freeMemory), unit, toMB(totalMemory - freeMemory), unit, toMB(availableMemory), unit, freeHeapPercentage)); return true; } return false; } static void printCurrentMemoryInfo() { Runtime runtime = Runtime.getRuntime(); long maxMemory = runtime.maxMemory(); long totalMemory = runtime.totalMemory(); long freeMemory = runtime.freeMemory(); long availableMemory = freeMemory + (maxMemory - totalMemory); double freeHeapPercentage = 100D * availableMemory / maxMemory; String unit = "M"; out.println(format(MESSAGE, toMB(maxMemory), unit, toMB(totalMemory), unit, toMB(freeMemory), unit, toMB(totalMemory - freeMemory), unit, toMB(availableMemory), unit, freeHeapPercentage)); } static int toMB(long bytes) { return (int) Math.rint(bytes / MB); } } Java version: openjdk version "1.8.0_91" OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14) OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode) OS info: Linux version 3.13.0-74-generic (buildd at lcy01-07) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #118-Ubuntu SMP Thu Dec 17 22:52:10 UTC 2015 Distributor ID: Ubuntu Description: Ubuntu 14.04.3 LTS Release: 14.04 Thanks in advance, -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Sat Jun 18 22:41:53 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Sun, 19 Jun 2016 00:41:53 +0200 Subject: Runtime.getRuntime().freeMemory() can report wrong values when collector is CMS? In-Reply-To: References: Message-ID: Hello, Maybe you should show output and gclog as well. However I would argue that logging and alerting memory usage numbers is next to useless in most situations. If you want to have some usefull numbers I would restrict myself to log free memory for the various pools after related GC runs. The JMX beans have a metric for that. Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: "ahmet m?r??k" To: hotspot-gc-dev at openjdk.java.net Sent: So., 19 Juni 2016 0:31 Subject: Runtime.getRuntime().freeMemory() can report wrong values when collector is CMS? Hi, I am running a test which is trying to log memory info. when free-heap-percentage is under a certain threshold. But noticed that when heap is around `-XX:CMSInitiatingOccupancyFraction`, Runtime.getRuntime().freeMemory() can report wrong values when compared to memory info from GC logs. It reports as if whole heap is nearly occupied, but actually there exists lots of free-memory. Issue is observable for a short-time period. Later it starts to report expected values. (Also tried my test with G1 defaults and Runtime.getRuntime().freeMemory() reported as expected) Issue is easily visible on large heaps. Is my assumption correct? Can Runtime.getRuntime().freeMemory() report wrong free-memory info for a while? Or how can we explain this situation? Here is my test and how i run it from command line: [PROBLEMATIC RUN WITH CMS]--> java -verbose:gc -Xms60G -Xmx60G -XX:CMSInitiatingOccupancyFraction=2 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -cp target/free-memory-issue-1.0-SNAPSHOT.jar FreeMemory [OK RUN WITH G1]--> java -verbose:gc -Xms60G -Xmx60G -XX:+UseG1GC -cp target/free-memory-issue-1.0-SNAPSHOT.jar FreeMemory public class FreeMemory { static final int MB = 1024 * 1024; static final String MESSAGE = "runtime.maxMemory=%d%s, runtime.totalMemory=%d%s, runtime.freeMemory=%d%s," + " runtime.usedMemory=%d%s, runTime.availableMemory=%d%s, freeHeapPercentage=%.2f"; public static void main(String[] args) throws InterruptedException { final ConcurrentHashMap map = new ConcurrentHashMap(); Runtime runtime = Runtime.getRuntime(); int availableProcessors = runtime.availableProcessors(); int threadCount = availableProcessors * 4; ArrayList threads = new ArrayList(); for (int i = 0; i < threadCount; i++) { threads.add(new Thread(new Runnable() { @Override public void run() { Random random = new Random(); while (true) { byte[] value = new byte[1024]; random.nextBytes(value); map.put(random.nextInt(), value); if (hasReachedMinFreeHeapPercentage(12)) { break; } } } })); } for (Thread thread : threads) { thread.start(); } for (Thread thread : threads) { thread.join(); } out.print("\n\n\nEnd of run...now we expect to see actual used-memory value\n"); while (true) { printCurrentMemoryInfo(); parkNanos(SECONDS.toNanos(5)); } } static boolean hasReachedMinFreeHeapPercentage(int minFreeHeapPercentage) { Runtime runtime = Runtime.getRuntime(); long maxMemory = runtime.maxMemory(); long totalMemory = runtime.totalMemory(); long freeMemory = runtime.freeMemory(); long availableMemory = freeMemory + (maxMemory - totalMemory); double freeHeapPercentage = 100D * availableMemory / maxMemory; if (freeHeapPercentage < minFreeHeapPercentage) { String unit = "M"; out.println(format(MESSAGE, toMB(maxMemory), unit, toMB(totalMemory), unit, toMB(freeMemory), unit, toMB(totalMemory - freeMemory), unit, toMB(availableMemory), unit, freeHeapPercentage)); return true; } return false; } static void printCurrentMemoryInfo() { Runtime runtime = Runtime.getRuntime(); long maxMemory = runtime.maxMemory(); long totalMemory = runtime.totalMemory(); long freeMemory = runtime.freeMemory(); long availableMemory = freeMemory + (maxMemory - totalMemory); double freeHeapPercentage = 100D * availableMemory / maxMemory; String unit = "M"; out.println(format(MESSAGE, toMB(maxMemory), unit, toMB(totalMemory), unit, toMB(freeMemory), unit, toMB(totalMemory - freeMemory), unit, toMB(availableMemory), unit, freeHeapPercentage)); } static int toMB(long bytes) { return (int) Math.rint(bytes / MB); } } Java version: openjdk version "1.8.0_91" OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14) OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode) OS info: Linux version 3.13.0-74-generic (buildd at lcy01-07) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #118-Ubuntu SMP Thu Dec 17 22:52:10 UTC 2015 Distributor ID: Ubuntu Description: Ubuntu 14.04.3 LTS Release: 14.04 Thanks in advance, From ahmetmircik at gmail.com Sat Jun 18 22:56:57 2016 From: ahmetmircik at gmail.com (=?UTF-8?B?YWhtZXQgbcSxcsOnxLFr?=) Date: Sat, 18 Jun 2016 22:56:57 +0000 Subject: Runtime.getRuntime().freeMemory() can report wrong values when collector is CMS? In-Reply-To: References: Message-ID: Adding all logs from start of run: java -verbose:gc -Xms60G -Xmx60G -XX:CMSInitiatingOccupancyFraction=2 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -cp target/free-memory-issue-1.0-SNAPSHOT.jar FreeMemory [GC (Allocation Failure) 886080K->21645K(62803840K), 0.0743103 secs] [GC (Allocation Failure) 907725K->568287K(62803840K), 0.4186990 secs] [GC (Allocation Failure) 1454367K->1232520K(62803840K), 0.2885866 secs] [GC (Allocation Failure) 2118600K->1985828K(62803840K), 0.3087718 secs] [GC (CMS Initial Mark) 2042073K(62803840K), 0.0037783 secs] [GC (Allocation Failure) 2871908K->2786446K(62803840K), 0.3650447 secs] [GC (Allocation Failure) 3672526K->3670514K(62803840K), 0.3675287 secs] [GC (Allocation Failure) 4556594K->4445914K(62803840K), 0.3455842 secs] [GC (Allocation Failure) 5331994K->5302365K(62803840K), 0.3627719 secs] [GC (CMS Final Remark) 5304053K(62803840K), 0.0586894 secs] runtime.maxMemory=61331M, runtime.totalMemory=61331M, runtime.freeMemory=509M, runtime.usedMemory=60822M, runTime.availableMemory=509M, freeHeapPercentage=0.83 runtime.maxMemory=61331M, runtime.totalMemory=61331M, runtime.freeMemory=509M, runtime.usedMemory=60822M, runTime.availableMemory=509M, freeHeapPercentage=0.83 End of run and free-memory returned expected values: (55734M instead of 509M) runtime.maxMemory=61331M, runtime.totalMemory=61331M, runtime.freeMemory=55734M, runtime.usedMemory=5597M, runTime.availableMemory=55734M, freeHeapPercentage=90.87 ? 19 Haz 2016 Paz, 01:44 tarihinde ?unu yazd?: > Hello, > > Maybe you should show output and gclog as well. > > However I would argue that logging and alerting memory usage numbers is > next to useless in most situations. If you want to have some usefull > numbers I would restrict myself to log free memory for the various pools > after related GC runs. The JMX beans have a metric for that. > > Gruss > Bernd > > -- > http://bernd.eckenfels.net > > -----Original Message----- > From: "ahmet m?r??k" > To: hotspot-gc-dev at openjdk.java.net > Sent: So., 19 Juni 2016 0:31 > Subject: Runtime.getRuntime().freeMemory() can report wrong values when > collector is CMS? > > Hi, > > I am running a test which is trying to log memory info. when > free-heap-percentage is under a certain threshold. But noticed that when > heap is around `-XX:CMSInitiatingOccupancyFraction`, > Runtime.getRuntime().freeMemory() can report wrong values when compared to > memory info from GC logs. It reports as if whole heap is nearly occupied, > but actually there exists lots of free-memory. Issue is observable for a > short-time period. Later it starts to report expected values. (Also tried > my test with G1 defaults and Runtime.getRuntime().freeMemory() reported as > expected) > > Issue is easily visible on large heaps. > > Is my assumption correct? Can Runtime.getRuntime().freeMemory() report > wrong free-memory info for a while? Or how can we explain this situation? > > Here is my test and how i run it from command line: > > [PROBLEMATIC RUN WITH CMS]--> java -verbose:gc -Xms60G -Xmx60G > -XX:CMSInitiatingOccupancyFraction=2 -XX:+UseConcMarkSweepGC > -XX:+UseParNewGC -cp target/free-memory-issue-1.0-SNAPSHOT.jar > FreeMemory > > [OK RUN WITH G1]--> java -verbose:gc -Xms60G -Xmx60G -XX:+UseG1GC -cp > target/free-memory-issue-1.0-SNAPSHOT.jar FreeMemory > > public class FreeMemory { > > static final int MB = 1024 * 1024; > static final String MESSAGE = "runtime.maxMemory=%d%s, > runtime.totalMemory=%d%s, runtime.freeMemory=%d%s," + > " runtime.usedMemory=%d%s, runTime.availableMemory=%d%s, > freeHeapPercentage=%.2f"; > > public static void main(String[] args) throws InterruptedException { > final ConcurrentHashMap map = new ConcurrentHashMap(); > > Runtime runtime = Runtime.getRuntime(); > int availableProcessors = runtime.availableProcessors(); > int threadCount = availableProcessors * 4; > > ArrayList threads = new ArrayList(); > > for (int i = 0; i < threadCount; i++) { > threads.add(new Thread(new Runnable() { > > @Override > public void run() { > Random random = new Random(); > while (true) { > byte[] value = new byte[1024]; > random.nextBytes(value); > > map.put(random.nextInt(), value); > > if (hasReachedMinFreeHeapPercentage(12)) { > break; > } > } > } > })); > } > > for (Thread thread : threads) { > thread.start(); > } > > for (Thread thread : threads) { > thread.join(); > } > > out.print("\n\n\nEnd of run...now we expect to see actual > used-memory value\n"); > > while (true) { > printCurrentMemoryInfo(); > parkNanos(SECONDS.toNanos(5)); > } > } > > static boolean hasReachedMinFreeHeapPercentage(int > minFreeHeapPercentage) { > Runtime runtime = Runtime.getRuntime(); > > long maxMemory = runtime.maxMemory(); > long totalMemory = runtime.totalMemory(); > long freeMemory = runtime.freeMemory(); > long availableMemory = freeMemory + (maxMemory - totalMemory); > double freeHeapPercentage = 100D * availableMemory / maxMemory; > > if (freeHeapPercentage < minFreeHeapPercentage) { > String unit = "M"; > out.println(format(MESSAGE, toMB(maxMemory), unit, > toMB(totalMemory), unit, toMB(freeMemory), unit, > toMB(totalMemory - freeMemory), unit, > toMB(availableMemory), unit, freeHeapPercentage)); > return true; > } > > return false; > } > > static void printCurrentMemoryInfo() { > Runtime runtime = Runtime.getRuntime(); > > long maxMemory = runtime.maxMemory(); > long totalMemory = runtime.totalMemory(); > long freeMemory = runtime.freeMemory(); > long availableMemory = freeMemory + (maxMemory - totalMemory); > double freeHeapPercentage = 100D * availableMemory / maxMemory; > > String unit = "M"; > out.println(format(MESSAGE, toMB(maxMemory), unit, > toMB(totalMemory), unit, toMB(freeMemory), unit, > toMB(totalMemory - freeMemory), unit, > toMB(availableMemory), unit, freeHeapPercentage)); > } > > static int toMB(long bytes) { > return (int) Math.rint(bytes / MB); > } > } > > Java version: > > openjdk version "1.8.0_91" > > OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14) > > OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode) > > OS info: > > Linux version 3.13.0-74-generic (buildd at lcy01-07) (gcc version 4.8.2 > (Ubuntu 4.8.2-19ubuntu1) ) #118-Ubuntu SMP Thu Dec 17 22:52:10 UTC 2015 > > Distributor ID: Ubuntu > > Description: Ubuntu 14.04.3 LTS > > Release: 14.04 > > > Thanks in advance, > -- ahmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Sun Jun 19 05:21:08 2016 From: kirk.pepperdine at gmail.com (kirk.pepperdine at gmail.com) Date: Sun, 19 Jun 2016 07:21:08 +0200 Subject: Runtime.getRuntime().freeMemory() can report wrong values when collector is CMS? In-Reply-To: References: Message-ID: <4E57A223-EDC3-44A8-9DA4-E580AEE9017C@gmail.com> > > > 19 Haz 2016 Paz, 01:44 tarihinde > ?unu yazd?: > Hello, > > Maybe you should show output and gclog as well. > > However I would argue that logging and alerting memory usage numbers is next to useless in most situations. While I would agree that the value of alerting on an absolute value is questionable, one can do analysis on the numbers and that can be exceptionally useful. Unfortunately the data from the MXBeans make this type of analysis quite difficult. It is easer to take the data from the GC logs even if you have to time box it. Kind regards, Kirk Pepperdine > If you want to have some usefull numbers I would restrict myself to log free memory for the various pools after related GC runs. The JMX beans have a metric for that. > > Gruss > Bernd > > -- > http://bernd.eckenfels.net > > -----Original Message----- > From: "ahmet m?r??k" > > To: hotspot-gc-dev at openjdk.java.net > Sent: So., 19 Juni 2016 0:31 > Subject: Runtime.getRuntime().freeMemory() can report wrong values when collector is CMS? > > Hi, > > I am running a test which is trying to log memory info. when > free-heap-percentage is under a certain threshold. But noticed that when > heap is around `-XX:CMSInitiatingOccupancyFraction`, > Runtime.getRuntime().freeMemory() can report wrong values when compared to > memory info from GC logs. It reports as if whole heap is nearly occupied, > but actually there exists lots of free-memory. Issue is observable for a > short-time period. Later it starts to report expected values. (Also tried > my test with G1 defaults and Runtime.getRuntime().freeMemory() reported as > expected) > > Issue is easily visible on large heaps. > > Is my assumption correct? Can Runtime.getRuntime().freeMemory() report > wrong free-memory info for a while? Or how can we explain this situation? > > Here is my test and how i run it from command line: > > [PROBLEMATIC RUN WITH CMS]--> java -verbose:gc -Xms60G -Xmx60G > -XX:CMSInitiatingOccupancyFraction=2 -XX:+UseConcMarkSweepGC > -XX:+UseParNewGC -cp target/free-memory-issue-1.0-SNAPSHOT.jar > FreeMemory > > [OK RUN WITH G1]--> java -verbose:gc -Xms60G -Xmx60G -XX:+UseG1GC -cp > target/free-memory-issue-1.0-SNAPSHOT.jar FreeMemory > > public class FreeMemory { > > static final int MB = 1024 * 1024; > static final String MESSAGE = "runtime.maxMemory=%d%s, > runtime.totalMemory=%d%s, runtime.freeMemory=%d%s," + > " runtime.usedMemory=%d%s, runTime.availableMemory=%d%s, > freeHeapPercentage=%.2f"; > > public static void main(String[] args) throws InterruptedException { > final ConcurrentHashMap map = new ConcurrentHashMap(); > > Runtime runtime = Runtime.getRuntime(); > int availableProcessors = runtime.availableProcessors(); > int threadCount = availableProcessors * 4; > > ArrayList threads = new ArrayList(); > > for (int i = 0; i < threadCount; i++) { > threads.add(new Thread(new Runnable() { > > @Override > public void run() { > Random random = new Random(); > while (true) { > byte[] value = new byte[1024]; > random.nextBytes(value); > > map.put(random.nextInt(), value); > > if (hasReachedMinFreeHeapPercentage(12)) { > break; > } > } > } > })); > } > > for (Thread thread : threads) { > thread.start(); > } > > for (Thread thread : threads) { > thread.join(); > } > > out.print("\n\n\nEnd of run...now we expect to see actual > used-memory value\n"); > > while (true) { > printCurrentMemoryInfo(); > parkNanos(SECONDS.toNanos(5)); > } > } > > static boolean hasReachedMinFreeHeapPercentage(int minFreeHeapPercentage) { > Runtime runtime = Runtime.getRuntime(); > > long maxMemory = runtime.maxMemory(); > long totalMemory = runtime.totalMemory(); > long freeMemory = runtime.freeMemory(); > long availableMemory = freeMemory + (maxMemory - totalMemory); > double freeHeapPercentage = 100D * availableMemory / maxMemory; > > if (freeHeapPercentage < minFreeHeapPercentage) { > String unit = "M"; > out.println(format(MESSAGE, toMB(maxMemory), unit, > toMB(totalMemory), unit, toMB(freeMemory), unit, > toMB(totalMemory - freeMemory), unit, > toMB(availableMemory), unit, freeHeapPercentage)); > return true; > } > > return false; > } > > static void printCurrentMemoryInfo() { > Runtime runtime = Runtime.getRuntime(); > > long maxMemory = runtime.maxMemory(); > long totalMemory = runtime.totalMemory(); > long freeMemory = runtime.freeMemory(); > long availableMemory = freeMemory + (maxMemory - totalMemory); > double freeHeapPercentage = 100D * availableMemory / maxMemory; > > String unit = "M"; > out.println(format(MESSAGE, toMB(maxMemory), unit, > toMB(totalMemory), unit, toMB(freeMemory), unit, > toMB(totalMemory - freeMemory), unit, > toMB(availableMemory), unit, freeHeapPercentage)); > } > > static int toMB(long bytes) { > return (int) Math.rint(bytes / MB); > } > } > > Java version: > > openjdk version "1.8.0_91" > > OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14) > > OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode) > > OS info: > > Linux version 3.13.0-74-generic (buildd at lcy01-07) (gcc version 4.8.2 > (Ubuntu 4.8.2-19ubuntu1) ) #118-Ubuntu SMP Thu Dec 17 22:52:10 UTC 2015 > > Distributor ID: Ubuntu > > Description: Ubuntu 14.04.3 LTS > > Release: 14.04 > > > Thanks in advance, > -- > ahmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Mon Jun 20 12:55:18 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 20 Jun 2016 14:55:18 +0200 Subject: RFR: 8159893: StringTable cleaning log line lacks the GC ID prefix Message-ID: <5767E7B6.8010904@oracle.com> Hi all, Please review this patch to fix the log line of the StringTable cleaning: http://cr.openjdk.java.net/~stefank/8159893/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8159893 Before the patch: [4.591s][debug][gc,phases,start ] GC(7) Parallel Unloading (4.591s) [4.596s][info ][gc,stringtable ] Cleaned string and symbol table, strings: 5899 processed, 0 removed, symbols: 34149 processed, 0 removed [4.596s][debug][gc,phases ] GC(7) Parallel Unloading (4.591s, 4.596s) 4.902ms [4.596s][info ][gc ] GC(7) Pause Remark 70M->70M(20480M) (4.578s, 4.596s) 18.161ms After the patch: [4.591s][debug][gc,phases,start ] GC(7) Parallel Unloading (4.591s) [4.596s][info ][gc,stringtable ] GC(7) Cleaned string and symbol table, strings: 5899 processed, 0 removed, symbols: 34149 processed, 0 removed [4.596s][debug][gc,phases ] GC(7) Parallel Unloading (4.591s, 4.596s) 4.902ms [4.596s][info ][gc ] GC(7) Pause Remark 70M->70M(20480M) (4.578s, 4.596s) 18.161ms The TestStringSymbolTableStats test was update to match and test the new format. Thanks, StefanK From per.liden at oracle.com Mon Jun 20 13:49:46 2016 From: per.liden at oracle.com (Per Liden) Date: Mon, 20 Jun 2016 15:49:46 +0200 Subject: RFR: 8159893: StringTable cleaning log line lacks the GC ID prefix In-Reply-To: <5767E7B6.8010904@oracle.com> References: <5767E7B6.8010904@oracle.com> Message-ID: <5767F47A.5020103@oracle.com> Looks good. /Per On 2016-06-20 14:55, Stefan Karlsson wrote: > Hi all, > > Please review this patch to fix the log line of the StringTable cleaning: > > http://cr.openjdk.java.net/~stefank/8159893/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8159893 > > Before the patch: > [4.591s][debug][gc,phases,start ] GC(7) Parallel Unloading (4.591s) > [4.596s][info ][gc,stringtable ] Cleaned string and symbol table, > strings: 5899 processed, 0 removed, symbols: 34149 processed, 0 removed > [4.596s][debug][gc,phases ] GC(7) Parallel Unloading (4.591s, > 4.596s) 4.902ms > [4.596s][info ][gc ] GC(7) Pause Remark 70M->70M(20480M) > (4.578s, 4.596s) 18.161ms > > After the patch: > [4.591s][debug][gc,phases,start ] GC(7) Parallel Unloading (4.591s) > [4.596s][info ][gc,stringtable ] GC(7) Cleaned string and symbol table, > strings: 5899 processed, 0 removed, symbols: 34149 processed, 0 removed > [4.596s][debug][gc,phases ] GC(7) Parallel Unloading (4.591s, > 4.596s) 4.902ms > [4.596s][info ][gc ] GC(7) Pause Remark 70M->70M(20480M) > (4.578s, 4.596s) 18.161ms > > The TestStringSymbolTableStats test was update to match and test the new > format. > > Thanks, > StefanK From dmitry.fazunenko at oracle.com Mon Jun 20 15:12:43 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Mon, 20 Jun 2016 18:12:43 +0300 Subject: RFR(s): 8151283: Implement setting jtreg @requires property vm.isG1Supported. In-Reply-To: References: <575E64D6.3070908@oracle.com> <0d04fb34-8103-9007-e15f-0e04521b6496@oracle.com> <5762A7A6.5050506@oracle.com> Message-ID: <1565a172-74ae-aef9-44c7-e3629cd16f58@oracle.com> Hello, During the review period of this CR a couple of changes adding new requires properties were integrated: 8157831: vm.simpleArch 8158412: vm.flightRecorder Merged variant: http://cr.openjdk.java.net/~dfazunen/8151283/webrev.02/ Thanks, Dima On 16.06.2016 16:34, Dmitry Fazunenko wrote: > Hi Michail, > > This is TEST.ROOT file, which defines itself what is the root for > libraries: > 48 # Path to libraries in the topmost test directory. This is needed so @library > 49 # does not need ../../ notation to reach them > 50 external.lib.roots = ../../ > So, for the stuff like VMProps we need to use "../.." in paths > > Thanks, > Dima > > On 16.06.2016 16:20, Michail Chernov wrote: >> Hi Dima, >> >> I have a question about paths: >> >> requires.extraPropDefns = ../../test/jtreg-ext/requires/VMProps.java >> -requires.properties=sun.arch.data.model >> +requires.extraPropDefns.bootlibs = ../../test/lib/sun >> >> Do we need to use relative paths instead of full? We use full path in >> tests: >> >> TestSmallHeap.java: * @library /testlibrary /test/lib >> /test/lib/share/classes >> >> Thanks, >> Michail >> >> On 06/14/2016 07:14 PM, Dmitry Fazunenko wrote: >>> Hi Stefan, >>> >>> The idea of 'vm.gc.X.acceptable' was an ability to introduce other >>> GC related properties like 'supported', 'default', >>> 'setByErgonomics', 'deprecated', etc. >>> But setting 'vm.gc.X' won't prevent us from adding 'vm.gc.X.Y' later >>> when needed. >>> >>> I fully agree: @requires vm.gc.G1 looks much nicer and causes less >>> questions. >>> >>> New edition: >>> http://cr.openjdk.java.net/~dfazunen/8151283/webrev.01/ >>> >>> Thanks for suggestion that, >>> Dima >>> >>> >>> On 13.06.2016 10:46, Stefan Johansson wrote: >>>> Hi Dima, >>>> >>>> I don't know the code and the way this is invoked good enough to do >>>> a proper review, but I have a style comment. Wouldn't it be nice to >>>> only call the value "vm.gc.G1", and have: >>>> @requires vm.gc.G1 >>>> >>>> I feel that "acceptable" provide very little information and what >>>> we want to @require is that the test is only run with G1 (when >>>> supported) and I think that is clear from such syntax. Comments? >>>> >>>> Thanks, >>>> Stefan >>>> >>>> On 2016-06-10 18:04, Dmitry Fazunenko wrote: >>>>> Hello, >>>>> >>>>> I'm looking for a couple of Reviewers for a simple change, which >>>>> allows to skip tests depending on non supported garbage collectors. >>>>> >>>>> http://cr.openjdk.java.net/~dfazunen/8151283/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8151283 >>>>> >>>>> The fix introduces four new requires boolean properties: >>>>> vm.gc.G1.acceptable >>>>> vm.gc.Serial.acceptable >>>>> vm.gc.Parallel.acceptable >>>>> vm.gc.ConcMarkSweep.acceptable >>>>> Which are set by the jtreg plugin prior the test execution starts. >>>>> After that fix we will be able to replace in tests: >>>>> @requires vm.gc == null | vm.gc == "G1" >>>>> with >>>>> @requires vm.gc.G1.acceptable >>>>> >>>>> 'vm.gc.G1.acceptable' will be evaluated to 'false' not only if >>>>> other GC is set externally, but also if G1 is not supported. >>>>> In other words the fix allows not to run GC specific tests in not >>>>> applicable configurations. >>>>> >>>>> Thanks, >>>>> Dima >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Mon Jun 20 16:08:11 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 20 Jun 2016 09:08:11 -0700 Subject: RFR: 8159893: StringTable cleaning log line lacks the GC ID prefix In-Reply-To: <5767E7B6.8010904@oracle.com> References: <5767E7B6.8010904@oracle.com> Message-ID: <576814EB.8060401@oracle.com> Change looks good. Jon On 06/20/2016 05:55 AM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to fix the log line of the StringTable cleaning: > > http://cr.openjdk.java.net/~stefank/8159893/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8159893 > > Before the patch: > [4.591s][debug][gc,phases,start ] GC(7) Parallel Unloading (4.591s) > [4.596s][info ][gc,stringtable ] Cleaned string and symbol table, > strings: 5899 processed, 0 removed, symbols: 34149 processed, 0 removed > [4.596s][debug][gc,phases ] GC(7) Parallel Unloading (4.591s, > 4.596s) 4.902ms > [4.596s][info ][gc ] GC(7) Pause Remark 70M->70M(20480M) > (4.578s, 4.596s) 18.161ms > > After the patch: > [4.591s][debug][gc,phases,start ] GC(7) Parallel Unloading (4.591s) > [4.596s][info ][gc,stringtable ] GC(7) Cleaned string and symbol > table, strings: 5899 processed, 0 removed, symbols: 34149 processed, 0 > removed > [4.596s][debug][gc,phases ] GC(7) Parallel Unloading (4.591s, > 4.596s) 4.902ms > [4.596s][info ][gc ] GC(7) Pause Remark 70M->70M(20480M) > (4.578s, 4.596s) 18.161ms > > The TestStringSymbolTableStats test was update to match and test the > new format. > > Thanks, > StefanK From igor.ignatyev at oracle.com Mon Jun 20 20:35:15 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 20 Jun 2016 23:35:15 +0300 Subject: RFR(s): 8151283: Implement setting jtreg @requires property vm.isG1Supported. In-Reply-To: <1565a172-74ae-aef9-44c7-e3629cd16f58@oracle.com> References: <575E64D6.3070908@oracle.com> <0d04fb34-8103-9007-e15f-0e04521b6496@oracle.com> <5762A7A6.5050506@oracle.com> <1565a172-74ae-aef9-44c7-e3629cd16f58@oracle.com> Message-ID: Dima, the fix looks good to me, thanks for implementing that. I have a question about -Xbootclasspath/a:bootClasses, is it required? I thought classes from requires.extraPropDefns.bootlibs will be added to BCP by jtreg. Thanks, ? Igor > On Jun 20, 2016, at 6:12 PM, Dmitry Fazunenko wrote: > > Hello, > > During the review period of this CR a couple of changes adding new requires properties were integrated: > 8157831: vm.simpleArch > 8158412: vm.flightRecorder > > Merged variant: > http://cr.openjdk.java.net/~dfazunen/8151283/webrev.02/ > > Thanks, > Dima > > > On 16.06.2016 16:34, Dmitry Fazunenko wrote: >> Hi Michail, >> >> This is TEST.ROOT file, which defines itself what is the root for libraries: >> 48 # Path to libraries in the topmost test directory. This is needed so @library >> 49 # does not need ../../ notation to reach them >> 50 external.lib.roots = ../../ >> >> So, for the stuff like VMProps we need to use "../.." in paths >> >> Thanks, >> Dima >> >> On 16.06.2016 16:20, Michail Chernov wrote: >>> Hi Dima, >>> >>> I have a question about paths: >>> >>> requires.extraPropDefns = ../../test/jtreg-ext/requires/VMProps.java >>> -requires.properties=sun.arch.data.model >>> +requires.extraPropDefns.bootlibs = ../../test/lib/sun >>> >>> >>> Do we need to use relative paths instead of full? We use full path in tests: >>> >>> TestSmallHeap.java: * @library /testlibrary /test/lib /test/lib/share/classes >>> >>> Thanks, >>> Michail >>> >>> On 06/14/2016 07:14 PM, Dmitry Fazunenko wrote: >>>> Hi Stefan, >>>> >>>> The idea of 'vm.gc.X.acceptable' was an ability to introduce other GC related properties like 'supported', 'default', 'setByErgonomics', 'deprecated', etc. >>>> But setting 'vm.gc.X' won't prevent us from adding 'vm.gc.X.Y' later when needed. >>>> >>>> I fully agree: @requires vm.gc.G1 looks much nicer and causes less questions. >>>> >>>> New edition: >>>> http://cr.openjdk.java.net/~dfazunen/8151283/webrev.01/ >>>> >>>> Thanks for suggestion that, >>>> Dima >>>> >>>> >>>> On 13.06.2016 10:46, Stefan Johansson wrote: >>>>> Hi Dima, >>>>> >>>>> I don't know the code and the way this is invoked good enough to do a proper review, but I have a style comment. Wouldn't it be nice to only call the value "vm.gc.G1", and have: >>>>> @requires vm.gc.G1 >>>>> >>>>> I feel that "acceptable" provide very little information and what we want to @require is that the test is only run with G1 (when supported) and I think that is clear from such syntax. Comments? >>>>> >>>>> Thanks, >>>>> Stefan >>>>> >>>>> On 2016-06-10 18:04, Dmitry Fazunenko wrote: >>>>>> Hello, >>>>>> >>>>>> I'm looking for a couple of Reviewers for a simple change, which allows to skip tests depending on non supported garbage collectors. >>>>>> >>>>>> http://cr.openjdk.java.net/~dfazunen/8151283/webrev.00/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8151283 >>>>>> >>>>>> The fix introduces four new requires boolean properties: >>>>>> vm.gc.G1.acceptable >>>>>> vm.gc.Serial.acceptable >>>>>> vm.gc.Parallel.acceptable >>>>>> vm.gc.ConcMarkSweep.acceptable >>>>>> Which are set by the jtreg plugin prior the test execution starts. >>>>>> After that fix we will be able to replace in tests: >>>>>> @requires vm.gc == null | vm.gc == "G1" >>>>>> with >>>>>> @requires vm.gc.G1.acceptable >>>>>> >>>>>> 'vm.gc.G1.acceptable' will be evaluated to 'false' not only if other GC is set externally, but also if G1 is not supported. >>>>>> In other words the fix allows not to run GC specific tests in not applicable configurations. >>>>>> >>>>>> Thanks, >>>>>> Dima >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > From dmitry.fazunenko at oracle.com Mon Jun 20 21:29:21 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Tue, 21 Jun 2016 00:29:21 +0300 Subject: RFR(s): 8151283: Implement setting jtreg @requires property vm.isG1Supported. In-Reply-To: References: <575E64D6.3070908@oracle.com> <0d04fb34-8103-9007-e15f-0e04521b6496@oracle.com> <5762A7A6.5050506@oracle.com> <1565a172-74ae-aef9-44c7-e3629cd16f58@oracle.com> Message-ID: <940244ec-30b1-1dab-05c8-2e5320d061f6@oracle.com> Igor, Thanks a lot for the review! On 20.06.2016 23:35, Igor Ignatyev wrote: > Dima, > > the fix looks good to me, thanks for implementing that. I have a question about -Xbootclasspath/a:bootClasses, is it required? I thought classes from requires.extraPropDefns.bootlibs will be added to BCP by jtreg. Yes, it's required. We might decided for example to use -Xbootclasspath/*p*: instead. bootClasses - is the name of the local folder (under scratch dir) where classes from the'requires.extraPropDefns.bootlibs' will be compiled to. And I haven't mentioned, that I introduced a field, which is currently unused: private static final WhiteBox WB = WhiteBox.getWhiteBox(); This is for the simplification of use in the future. Thanks, Dima > > Thanks, > ? Igor >> On Jun 20, 2016, at 6:12 PM, Dmitry Fazunenko wrote: >> >> Hello, >> >> During the review period of this CR a couple of changes adding new requires properties were integrated: >> 8157831: vm.simpleArch >> 8158412: vm.flightRecorder >> >> Merged variant: >> http://cr.openjdk.java.net/~dfazunen/8151283/webrev.02/ >> >> Thanks, >> Dima >> >> >> On 16.06.2016 16:34, Dmitry Fazunenko wrote: >>> Hi Michail, >>> >>> This is TEST.ROOT file, which defines itself what is the root for libraries: >>> 48 # Path to libraries in the topmost test directory. This is needed so @library >>> 49 # does not need ../../ notation to reach them >>> 50 external.lib.roots = ../../ >>> >>> So, for the stuff like VMProps we need to use "../.." in paths >>> >>> Thanks, >>> Dima >>> >>> On 16.06.2016 16:20, Michail Chernov wrote: >>>> Hi Dima, >>>> >>>> I have a question about paths: >>>> >>>> requires.extraPropDefns = ../../test/jtreg-ext/requires/VMProps.java >>>> -requires.properties=sun.arch.data.model >>>> +requires.extraPropDefns.bootlibs = ../../test/lib/sun >>>> >>>> >>>> Do we need to use relative paths instead of full? We use full path in tests: >>>> >>>> TestSmallHeap.java: * @library /testlibrary /test/lib /test/lib/share/classes >>>> >>>> Thanks, >>>> Michail >>>> >>>> On 06/14/2016 07:14 PM, Dmitry Fazunenko wrote: >>>>> Hi Stefan, >>>>> >>>>> The idea of 'vm.gc.X.acceptable' was an ability to introduce other GC related properties like 'supported', 'default', 'setByErgonomics', 'deprecated', etc. >>>>> But setting 'vm.gc.X' won't prevent us from adding 'vm.gc.X.Y' later when needed. >>>>> >>>>> I fully agree: @requires vm.gc.G1 looks much nicer and causes less questions. >>>>> >>>>> New edition: >>>>> http://cr.openjdk.java.net/~dfazunen/8151283/webrev.01/ >>>>> >>>>> Thanks for suggestion that, >>>>> Dima >>>>> >>>>> >>>>> On 13.06.2016 10:46, Stefan Johansson wrote: >>>>>> Hi Dima, >>>>>> >>>>>> I don't know the code and the way this is invoked good enough to do a proper review, but I have a style comment. Wouldn't it be nice to only call the value "vm.gc.G1", and have: >>>>>> @requires vm.gc.G1 >>>>>> >>>>>> I feel that "acceptable" provide very little information and what we want to @require is that the test is only run with G1 (when supported) and I think that is clear from such syntax. Comments? >>>>>> >>>>>> Thanks, >>>>>> Stefan >>>>>> >>>>>> On 2016-06-10 18:04, Dmitry Fazunenko wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I'm looking for a couple of Reviewers for a simple change, which allows to skip tests depending on non supported garbage collectors. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dfazunen/8151283/webrev.00/ >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151283 >>>>>>> >>>>>>> The fix introduces four new requires boolean properties: >>>>>>> vm.gc.G1.acceptable >>>>>>> vm.gc.Serial.acceptable >>>>>>> vm.gc.Parallel.acceptable >>>>>>> vm.gc.ConcMarkSweep.acceptable >>>>>>> Which are set by the jtreg plugin prior the test execution starts. >>>>>>> After that fix we will be able to replace in tests: >>>>>>> @requires vm.gc == null | vm.gc == "G1" >>>>>>> with >>>>>>> @requires vm.gc.G1.acceptable >>>>>>> >>>>>>> 'vm.gc.G1.acceptable' will be evaluated to 'false' not only if other GC is set externally, but also if G1 is not supported. >>>>>>> In other words the fix allows not to run GC specific tests in not applicable configurations. >>>>>>> >>>>>>> Thanks, >>>>>>> Dima >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Tue Jun 21 08:07:24 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 21 Jun 2016 10:07:24 +0200 Subject: RFR: 8158871: Long response times with G1 and StringDeduplication In-Reply-To: <57625264.9020805@oracle.com> References: <575E88CD.8030803@oracle.com> <575FF626.6090409@oracle.com> <1465912973.2378.70.camel@oracle.com> <576106A6.8040205@oracle.com> <57625264.9020805@oracle.com> Message-ID: <1466496444.2695.9.camel@oracle.com> On Thu, 2016-06-16 at 09:16 +0200, Per Liden wrote: > Thanks StefanK/StefanJ/Dima/Thomas for reviewing. > > Updated webrev: http://cr.openjdk.java.net/~pliden/8158871/webrev.2/ > Diff: http://cr.openjdk.java.net/~pliden/8158871/webrev.2.diff/ > > thanks, > Per > > On 2016-06-15 09:41, Per Liden wrote: > > > > Hi Thomas, > > > > On 2016-06-14 16:02, Thomas Schatzl wrote: > > > > > > Hi Per, > > > > > > ???some quick initial comments: > > > > > > On Tue, 2016-06-14 at 14:18 +0200, Per Liden wrote: > > > > > > > > Hi, > > > > > > > > Received some comments off-line and here's an updated webrev: > > > > > > > > http://cr.openjdk.java.net/~pliden/8158871/webrev.1/ > > > > > > > > Main difference is that the overflow list now lives next to the > > > > cache > > > > list, rather than inside the cache list. > > > ???- did you ever measure how long the deletion of all entries > > > could > > Yes, for many millions of entries it can take many seconds. It's > > especially bad on Solaris (where this bug was uncovered). > > > > > > > > take? It does not try to synchronize for safepoints, so > > > potentially > > > could delay safepoint for a long time. > > > (in G1StringDedupEntryCache::delete_overflowed) > > I think you might have the STS backwards. You're only blocking (or > > synchronizing with) safepoints when joined to the STS. The purpose > > of this fix is to change how deletion works so that the dedup > > thread isn't joined to the STS and hence doesn't block safepoints. Okay. > > > ???- I would kind of prefer > > > if G1StringDedupEntryCache::G1StringDedupEntryCache() would call > > > set_max_size() to set _max_list_lengths instead of duplicating > > > the code > > > in the initialization list. > > Will fix. Thanks. > > > > > > > > > > > ???- any concurrent kind of work should have log message at the > > > beginning and the end of that work, otherwise it may be hard to > > > find > > > out what the process is doing from the log (i.e. delaying the > > > safepoint) at the moment. > > I agree, strdedup should be more aligned with how logging is done > > with UL these days. I'd prefer to file a separate bug for that as > > it's kind of unrelated to this bug (this bug . > > > > (and as mentioned above, this doesn't delay safepoints). Okay. Did you already file a CR for that? Otherwise I can do that. > > > ???- I am not sure if the default value of max_cache_size are > > > good values. I mean, if you have lots of threads (we are running > > > on machines with 2k+ threads already), the cache size will be > > > zero by default. > > I'm thinking that's ok. The max cache size will be small (or zero) > > only if you have a tiny dedup table. A tiny dedup table indicates > > that you aren't doing much inserts into it (if you did it would > > automatically grow and max_cache_size would grow with it), so a > > cache will not help you much anyway in that case. > > > > It's probably also worth mentioning that the main purpose of the > > cache is to allow for the delayed/deferred freeing of entries. Not completely convinced, as this kind of assumes that freeing scales pretty linearly with the number of threads. However, due to malloc/free from experience not scaling that well to that number of threads, this would mean these large machines will take more time than comparable smaller machines during the pause for the remaining entries. Since we do log the time taken, we can at least pin down this as an issue in the future. So, okay for now. Thanks, ? Thomas From igor.ignatyev at oracle.com Tue Jun 21 09:26:38 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 21 Jun 2016 12:26:38 +0300 Subject: RFR(s): 8151283: Implement setting jtreg @requires property vm.isG1Supported. In-Reply-To: <940244ec-30b1-1dab-05c8-2e5320d061f6@oracle.com> References: <575E64D6.3070908@oracle.com> <0d04fb34-8103-9007-e15f-0e04521b6496@oracle.com> <5762A7A6.5050506@oracle.com> <1565a172-74ae-aef9-44c7-e3629cd16f58@oracle.com> <940244ec-30b1-1dab-05c8-2e5320d061f6@oracle.com> Message-ID: Dima, thank you for explanation. is ?bootClasses? documented somewhere? if no, could you please write a comment in TEST.ROOT? Thanks, ? Igor > On Jun 21, 2016, at 12:29 AM, Dmitry Fazunenko wrote: > > Igor, > > Thanks a lot for the review! > > On 20.06.2016 23:35, Igor Ignatyev wrote: >> Dima, >> >> the fix looks good to me, thanks for implementing that. I have a question about -Xbootclasspath/a:bootClasses, is it required? I thought classes from requires.extraPropDefns.bootlibs will be added to BCP by jtreg. >> > > Yes, it's required. We might decided for example to use -Xbootclasspath/p: instead. > bootClasses - is the name of the local folder (under scratch dir) where > classes from the > 'requires.extraPropDefns.bootlibs' will be compiled to. > > And I haven't mentioned, that I introduced a field, which is currently unused: > > private static final WhiteBox WB = WhiteBox.getWhiteBox(); > > This is for the simplification of use in the future. > > Thanks, > Dima > > >> >> Thanks, >> ? Igor >> >>> On Jun 20, 2016, at 6:12 PM, Dmitry Fazunenko >>> wrote: >>> >>> Hello, >>> >>> During the review period of this CR a couple of changes adding new requires properties were integrated: >>> 8157831: vm.simpleArch >>> 8158412: vm.flightRecorder >>> >>> Merged variant: >>> >>> http://cr.openjdk.java.net/~dfazunen/8151283/webrev.02/ >>> >>> >>> Thanks, >>> Dima >>> >>> >>> On 16.06.2016 16:34, Dmitry Fazunenko wrote: >>> >>>> Hi Michail, >>>> >>>> This is TEST.ROOT file, which defines itself what is the root for libraries: >>>> 48 # Path to libraries in the topmost test directory. This is needed so @library >>>> 49 # does not need ../../ notation to reach them >>>> 50 external.lib.roots = ../../ >>>> >>>> So, for the stuff like VMProps we need to use "../.." in paths >>>> >>>> Thanks, >>>> Dima >>>> >>>> On 16.06.2016 16:20, Michail Chernov wrote: >>>> >>>>> Hi Dima, >>>>> >>>>> I have a question about paths: >>>>> >>>>> requires.extraPropDefns = ../../test/jtreg-ext/requires/VMProps.java >>>>> -requires.properties=sun.arch.data.model >>>>> +requires.extraPropDefns.bootlibs = ../../test/lib/sun >>>>> >>>>> >>>>> Do we need to use relative paths instead of full? We use full path in tests: >>>>> >>>>> TestSmallHeap.java: * @library /testlibrary /test/lib /test/lib/share/classes >>>>> >>>>> Thanks, >>>>> Michail >>>>> >>>>> On 06/14/2016 07:14 PM, Dmitry Fazunenko wrote: >>>>> >>>>>> Hi Stefan, >>>>>> >>>>>> The idea of 'vm.gc.X.acceptable' was an ability to introduce other GC related properties like 'supported', 'default', 'setByErgonomics', 'deprecated', etc. >>>>>> But setting 'vm.gc.X' won't prevent us from adding 'vm.gc.X.Y' later when needed. >>>>>> >>>>>> I fully agree: @requires vm.gc.G1 looks much nicer and causes less questions. >>>>>> >>>>>> New edition: >>>>>> >>>>>> http://cr.openjdk.java.net/~dfazunen/8151283/webrev.01/ >>>>>> >>>>>> >>>>>> Thanks for suggestion that, >>>>>> Dima >>>>>> >>>>>> >>>>>> On 13.06.2016 10:46, Stefan Johansson wrote: >>>>>> >>>>>>> Hi Dima, >>>>>>> >>>>>>> I don't know the code and the way this is invoked good enough to do a proper review, but I have a style comment. Wouldn't it be nice to only call the value "vm.gc.G1", and have: >>>>>>> @requires vm.gc.G1 >>>>>>> >>>>>>> I feel that "acceptable" provide very little information and what we want to @require is that the test is only run with G1 (when supported) and I think that is clear from such syntax. Comments? >>>>>>> >>>>>>> Thanks, >>>>>>> Stefan >>>>>>> >>>>>>> On 2016-06-10 18:04, Dmitry Fazunenko wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I'm looking for a couple of Reviewers for a simple change, which allows to skip tests depending on non supported garbage collectors. >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dfazunen/8151283/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151283 >>>>>>>> >>>>>>>> >>>>>>>> The fix introduces four new requires boolean properties: >>>>>>>> vm.gc.G1.acceptable >>>>>>>> vm.gc.Serial.acceptable >>>>>>>> vm.gc.Parallel.acceptable >>>>>>>> vm.gc.ConcMarkSweep.acceptable >>>>>>>> Which are set by the jtreg plugin prior the test execution starts. >>>>>>>> After that fix we will be able to replace in tests: >>>>>>>> @requires vm.gc == null | vm.gc == "G1" >>>>>>>> with >>>>>>>> @requires vm.gc.G1.acceptable >>>>>>>> >>>>>>>> 'vm.gc.G1.acceptable' will be evaluated to 'false' not only if other GC is set externally, but also if G1 is not supported. >>>>>>>> In other words the fix allows not to run GC specific tests in not applicable configurations. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dima >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> > From thomas.schatzl at oracle.com Tue Jun 21 10:34:33 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 21 Jun 2016 12:34:33 +0200 Subject: RFR(s): 8151283: Implement setting jtreg @requires property vm.isG1Supported. In-Reply-To: <940244ec-30b1-1dab-05c8-2e5320d061f6@oracle.com> References: <575E64D6.3070908@oracle.com> <0d04fb34-8103-9007-e15f-0e04521b6496@oracle.com> <5762A7A6.5050506@oracle.com> <1565a172-74ae-aef9-44c7-e3629cd16f58@oracle.com> <940244ec-30b1-1dab-05c8-2e5320d061f6@oracle.com> Message-ID: <1466505273.2695.57.camel@oracle.com> Hi, On Tue, 2016-06-21 at 00:29 +0300, Dmitry Fazunenko wrote: > Igor, > > Thanks a lot for the review! > > On 20.06.2016 23:35, Igor Ignatyev wrote: > > Dima, > > > > the fix looks good to me, thanks for implementing that. I have a > > question about -Xbootclasspath/a:bootClasses, is it required? I > > thought classes from requires.extraPropDefns.bootlibs will be added > > to BCP by jtreg. > ? > Yes, it's required. We might decided for example to use > -Xbootclasspath/p:? instead. > bootClasses - is the name of the local folder (under scratch dir) > where ?classes from the 'requires.extraPropDefns.bootlibs' will be > compiled to. > > And I haven't mentioned, that I introduced a field, which is > currently unused: > > ??????private static final WhiteBox WB = WhiteBox.getWhiteBox(); > > This is for the simplification of use in the future. ? thanks for clarifying this - I asked myselves for the reason of that option too. I would prefer to have unused code in the change at hand unless unavoidable. Thanks, ? Thomas From dmitry.fazunenko at oracle.com Tue Jun 21 11:53:52 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Tue, 21 Jun 2016 14:53:52 +0300 Subject: RFR(s): 8151283: Implement setting jtreg @requires property vm.isG1Supported. In-Reply-To: <1466505273.2695.57.camel@oracle.com> References: <575E64D6.3070908@oracle.com> <0d04fb34-8103-9007-e15f-0e04521b6496@oracle.com> <5762A7A6.5050506@oracle.com> <1565a172-74ae-aef9-44c7-e3629cd16f58@oracle.com> <940244ec-30b1-1dab-05c8-2e5320d061f6@oracle.com> <1466505273.2695.57.camel@oracle.com> Message-ID: <9022e975-56ac-9671-628a-279dc00cf7ee@oracle.com> Igor, Thomas Thanks for the comments: http://cr.openjdk.java.net/~dfazunen/8151283/webrev.03/ Because the change is small, I do not publish the diff between version. Thanks, Dima On 21.06.2016 13:34, Thomas Schatzl wrote: > Hi, > > On Tue, 2016-06-21 at 00:29 +0300, Dmitry Fazunenko wrote: >> Igor, >> >> Thanks a lot for the review! >> >> On 20.06.2016 23:35, Igor Ignatyev wrote: >>> Dima, >>> >>> the fix looks good to me, thanks for implementing that. I have a >>> question about -Xbootclasspath/a:bootClasses, is it required? I >>> thought classes from requires.extraPropDefns.bootlibs will be added >>> to BCP by jtreg. >> >> Yes, it's required. We might decided for example to use >> -Xbootclasspath/p: instead. >> bootClasses - is the name of the local folder (under scratch dir) >> where classes from the 'requires.extraPropDefns.bootlibs' will be >> compiled to. >> >> And I haven't mentioned, that I introduced a field, which is >> currently unused: >> >> private static final WhiteBox WB = WhiteBox.getWhiteBox(); >> >> This is for the simplification of use in the future. > thanks for clarifying this - I asked myselves for the reason of that > option too. > > I would prefer to have unused code in the change at hand unless > unavoidable. > > Thanks, > Thomas > From stefan.karlsson at oracle.com Tue Jun 21 11:57:54 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 Jun 2016 13:57:54 +0200 Subject: RFR: 8159893: StringTable cleaning log line lacks the GC ID prefix In-Reply-To: <5767F47A.5020103@oracle.com> References: <5767E7B6.8010904@oracle.com> <5767F47A.5020103@oracle.com> Message-ID: <57692BC2.6040607@oracle.com> Thanks, Per. StefanK On 2016-06-20 15:49, Per Liden wrote: > Looks good. > > /Per > > On 2016-06-20 14:55, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to fix the log line of the StringTable >> cleaning: >> >> http://cr.openjdk.java.net/~stefank/8159893/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8159893 >> >> Before the patch: >> [4.591s][debug][gc,phases,start ] GC(7) Parallel Unloading (4.591s) >> [4.596s][info ][gc,stringtable ] Cleaned string and symbol table, >> strings: 5899 processed, 0 removed, symbols: 34149 processed, 0 removed >> [4.596s][debug][gc,phases ] GC(7) Parallel Unloading (4.591s, >> 4.596s) 4.902ms >> [4.596s][info ][gc ] GC(7) Pause Remark 70M->70M(20480M) >> (4.578s, 4.596s) 18.161ms >> >> After the patch: >> [4.591s][debug][gc,phases,start ] GC(7) Parallel Unloading (4.591s) >> [4.596s][info ][gc,stringtable ] GC(7) Cleaned string and symbol table, >> strings: 5899 processed, 0 removed, symbols: 34149 processed, 0 removed >> [4.596s][debug][gc,phases ] GC(7) Parallel Unloading (4.591s, >> 4.596s) 4.902ms >> [4.596s][info ][gc ] GC(7) Pause Remark 70M->70M(20480M) >> (4.578s, 4.596s) 18.161ms >> >> The TestStringSymbolTableStats test was update to match and test the new >> format. >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Tue Jun 21 11:58:06 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 Jun 2016 13:58:06 +0200 Subject: RFR: 8159893: StringTable cleaning log line lacks the GC ID prefix In-Reply-To: <576814EB.8060401@oracle.com> References: <5767E7B6.8010904@oracle.com> <576814EB.8060401@oracle.com> Message-ID: <57692BCE.70706@oracle.com> Thanks, Jon. StefanK On 2016-06-20 18:08, Jon Masamitsu wrote: > Change looks good. > > Jon > > On 06/20/2016 05:55 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to fix the log line of the StringTable >> cleaning: >> >> http://cr.openjdk.java.net/~stefank/8159893/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8159893 >> >> Before the patch: >> [4.591s][debug][gc,phases,start ] GC(7) Parallel Unloading (4.591s) >> [4.596s][info ][gc,stringtable ] Cleaned string and symbol table, >> strings: 5899 processed, 0 removed, symbols: 34149 processed, 0 removed >> [4.596s][debug][gc,phases ] GC(7) Parallel Unloading (4.591s, >> 4.596s) 4.902ms >> [4.596s][info ][gc ] GC(7) Pause Remark 70M->70M(20480M) >> (4.578s, 4.596s) 18.161ms >> >> After the patch: >> [4.591s][debug][gc,phases,start ] GC(7) Parallel Unloading (4.591s) >> [4.596s][info ][gc,stringtable ] GC(7) Cleaned string and symbol >> table, strings: 5899 processed, 0 removed, symbols: 34149 processed, >> 0 removed >> [4.596s][debug][gc,phases ] GC(7) Parallel Unloading (4.591s, >> 4.596s) 4.902ms >> [4.596s][info ][gc ] GC(7) Pause Remark 70M->70M(20480M) >> (4.578s, 4.596s) 18.161ms >> >> The TestStringSymbolTableStats test was update to match and test the >> new format. >> >> Thanks, >> StefanK > From thomas.schatzl at oracle.com Tue Jun 21 12:00:25 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 21 Jun 2016 14:00:25 +0200 Subject: RFR(s): 8151283: Implement setting jtreg @requires property vm.isG1Supported. In-Reply-To: <9022e975-56ac-9671-628a-279dc00cf7ee@oracle.com> References: <575E64D6.3070908@oracle.com> <0d04fb34-8103-9007-e15f-0e04521b6496@oracle.com> <5762A7A6.5050506@oracle.com> <1565a172-74ae-aef9-44c7-e3629cd16f58@oracle.com> <940244ec-30b1-1dab-05c8-2e5320d061f6@oracle.com> <1466505273.2695.57.camel@oracle.com> <9022e975-56ac-9671-628a-279dc00cf7ee@oracle.com> Message-ID: <1466510425.2695.59.camel@oracle.com> Hi Dmitry, On Tue, 2016-06-21 at 14:53 +0300, Dmitry Fazunenko wrote: > Igor, Thomas > > Thanks for the comments: > http://cr.openjdk.java.net/~dfazunen/8151283/webrev.03/ > > Because the change is small, I do not publish the diff between > version. > ? could you comment on what you changed? > Thanks, > Dima > > On 21.06.2016 13:34, Thomas Schatzl wrote: > > > > Hi, > > > > On Tue, 2016-06-21 at 00:29 +0300, Dmitry Fazunenko wrote: > > > > > > Igor, > > > > > > Thanks a lot for the review! > > > > > > On 20.06.2016 23:35, Igor Ignatyev wrote: > > > > > > > > Dima, > > > > > > > > the fix looks good to me, thanks for implementing that. I have > > > > a > > > > question about -Xbootclasspath/a:bootClasses, is it required? I > > > > thought classes from requires.extraPropDefns.bootlibs will be > > > > added > > > > to BCP by jtreg. > > > ?? > > > Yes, it's required. We might decided for example to use > > > -Xbootclasspath/p:??instead. > > > bootClasses - is the name of the local folder (under scratch dir) > > > where??classes from the 'requires.extraPropDefns.bootlibs' will > > > be > > > compiled to. > > > > > > And I haven't mentioned, that I introduced a field, which is > > > currently unused: > > > > > > ???????private static final WhiteBox WB = WhiteBox.getWhiteBox(); > > > > > > This is for the simplification of use in the future. > > ???thanks for clarifying this - I asked myselves for the reason of > > that > > option too. > > > > I would prefer to have unused code in the change at hand unless > > unavoidable. ... and I forgot a "not" here. I would prefer to not have completely unused code added to a change. If it is required for some further change, there should be no problem adding it there. Thanks, ? Thomas From dmitry.fazunenko at oracle.com Tue Jun 21 12:24:41 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Tue, 21 Jun 2016 15:24:41 +0300 Subject: RFR(s): 8151283: Implement setting jtreg @requires property vm.isG1Supported. In-Reply-To: <1466510425.2695.59.camel@oracle.com> References: <575E64D6.3070908@oracle.com> <0d04fb34-8103-9007-e15f-0e04521b6496@oracle.com> <5762A7A6.5050506@oracle.com> <1565a172-74ae-aef9-44c7-e3629cd16f58@oracle.com> <940244ec-30b1-1dab-05c8-2e5320d061f6@oracle.com> <1466505273.2695.57.camel@oracle.com> <9022e975-56ac-9671-628a-279dc00cf7ee@oracle.com> <1466510425.2695.59.camel@oracle.com> Message-ID: <9be2fe33-71e3-811f-1160-73a31f1c0f68@oracle.com> On 21.06.2016 15:00, Thomas Schatzl wrote: > Hi Dmitry, > > On Tue, 2016-06-21 at 14:53 +0300, Dmitry Fazunenko wrote: >> Igor, Thomas >> >> Thanks for the comments: >> http://cr.openjdk.java.net/~dfazunen/8151283/webrev.03/ >> >> Because the change is small, I do not publish the diff between >> version. >> > could you comment on what you changed? Sorry, a added a note about 36 # Note: compiled bootlibs code will be located in the folder 'bootClasses' And removed unused WB field. Thanks, Dima > >> Thanks, >> Dima >> >> On 21.06.2016 13:34, Thomas Schatzl wrote: >>> Hi, >>> >>> On Tue, 2016-06-21 at 00:29 +0300, Dmitry Fazunenko wrote: >>>> Igor, >>>> >>>> Thanks a lot for the review! >>>> >>>> On 20.06.2016 23:35, Igor Ignatyev wrote: >>>>> Dima, >>>>> >>>>> the fix looks good to me, thanks for implementing that. I have >>>>> a >>>>> question about -Xbootclasspath/a:bootClasses, is it required? I >>>>> thought classes from requires.extraPropDefns.bootlibs will be >>>>> added >>>>> to BCP by jtreg. >>>> >>>> Yes, it's required. We might decided for example to use >>>> -Xbootclasspath/p: instead. >>>> bootClasses - is the name of the local folder (under scratch dir) >>>> where classes from the 'requires.extraPropDefns.bootlibs' will >>>> be >>>> compiled to. >>>> >>>> And I haven't mentioned, that I introduced a field, which is >>>> currently unused: >>>> >>>> private static final WhiteBox WB = WhiteBox.getWhiteBox(); >>>> >>>> This is for the simplification of use in the future. >>> thanks for clarifying this - I asked myselves for the reason of >>> that >>> option too. >>> >>> I would prefer to have unused code in the change at hand unless >>> unavoidable. > ... and I forgot a "not" here. > > I would prefer to not have completely unused code added to a change. If > it is required for some further change, there should be no problem > adding it there. > > Thanks, > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Tue Jun 21 13:02:51 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 21 Jun 2016 15:02:51 +0200 Subject: RFR(s): 8151283: Implement setting jtreg @requires property vm.isG1Supported. In-Reply-To: <9be2fe33-71e3-811f-1160-73a31f1c0f68@oracle.com> References: <575E64D6.3070908@oracle.com> <0d04fb34-8103-9007-e15f-0e04521b6496@oracle.com> <5762A7A6.5050506@oracle.com> <1565a172-74ae-aef9-44c7-e3629cd16f58@oracle.com> <940244ec-30b1-1dab-05c8-2e5320d061f6@oracle.com> <1466505273.2695.57.camel@oracle.com> <9022e975-56ac-9671-628a-279dc00cf7ee@oracle.com> <1466510425.2695.59.camel@oracle.com> <9be2fe33-71e3-811f-1160-73a31f1c0f68@oracle.com> Message-ID: <1466514171.2695.60.camel@oracle.com> Hi, On Tue, 2016-06-21 at 15:24 +0300, Dmitry Fazunenko wrote: > > > On 21.06.2016 15:00, Thomas Schatzl wrote: > > Hi Dmitry, > > > > On Tue, 2016-06-21 at 14:53 +0300, Dmitry Fazunenko wrote: > > > Igor, Thomas > > > > > > Thanks for the comments: > > > http://cr.openjdk.java.net/~dfazunen/8151283/webrev.03/ > > > > > > Because the change is small, I do not publish the diff between > > > version. > > > > > ? could you comment on what you changed? > ? > Sorry,? > a added a note about? > ?36 # Note: compiled bootlibs code will be located in the folder > 'bootClasses' > And removed unused WB field. ? thanks. Looks good. Thomas From igor.ignatyev at oracle.com Tue Jun 21 13:08:59 2016 From: igor.ignatyev at oracle.com (=?utf-8?B?aWdvci5pZ25hdHlldkBvcmFjbGUuY29t?=) Date: Tue, 21 Jun 2016 16:08:59 +0300 Subject: =?utf-8?B?UmU6IFJGUihzKTogODE1MTI4MzogSW1wbGVtZW50IHNldHRpbmcganRyZWcgQHJl?= =?utf-8?B?cXVpcmVzIHByb3BlcnR5IHZtLmlzRzFTdXBwb3J0ZWQu?= Message-ID: <201606211309.u5LD96Pb029775@aserv0122.oracle.com> Dima, Looks good to me. Thanks. -- II ----- Reply message ----- From: "Thomas Schatzl" To: "Dmitry Fazunenko" , "Igor Ignatyev" Cc: Subject: RFR(s): 8151283: Implement setting jtreg @requires property vm.isG1Supported. Date: Tue, Jun 21, 2016 16:02 Hi, On Tue, 2016-06-21 at 15:24 +0300, Dmitry Fazunenko wrote: > > > On 21.06.2016 15:00, Thomas Schatzl wrote: > > Hi Dmitry, > > > > On Tue, 2016-06-21 at 14:53 +0300, Dmitry Fazunenko wrote: > > > Igor, Thomas > > > > > > Thanks for the comments: > > > http://cr.openjdk.java.net/~dfazunen/8151283/webrev.03/ > > > > > > Because the change is small, I do not publish the diff between > > > version. > > > > > could you comment on what you changed? > > Sorry, > a added a note about > 36 # Note: compiled bootlibs code will be located in the folder > 'bootClasses' > And removed unused WB field. thanks. Looks good. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.fazunenko at oracle.com Tue Jun 21 13:08:54 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Tue, 21 Jun 2016 16:08:54 +0300 Subject: RFR(s): 8151283: Implement setting jtreg @requires property vm.isG1Supported. Message-ID: <00f69728-2e01-a76e-457e-3847d4d21885@oracle.com> Igor, Thomas thanks for review! -- Dima On 21.06.2016 16:08, igor.ignatyev at oracle.com wrote: > Dima, > > Looks good to me. Thanks. > > -- II > > ----- Reply message ----- > From: "Thomas Schatzl" > To: "Dmitry Fazunenko" , "Igor Ignatyev" > > Cc: > Subject: RFR(s): 8151283: Implement setting jtreg @requires property > vm.isG1Supported. > Date: Tue, Jun 21, 2016 16:02 > > Hi, > > On Tue, 2016-06-21 at 15:24 +0300, Dmitry Fazunenko wrote: > > > > > > On 21.06.2016 15:00, Thomas Schatzl wrote: > > > Hi Dmitry, > > > > > > On Tue, 2016-06-21 at 14:53 +0300, Dmitry Fazunenko wrote: > > > > Igor, Thomas > > > > > > > > Thanks for the comments: > > > >http://cr.openjdk.java.net/~dfazunen/8151283/webrev.03/ > > > > > > > > > Because the change is small, I do not publish the diff between > > > > version. > > > > > > > could you comment on what you changed? > > > > Sorry, > > a added a note about > > 36 # Note: compiled bootlibs code will be located in the folder > > 'bootClasses' > > And removed unused WB field. > > thanks. > > Looks good. > > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From per.liden at oracle.com Tue Jun 21 13:21:13 2016 From: per.liden at oracle.com (Per Liden) Date: Tue, 21 Jun 2016 15:21:13 +0200 Subject: RFR: 8158871: Long response times with G1 and StringDeduplication In-Reply-To: <1466496444.2695.9.camel@oracle.com> References: <575E88CD.8030803@oracle.com> <575FF626.6090409@oracle.com> <1465912973.2378.70.camel@oracle.com> <576106A6.8040205@oracle.com> <57625264.9020805@oracle.com> <1466496444.2695.9.camel@oracle.com> Message-ID: <57693F49.3050102@oracle.com> Hi Thomas, On 2016-06-21 10:07, Thomas Schatzl wrote: > On Thu, 2016-06-16 at 09:16 +0200, Per Liden wrote: >> Thanks StefanK/StefanJ/Dima/Thomas for reviewing. >> >> Updated webrev: http://cr.openjdk.java.net/~pliden/8158871/webrev.2/ >> Diff: http://cr.openjdk.java.net/~pliden/8158871/webrev.2.diff/ >> >> thanks, >> Per >> >> On 2016-06-15 09:41, Per Liden wrote: >>> >>> Hi Thomas, >>> >>> On 2016-06-14 16:02, Thomas Schatzl wrote: >>>> >>>> Hi Per, >>>> >>>> some quick initial comments: >>>> >>>> On Tue, 2016-06-14 at 14:18 +0200, Per Liden wrote: >>>>> >>>>> Hi, >>>>> >>>>> Received some comments off-line and here's an updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~pliden/8158871/webrev.1/ >>>>> >>>>> Main difference is that the overflow list now lives next to the >>>>> cache >>>>> list, rather than inside the cache list. >>>> - did you ever measure how long the deletion of all entries >>>> could >>> Yes, for many millions of entries it can take many seconds. It's >>> especially bad on Solaris (where this bug was uncovered). >>> >>>> >>>> take? It does not try to synchronize for safepoints, so >>>> potentially >>>> could delay safepoint for a long time. >>>> (in G1StringDedupEntryCache::delete_overflowed) >>> I think you might have the STS backwards. You're only blocking (or >>> synchronizing with) safepoints when joined to the STS. The purpose >>> of this fix is to change how deletion works so that the dedup >>> thread isn't joined to the STS and hence doesn't block safepoints. > > Okay. > >>>> - I would kind of prefer >>>> if G1StringDedupEntryCache::G1StringDedupEntryCache() would call >>>> set_max_size() to set _max_list_lengths instead of duplicating >>>> the code >>>> in the initialization list. >>> Will fix. > > Thanks. > >>> >>>> >>>> >>>> - any concurrent kind of work should have log message at the >>>> beginning and the end of that work, otherwise it may be hard to >>>> find >>>> out what the process is doing from the log (i.e. delaying the >>>> safepoint) at the moment. >>> I agree, strdedup should be more aligned with how logging is done >>> with UL these days. I'd prefer to file a separate bug for that as >>> it's kind of unrelated to this bug (this bug . >>> >>> (and as mentioned above, this doesn't delay safepoints). > > Okay. Did you already file a CR for that? Otherwise I can do that. Just created it. https://bugs.openjdk.java.net/browse/JDK-8159974 > >>>> - I am not sure if the default value of max_cache_size are >>>> good values. I mean, if you have lots of threads (we are running >>>> on machines with 2k+ threads already), the cache size will be >>>> zero by default. >>> I'm thinking that's ok. The max cache size will be small (or zero) >>> only if you have a tiny dedup table. A tiny dedup table indicates >>> that you aren't doing much inserts into it (if you did it would >>> automatically grow and max_cache_size would grow with it), so a >>> cache will not help you much anyway in that case. >>> >>> It's probably also worth mentioning that the main purpose of the >>> cache is to allow for the delayed/deferred freeing of entries. > > Not completely convinced, as this kind of assumes that freeing scales > pretty linearly with the number of threads. > > However, due to malloc/free from experience not scaling that well to > that number of threads, this would mean these large machines will take > more time than comparable smaller machines during the pause for the > remaining entries. > > Since we do log the time taken, we can at least pin down this as an > issue in the future. So, okay for now. Sounds good, thanks. cheers, Per > > Thanks, > Thomas > From erik.helin at oracle.com Tue Jun 21 15:16:30 2016 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 21 Jun 2016 17:16:30 +0200 Subject: RFR: 8154343: Make SATB related code available to other GCs In-Reply-To: <1461612690.4482.103.camel@redhat.com> References: <1460741484.2795.95.camel@redhat.com> <1460747869.2795.97.camel@redhat.com> <57115D73.7000000@oracle.com> <1460980206.3784.2.camel@redhat.com> <57151E5B.30106@oracle.com> <1461174867.4482.38.camel@redhat.com> <1461612690.4482.103.camel@redhat.com> Message-ID: <20160621151630.GC20451@ehelin.jrpg.bea.com> On 2016-04-25, Roman Kennke wrote: > Am Mittwoch, den 20.04.2016, 19:54 +0200 schrieb Roman Kennke: > > Am Montag, den 18.04.2016, 10:50 -0700 schrieb Jon Masamitsu: > > > > > > > > > On 04/18/2016 04:50 AM, Roman Kennke wrote: > > > > > > > > > > > > Am Freitag, den 15.04.2016, 14:30 -0700 schrieb Jon Masamitsu: > > > > > > > > > > > > > > > On 4/15/2016 12:17 PM, Roman Kennke wrote: > > > > > > > > > > > > > > > > > > I just noticed that I made the patch against the jdk9 > > > > > > repository, > > > > > > instead of jdk9-dev. There was a small change to make to > > > > > > require_marking()/retain_entry(). The updated webrev is here: > > > > > > > > > > > > http://cr.openjdk.java.net/~rkennke/jdk-8154343/webrev.01/ > > > > > > > > > > > > And I also forgot to post a link to the jira entry: > > > > > > https://bugs.openjdk.java.net/browse/JDK-8154343 > > > > > > > > > > > > Please let me know what you think, and if I can commit it. > > > > > > Thanks! > > > > > Roman, > > > > > > > > > > You're aware of jprt???The tool that Oracle uses to build > > > > > hotspot > > > > > patches on all platforms, > > > > > do a minimum amount of testing, and then does the commit???For > > > > > shared > > > > > code > > > > > such as in your patch, it is always used.??Sorry if I'm stating > > > > > old > > > > > news > > > > > but I wasn't > > > > > sure what to make of your request to commit (yourself). > > > > Yes, I am aware, but wasn't sure if it's still used or if > > > > external > > > > contributors need to worry about it, because I heard conflicting > > > > stories about the possibility to commit patches ourself. > > > If a change is to platform specific code and not shared (I'm > > > thinking > > > Zero and Shark), then the pushes can done by the external > > > contributor. > > > Please don't quote that as definitive.???It was stated more > > > precisely > > > somewhere.??But your change is to share code so does not qualify. > > > > > > > > > > > > > > > > > > > So how would I go about getting a sponsor for a patch like this? > > > When it's been reviewed (for anything significant by 2 reviewers, > > > one > > > of which needs to have Reviewer status as defined by the Bylaws), > > > ask > > > for a sponsor. > > Ping! How can we make progress with this change? If there's anything I > can do to make it easier, please let me know. Hi Roman, how does moving ptrQueue.{hpp,cpp} and g1SATBMarkQueue.{hpp,cpp} makes merging easier for you guys? This code hasn't (sadly) seen much changes lately, g1SATBMarkQueue.{hpp,cpp} hasn't been changed in the past six months and there has only been three changes to ptrQueue.{hpp,cpp} during the same period. I'm a bit hesitant to move this code to gc/shared, even more when this is rather old code that is in desperate need of a rewrite. Thanks, Erik > Best regards, > Roman From rkennke at redhat.com Tue Jun 21 16:49:17 2016 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Jun 2016 18:49:17 +0200 Subject: RFR: 8154343: Make SATB related code available to other GCs In-Reply-To: <20160621151630.GC20451@ehelin.jrpg.bea.com> References: <1460741484.2795.95.camel@redhat.com> <1460747869.2795.97.camel@redhat.com> <57115D73.7000000@oracle.com> <1460980206.3784.2.camel@redhat.com> <57151E5B.30106@oracle.com> <1461174867.4482.38.camel@redhat.com> <1461612690.4482.103.camel@redhat.com> <20160621151630.GC20451@ehelin.jrpg.bea.com> Message-ID: <1466527757.3203.106.camel@redhat.com> Am Dienstag, den 21.06.2016, 17:16 +0200 schrieb Erik Helin: > On 2016-04-25, Roman Kennke wrote: > > > > Am Mittwoch, den 20.04.2016, 19:54 +0200 schrieb Roman Kennke: > > > > > > Am Montag, den 18.04.2016, 10:50 -0700 schrieb Jon Masamitsu: > > > > > > > > > > > > > > > > On 04/18/2016 04:50 AM, Roman Kennke wrote: > > > > > > > > > > > > > > > > > > > > Am Freitag, den 15.04.2016, 14:30 -0700 schrieb Jon > > > > > Masamitsu: > > > > > > > > > > > > > > > > > > > > > > > > On 4/15/2016 12:17 PM, Roman Kennke wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > I just noticed that I made the patch against the jdk9 > > > > > > > repository, > > > > > > > instead of jdk9-dev. There was a small change to make to > > > > > > > require_marking()/retain_entry(). The updated webrev is > > > > > > > here: > > > > > > > > > > > > > > http://cr.openjdk.java.net/~rkennke/jdk-8154343/webrev.01 > > > > > > > / > > > > > > > > > > > > > > And I also forgot to post a link to the jira entry: > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8154343 > > > > > > > > > > > > > > Please let me know what you think, and if I can commit > > > > > > > it. > > > > > > > Thanks! > > > > > > Roman, > > > > > > > > > > > > You're aware of jprt???The tool that Oracle uses to build > > > > > > hotspot > > > > > > patches on all platforms, > > > > > > do a minimum amount of testing, and then does the > > > > > > commit???For > > > > > > shared > > > > > > code > > > > > > such as in your patch, it is always used.??Sorry if I'm > > > > > > stating > > > > > > old > > > > > > news > > > > > > but I wasn't > > > > > > sure what to make of your request to commit (yourself). > > > > > Yes, I am aware, but wasn't sure if it's still used or if > > > > > external > > > > > contributors need to worry about it, because I heard > > > > > conflicting > > > > > stories about the possibility to commit patches ourself. > > > > If a change is to platform specific code and not shared (I'm > > > > thinking > > > > Zero and Shark), then the pushes can done by the external > > > > contributor. > > > > Please don't quote that as definitive.???It was stated more > > > > precisely > > > > somewhere.??But your change is to share code so does not > > > > qualify. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So how would I go about getting a sponsor for a patch like > > > > > this? > > > > When it's been reviewed (for anything significant by 2 > > > > reviewers, > > > > one > > > > of which needs to have Reviewer status as defined by the > > > > Bylaws), > > > > ask > > > > for a sponsor. > > Ping! How can we make progress with this change? If there's > > anything I > > can do to make it easier, please let me know. > Hi Roman, > > how does moving ptrQueue.{hpp,cpp} and g1SATBMarkQueue.{hpp,cpp} > makes > merging easier for you guys? We made some small changes for Shenandoah in those files. Now everytime I'm trying to merge a change from you guys, Mercurial flags all of it as red, and I need to go through it line by line and figure out what actually changed, and incorporate it into our changed version. I know it should be easier, I probably did something wrong, but that's how it is. > This code hasn't (sadly) seen much changes > lately, g1SATBMarkQueue.{hpp,cpp} hasn't been changed in the past six > months and there has only been three changes to ptrQueue.{hpp,cpp} > during the same period. Yup. And everytime it happens, I'm pulling my hair out ;-) The same is true (even more so) for the changes we did to pull CMBitMap stuff into gc/shared. > I'm a bit hesitant to move this code to gc/shared, even more when > this > is rather old code that is in desperate need of a rewrite. Could you outline what you have in mind for a rewrite? I'd be happy to help you out. Cheers, Roman From kirill.zhaldybin at oracle.com Tue Jun 21 17:45:09 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Tue, 21 Jun 2016 20:45:09 +0300 Subject: =?UTF-8?Q?RFR=28S=29:_8132715:_Add_tests_which_check_that_no_alloca?= =?UTF-8?Q?tions_allowed_in_any_of_humongous_regions=e2=80=8b?= Message-ID: <57697D25.6080406@oracle.com> Dear all, Could please review this test for 8132715? The test fills heap with humongous objects with a lot of wasted space, then starts to allocate non-humongous objects and checks that no allocations happened in humongous regions. There are 3 runs of the test: with filled 10%, 50% and 80% of heap. CR: https://bugs.openjdk.java.net/browse/JDK-8132715 WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev.01/ Thank you. Regards, Kirill From derek.white at oracle.com Tue Jun 21 18:03:07 2016 From: derek.white at oracle.com (Derek White) Date: Tue, 21 Jun 2016 14:03:07 -0400 Subject: RFR: JDK-8114823 - G1 doesn't honor request to disable class unloading In-Reply-To: References: <56FD2B4F.9040806@oracle.com> <105bcd03-ccb4-b89b-4237-7d1abd3f8248@oracle.com> <57277672.7030709@oracle.com> Message-ID: Hi Jesper, This looks good! - Derek On 6/2/16 9:23 AM, Jesper Wilhelmsson wrote: > Hi, > > I finally got back to looking at this. > > The last change had an issue as noted by Derek below, and by StefanK > offline, we didn't handle nmethod scanning in the same way in the > different collectors. Both approaches are most likely OK, but we > should use the same approach in all GCs. > > The way we did it in G1, to treat all nmethods as strong roots, is the > way we chose to implement right now. This is a safer/smaller step than > to perform nmethod unloading even though class unloading is disabled. > In the future we may want to perform nmethod unloading as is done in > the other approach, but this should be done in a separate change. > > A new webrev is available here: > > http://cr.openjdk.java.net/~jwilhelm/8114823/webrev.03/ > > I have run this through JPRT and GCBasher with all collectors and > ClassUnloading set to false. It seems to hold together. > > Thanks, > /Jesper > > > Den 2/5/16 kl. 17:46, skrev Derek White: >> Hi Jesper, >> >> On 5/2/16 11:22 AM, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> A new version of the patch is now available: >>> >>> http://cr.openjdk.java.net/~jwilhelm/8114823/webrev.02/ >>> >>> Based on comments from Mikael, Derek, and Stefan K I have made the >>> following >>> changes: >>> >>> * CMSClassUnloadingEnabled is removed for real and made an alias of >>> ClassUnloadingWithConcurrentMark. This removes the questionable code >>> when >>> initializing the flags. >>> >>> * A new call to unload nmethods if class unloading is disabled in >>> psMarkSweep, >>> psParallelCompact, and genMarkSweep. It turned out that in some >>> cases the call >>> to unload nmethods is needed even if we do not perform class unloading. >> My only question is why don't we need to do that for G1 also? We used >> to, but >> change at g1MarkSweep.cpp:Line 165 means we don't anymore? >> >> The rest looks good to me. >> >> - Derek >>> >>> Thanks, >>> /Jesper >>> >>> >>> Den 31/3/16 kl. 15:51, skrev Jesper Wilhelmsson: >>>> Hi, >>>> >>>> Please review this change to make the GCs disable class unloading >>>> if disabled on >>>> the command line. >>>> >>>> There are a few parts in this change: >>>> >>>> 1. The flag ClassUnloadingWithConcurrentMark was not set to false if >>>> ClassUnloading was disabled on the command line. This is now done. >>>> >>>> 2. CMS was using CMSClassUnloadingEnabled instead of the more generic >>>> ClassUnloadingWithConcurrentMark. I changed so that >>>> ClassUnloadingWithConcurrentMark is used all over and >>>> CMSClassUnloadingEnabled >>>> is only used as an alias when initializing the arguments. At some >>>> point it would >>>> be nice to deprecate CMSClassUnloadingEnabled but it is a fairly >>>> well known flag >>>> so that's not part of this change. >>>> >>>> 3. CMS, Serial, and PS did correctly disable class unloading when >>>> told so, but >>>> the outermost code witch included some logging was still enabled >>>> making class >>>> unloading output present in the log file. I changed so that this >>>> code is also >>>> disabled. >>>> >>>> 4. G1 did not disable class unloading during full GCs at all. This >>>> is now done. >>>> >>>> Testing: I used SecureDBBTest.java as suggested in the bug while >>>> fixing to >>>> verify that class unloading was happening before the fix and not >>>> after. I also >>>> ran it through JPRT. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8114823 >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8114823/webrev.00/ >>>> >>>> Thanks, >>>> /Jesper >> From kim.barrett at oracle.com Tue Jun 21 18:46:33 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 21 Jun 2016 14:46:33 -0400 Subject: RFR: 8154343: Make SATB related code available to other GCs In-Reply-To: <1466527757.3203.106.camel@redhat.com> References: <1460741484.2795.95.camel@redhat.com> <1460747869.2795.97.camel@redhat.com> <57115D73.7000000@oracle.com> <1460980206.3784.2.camel@redhat.com> <57151E5B.30106@oracle.com> <1461174867.4482.38.camel@redhat.com> <1461612690.4482.103.camel@redhat.com> <20160621151630.GC20451@ehelin.jrpg.bea.com> <1466527757.3203.106.camel@redhat.com> Message-ID: > On Jun 21, 2016, at 12:49 PM, Roman Kennke wrote: >> how does moving ptrQueue.{hpp,cpp} and g1SATBMarkQueue.{hpp,cpp} >> makes >> merging easier for you guys? > > We made some small changes for Shenandoah in those files. Now everytime > I'm trying to merge a change from you guys, Mercurial flags all of it > as red, and I need to go through it line by line and figure out what > actually changed, and incorporate it into our changed version. I know > it should be easier, I probably did something wrong, but that's how it > is. To me, this sounds like something may be messed up in your repo. Moving files around doesn't seem like something that needs to be done at this stage in the JDK 9 release cycle. Some of the other changes involve substantially more process, e.g. renaming product flags is not nearly so simple, requiring retention of the old names as deprecated synonyms. And there are other changes in there that want to think about more, and would prefer were their own change sets, to be considered separately from the file moves. To move forward right now, an FC extension is required, per the process described by Mark a couple of weeks ago. Also, since this is a hotspot change, the right forest to base against and to be pushed to is presently jdk9/hs (was jdk9/hs-rt, but that switch occurred right around the time of the initial RFR). FYI, I have a stack of half a dozen or so pending cleanups and refactorings in this area, with intent for at least a couple more. Unfortunately, they didn't finish coming together until JDK 9 FC was looming, so I'm going to have to sit on them for a while. It would be a bit of a merging mess to have those files moved out from under my mq patches, though I could cope if it were really necessary. Note that some of these attempt to reduce the entanglement between these classes (esp. PtrQueue) and other parts of G1, which may have benefits for Shenandoah too. And no, this does not constitute the rewrite Erik suggested this area needs. I've made a couple of forays in that direction, but have always been tripped up by various issues, some of which are fixed in that pending stack. I may try again once those settle. From derek.white at oracle.com Tue Jun 21 18:46:42 2016 From: derek.white at oracle.com (Derek White) Date: Tue, 21 Jun 2016 14:46:42 -0400 Subject: RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated Message-ID: https://bugs.openjdk.java.net/browse/JDK-8158946 This bug is a race between an assertion in the CMS sweeper and a Java thread loading a class. See the bug report for full description of the race. The fix is to bypass the assertion in CMS for this case, and add extra assertions to catch similar data races in the future. Webrev: http://cr.openjdk.java.net/~drwhite/8158946/webrev.01 Tests: jprt - Derek From derek.white at oracle.com Tue Jun 21 19:22:45 2016 From: derek.white at oracle.com (Derek White) Date: Tue, 21 Jun 2016 15:22:45 -0400 Subject: Request for Review (xs) - 8159073: Error handling incomplete when creating GC threads lazily In-Reply-To: <20160609083312.GI26799@ehelin.jrpg.bea.com> References: <1208fcbd-ff75-cbce-1692-225280eeab52@oracle.com> <20160609083312.GI26799@ehelin.jrpg.bea.com> Message-ID: <722fc666-6a9a-a75b-9df6-b8b7c6298728@oracle.com> On 6/9/16 4:33 AM, Erik Helin wrote: > On 2016-06-08, Jon Masamitsu wrote: >> https://bugs.openjdk.java.net/browse/JDK-8159073 >> >> The error handling in add_workers() was not treating the non-initializing >> case correctly. If in the non-initializing case, it is OK to fail the >> creation >> of additional threads but the number of created threads should not be >> incremented nor non-existent thread started. >> >> http://cr.openjdk.java.net/~jmasa/8159073/webrev.00/ > Should we add some logging in case the code fail to create a worker > thread (in the non initializing case)? > > Thanks, > Erik > >> Tested with gc_test_suite with UseDynamicGCThreads turned on. >> >> Thanks. >> >> Jon Hi Jon, Looks good, but I agree with Eric that logging would be nice. - Derek From joseph.provino at oracle.com Tue Jun 21 19:40:33 2016 From: joseph.provino at oracle.com (Joseph Provino) Date: Tue, 21 Jun 2016 15:40:33 -0400 Subject: RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: References: Message-ID: <63df5131-3974-f983-1cf4-d17e78b2b4aa@oracle.com> Looks good. joe On 6/21/2016 2:46 PM, Derek White wrote: > https://bugs.openjdk.java.net/browse/JDK-8158946 > > This bug is a race between an assertion in the CMS sweeper and a Java > thread loading a class. See the bug report for full description of the > race. > > The fix is to bypass the assertion in CMS for this case, and add extra > assertions to catch similar data races in the future. > > Webrev: http://cr.openjdk.java.net/~drwhite/8158946/webrev.01 > > Tests: jprt > > - Derek > From jesper.wilhelmsson at oracle.com Tue Jun 21 20:01:58 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 21 Jun 2016 22:01:58 +0200 Subject: RFR: 8024137 - Flags should be set using the proper macro Message-ID: <9e04cfe3-2c11-2080-9f7b-2f198a8a0d69@oracle.com> Hi, Please review this change to make the GC ergonomics use FLAG_SET_ERGO() instead of setting values directly in flags. This change builds on the fix for JDK-8048093 and assumes that we will remember that the flags was set on the command line. If you know of any other places where we assign a flag directly without using FLAG_SET_ERGO() please let me know since it would make sense to change all these places in this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8024137 Webrev: http://cr.openjdk.java.net/~jwilhelm/8024137/webrev.00/ Thanks, /Jesper From derek.white at oracle.com Tue Jun 21 20:24:31 2016 From: derek.white at oracle.com (Derek White) Date: Tue, 21 Jun 2016 16:24:31 -0400 Subject: [ON HOLD] Re: RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: References: Message-ID: <8c360c59-c4c6-715b-fb01-df04c2b45db4@oracle.com> Kim and I just sketched out a more principled solution to this problem. I'll see if it works out and get a new webrev in a bit. Thanks for pushing on this Kim, and not vomiting too much :-) - Derek On 6/21/16 2:46 PM, Derek White wrote: > https://bugs.openjdk.java.net/browse/JDK-8158946 > > This bug is a race between an assertion in the CMS sweeper and a Java > thread loading a class. See the bug report for full description of the > race. > > The fix is to bypass the assertion in CMS for this case, and add extra > assertions to catch similar data races in the future. > > Webrev: http://cr.openjdk.java.net/~drwhite/8158946/webrev.01 > > Tests: jprt > > - Derek > From jon.masamitsu at oracle.com Tue Jun 21 20:52:35 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 21 Jun 2016 13:52:35 -0700 Subject: Request for Review (xs) - 8159073: Error handling incomplete when creating GC threads lazily In-Reply-To: <722fc666-6a9a-a75b-9df6-b8b7c6298728@oracle.com> References: <1208fcbd-ff75-cbce-1692-225280eeab52@oracle.com> <20160609083312.GI26799@ehelin.jrpg.bea.com> <722fc666-6a9a-a75b-9df6-b8b7c6298728@oracle.com> Message-ID: On 6/21/2016 12:22 PM, Derek White wrote: > On 6/9/16 4:33 AM, Erik Helin wrote: >> On 2016-06-08, Jon Masamitsu wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8159073 >>> >>> The error handling in add_workers() was not treating the >>> non-initializing >>> case correctly. If in the non-initializing case, it is OK to fail the >>> creation >>> of additional threads but the number of created threads should not be >>> incremented nor non-existent thread started. >>> >>> http://cr.openjdk.java.net/~jmasa/8159073/webrev.00/ >> Should we add some logging in case the code fail to create a worker >> thread (in the non initializing case)? >> >> Thanks, >> Erik >> >>> Tested with gc_test_suite with UseDynamicGCThreads turned on. >>> >>> Thanks. >>> >>> Jon > > > Hi Jon, > > Looks good, but I agree with Eric that logging would be nice. Derek, Thanks for the review. Unfortunately there is more code than I've fixed that need to tolerate thread creation failure so I'm still working on a complete fix. Jon > > - Derek > From derek.white at oracle.com Tue Jun 21 22:14:40 2016 From: derek.white at oracle.com (Derek White) Date: Tue, 21 Jun 2016 18:14:40 -0400 Subject: =?UTF-8?Q?Re:_RFR=28S=29:_8132715:_Add_tests_which_check_that_no_al?= =?UTF-8?Q?locations_allowed_in_any_of_humongous_regions=e2=80=8b?= In-Reply-To: <57697D25.6080406@oracle.com> References: <57697D25.6080406@oracle.com> Message-ID: <2b93d8cb-70fb-94b1-58c6-18c2f52bae68@oracle.com> On 6/21/16 1:45 PM, Kirill Zhaldybin wrote: > Dear all, > > Could please review this test for 8132715? > > The test fills heap with humongous objects with a lot of wasted space, > then starts to allocate non-humongous objects and checks that no > allocations happened in humongous regions. > There are 3 runs of the test: with filled 10%, 50% and 80% of heap. > > CR: https://bugs.openjdk.java.net/browse/JDK-8132715 > WebRev: > http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev.01/ > > Thank you. > > Regards, Kirill Looks good. - Derek From derek.white at oracle.com Tue Jun 21 22:27:27 2016 From: derek.white at oracle.com (Derek White) Date: Tue, 21 Jun 2016 18:27:27 -0400 Subject: [RESUMED] Re: RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: <8c360c59-c4c6-715b-fb01-df04c2b45db4@oracle.com> References: <8c360c59-c4c6-715b-fb01-df04c2b45db4@oracle.com> Message-ID: <25b125dd-5512-9337-22b4-29b90b0547e9@oracle.com> Here's a more complete solution to the problem. As Kim mentioned, the new version sets the object size field of a java.lang.Class object before it sets the object's header, so GC can reliably get the size of any object with it's header set. This fix works by adding a CollectedHeap::class_allocate() method and associated helpers. These are implemented in CollectedHeap.inline.hpp only because they share so much structure and code with CollectedHeap::obj_allocate() that I thought it best to keep them together (even though there is no performance reason to have the new code inlined). Webrev: http://cr.openjdk.java.net/~drwhite/8158946/webrev.02 jprt in progress... - Derek On 6/21/16 4:24 PM, Derek White wrote: > Kim and I just sketched out a more principled solution to this > problem. I'll see if it works out and get a new webrev in a bit. > > Thanks for pushing on this Kim, and not vomiting too much :-) > > - Derek > > On 6/21/16 2:46 PM, Derek White wrote: >> https://bugs.openjdk.java.net/browse/JDK-8158946 >> >> This bug is a race between an assertion in the CMS sweeper and a Java >> thread loading a class. See the bug report for full description of >> the race. >> >> The fix is to bypass the assertion in CMS for this case, and add >> extra assertions to catch similar data races in the future. >> >> Webrev: http://cr.openjdk.java.net/~drwhite/8158946/webrev.01 >> >> Tests: jprt >> >> - Derek >> > From thomas.schatzl at oracle.com Tue Jun 21 22:36:30 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 22 Jun 2016 00:36:30 +0200 Subject: [RESUMED] Re: RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: <25b125dd-5512-9337-22b4-29b90b0547e9@oracle.com> References: <8c360c59-c4c6-715b-fb01-df04c2b45db4@oracle.com> <25b125dd-5512-9337-22b4-29b90b0547e9@oracle.com> Message-ID: <1466548590.2941.3.camel@oracle.com> Hi, On Tue, 2016-06-21 at 18:27 -0400, Derek White wrote: > Here's a more complete solution to the problem. > > As Kim mentioned, the new version sets the object size field of a? > java.lang.Class object before it sets the object's header, so GC can? > reliably get the size of any object with it's header set. ? just briefly looking over the code (maybe I am overlooking something obvious, I am only looking at the webrev) - wouldn't the code need some compiler and memory barriers that make sure that this required read/write orderings are observed? > This fix works by adding a CollectedHeap::class_allocate() method and > associated helpers. These are implemented in CollectedHeap.inline.hpp > only because they share so much structure and code with? > CollectedHeap::obj_allocate() that I thought it best to keep them? > together (even though there is no performance reason to have the new? > code inlined). > > Webrev: http://cr.openjdk.java.net/~drwhite/8158946/webrev.02 > jprt in progress... Thanks, ? Thomas From kim.barrett at oracle.com Wed Jun 22 02:07:19 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 21 Jun 2016 22:07:19 -0400 Subject: [RESUMED] RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: <1466548590.2941.3.camel@oracle.com> References: <8c360c59-c4c6-715b-fb01-df04c2b45db4@oracle.com> <25b125dd-5512-9337-22b4-29b90b0547e9@oracle.com> <1466548590.2941.3.camel@oracle.com> Message-ID: <62101D79-2A20-457E-A8E0-0CB678AB67D7@oracle.com> > On Jun 21, 2016, at 6:36 PM, Thomas Schatzl wrote: > > Hi, > > On Tue, 2016-06-21 at 18:27 -0400, Derek White wrote: >> Here's a more complete solution to the problem. >> >> As Kim mentioned, the new version sets the object size field of a >> java.lang.Class object before it sets the object's header, so GC can >> reliably get the size of any object with it's header set. > > just briefly looking over the code (maybe I am overlooking something > obvious, I am only looking at the webrev) - wouldn't the code need some > compiler and memory barriers that make sure that this required > read/write orderings are observed? I agree with Thomas. I think there needs to be an OrderAccess::storestore() between the setting of the size and the setting of the klass. And that makes me wonder why CollectedHeap::post_allocation_setup_array doesn't appear to have a similar store barrier. It even has the corresponding comment about how the array length must be set before setting the _klass field so the object is parsable by concurrent GC. Maybe this only causes problems when the object is allocated in the old gen (perhaps because it is large). Is there some other path for large arrays, so we don't have a barrier for every array allocation? I hope I'm missing something... >> This fix works by adding a CollectedHeap::class_allocate() method and >> associated helpers. These are implemented in CollectedHeap.inline.hpp >> only because they share so much structure and code with >> CollectedHeap::obj_allocate() that I thought it best to keep them >> together (even though there is no performance reason to have the new >> code inlined). >> >> Webrev: http://cr.openjdk.java.net/~drwhite/8158946/webrev.02 >> jprt in progress... > > > Thanks, > Thomas From david.holmes at oracle.com Wed Jun 22 03:16:29 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jun 2016 13:16:29 +1000 Subject: RFR(M): 8155949: Support relaxed semantics in cmpxchg In-Reply-To: <17598d6f-6729-65c1-0af0-60ba93b4c003@oracle.com> References: <201605101044.u4AAingb016922@d19av07.sagamino.japan.ibm.com> <8bc82016-81fd-b420-7d4e-1c31e615c218@oracle.com> <1f78facd-2872-2eda-23e2-fd5de0fd8c42@oracle.com> <201605101318.u4ADI0NW004604@d19av05.sagamino.japan.ibm.com> <7a0f80de7788484da6d93f03c3eddd19@DEWDFE13DE14.global.corp.sap> <83338d53a921449fada28b7bf31e3665@DEWDFE13DE14.global.corp.sap> <267a624c-626f-4238-0166-baa14ff4b412@oracle.com> <9cff0b75-e234-e789-910d-d86154bba834@oracle.com> <17598d6f-6729-65c1-0af0-60ba93b4c003@oracle.com> Message-ID: Finally pushed: Changeset: 1daa31adf6fc Author: mdoerr Date: 2016-06-21 19:25 -0400 URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1daa31adf6fc 8155949: Support relaxed semantics in cmpxchg Reviewed-by: dholmes, kbarrett, goetz, aph Contributed-by: horii at jp.ibm.com, martin.doerr at sap.com Thanks, David ------ On 26/05/2016 11:29 AM, David Holmes wrote: > Filed: https://bugs.openjdk.java.net/browse/JDK-8157904 > > Atomic::cmpxchg_general for jbyte is missing a fence on initial failure > > David > > On 26/05/2016 11:09 AM, David Holmes wrote: >> Hi Kim, >> >> On 26/05/2016 10:04 AM, Kim Barrett wrote: >>>> On May 24, 2016, at 5:37 AM, Doerr, Martin >>>> wrote: >>>> >>>> Hi David and Andrew, >>>> >>>> sorry for missing this one. There were too many emails. >>>> >>>> After moving the jint version as well, there was not much left of >>>> atomic.cpp. >>>> I think it doesn't make any sense to keep a couple of trivial >>>> functions in the cpp file. >>>> Therefore, I have removed atomic.cpp and moved the remaining small >>>> functions into the inline file. >>>> >>>> Webrev is here: >>>> http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.05/ >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> 100 inline jbyte Atomic::cmpxchg(jbyte exchange_value, volatile jbyte >>> *dest, jbyte comparand, cmpxchg_memory_order order) >>> >>> The addition of the order option makes it a bit more obvious that this >>> does not, and never has, executed any fences in the immediate failure >>> case, e.g. when >>> >>> 111 while (cur_as_bytes[offset] == comparand) { >>> >>> is false on the first iteration. This seems like a bug. Assuming it >>> is, I'm not sure whether this should be dealt with as part of this >>> changeset, or moved to a separate bug for this (pre-existing) issue. >>> I think only ARM targets (and zero?) are lacking specialized cmpxchg >>> on bytes and so use this version? >> >> I'll file a separate bug for that. >> >> Thanks, >> David >> ------ >> >> >>> Sorry I didn't notice this previously. >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> >>> Other than that and the already mentioned (pre-existing) Atomic::add >>> for jlong return value problem, this looks good. >>> From kirk at kodewerk.com Wed Jun 22 06:12:10 2016 From: kirk at kodewerk.com (kirk at kodewerk.com) Date: Wed, 22 Jun 2016 08:12:10 +0200 Subject: RFR: 8159893: StringTable cleaning log line lacks the GC ID prefix In-Reply-To: <57692BCE.70706@oracle.com> References: <5767E7B6.8010904@oracle.com> <576814EB.8060401@oracle.com> <57692BCE.70706@oracle.com> Message-ID: <4E3C30A5-DAAA-4AE2-BA57-3A34F06CBEE7@kodewerk.com> Hi Stefan, The GC logs carry their own timers aside from the decorations provided by the logging framework. Should this entry also uses that timer? Kind regards, Kirk Pepperdine > On Jun 21, 2016, at 1:58 PM, Stefan Karlsson wrote: > > Thanks, Jon. > > StefanK > > On 2016-06-20 18:08, Jon Masamitsu wrote: >> Change looks good. >> >> Jon >> >> On 06/20/2016 05:55 AM, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to fix the log line of the StringTable cleaning: >>> >>> http://cr.openjdk.java.net/~stefank/8159893/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8159893 >>> >>> Before the patch: >>> [4.591s][debug][gc,phases,start ] GC(7) Parallel Unloading (4.591s) >>> [4.596s][info ][gc,stringtable ] Cleaned string and symbol table, strings: 5899 processed, 0 removed, symbols: 34149 processed, 0 removed >>> [4.596s][debug][gc,phases ] GC(7) Parallel Unloading (4.591s, 4.596s) 4.902ms >>> [4.596s][info ][gc ] GC(7) Pause Remark 70M->70M(20480M) (4.578s, 4.596s) 18.161ms >>> >>> After the patch: >>> [4.591s][debug][gc,phases,start ] GC(7) Parallel Unloading (4.591s) >>> [4.596s][info ][gc,stringtable ] GC(7) Cleaned string and symbol table, strings: 5899 processed, 0 removed, symbols: 34149 processed, 0 removed >>> [4.596s][debug][gc,phases ] GC(7) Parallel Unloading (4.591s, 4.596s) 4.902ms >>> [4.596s][info ][gc ] GC(7) Pause Remark 70M->70M(20480M) (4.578s, 4.596s) 18.161ms >>> >>> The TestStringSymbolTableStats test was update to match and test the new format. >>> >>> Thanks, >>> StefanK >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From martin.doerr at sap.com Wed Jun 22 07:39:30 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 22 Jun 2016 07:39:30 +0000 Subject: RFR(M): 8155949: Support relaxed semantics in cmpxchg In-Reply-To: References: <201605101044.u4AAingb016922@d19av07.sagamino.japan.ibm.com> <8bc82016-81fd-b420-7d4e-1c31e615c218@oracle.com> <1f78facd-2872-2eda-23e2-fd5de0fd8c42@oracle.com> <201605101318.u4ADI0NW004604@d19av05.sagamino.japan.ibm.com> <7a0f80de7788484da6d93f03c3eddd19@DEWDFE13DE14.global.corp.sap> <83338d53a921449fada28b7bf31e3665@DEWDFE13DE14.global.corp.sap> <267a624c-626f-4238-0166-baa14ff4b412@oracle.com> <9cff0b75-e234-e789-910d-d86154bba834@oracle.com> <17598d6f-6729-65c1-0af0-60ba93b4c003@oracle.com> Message-ID: <24fcd4ac4d0b40f991b9fe15d88e9b5b@DEWDFE13DE14.global.corp.sap> Hi David, thank you very much for sponsoring and your support. The main bug JDK-8154736 is currently targeted to 10. I guess we will have to discuss it on the gc mailing list and request it for 9. Best regards, Martin -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Mittwoch, 22. Juni 2016 05:16 To: Kim Barrett ; Doerr, Martin Cc: Tim Ellison ; ppc-aix-port-dev at openjdk.java.net; Hiroshi H Horii ; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(M): 8155949: Support relaxed semantics in cmpxchg Finally pushed: Changeset: 1daa31adf6fc Author: mdoerr Date: 2016-06-21 19:25 -0400 URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1daa31adf6fc 8155949: Support relaxed semantics in cmpxchg Reviewed-by: dholmes, kbarrett, goetz, aph Contributed-by: horii at jp.ibm.com, martin.doerr at sap.com Thanks, David ------ On 26/05/2016 11:29 AM, David Holmes wrote: > Filed: https://bugs.openjdk.java.net/browse/JDK-8157904 > > Atomic::cmpxchg_general for jbyte is missing a fence on initial failure > > David > > On 26/05/2016 11:09 AM, David Holmes wrote: >> Hi Kim, >> >> On 26/05/2016 10:04 AM, Kim Barrett wrote: >>>> On May 24, 2016, at 5:37 AM, Doerr, Martin >>>> wrote: >>>> >>>> Hi David and Andrew, >>>> >>>> sorry for missing this one. There were too many emails. >>>> >>>> After moving the jint version as well, there was not much left of >>>> atomic.cpp. >>>> I think it doesn't make any sense to keep a couple of trivial >>>> functions in the cpp file. >>>> Therefore, I have removed atomic.cpp and moved the remaining small >>>> functions into the inline file. >>>> >>>> Webrev is here: >>>> http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.05/ >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> 100 inline jbyte Atomic::cmpxchg(jbyte exchange_value, volatile jbyte >>> *dest, jbyte comparand, cmpxchg_memory_order order) >>> >>> The addition of the order option makes it a bit more obvious that this >>> does not, and never has, executed any fences in the immediate failure >>> case, e.g. when >>> >>> 111 while (cur_as_bytes[offset] == comparand) { >>> >>> is false on the first iteration. This seems like a bug. Assuming it >>> is, I'm not sure whether this should be dealt with as part of this >>> changeset, or moved to a separate bug for this (pre-existing) issue. >>> I think only ARM targets (and zero?) are lacking specialized cmpxchg >>> on bytes and so use this version? >> >> I'll file a separate bug for that. >> >> Thanks, >> David >> ------ >> >> >>> Sorry I didn't notice this previously. >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> >>> Other than that and the already mentioned (pre-existing) Atomic::add >>> for jlong return value problem, this looks good. >>> From stefan.karlsson at oracle.com Wed Jun 22 09:28:22 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 22 Jun 2016 11:28:22 +0200 Subject: RFR: 8159893: StringTable cleaning log line lacks the GC ID prefix In-Reply-To: <4E3C30A5-DAAA-4AE2-BA57-3A34F06CBEE7@kodewerk.com> References: <5767E7B6.8010904@oracle.com> <576814EB.8060401@oracle.com> <57692BCE.70706@oracle.com> <4E3C30A5-DAAA-4AE2-BA57-3A34F06CBEE7@kodewerk.com> Message-ID: <576A5A36.40503@oracle.com> Hi Kirk, On 2016-06-22 08:12, kirk at kodewerk.com wrote: > Hi Stefan, > > The GC logs carry their own timers aside from the decorations provided by the logging framework. Should this entry also uses that timer? Unfortunately, there's no separate string table and symbol table cleaning phase. The cleaning is done in parallel with the code cache cleaning and Klass cleaning in the Parallel Unloading phase: GC(7) Parallel Unloading (4.591s, 4.596s) 4.902ms StefanK > > Kind regards, > Kirk Pepperdine > >> On Jun 21, 2016, at 1:58 PM, Stefan Karlsson wrote: >> >> Thanks, Jon. >> >> StefanK >> >> On 2016-06-20 18:08, Jon Masamitsu wrote: >>> Change looks good. >>> >>> Jon >>> >>> On 06/20/2016 05:55 AM, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Please review this patch to fix the log line of the StringTable cleaning: >>>> >>>> http://cr.openjdk.java.net/~stefank/8159893/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8159893 >>>> >>>> Before the patch: >>>> [4.591s][debug][gc,phases,start ] GC(7) Parallel Unloading (4.591s) >>>> [4.596s][info ][gc,stringtable ] Cleaned string and symbol table, strings: 5899 processed, 0 removed, symbols: 34149 processed, 0 removed >>>> [4.596s][debug][gc,phases ] GC(7) Parallel Unloading (4.591s, 4.596s) 4.902ms >>>> [4.596s][info ][gc ] GC(7) Pause Remark 70M->70M(20480M) (4.578s, 4.596s) 18.161ms >>>> >>>> After the patch: >>>> [4.591s][debug][gc,phases,start ] GC(7) Parallel Unloading (4.591s) >>>> [4.596s][info ][gc,stringtable ] GC(7) Cleaned string and symbol table, strings: 5899 processed, 0 removed, symbols: 34149 processed, 0 removed >>>> [4.596s][debug][gc,phases ] GC(7) Parallel Unloading (4.591s, 4.596s) 4.902ms >>>> [4.596s][info ][gc ] GC(7) Pause Remark 70M->70M(20480M) (4.578s, 4.596s) 18.161ms >>>> >>>> The TestStringSymbolTableStats test was update to match and test the new format. >>>> >>>> Thanks, >>>> StefanK From ahmetmircik at gmail.com Wed Jun 22 10:42:31 2016 From: ahmetmircik at gmail.com (=?UTF-8?B?YWhtZXQgbcSxcsOnxLFr?=) Date: Wed, 22 Jun 2016 10:42:31 +0000 Subject: Runtime.getRuntime().freeMemory() can report wrong values when collector is CMS? In-Reply-To: References: Message-ID: As Jon requested, adding whole logs of run with -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 0.387: [GC0.387: [ParNew: 1908416K->1478K(2146944K), 0.1184640 secs] 1908416K->1478K(62676032K), 0.1186650 secs] [Times: user=1.46 sys=0.06, real=0.12 secs] 2.044: [GC2.044: [ParNew: 1909894K->238528K(2146944K), 1.0219420 secs] 1909894K->990306K(62676032K), 1.0221530 secs] [Times: user=3.43 sys=0.65, real=1.03 secs] 5.371: [GC5.371: [ParNew: 2146944K->238528K(2146944K), 0.7925770 secs] 2898722K->2563370K(62676032K), 0.7928370 secs] [Times: user=3.91 sys=0.92, real=0.79 secs] 6.212: [GC [1 CMS-initial-mark: 2324842K(60529088K)] 2970151K(62676032K), 0.0798090 secs] [Times: user=0.07 sys=0.01, real=0.08 secs] 6.292: [CMS-concurrent-mark-start] 6.409: [CMS-concurrent-mark: 0.117/0.117 secs] [Times: user=1.11 sys=0.03, real=0.12 secs] 6.409: [CMS-concurrent-preclean-start] 6.488: [CMS-concurrent-preclean: 0.079/0.079 secs] [Times: user=0.30 sys=0.01, real=0.08 secs] 6.488: [CMS-concurrent-abortable-preclean-start] 8.608: [GC8.608: [ParNew: 2146944K->238528K(2146944K), 0.6036620 secs] 4471786K->4179773K(62676032K), 0.6038550 secs] [Times: user=4.74 sys=0.85, real=0.60 secs] 10.330: [CMS-concurrent-abortable-preclean: 2.932/3.842 secs] [Times: user=18.73 sys=0.98, real=3.84 secs] 10.331: [GC[YG occupancy: 1202595 K (2146944 K)]10.331: [Rescan (parallel) , 0.1014670 secs]10.432: [weak refs processing, 0.0000220 secs]10.432: [scrub string table, 0.0001390 secs] [1 CMS-remark: 3941245K(60529088K)] 5143841K(62676032K), 0.1017860 secs] [Times: user=2.01 sys=0.01, real=0.10 secs] 10.432: [CMS-concurrent-sweep-start] 10.855: [CMS-concurrent-sweep: 0.423/0.423 secs] [Times: user=1.83 sys=0.02, real=0.43 secs] 10.856: [CMS-concurrent-reset-start] 11.225: [CMS-concurrent-reset: 0.369/0.369 secs] [Times: user=1.41 sys=0.33, real=0.37 secs] 12.042: [GC12.042: [ParNew: 2146944K->238528K(2146944K), 0.5858140 secs] 6084759K->5903972K(62676032K), 0.5859810 secs] [Times: user=4.58 sys=0.84, real=0.59 secs] 12.638: [GC [1 CMS-initial-mark: 5665444K(60529088K)] 5979114K(62676032K), 0.0419200 secs] [Times: user=0.04 sys=0.00, real=0.04 secs] 12.680: [CMS-concurrent-mark-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=660M, runtime.usedMemory=60546M, runTime.availableMemory=660M, freeHeapPercentage=1.08 13.083: [CMS-concurrent-mark: 0.393/0.403 secs] [Times: user=4.16 sys=0.05, real=0.40 secs] 13.083: [CMS-concurrent-preclean-start] 13.221: [CMS-concurrent-preclean: 0.135/0.138 secs] [Times: user=0.74 sys=0.00, real=0.14 secs] 13.221: [CMS-concurrent-abortable-preclean-start] 15.433: [GC15.433: [ParNew: 2146944K->238528K(2146944K), 0.6007190 secs] 7812388K->7683258K(62676032K), 0.6008890 secs] [Times: user=5.73 sys=0.89, real=0.60 secs] 17.907: [CMS-concurrent-abortable-preclean: 3.832/4.686 secs] [Times: user=27.47 sys=0.99, real=4.69 secs] 17.907: [GC[YG occupancy: 1343364 K (2146944 K)]17.907: [Rescan (parallel) , 0.0650330 secs]17.972: [weak refs processing, 0.0000260 secs]17.972: [scrub string table, 0.0001410 secs] [1 CMS-remark: 7444730K(60529088K)] 8788094K(62676032K), 0.0653380 secs] [Times: user=1.14 sys=0.01, real=0.06 secs] 17.973: [CMS-concurrent-sweep-start] 18.748: [CMS-concurrent-sweep: 0.775/0.775 secs] [Times: user=3.85 sys=0.03, real=0.78 secs] 18.748: [CMS-concurrent-reset-start] 18.870: [CMS-concurrent-reset: 0.122/0.122 secs] [Times: user=0.57 sys=0.00, real=0.12 secs] 19.489: [GC19.489: [ParNew: 2146944K->238528K(2146944K), 0.6780350 secs] 9577677K->9505999K(62676032K), 0.6781850 secs] [Times: user=7.28 sys=0.93, real=0.68 secs] 20.188: [GC [1 CMS-initial-mark: 9267471K(60529088K)] 9620491K(62676032K), 0.0422140 secs] [Times: user=0.05 sys=0.00, real=0.04 secs] 20.230: [CMS-concurrent-mark-start] 21.059: [CMS-concurrent-mark: 0.829/0.829 secs] [Times: user=8.05 sys=0.13, real=0.83 secs] 21.059: [CMS-concurrent-preclean-start] 21.253: [CMS-concurrent-preclean: 0.188/0.194 secs] [Times: user=0.94 sys=0.00, real=0.19 secs] 21.253: [CMS-concurrent-abortable-preclean-start] 23.664: [GC23.664: [ParNew: 2146944K->238528K(2146944K), 0.6295930 secs] 11414415K->11354247K(62676032K), 0.6297570 secs] [Times: user=9.36 sys=1.17, real=0.63 secs] 26.011: [CMS-concurrent-abortable-preclean: 3.811/4.757 secs] [Times: user=30.09 sys=1.26, real=4.76 secs] 26.011: [GC[YG occupancy: 1231128 K (2146944 K)]26.011: [Rescan (parallel) , 0.0362050 secs]26.047: [weak refs processing, 0.0000230 secs]26.047: [scrub string table, 0.0001350 secs] [1 CMS-remark: 11115719K(60529088K)] 12346847K(62676032K), 0.0365120 secs] [Times: user=0.72 sys=0.01, real=0.04 secs] 26.048: [CMS-concurrent-sweep-start] 27.247: [CMS-concurrent-sweep: 1.199/1.199 secs] [Times: user=5.95 sys=0.02, real=1.20 secs] 27.247: [CMS-concurrent-reset-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=404M, runtime.usedMemory=60802M, runTime.availableMemory=404M, freeHeapPercentage=0.66 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=404M, runtime.usedMemory=60802M, runTime.availableMemory=404M, freeHeapPercentage=0.66 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=404M, runtime.usedMemory=60802M, runTime.availableMemory=404M, freeHeapPercentage=0.66 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=404M, runtime.usedMemory=60802M, runTime.availableMemory=404M, freeHeapPercentage=0.66 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=404M, runtime.usedMemory=60802M, runTime.availableMemory=404M, freeHeapPercentage=0.66 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=404M, runtime.usedMemory=60802M, runTime.availableMemory=404M, freeHeapPercentage=0.66 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=404M, runtime.usedMemory=60802M, runTime.availableMemory=404M, freeHeapPercentage=0.66 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=404M, runtime.usedMemory=60802M, runTime.availableMemory=404M, freeHeapPercentage=0.66 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=404M, runtime.usedMemory=60802M, runTime.availableMemory=404M, freeHeapPercentage=0.66 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=404M, runtime.usedMemory=60802M, runTime.availableMemory=404M, freeHeapPercentage=0.66 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=404M, runtime.usedMemory=60802M, runTime.availableMemory=404M, freeHeapPercentage=0.66 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=404M, runtime.usedMemory=60802M, runTime.availableMemory=404M, freeHeapPercentage=0.66 27.370: [CMS-concurrent-reset: 0.123/0.123 secs] [Times: user=0.59 sys=0.00, real=0.12 secs] 27.781: [GC27.781: [ParNew: 2146944K->238528K(2146944K), 0.7943920 secs] 13143349K->13102932K(62676032K), 0.7945470 secs] [Times: user=6.38 sys=0.84, real=0.80 secs] 28.582: [GC [1 CMS-initial-mark: 12864404K(60529088K)] 13127809K(62676032K), 0.0449620 secs] [Times: user=0.05 sys=0.00, real=0.05 secs] 28.627: [CMS-concurrent-mark-start] 29.683: [CMS-concurrent-mark: 1.055/1.055 secs] [Times: user=11.21 sys=0.10, real=1.05 secs] 29.683: [CMS-concurrent-preclean-start] 29.898: [CMS-concurrent-preclean: 0.209/0.215 secs] [Times: user=1.33 sys=0.01, real=0.22 secs] 29.898: [CMS-concurrent-abortable-preclean-start] 31.486: [GC31.486: [ParNew: 2146944K->238528K(2146944K), 0.6539690 secs] 15011348K->14984067K(62676032K), 0.6541020 secs] [Times: user=6.12 sys=0.95, real=0.65 secs] 34.126: [CMS-concurrent-abortable-preclean: 3.350/4.228 secs] [Times: user=25.87 sys=1.04, real=4.23 secs] 34.126: [GC[YG occupancy: 1561671 K (2146944 K)]34.126: [Rescan (parallel) , 0.0510120 secs]34.177: [weak refs processing, 0.0000230 secs]34.177: [scrub string table, 0.0001370 secs] [1 CMS-remark: 14745539K(60529088K)] 16307210K(62676032K), 0.0513170 secs] [Times: user=0.78 sys=0.00, real=0.05 secs] 34.177: [CMS-concurrent-sweep-start] 35.280: [GC35.280: [ParNew: 2146944K->238528K(2146944K), 0.5963010 secs] 16884983K->16853353K(62676032K), 0.5964590 secs] [Times: user=5.68 sys=0.90, real=0.60 secs] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 36.472: [CMS-concurrent-sweep: 1.697/2.294 secs] [Times: user=13.86 sys=0.94, real=2.29 secs] 36.472: [CMS-concurrent-reset-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=1576M, runtime.usedMemory=59630M, runTime.availableMemory=1576M, freeHeapPercentage=2.58 36.594: [CMS-concurrent-reset: 0.122/0.122 secs] [Times: user=0.56 sys=0.01, real=0.12 secs] 38.594: [GC [1 CMS-initial-mark: 16614437K(60529088K)] 18658849K(62676032K), 0.3918420 secs] [Times: user=0.40 sys=0.00, real=0.40 secs] 38.986: [CMS-concurrent-mark-start] 39.170: [GC39.170: [ParNew: 2146944K->238528K(2146944K), 0.6542340 secs] 18761381K->18734221K(62676032K), 0.6543650 secs] [Times: user=9.06 sys=1.06, real=0.66 secs] 41.592: [CMS-concurrent-mark: 1.952/2.606 secs] [Times: user=27.04 sys=1.44, real=2.60 secs] 41.592: [CMS-concurrent-preclean-start] 42.630: [GC42.630: [ParNew: 2146944K->238528K(2146944K), 0.6582430 secs] 20642637K->20619236K(62676032K), 0.6583630 secs] [Times: user=7.10 sys=0.96, real=0.66 secs] 45.295: [CMS-concurrent-preclean: 2.545/3.703 secs] [Times: user=20.74 sys=1.03, real=3.71 secs] 45.295: [CMS-concurrent-abortable-preclean-start] 45.754: [CMS-concurrent-abortable-preclean: 0.440/0.459 secs] [Times: user=1.97 sys=0.01, real=0.45 secs] 45.754: [GC[YG occupancy: 1972273 K (2146944 K)]45.754: [Rescan (parallel) , 0.0567050 secs]45.811: [weak refs processing, 0.0000290 secs]45.811: [scrub string table, 0.0001650 secs] [1 CMS-remark: 20380708K(60529088K)] 22352981K(62676032K), 0.0570420 secs] [Times: user=0.99 sys=0.00, real=0.06 secs] 45.811: [CMS-concurrent-sweep-start] 46.057: [GC46.057: [ParNew: 2146944K->238528K(2146944K), 0.6509200 secs] 22520760K->22498628K(62676032K), 0.6510540 secs] [Times: user=5.80 sys=0.90, real=0.65 secs] 48.782: [CMS-concurrent-sweep: 2.320/2.971 secs] [Times: user=15.44 sys=0.94, real=2.97 secs] 48.782: [CMS-concurrent-reset-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=798M, runtime.usedMemory=60409M, runTime.availableMemory=798M, freeHeapPercentage=1.30 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=798M, runtime.usedMemory=60409M, runTime.availableMemory=798M, freeHeapPercentage=1.30 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=798M, runtime.usedMemory=60409M, runTime.availableMemory=798M, freeHeapPercentage=1.30 48.905: [CMS-concurrent-reset: 0.123/0.123 secs] [Times: user=0.54 sys=0.00, real=0.13 secs] 49.576: [GC49.576: [ParNew: 2146944K->238528K(2146944K), 0.9098200 secs] 24168579K->24146272K(62676032K), 0.9099430 secs] [Times: user=5.52 sys=0.76, real=0.91 secs] 50.495: [GC [1 CMS-initial-mark: 23907744K(60529088K)] 24183040K(62676032K), 0.0441810 secs] [Times: user=0.04 sys=0.00, real=0.04 secs] 50.539: [CMS-concurrent-mark-start] 52.849: [CMS-concurrent-mark: 2.310/2.310 secs] [Times: user=21.75 sys=0.37, real=2.31 secs] 52.849: [CMS-concurrent-preclean-start] 53.232: [CMS-concurrent-preclean: 0.378/0.383 secs] [Times: user=1.86 sys=0.01, real=0.38 secs] 53.232: [CMS-concurrent-abortable-preclean-start] 53.262: [GC53.262: [ParNew: 2146944K->238528K(2146944K), 0.6388870 secs] 26054688K->26033598K(62676032K), 0.6390090 secs] [Times: user=5.77 sys=0.87, real=0.64 secs] 55.790: [CMS-concurrent-abortable-preclean: 1.657/2.558 secs] [Times: user=13.95 sys=0.91, real=2.56 secs] 55.790: [GC[YG occupancy: 1519225 K (2146944 K)]55.790: [Rescan (parallel) , 0.0415720 secs]55.832: [weak refs processing, 0.0000290 secs]55.832: [scrub string table, 0.0001280 secs] [1 CMS-remark: 25795070K(60529088K)] 27314296K(62676032K), 0.0418560 secs] [Times: user=0.73 sys=0.00, real=0.04 secs] 55.832: [CMS-concurrent-sweep-start] 56.712: [GC56.712: [ParNew: 2146944K->238528K(2146944K), 0.6404990 secs] 27932356K->27910577K(62676032K), 0.6406280 secs] [Times: user=6.26 sys=0.94, real=0.64 secs] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=483M, runtime.usedMemory=60723M, runTime.availableMemory=483M, freeHeapPercentage=0.79 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=483M, runtime.usedMemory=60723M, runTime.availableMemory=483M, freeHeapPercentage=0.79 59.273: [CMS-concurrent-sweep: 2.799/3.440 secs]runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=483M, runtime.usedMemory=60723M, runTime.availableMemory=483M, freeHeapPercentage=0.79 [Times: user=17.00 sys=0.99, real=3.44 secs] 59.273: [CMS-concurrent-reset-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=483M, runtime.usedMemory=60723M, runTime.availableMemory=483M, freeHeapPercentage=0.79 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=483M, runtime.usedMemory=60723M, runTime.availableMemory=483M, freeHeapPercentage=0.79 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=483M, runtime.usedMemory=60723M, runTime.availableMemory=483M, freeHeapPercentage=0.79 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=483M, runtime.usedMemory=60723M, runTime.availableMemory=483M, freeHeapPercentage=0.79 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=483M, runtime.usedMemory=60723M, runTime.availableMemory=483M, freeHeapPercentage=0.79 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=483M, runtime.usedMemory=60723M, runTime.availableMemory=483M, freeHeapPercentage=0.79 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=483M, runtime.usedMemory=60723M, runTime.availableMemory=483M, freeHeapPercentage=0.79 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=483M, runtime.usedMemory=60723M, runTime.availableMemory=483M, freeHeapPercentage=0.79 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=483M, runtime.usedMemory=60723M, runTime.availableMemory=483M, freeHeapPercentage=0.79 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=483M, runtime.usedMemory=60723M, runTime.availableMemory=483M, freeHeapPercentage=0.79 59.393: [CMS-concurrent-reset: 0.121/0.121 secs] [Times: user=0.60 sys=0.00, real=0.12 secs] 59.902: [GC59.902: [ParNew: 2146944K->238528K(2146944K), 0.7065190 secs] 29803757K->29797857K(62676032K), 0.7066380 secs] [Times: user=6.42 sys=0.96, real=0.71 secs] 60.622: [GC [1 CMS-initial-mark: 29559329K(60529088K)] 29822295K(62676032K), 0.1058490 secs] [Times: user=0.11 sys=0.00, real=0.11 secs] 60.728: [CMS-concurrent-mark-start] 63.586: [GC63.586: [ParNew: 2146944K->238528K(2146944K), 0.6232010 secs] 31706273K->31683761K(62676032K), 0.6233350 secs] [Times: user=5.46 sys=0.91, real=0.62 secs] 64.440: [CMS-concurrent-mark: 3.088/3.712 secs] [Times: user=35.70 sys=1.46, real=3.71 secs] 64.440: [CMS-concurrent-preclean-start] 66.715: [CMS-concurrent-preclean: 1.982/2.275 secs] [Times: user=10.21 sys=0.04, real=2.28 secs] 66.716: [CMS-concurrent-abortable-preclean-start] 66.880: [GC66.880: [ParNew: 2146944K->238528K(2146944K), 0.6119610 secs] 33592177K->33573043K(62676032K), 0.6120760 secs] [Times: user=6.49 sys=0.93, real=0.61 secs] 69.702: [GC69.702: [ParNew: 2146944K->238528K(2146944K), 0.5955690 secs] 35481459K->35461194K(62676032K), 0.5956870 secs] [Times: user=6.46 sys=0.93, real=0.60 secs] 70.329: [CMS-concurrent-abortable-preclean: 2.099/3.614 secs] [Times: user=25.75 sys=1.92, real=3.61 secs] 70.329: [GC[YG occupancy: 293691 K (2146944 K)]70.329: [Rescan (parallel) , 0.0635560 secs]70.393: [weak refs processing, 0.0000230 secs]70.393: [scrub string table, 0.0001290 secs] [1 CMS-remark: 35222666K(60529088K)] 35516357K(62676032K), 0.0638250 secs] [Times: user=1.42 sys=0.02, real=0.06 secs] 70.393: [CMS-concurrent-sweep-start] 72.646: [GC72.646: [ParNew: 2146944K->238528K(2146944K), 0.9451240 secs] 36951043K->36929589K(62676032K), 0.9452550 secs] [Times: user=5.85 sys=0.71, real=0.94 secs] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 75.105: [CMS-concurrent-sweep: 3.767/4.712 secs] [Times: user=24.29 sys=0.80, real=4.72 secs] 75.106: [CMS-concurrent-reset-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=936M, runtime.usedMemory=60270M, runTime.availableMemory=936M, freeHeapPercentage=1.53 75.228: [CMS-concurrent-reset: 0.122/0.122 secs] [Times: user=0.53 sys=0.01, real=0.12 secs] 75.598: [GC [1 CMS-initial-mark: 36625076K(60529088K)] 38254679K(62676032K), 0.3188370 secs] [Times: user=0.32 sys=0.00, real=0.32 secs] 75.917: [CMS-concurrent-mark-start] 76.659: [GC76.659: [ParNew: 2146944K->238528K(2146944K), 0.8054530 secs] 38772020K->38749651K(62676032K), 0.8055600 secs] [Times: user=5.93 sys=0.84, real=0.81 secs] 80.291: [GC80.291: [ParNew: 2146944K->238528K(2146944K), 0.6266540 secs] 40658067K->40641414K(62676032K), 0.6267580 secs] [Times: user=6.63 sys=1.02, real=0.63 secs] 81.322: [CMS-concurrent-mark: 3.972/5.405 secs] [Times: user=50.57 sys=2.50, real=5.40 secs] 81.322: [CMS-concurrent-preclean-start] 83.503: [GC83.503: [ParNew: 2146944K->238528K(2146944K), 0.6219820 secs] 42549830K->42530440K(62676032K), 0.6220780 secs] [Times: user=6.70 sys=0.96, real=0.63 secs] 86.711: [GC86.711: [ParNew: 2146944K->238528K(2146944K), 0.6295710 secs] 44438856K->44419255K(62676032K), 0.6296720 secs] [Times: user=5.84 sys=0.92, real=0.63 secs] 89.829: [GC89.829: [ParNew: 2146944K->238528K(2146944K), 0.6297130 secs] 46327671K->46307853K(62676032K), 0.6298170 secs] [Times: user=7.59 sys=1.09, real=0.63 secs] 90.459: [CMS-concurrent-preclean: 6.186/9.137 secs] [Times: user=54.90 sys=3.11, real=9.14 secs] 90.459: [CMS-concurrent-abortable-preclean-start] 93.106: [GC93.106: [ParNew: 2146944K->238528K(2146944K), 0.6533050 secs] 48216269K->48193771K(62676032K), 0.6534110 secs] [Times: user=10.04 sys=1.22, real=0.65 secs] 93.797: [CMS-concurrent-abortable-preclean: 2.383/3.338 secs] [Times: user=22.51 sys=1.27, real=3.34 secs] 93.797: [GC[YG occupancy: 291838 K (2146944 K)]93.797: [Rescan (parallel) , 0.0816650 secs]93.879: [weak refs processing, 0.0000220 secs]93.879: [scrub string table, 0.0001220 secs] [1 CMS-remark: 47955243K(60529088K)] 48247082K(62676032K), 0.0819420 secs] [Times: user=1.61 sys=0.01, real=0.08 secs] 93.879: [CMS-concurrent-sweep-start] 96.615: [GC96.615: [ParNew: 2146944K->238528K(2146944K), 0.6331560 secs] 50053061K->50034231K(62676032K), 0.6332520 secs] [Times: user=7.67 sys=1.03, real=0.63 secs] 99.520: [CMS-concurrent-sweep: 5.007/5.640 secs] [Times: user=30.41 sys=1.15, real=5.64 secs] 99.520: [CMS-concurrent-reset-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=319M, runtime.usedMemory=60887M, runTime.availableMemory=319M, freeHeapPercentage=0.52 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=319M, runtime.usedMemory=60887M, runTime.availableMemory=319M, freeHeapPercentage=0.52 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=319M, runtime.usedMemory=60887M, runTime.availableMemory=319M, freeHeapPercentage=0.52 99.641: [CMS-concurrent-reset: 0.122/0.122 secs] [Times: user=0.67 sys=0.01, real=0.12 secs] 99.896: [GC99.896: [ParNew: 2146944K->238528K(2146944K), 0.5846780 secs] 51929136K->51910762K(62676032K), 0.5847860 secs] [Times: user=5.33 sys=0.92, real=0.58 secs] 100.484: [GC [1 CMS-initial-mark: 51672234K(60529088K)] 51925538K(62676032K), 0.0461750 secs] [Times: user=0.05 sys=0.00, real=0.05 secs] 100.530: [CMS-concurrent-mark-start] 102.959: [GC102.959: [ParNew: 2146944K->238528K(2146944K), 0.5868320 secs] 53819178K->53798644K(62676032K), 0.5869410 secs] [Times: user=6.25 sys=0.88, real=0.59 secs] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7343M, runtime.usedMemory=53863M, runTime.availableMemory=7343M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7342M, runtime.usedMemory=53864M, runTime.availableMemory=7342M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7342M, runtime.usedMemory=53864M, runTime.availableMemory=7342M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7342M, runtime.usedMemory=53864M, runTime.availableMemory=7342M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7342M, runtime.usedMemory=53864M, runTime.availableMemory=7342M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7342M, runtime.usedMemory=53864M, runTime.availableMemory=7342M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7342M, runtime.usedMemory=53864M, runTime.availableMemory=7342M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7342M, runtime.usedMemory=53864M, runTime.availableMemory=7342M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7342M, runtime.usedMemory=53864M, runTime.availableMemory=7342M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7342M, runtime.usedMemory=53864M, runTime.availableMemory=7342M, freeHeapPercentage=12.00 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7342M, runtime.usedMemory=53864M, runTime.availableMemory=7342M, freeHeapPercentage=12.00 End of run...now we expect to see actual used-memory value runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7342M, runtime.usedMemory=53865M, runTime.availableMemory=7342M, freeHeapPercentage=12.00 108.307: [CMS-concurrent-mark: 7.187/7.777 secs] [Times: user=68.29 sys=1.90, real=7.78 secs] 108.307: [CMS-concurrent-preclean-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7329M, runtime.usedMemory=53877M, runTime.availableMemory=7329M, freeHeapPercentage=11.98 110.690: [CMS-concurrent-preclean: 2.088/2.383 secs] [Times: user=2.39 sys=0.00, real=2.38 secs] 110.690: [CMS-concurrent-abortable-preclean-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7329M, runtime.usedMemory=53877M, runTime.availableMemory=7329M, freeHeapPercentage=11.98 CMS: abort preclean due to time 115.797: [CMS-concurrent-abortable-preclean: 3.706/5.107 secs] [Times: user=3.71 sys=0.00, real=5.11 secs] 115.797: [GC[YG occupancy: 1610438 K (2146944 K)]115.797: [Rescan (parallel) , 0.3345390 secs]116.132: [weak refs processing, 0.0000200 secs]116.132: [scrub string table, 0.0001210 secs] [1 CMS-remark: 53560116K(60529088K)] 55170554K(62676032K), 0.3347610 secs] [Times: user=6.36 sys=0.02, real=0.33 secs] 116.132: [CMS-concurrent-sweep-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7444M, runtime.usedMemory=53762M, runTime.availableMemory=7444M, freeHeapPercentage=12.16 121.468: [CMS-concurrent-sweep: 5.336/5.336 secs] [Times: user=5.35 sys=0.00, real=5.34 secs] 121.469: [CMS-concurrent-reset-start] 121.593: [CMS-concurrent-reset: 0.125/0.125 secs] [Times: user=0.13 sys=0.00, real=0.12 secs] 123.593: [GC [1 CMS-initial-mark: 53426011K(60529088K)] 55036449K(62676032K), 0.3241770 secs] [Times: user=0.32 sys=0.00, real=0.33 secs] 123.918: [CMS-concurrent-mark-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7460M, runtime.usedMemory=53746M, runTime.availableMemory=7460M, freeHeapPercentage=12.19 128.910: [CMS-concurrent-mark: 4.993/4.993 secs] [Times: user=32.81 sys=0.80, real=4.99 secs] 128.910: [CMS-concurrent-preclean-start] 128.969: [CMS-concurrent-preclean: 0.058/0.058 secs] [Times: user=0.06 sys=0.00, real=0.06 secs] 128.969: [CMS-concurrent-abortable-preclean-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7460M, runtime.usedMemory=53746M, runTime.availableMemory=7460M, freeHeapPercentage=12.19 CMS: abort preclean due to time 134.096: [CMS-concurrent-abortable-preclean: 3.726/5.127 secs] [Times: user=3.74 sys=0.00, real=5.13 secs] 134.096: [GC[YG occupancy: 1610438 K (2146944 K)]134.096: [Rescan (parallel) , 0.3166330 secs]134.413: [weak refs processing, 0.0000220 secs]134.413: [scrub string table, 0.0001220 secs] [1 CMS-remark: 53426011K(60529088K)] 55036449K(62676032K), 0.3168870 secs] [Times: user=6.06 sys=0.05, real=0.31 secs] 134.413: [CMS-concurrent-sweep-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7461M, runtime.usedMemory=53745M, runTime.availableMemory=7461M, freeHeapPercentage=12.19 139.841: [CMS-concurrent-sweep: 5.428/5.428 secs] [Times: user=5.44 sys=0.00, real=5.43 secs] 139.841: [CMS-concurrent-reset-start] 139.965: [CMS-concurrent-reset: 0.124/0.124 secs] [Times: user=0.13 sys=0.00, real=0.13 secs] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 141.965: [GC [1 CMS-initial-mark: 53419286K(60529088K)] 55029724K(62676032K), 0.3267790 secs] [Times: user=0.33 sys=0.00, real=0.32 secs] 142.292: [CMS-concurrent-mark-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 146.897: [CMS-concurrent-mark: 4.605/4.605 secs] [Times: user=30.89 sys=0.48, real=4.61 secs] 146.898: [CMS-concurrent-preclean-start] 146.955: [CMS-concurrent-preclean: 0.058/0.058 secs] [Times: user=0.06 sys=0.00, real=0.06 secs] 146.955: [CMS-concurrent-abortable-preclean-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 CMS: abort preclean due to time 152.087: [CMS-concurrent-abortable-preclean: 3.731/5.132 secs] [Times: user=3.74 sys=0.00, real=5.13 secs] 152.088: [GC[YG occupancy: 1610438 K (2146944 K)]152.088: [Rescan (parallel) , 0.5756110 secs]152.663: [weak refs processing, 0.0000230 secs]152.663: [scrub string table, 0.0001300 secs] [1 CMS-remark: 53419286K(60529088K)] 55029724K(62676032K), 0.5758770 secs] [Times: user=11.00 sys=0.08, real=0.57 secs] 152.664: [CMS-concurrent-sweep-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 158.034: [CMS-concurrent-sweep: 5.371/5.371 secs] [Times: user=5.38 sys=0.00, real=5.37 secs] 158.034: [CMS-concurrent-reset-start] 158.158: [CMS-concurrent-reset: 0.124/0.124 secs] [Times: user=0.13 sys=0.00, real=0.12 secs] 160.158: [GC [1 CMS-initial-mark: 53419286K(60529088K)] 55029724K(62676032K), 0.3387750 secs] [Times: user=0.34 sys=0.00, real=0.34 secs] 160.497: [CMS-concurrent-mark-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 165.390: [CMS-concurrent-mark: 4.892/4.893 secs] [Times: user=32.05 sys=0.66, real=4.89 secs] 165.390: [CMS-concurrent-preclean-start] 165.449: [CMS-concurrent-preclean: 0.059/0.059 secs] [Times: user=0.06 sys=0.00, real=0.06 secs] 165.449: [CMS-concurrent-abortable-preclean-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 CMS: abort preclean due to time 170.580: [CMS-concurrent-abortable-preclean: 3.730/5.131 secs] [Times: user=3.74 sys=0.00, real=5.13 secs] 170.580: [GC[YG occupancy: 1610438 K (2146944 K)]170.580: [Rescan (parallel) , 0.3244620 secs]170.905: [weak refs processing, 0.0000200 secs]170.905: [scrub string table, 0.0001360 secs] [1 CMS-remark: 53419286K(60529088K)] 55029724K(62676032K), 0.3247170 secs] [Times: user=5.98 sys=0.05, real=0.33 secs] 170.905: [CMS-concurrent-sweep-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 176.327: [CMS-concurrent-sweep: 5.422/5.422 secs] [Times: user=5.43 sys=0.00, real=5.42 secs] 176.327: [CMS-concurrent-reset-start] 176.451: [CMS-concurrent-reset: 0.124/0.124 secs] [Times: user=0.12 sys=0.00, real=0.12 secs] 178.452: [GC [1 CMS-initial-mark: 53419286K(60529088K)] 55029724K(62676032K), 0.3595980 secs] [Times: user=0.36 sys=0.00, real=0.36 secs] 178.811: [CMS-concurrent-mark-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 183.353: [CMS-concurrent-mark: 4.541/4.541 secs] [Times: user=30.41 sys=0.51, real=4.54 secs] 183.353: [CMS-concurrent-preclean-start] 183.416: [CMS-concurrent-preclean: 0.063/0.063 secs] [Times: user=0.06 sys=0.00, real=0.07 secs] 183.416: [CMS-concurrent-abortable-preclean-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 CMS: abort preclean due to time 188.572: [CMS-concurrent-abortable-preclean: 3.755/5.156 secs] [Times: user=3.76 sys=0.00, real=5.15 secs] 188.572: [GC[YG occupancy: 1610438 K (2146944 K)]188.572: [Rescan (parallel) , 0.3576490 secs]188.929: [weak refs processing, 0.0000250 secs]188.929: [scrub string table, 0.0001260 secs] [1 CMS-remark: 53419286K(60529088K)] 55029724K(62676032K), 0.3579100 secs] [Times: user=6.56 sys=0.07, real=0.36 secs] 188.930: [CMS-concurrent-sweep-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 194.404: [CMS-concurrent-sweep: 5.474/5.474 secs] [Times: user=5.49 sys=0.00, real=5.47 secs] 194.404: [CMS-concurrent-reset-start] 194.527: [CMS-concurrent-reset: 0.124/0.124 secs] [Times: user=0.12 sys=0.00, real=0.13 secs] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 196.528: [GC [1 CMS-initial-mark: 53419286K(60529088K)] 55029724K(62676032K), 0.3428100 secs] [Times: user=0.35 sys=0.00, real=0.34 secs] 196.871: [CMS-concurrent-mark-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 201.918: [CMS-concurrent-mark: 5.047/5.047 secs] [Times: user=33.24 sys=0.83, real=5.05 secs] 201.918: [CMS-concurrent-preclean-start] 201.976: [CMS-concurrent-preclean: 0.058/0.058 secs] [Times: user=0.05 sys=0.00, real=0.06 secs] 201.976: [CMS-concurrent-abortable-preclean-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 CMS: abort preclean due to time 207.071: [CMS-concurrent-abortable-preclean: 3.694/5.095 secs] [Times: user=3.71 sys=0.00, real=5.09 secs] 207.071: [GC[YG occupancy: 1610438 K (2146944 K)]207.071: [Rescan (parallel) , 0.3230240 secs]207.394: [weak refs processing, 0.0000250 secs]207.394: [scrub string table, 0.0001370 secs] [1 CMS-remark: 53419286K(60529088K)] 55029724K(62676032K), 0.3232880 secs] [Times: user=5.73 sys=0.03, real=0.33 secs] 207.395: [CMS-concurrent-sweep-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 212.728: [CMS-concurrent-sweep: 5.333/5.333 secs] [Times: user=5.35 sys=0.00, real=5.33 secs] 212.728: [CMS-concurrent-reset-start] 212.852: [CMS-concurrent-reset: 0.124/0.124 secs] [Times: user=0.12 sys=0.00, real=0.12 secs] 214.852: [GC [1 CMS-initial-mark: 53419286K(60529088K)] 55029724K(62676032K), 0.3493740 secs] [Times: user=0.35 sys=0.00, real=0.35 secs] 215.202: [CMS-concurrent-mark-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 220.095: [CMS-concurrent-mark: 4.893/4.893 secs] [Times: user=32.33 sys=0.76, real=4.90 secs] 220.095: [CMS-concurrent-preclean-start] 220.154: [CMS-concurrent-preclean: 0.059/0.059 secs] [Times: user=0.06 sys=0.00, real=0.05 secs] 220.154: [CMS-concurrent-abortable-preclean-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 CMS: abort preclean due to time 225.272: [CMS-concurrent-abortable-preclean: 3.718/5.119 secs] [Times: user=3.73 sys=0.00, real=5.12 secs] 225.272: [GC[YG occupancy: 1610438 K (2146944 K)]225.272: [Rescan (parallel) , 0.3205500 secs]225.593: [weak refs processing, 0.0000220 secs]225.593: [scrub string table, 0.0001240 secs] [1 CMS-remark: 53419286K(60529088K)] 55029724K(62676032K), 0.3208060 secs] [Times: user=5.53 sys=0.07, real=0.32 secs] 225.593: [CMS-concurrent-sweep-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 230.979: [CMS-concurrent-sweep: 5.386/5.386 secs] [Times: user=5.40 sys=0.00, real=5.39 secs] 230.979: [CMS-concurrent-reset-start] 231.103: [CMS-concurrent-reset: 0.124/0.124 secs] [Times: user=0.13 sys=0.00, real=0.12 secs] 233.104: [GC [1 CMS-initial-mark: 53419286K(60529088K)] 55029724K(62676032K), 0.3235480 secs] [Times: user=0.32 sys=0.00, real=0.33 secs] 233.427: [CMS-concurrent-mark-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 238.241: [CMS-concurrent-mark: 4.814/4.814 secs] [Times: user=31.71 sys=0.70, real=4.81 secs] 238.241: [CMS-concurrent-preclean-start] 238.299: [CMS-concurrent-preclean: 0.058/0.058 secs] [Times: user=0.05 sys=0.00, real=0.06 secs] 238.299: [CMS-concurrent-abortable-preclean-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 CMS: abort preclean due to time 243.393: [CMS-concurrent-abortable-preclean: 3.692/5.093 secs] [Times: user=3.70 sys=0.00, real=5.09 secs] 243.393: [GC[YG occupancy: 1610438 K (2146944 K)]243.393: [Rescan (parallel) , 0.4171870 secs]243.810: [weak refs processing, 0.0000220 secs]243.810: [scrub string table, 0.0001300 secs] [1 CMS-remark: 53419286K(60529088K)] 55029724K(62676032K), 0.4174430 secs] [Times: user=7.59 sys=0.04, real=0.42 secs] 243.810: [CMS-concurrent-sweep-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 249.138: [CMS-concurrent-sweep: 5.328/5.328 secs] [Times: user=5.34 sys=0.00, real=5.33 secs] 249.138: [CMS-concurrent-reset-start] 249.262: [CMS-concurrent-reset: 0.123/0.123 secs] [Times: user=0.13 sys=0.00, real=0.12 secs] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 251.262: [GC [1 CMS-initial-mark: 53419286K(60529088K)] 55029724K(62676032K), 0.3307570 secs] [Times: user=0.33 sys=0.00, real=0.33 secs] 251.593: [CMS-concurrent-mark-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 256.226: [CMS-concurrent-mark: 4.633/4.633 secs] [Times: user=30.73 sys=0.69, real=4.64 secs] 256.226: [CMS-concurrent-preclean-start] 256.284: [CMS-concurrent-preclean: 0.058/0.058 secs] [Times: user=0.05 sys=0.00, real=0.05 secs] 256.284: [CMS-concurrent-abortable-preclean-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 CMS: abort preclean due to time 261.444: [CMS-concurrent-abortable-preclean: 3.759/5.160 secs] [Times: user=3.77 sys=0.00, real=5.16 secs] 261.444: [GC[YG occupancy: 1610438 K (2146944 K)]261.444: [Rescan (parallel) , 0.3162650 secs]261.760: [weak refs processing, 0.0000230 secs]261.760: [scrub string table, 0.0001400 secs] [1 CMS-remark: 53419286K(60529088K)] 55029724K(62676032K), 0.3165290 secs] [Times: user=5.42 sys=0.02, real=0.32 secs] 261.761: [CMS-concurrent-sweep-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 267.124: [CMS-concurrent-sweep: 5.364/5.364 secs] [Times: user=5.37 sys=0.00, real=5.36 secs] 267.124: [CMS-concurrent-reset-start] 267.248: [CMS-concurrent-reset: 0.124/0.124 secs] [Times: user=0.13 sys=0.00, real=0.13 secs] 269.249: [GC [1 CMS-initial-mark: 53419286K(60529088K)] 55029724K(62676032K), 0.3293280 secs] [Times: user=0.33 sys=0.00, real=0.33 secs] 269.578: [CMS-concurrent-mark-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 274.842: [CMS-concurrent-mark: 5.264/5.264 secs] [Times: user=33.32 sys=0.61, real=5.26 secs] 274.842: [CMS-concurrent-preclean-start] 274.900: [CMS-concurrent-preclean: 0.058/0.058 secs] [Times: user=0.05 sys=0.00, real=0.06 secs] 274.900: [CMS-concurrent-abortable-preclean-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 CMS: abort preclean due to time 279.951: [CMS-concurrent-abortable-preclean: 3.649/5.050 secs] [Times: user=3.66 sys=0.00, real=5.05 secs] 279.951: [GC[YG occupancy: 1610438 K (2146944 K)]279.951: [Rescan (parallel) , 0.3062610 secs]280.257: [weak refs processing, 0.0000230 secs]280.257: [scrub string table, 0.0001380 secs] [1 CMS-remark: 53419286K(60529088K)] 55029724K(62676032K), 0.3065390 secs] [Times: user=5.49 sys=0.04, real=0.31 secs] 280.258: [CMS-concurrent-sweep-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 285.596: [CMS-concurrent-sweep: 5.338/5.338 secs] [Times: user=5.35 sys=0.00, real=5.34 secs] 285.596: [CMS-concurrent-reset-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 285.720: [CMS-concurrent-reset: 0.123/0.123 secs] [Times: user=0.13 sys=0.00, real=0.12 secs] 287.720: [GC [1 CMS-initial-mark: 53419286K(60529088K)] 55029724K(62676032K), 0.3431370 secs] [Times: user=0.34 sys=0.00, real=0.34 secs] 288.063: [CMS-concurrent-mark-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 293.197: [CMS-concurrent-mark: 5.134/5.134 secs] [Times: user=31.78 sys=0.77, real=5.14 secs] 293.197: [CMS-concurrent-preclean-start] 293.255: [CMS-concurrent-preclean: 0.058/0.058 secs] [Times: user=0.06 sys=0.00, real=0.06 secs] 293.255: [CMS-concurrent-abortable-preclean-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 CMS: abort preclean due to time 298.361: [CMS-concurrent-abortable-preclean: 3.705/5.106 secs] [Times: user=3.71 sys=0.00, real=5.10 secs] 298.361: [GC[YG occupancy: 1610438 K (2146944 K)]298.361: [Rescan (parallel) , 0.3069420 secs]298.668: [weak refs processing, 0.0000220 secs]298.668: [scrub string table, 0.0001220 secs] [1 CMS-remark: 53419286K(60529088K)] 55029724K(62676032K), 0.3071670 secs] [Times: user=5.53 sys=0.08, real=0.31 secs] 298.668: [CMS-concurrent-sweep-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 304.039: [CMS-concurrent-sweep: 5.370/5.370 secs] [Times: user=5.38 sys=0.00, real=5.37 secs] 304.039: [CMS-concurrent-reset-start] 304.162: [CMS-concurrent-reset: 0.124/0.124 secs] [Times: user=0.12 sys=0.00, real=0.12 secs] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 306.163: [GC [1 CMS-initial-mark: 53419286K(60529088K)] 55029724K(62676032K), 0.3258150 secs] [Times: user=0.33 sys=0.00, real=0.33 secs] 306.488: [CMS-concurrent-mark-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 311.716: [CMS-concurrent-mark: 5.228/5.228 secs] [Times: user=33.89 sys=0.97, real=5.23 secs] 311.716: [CMS-concurrent-preclean-start] 311.777: [CMS-concurrent-preclean: 0.060/0.060 secs] [Times: user=0.06 sys=0.00, real=0.06 secs] 311.777: [CMS-concurrent-abortable-preclean-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 CMS: abort preclean due to time 316.855: [CMS-concurrent-abortable-preclean: 3.677/5.078 secs] [Times: user=3.69 sys=0.00, real=5.08 secs] 316.855: [GC[YG occupancy: 1610438 K (2146944 K)]316.855: [Rescan (parallel) , 0.3299850 secs]317.185: [weak refs processing, 0.0000220 secs]317.185: [scrub string table, 0.0001320 secs] [1 CMS-remark: 53419286K(60529088K)] 55029724K(62676032K), 0.3302460 secs] [Times: user=6.28 sys=0.08, real=0.33 secs] 317.185: [CMS-concurrent-sweep-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 322.600: [CMS-concurrent-sweep: 5.415/5.415 secs] [Times: user=5.43 sys=0.00, real=5.41 secs] 322.600: [CMS-concurrent-reset-start] 322.724: [CMS-concurrent-reset: 0.123/0.123 secs] [Times: user=0.12 sys=0.00, real=0.12 secs] 324.724: [GC [1 CMS-initial-mark: 53419286K(60529088K)] 55029724K(62676032K), 0.3439200 secs] [Times: user=0.35 sys=0.00, real=0.35 secs] 325.068: [CMS-concurrent-mark-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 330.097: [CMS-concurrent-mark: 5.029/5.029 secs] [Times: user=33.20 sys=0.74, real=5.03 secs] 330.097: [CMS-concurrent-preclean-start] 330.158: [CMS-concurrent-preclean: 0.061/0.061 secs] [Times: user=0.06 sys=0.00, real=0.06 secs] 330.158: [CMS-concurrent-abortable-preclean-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 CMS: abort preclean due to time 335.261: [CMS-concurrent-abortable-preclean: 3.702/5.103 secs] [Times: user=3.71 sys=0.00, real=5.10 secs] 335.261: [GC[YG occupancy: 1610438 K (2146944 K)]335.261: [Rescan (parallel) , 0.4076950 secs]335.669: [weak refs processing, 0.0000200 secs]335.669: [scrub string table, 0.0001280 secs] [1 CMS-remark: 53419286K(60529088K)] 55029724K(62676032K), 0.4079360 secs] [Times: user=7.02 sys=0.02, real=0.41 secs] 335.669: [CMS-concurrent-sweep-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 341.024: [CMS-concurrent-sweep: 5.355/5.355 secs] [Times: user=5.36 sys=0.00, real=5.36 secs] 341.025: [CMS-concurrent-reset-start] 341.148: [CMS-concurrent-reset: 0.123/0.123 secs] [Times: user=0.13 sys=0.00, real=0.12 secs] 343.148: [GC [1 CMS-initial-mark: 53419286K(60529088K)] 55029724K(62676032K), 0.3265310 secs] [Times: user=0.32 sys=0.00, real=0.33 secs] 343.475: [CMS-concurrent-mark-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 348.373: [CMS-concurrent-mark: 4.898/4.899 secs] [Times: user=32.31 sys=0.81, real=4.89 secs] 348.373: [CMS-concurrent-preclean-start] 348.431: [CMS-concurrent-preclean: 0.058/0.058 secs] [Times: user=0.06 sys=0.00, real=0.06 secs] 348.431: [CMS-concurrent-abortable-preclean-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 CMS: abort preclean due to time 353.490: [CMS-concurrent-abortable-preclean: 3.658/5.059 secs] [Times: user=3.67 sys=0.00, real=5.06 secs] 353.490: [GC[YG occupancy: 1610438 K (2146944 K)]353.490: [Rescan (parallel) , 0.5716350 secs]354.062: [weak refs processing, 0.0000230 secs]354.062: [scrub string table, 0.0001300 secs] [1 CMS-remark: 53419286K(60529088K)] 55029724K(62676032K), 0.5718720 secs] [Times: user=10.28 sys=0.09, real=0.57 secs] 354.062: [CMS-concurrent-sweep-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 359.432: [CMS-concurrent-sweep: 5.370/5.370 secs] [Times: user=5.38 sys=0.00, real=5.37 secs] 359.432: [CMS-concurrent-reset-start] 359.556: [CMS-concurrent-reset: 0.123/0.123 secs] [Times: user=0.12 sys=0.00, real=0.13 secs] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 361.556: [GC [1 CMS-initial-mark: 53419286K(60529088K)] 55029724K(62676032K), 0.3277380 secs] [Times: user=0.33 sys=0.00, real=0.32 secs] 361.884: [CMS-concurrent-mark-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 366.817: [CMS-concurrent-mark: 4.933/4.933 secs] [Times: user=32.78 sys=0.77, real=4.94 secs] 366.817: [CMS-concurrent-preclean-start] 366.875: [CMS-concurrent-preclean: 0.058/0.058 secs] [Times: user=0.06 sys=0.00, real=0.06 secs] 366.875: [CMS-concurrent-abortable-preclean-start] runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=7467M, runtime.usedMemory=53739M, runTime.availableMemory=7467M, freeHeapPercentage=12.20 Heap par new generation total 2146944K, used 1649288K [0x00007f2d45a00000, 0x00007f2dd7390000, 0x00007f2dd7390000) eden space 1908416K, 73% used [0x00007f2d45a00000, 0x00007f2d9bbb21a8, 0x00007f2dba1b0000) from space 238528K, 100% used [0x00007f2dc8aa0000, 0x00007f2dd7390000, 0x00007f2dd7390000) to space 238528K, 0% used [0x00007f2dba1b0000, 0x00007f2dba1b0000, 0x00007f2dc8aa0000) concurrent mark-sweep generation total 60529088K, used 53419286K [0x00007f2dd7390000, 0x00007f3c45a00000, 0x00007f3c45a00000) concurrent-mark-sweep perm gen total 21248K, used 3240K [0x00007f3c45a00000, 0x00007f3c46ec0000, 0x00007f3c50000000) ? 19 Haz 2016 Paz, 01:56 tarihinde, ahmet m?r??k ?unu yazd?: > Adding all logs from start of run: > > java -verbose:gc -Xms60G -Xmx60G -XX:CMSInitiatingOccupancyFraction=2 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -cp target/free-memory-issue-1.0- > > SNAPSHOT.jar FreeMemory > > [GC (Allocation Failure) 886080K->21645K(62803840K), 0.0743103 secs] > [GC (Allocation Failure) 907725K->568287K(62803840K), 0.4186990 secs] > [GC (Allocation Failure) 1454367K->1232520K(62803840K), 0.2885866 secs] > [GC (Allocation Failure) 2118600K->1985828K(62803840K), 0.3087718 secs] > [GC (CMS Initial Mark) 2042073K(62803840K), 0.0037783 secs] > [GC (Allocation Failure) 2871908K->2786446K(62803840K), 0.3650447 secs] > [GC (Allocation Failure) 3672526K->3670514K(62803840K), 0.3675287 secs] > [GC (Allocation Failure) 4556594K->4445914K(62803840K), 0.3455842 secs] > [GC (Allocation Failure) 5331994K->5302365K(62803840K), 0.3627719 secs] > [GC (CMS Final Remark) 5304053K(62803840K), 0.0586894 secs] > runtime.maxMemory=61331M, runtime.totalMemory=61331M, runtime.freeMemory=509M, runtime.usedMemory=60822M, runTime.availableMemory=509M, freeHeapPercentage=0.83 > runtime.maxMemory=61331M, runtime.totalMemory=61331M, runtime.freeMemory=509M, runtime.usedMemory=60822M, runTime.availableMemory=509M, freeHeapPercentage=0.83 > > End of run and free-memory returned expected values: (55734M instead of > 509M) > > runtime.maxMemory=61331M, runtime.totalMemory=61331M, runtime.freeMemory=55734M, runtime.usedMemory=5597M, runTime.availableMemory=55734M, freeHeapPercentage=90.87 > > ? > > > > 19 Haz 2016 Paz, 01:44 tarihinde ?unu yazd?: > >> Hello, >> >> Maybe you should show output and gclog as well. >> >> However I would argue that logging and alerting memory usage numbers is >> next to useless in most situations. If you want to have some usefull >> numbers I would restrict myself to log free memory for the various pools >> after related GC runs. The JMX beans have a metric for that. >> >> Gruss >> Bernd >> >> -- >> http://bernd.eckenfels.net >> >> -----Original Message----- >> From: "ahmet m?r??k" >> To: hotspot-gc-dev at openjdk.java.net >> Sent: So., 19 Juni 2016 0:31 >> Subject: Runtime.getRuntime().freeMemory() can report wrong values when >> collector is CMS? >> >> Hi, >> >> I am running a test which is trying to log memory info. when >> free-heap-percentage is under a certain threshold. But noticed that when >> heap is around `-XX:CMSInitiatingOccupancyFraction`, >> Runtime.getRuntime().freeMemory() can report wrong values when compared to >> memory info from GC logs. It reports as if whole heap is nearly occupied, >> but actually there exists lots of free-memory. Issue is observable for a >> short-time period. Later it starts to report expected values. (Also tried >> my test with G1 defaults and Runtime.getRuntime().freeMemory() reported as >> expected) >> >> Issue is easily visible on large heaps. >> >> Is my assumption correct? Can Runtime.getRuntime().freeMemory() report >> wrong free-memory info for a while? Or how can we explain this situation? >> >> Here is my test and how i run it from command line: >> >> [PROBLEMATIC RUN WITH CMS]--> java -verbose:gc -Xms60G -Xmx60G >> -XX:CMSInitiatingOccupancyFraction=2 -XX:+UseConcMarkSweepGC >> -XX:+UseParNewGC -cp target/free-memory-issue-1.0-SNAPSHOT.jar >> FreeMemory >> >> [OK RUN WITH G1]--> java -verbose:gc -Xms60G -Xmx60G -XX:+UseG1GC -cp >> target/free-memory-issue-1.0-SNAPSHOT.jar FreeMemory >> >> public class FreeMemory { >> >> static final int MB = 1024 * 1024; >> static final String MESSAGE = "runtime.maxMemory=%d%s, >> runtime.totalMemory=%d%s, runtime.freeMemory=%d%s," + >> " runtime.usedMemory=%d%s, runTime.availableMemory=%d%s, >> freeHeapPercentage=%.2f"; >> >> public static void main(String[] args) throws InterruptedException { >> final ConcurrentHashMap map = new ConcurrentHashMap(); >> >> Runtime runtime = Runtime.getRuntime(); >> int availableProcessors = runtime.availableProcessors(); >> int threadCount = availableProcessors * 4; >> >> ArrayList threads = new ArrayList(); >> >> for (int i = 0; i < threadCount; i++) { >> threads.add(new Thread(new Runnable() { >> >> @Override >> public void run() { >> Random random = new Random(); >> while (true) { >> byte[] value = new byte[1024]; >> random.nextBytes(value); >> >> map.put(random.nextInt(), value); >> >> if (hasReachedMinFreeHeapPercentage(12)) { >> break; >> } >> } >> } >> })); >> } >> >> for (Thread thread : threads) { >> thread.start(); >> } >> >> for (Thread thread : threads) { >> thread.join(); >> } >> >> out.print("\n\n\nEnd of run...now we expect to see actual >> used-memory value\n"); >> >> while (true) { >> printCurrentMemoryInfo(); >> parkNanos(SECONDS.toNanos(5)); >> } >> } >> >> static boolean hasReachedMinFreeHeapPercentage(int >> minFreeHeapPercentage) { >> Runtime runtime = Runtime.getRuntime(); >> >> long maxMemory = runtime.maxMemory(); >> long totalMemory = runtime.totalMemory(); >> long freeMemory = runtime.freeMemory(); >> long availableMemory = freeMemory + (maxMemory - totalMemory); >> double freeHeapPercentage = 100D * availableMemory / maxMemory; >> >> if (freeHeapPercentage < minFreeHeapPercentage) { >> String unit = "M"; >> out.println(format(MESSAGE, toMB(maxMemory), unit, >> toMB(totalMemory), unit, toMB(freeMemory), unit, >> toMB(totalMemory - freeMemory), unit, >> toMB(availableMemory), unit, freeHeapPercentage)); >> return true; >> } >> >> return false; >> } >> >> static void printCurrentMemoryInfo() { >> Runtime runtime = Runtime.getRuntime(); >> >> long maxMemory = runtime.maxMemory(); >> long totalMemory = runtime.totalMemory(); >> long freeMemory = runtime.freeMemory(); >> long availableMemory = freeMemory + (maxMemory - totalMemory); >> double freeHeapPercentage = 100D * availableMemory / maxMemory; >> >> String unit = "M"; >> out.println(format(MESSAGE, toMB(maxMemory), unit, >> toMB(totalMemory), unit, toMB(freeMemory), unit, >> toMB(totalMemory - freeMemory), unit, >> toMB(availableMemory), unit, freeHeapPercentage)); >> } >> >> static int toMB(long bytes) { >> return (int) Math.rint(bytes / MB); >> } >> } >> >> Java version: >> >> openjdk version "1.8.0_91" >> >> OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14) >> >> OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode) >> >> OS info: >> >> Linux version 3.13.0-74-generic (buildd at lcy01-07) (gcc version 4.8.2 >> (Ubuntu 4.8.2-19ubuntu1) ) #118-Ubuntu SMP Thu Dec 17 22:52:10 UTC 2015 >> >> Distributor ID: Ubuntu >> >> Description: Ubuntu 14.04.3 LTS >> >> Release: 14.04 >> >> >> Thanks in advance, >> > -- > ahmet > -- ahmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirill.zhaldybin at oracle.com Wed Jun 22 11:34:08 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Wed, 22 Jun 2016 14:34:08 +0300 Subject: =?UTF-8?Q?Re:_RFR=28S=29:_8132715:_Add_tests_which_check_that_no_al?= =?UTF-8?Q?locations_allowed_in_any_of_humongous_regions=e2=80=8b?= In-Reply-To: <2b93d8cb-70fb-94b1-58c6-18c2f52bae68@oracle.com> References: <57697D25.6080406@oracle.com> <2b93d8cb-70fb-94b1-58c6-18c2f52bae68@oracle.com> Message-ID: <576A77B0.30407@oracle.com> Derek, Thank you for review! Regards, Kirill On 22.06.2016 01:14, Derek White wrote: > On 6/21/16 1:45 PM, Kirill Zhaldybin wrote: >> Dear all, >> >> Could please review this test for 8132715? >> >> The test fills heap with humongous objects with a lot of wasted space, >> then starts to allocate non-humongous objects and checks that no >> allocations happened in humongous regions. >> There are 3 runs of the test: with filled 10%, 50% and 80% of heap. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8132715 >> WebRev: >> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev.01/ >> >> Thank you. >> >> Regards, Kirill > > Looks good. > > - Derek > From thomas.schatzl at oracle.com Wed Jun 22 12:16:10 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 22 Jun 2016 14:16:10 +0200 Subject: RFR(S): 8132715: Add tests which check that no allocations allowed in any of humongous =?UTF-8?Q?regions=E2=80=8B?= In-Reply-To: <2b93d8cb-70fb-94b1-58c6-18c2f52bae68@oracle.com> References: <57697D25.6080406@oracle.com> <2b93d8cb-70fb-94b1-58c6-18c2f52bae68@oracle.com> Message-ID: <1466597770.2725.17.camel@oracle.com> Hi Kirill, On Tue, 2016-06-21 at 18:14 -0400, Derek White wrote: > On 6/21/16 1:45 PM, Kirill Zhaldybin wrote: > > > > Dear all, > > > > Could please review this test for 8132715? > > > > The test fills heap with humongous objects with a lot of wasted > > space,? > > then starts to allocate non-humongous objects and checks that no? > > allocations happened in humongous regions. > > There are 3 runs of the test: with filled 10%, 50% and 80% of heap. > > > > CR: https://bugs.openjdk.java.net/browse/JDK-8132715 > > WebRev:? > > http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev.01/ > > > > Thank you. > > > > Regards, Kirill ? I would kind of prefer if the test took a more systematic approach, i.e. increase the "opportunity" that allocations at the end of humongous objects occur, and increase the kind of allocations that may occur. So the test first allocates one of three different kinds of humongous objects (half a region, "just above a region" and "just above two regions"). Then it allocates random object arrays, trying to make G1 allocate at the end of an existing humongous object (apparently at least). So, while the setup seems fairly okay, I am not sure whether randomizing the initial humongous object sizes makes a lot of difference (it does not to the allocator). Maybe, just maybe having all of these in the test at the same time might make the test more reproducable. It's not a big deal though. My main concern is with the second part, the allocation of the "poison" objects by the Allocator thread. Since they are smaller than a region size, they will always be allocated in young gen first. Which means, that it is very unlikely (since they are fairly short living) that they may be allocated in old gen. So the amount of opportunities when such a bad allocation happens seems too small. Thanks, ? Thomas From dmitry.fazunenko at oracle.com Wed Jun 22 12:33:47 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 22 Jun 2016 15:33:47 +0300 Subject: =?UTF-8?Q?Re:_RFR=28S=29:_8132715:_Add_tests_which_check_that_no_al?= =?UTF-8?Q?locations_allowed_in_any_of_humongous_regions=e2=80=8b?= In-Reply-To: <57697D25.6080406@oracle.com> References: <57697D25.6080406@oracle.com> Message-ID: <4aec4ce7-9597-84ce-c9ca-0812327482b9@oracle.com> Hi Kirill, Overall the test looks good. Some minor comments/suggestions 1) @requires vm.gc == null | vm.gc == G1 --> @requires vm.gc.G1 2) Calendar.getInstance().getTimeInMillis() --> System.currentTimeMillis 3) Would you document parameters args[0] and args[1] You have long duration = Integer.parseInt(args[0]) * 1000L; Right after args.length check, it's good. If you introduce the second parameters in the same way - it would be enough. Adding a short comment would also increase readability. 4) Will it make sense to vary G1 region size as well? 5) Would you consider renaming ALLOCATORS_COUNT --> ALLOC_THREAD_CONUT To include "thread" in the variable name. Thanks, Dima On 21.06.2016 20:45, Kirill Zhaldybin wrote: > Dear all, > > Could please review this test for 8132715? > > The test fills heap with humongous objects with a lot of wasted space, > then starts to allocate non-humongous objects and checks that no > allocations happened in humongous regions. > There are 3 runs of the test: with filled 10%, 50% and 80% of heap. > > CR: https://bugs.openjdk.java.net/browse/JDK-8132715 > WebRev: > http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev.01/ > > Thank you. > > Regards, Kirill From derek.white at oracle.com Wed Jun 22 15:21:04 2016 From: derek.white at oracle.com (Derek White) Date: Wed, 22 Jun 2016 11:21:04 -0400 Subject: [RESUMED] RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: <62101D79-2A20-457E-A8E0-0CB678AB67D7@oracle.com> References: <8c360c59-c4c6-715b-fb01-df04c2b45db4@oracle.com> <25b125dd-5512-9337-22b4-29b90b0547e9@oracle.com> <1466548590.2941.3.camel@oracle.com> <62101D79-2A20-457E-A8E0-0CB678AB67D7@oracle.com> Message-ID: On 6/21/16 10:07 PM, Kim Barrett wrote: >> On Jun 21, 2016, at 6:36 PM, Thomas Schatzl wrote: >> >> Hi, >> >> On Tue, 2016-06-21 at 18:27 -0400, Derek White wrote: >>> Here's a more complete solution to the problem. >>> >>> As Kim mentioned, the new version sets the object size field of a >>> java.lang.Class object before it sets the object's header, so GC can >>> reliably get the size of any object with it's header set. >> just briefly looking over the code (maybe I am overlooking something >> obvious, I am only looking at the webrev) - wouldn't the code need some >> compiler and memory barriers that make sure that this required >> read/write orderings are observed? > I agree with Thomas. I think there needs to be an > OrderAccess::storestore() between the setting of the size and the > setting of the klass. > > And that makes me wonder why > CollectedHeap::post_allocation_setup_array doesn't appear to have > a similar store barrier. It even has the corresponding comment about > how the array length must be set before setting the _klass field so > the object is parsable by concurrent GC. > > Maybe this only causes problems when the object is allocated in the > old gen (perhaps because it is large). Is there some other path for > large arrays, so we don't have a barrier for every array allocation? > I hope I'm missing something... My new code is has basically no performance requirements, so I'm not opposed to adding a barrier, but like Kim asked, how does the similar (and much more frequently called) array_allocate() get away with not using one? - Derek > >>> This fix works by adding a CollectedHeap::class_allocate() method and >>> associated helpers. These are implemented in CollectedHeap.inline.hpp >>> only because they share so much structure and code with >>> CollectedHeap::obj_allocate() that I thought it best to keep them >>> together (even though there is no performance reason to have the new >>> code inlined). >>> >>> Webrev: http://cr.openjdk.java.net/~drwhite/8158946/webrev.02 >>> jprt in progress... >> >> Thanks, >> Thomas > From thomas.schatzl at oracle.com Wed Jun 22 16:10:38 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 22 Jun 2016 18:10:38 +0200 Subject: [RESUMED] RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: <62101D79-2A20-457E-A8E0-0CB678AB67D7@oracle.com> References: <8c360c59-c4c6-715b-fb01-df04c2b45db4@oracle.com> <25b125dd-5512-9337-22b4-29b90b0547e9@oracle.com> <1466548590.2941.3.camel@oracle.com> <62101D79-2A20-457E-A8E0-0CB678AB67D7@oracle.com> Message-ID: <1466611838.2725.30.camel@oracle.com> Hi, On Tue, 2016-06-21 at 22:07 -0400, Kim Barrett wrote: > > > > On Jun 21, 2016, at 6:36 PM, Thomas Schatzl > com> wrote: > > > > Hi, > > > > On Tue, 2016-06-21 at 18:27 -0400, Derek White wrote: > > > > > > Here's a more complete solution to the problem. > > > > > > As Kim mentioned, the new version sets the object size field of > > > a? > > > java.lang.Class object before it sets the object's header, so GC > > > can? > > > reliably get the size of any object with it's header set. > > ? just briefly looking over the code (maybe I am overlooking > > something > > obvious, I am only looking at the webrev) - wouldn't the code need > > some > > compiler and memory barriers that make sure that this required > > read/write orderings are observed? > I agree with Thomas.??I think there needs to be an > OrderAccess::storestore() between the setting of the size and the > setting of the klass. Also the reader thread needs barriers. > And that makes me wonder why > CollectedHeap::post_allocation_setup_array doesn't appear to have > a similar store barrier.??It even has the corresponding comment about > how the array length must be set before setting the _klass field so > the object is parsable by concurrent GC. > > Maybe this only causes problems when the object is allocated in the > old gen (perhaps because it is large).??Is there some other path for > large arrays, so we don't have a barrier for every array allocation? > I hope I'm missing something... I do not know for CMS, but G1's humongous objects do have a storestore barrier at the correct place (and it should have the corresponding at the reader side). These are the only direct old gen allocations G1 ever does. In any case, as soon as CMS uses this method for old gen allocation, it needs to have the necessary barriers (obviously). It seems that in CMS, the threshold to use a direct old gen allocation is pretty high, i.e. object_size > young-gen-capacity, so really really seldom (in GenCollectorPolicy::should_try_older_generation_allocation) (or if the gc locker is active). > > > This fix works by adding a CollectedHeap::class_allocate() method > > > and > > > associated helpers. These are implemented in > > > CollectedHeap.inline.hpp > > > only because they share so much structure and code with? > > > CollectedHeap::obj_allocate() that I thought it best to keep > > > them? > > > together (even though there is no performance reason to have the > > > new? > > > code inlined). > > > > > > Webrev: http://cr.openjdk.java.net/~drwhite/8158946/webrev.02 > > > jprt in progress... Thanks, ? Thomas From jon.masamitsu at oracle.com Wed Jun 22 17:56:13 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 22 Jun 2016 10:56:13 -0700 Subject: Runtime.getRuntime().freeMemory() can report wrong values when collector is CMS? In-Reply-To: References: Message-ID: <576AD13D.4070905@oracle.com> On 06/18/2016 03:21 PM, ahmet m?r??k wrote: > > Hi, > > I am running a test which is trying to log memory info. when > free-heap-percentage is under a certain threshold. But noticed that > when heap is around `-XX:CMSInitiatingOccupancyFraction`, > Runtime.getRuntime().freeMemory() can report wrong values when > compared to memory info from GC logs. It reports as if whole heap is > nearly occupied, but actually there exists lots of free-memory. Issue > is observable for a short-time period. Later it starts to report > expected values. (Also tried my test with G1 defaults and > Runtime.getRuntime().freeMemory() reported as expected) > From the latest log (with PrintGCDetails) is this an example of the freeMemory being wrong but it gets better? runtime.maxMemory=61207M, runtime.totalMemory=61207M, runtime.freeMemory=319M, runtime.usedMemory=60887M, runTime.availableMemory=319M, freeHeapPercentage=0.52 99.641: [CMS-concurrent-reset: 0.122/0.122 secs] [Times: user=0.67 sys=0.01, real=0.12 secs] 99.896: [GC99.896: [ParNew: 2146944K->238528K(2146944K), 0.5846780 secs] 51929136K->51910762K(62676032K), 0.5847860 secs] [Times: user=5.33 sys=0.92, real=0.58 secs] 100.484: [GC [1 CMS-initial-mark: 51672234K(60529088K)] 51925538K(62676032K), 0.0461750 secs] [Times: user=0.05 sys=0.00, real=0.05 secs] 100.530: [CMS-concurrent-mark-start] 102.959: [GC102.959: [ParNew: 2146944K->238528K(2146944K), 0.5868320 secs] 53819178K->53798644K(62676032K), 0.5869410 secs] [Times: user=6.25 sys=0.88, real=0.59 secs] runtime.maxMemory=61207M,runtime.totalMemory=61207M, runtime.freeMemory=7344M, runtime.usedMemory=53862M, runTime.availableMemory=7344M, freeHeapPercentage=12.00 Jon > Issue is easily visible on large heaps. > > Is my assumption correct? Can Runtime.getRuntime().freeMemory() report > wrong free-memory info for a while? Or how can we explain this situation? > > Here is my test and how i run it from command line: > > [PROBLEMATIC RUN WITH CMS]--> java -verbose:gc -Xms60G -Xmx60G > -XX:CMSInitiatingOccupancyFraction=2 -XX:+UseConcMarkSweepGC > -XX:+UseParNewGC -cp target/free-memory-issue-1.0-SNAPSHOT.jar FreeMemory > [OK RUN WITH G1]--> java -verbose:gc -Xms60G -Xmx60G -XX:+UseG1GC -cp target/free-memory-issue-1.0-SNAPSHOT.jar FreeMemory > public class FreeMemory { > > static final int MB = 1024 * 1024; > static final String MESSAGE = "runtime.maxMemory=%d%s, runtime.totalMemory=%d%s, runtime.freeMemory=%d%s," + > " runtime.usedMemory=%d%s, runTime.availableMemory=%d%s, freeHeapPercentage=%.2f"; > > public static void main(String[] args) throws InterruptedException { > final ConcurrentHashMap map = new ConcurrentHashMap(); > > Runtime runtime = Runtime.getRuntime(); > int availableProcessors = runtime.availableProcessors(); > int threadCount = availableProcessors * 4; > > ArrayList threads = new ArrayList(); > > for (int i = 0; i < threadCount; i++) { > threads.add(new Thread(new Runnable() { > > @Override > public void run() { > Random random = new Random(); > while (true) { > byte[] value = new byte[1024]; > random.nextBytes(value); > > map.put(random.nextInt(), value); > > if (hasReachedMinFreeHeapPercentage(12)) { > break; > } > } > } > })); > } > > for (Thread thread : threads) { > thread.start(); > } > > for (Thread thread : threads) { > thread.join(); > } > > out.print("\n\n\nEnd of run...now we expect to see actual used-memory value\n"); > > while (true) { > printCurrentMemoryInfo(); > parkNanos(SECONDS.toNanos(5)); > } > } > > static boolean hasReachedMinFreeHeapPercentage(int minFreeHeapPercentage) { > Runtime runtime = Runtime.getRuntime(); > > long maxMemory = runtime.maxMemory(); > long totalMemory = runtime.totalMemory(); > long freeMemory = runtime.freeMemory(); > long availableMemory = freeMemory + (maxMemory - totalMemory); > double freeHeapPercentage = 100D * availableMemory / maxMemory; > > if (freeHeapPercentage < minFreeHeapPercentage) { > String unit = "M"; > out.println(format(MESSAGE, toMB(maxMemory), unit, toMB(totalMemory), unit, toMB(freeMemory), unit, > toMB(totalMemory - freeMemory), unit, toMB(availableMemory), unit, freeHeapPercentage)); > return true; > } > > return false; > } > > static void printCurrentMemoryInfo() { > Runtime runtime = Runtime.getRuntime(); > > long maxMemory = runtime.maxMemory(); > long totalMemory = runtime.totalMemory(); > long freeMemory = runtime.freeMemory(); > long availableMemory = freeMemory + (maxMemory - totalMemory); > double freeHeapPercentage = 100D * availableMemory / maxMemory; > > String unit = "M"; > out.println(format(MESSAGE, toMB(maxMemory), unit, toMB(totalMemory), unit, toMB(freeMemory), unit, > toMB(totalMemory - freeMemory), unit, toMB(availableMemory), unit, freeHeapPercentage)); > } > > static int toMB(long bytes) { > return (int) Math.rint(bytes / MB); > } > } > > Java version: > > openjdk version "1.8.0_91" > > OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14) > > OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode) > > > OS info: > > Linux version 3.13.0-74-generic (buildd at lcy01-07) (gcc version 4.8.2 > (Ubuntu 4.8.2-19ubuntu1) ) #118-Ubuntu SMP Thu Dec 17 22:52:10 UTC 2015 > > Distributor ID: Ubuntu > > Description: Ubuntu 14.04.3 LTS > > Release: 14.04 > > > Thanks in advance, > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek.white at oracle.com Wed Jun 22 18:34:48 2016 From: derek.white at oracle.com (Derek White) Date: Wed, 22 Jun 2016 14:34:48 -0400 Subject: [RESUMED] RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: <1466611838.2725.30.camel@oracle.com> References: <8c360c59-c4c6-715b-fb01-df04c2b45db4@oracle.com> <25b125dd-5512-9337-22b4-29b90b0547e9@oracle.com> <1466548590.2941.3.camel@oracle.com> <62101D79-2A20-457E-A8E0-0CB678AB67D7@oracle.com> <1466611838.2725.30.camel@oracle.com> Message-ID: <7b0fe659-2a5b-0494-49b5-be13f375f20f@oracle.com> Hi Thomas, Thanks for the comments! Questions below... On 6/22/16 12:10 PM, Thomas Schatzl wrote: > Hi, > > On Tue, 2016-06-21 at 22:07 -0400, Kim Barrett wrote: >>> On Jun 21, 2016, at 6:36 PM, Thomas Schatzl >> com> wrote: >>> >>> Hi, >>> >>> On Tue, 2016-06-21 at 18:27 -0400, Derek White wrote: >>>> Here's a more complete solution to the problem. >>>> >>>> As Kim mentioned, the new version sets the object size field of >>>> a >>>> java.lang.Class object before it sets the object's header, so GC >>>> can >>>> reliably get the size of any object with it's header set. >>> just briefly looking over the code (maybe I am overlooking >>> something >>> obvious, I am only looking at the webrev) - wouldn't the code need >>> some >>> compiler and memory barriers that make sure that this required >>> read/write orderings are observed? >> I agree with Thomas. I think there needs to be an >> OrderAccess::storestore() between the setting of the size and the >> setting of the klass. > Also the reader thread needs barriers. > >> And that makes me wonder why >> CollectedHeap::post_allocation_setup_array doesn't appear to have >> a similar store barrier. It even has the corresponding comment about >> how the array length must be set before setting the _klass field so >> the object is parsable by concurrent GC. >> >> Maybe this only causes problems when the object is allocated in the >> old gen (perhaps because it is large). Is there some other path for >> large arrays, so we don't have a barrier for every array allocation? >> I hope I'm missing something... > I do not know for CMS, but G1's humongous objects do have a storestore > barrier at the correct place (and it should have the corresponding at > the reader side). These are the only direct old gen allocations G1 ever > does. Where is this barrier used? I thought the header setting was done up at CollectedHeap::array_allocate(), outside of G1 code? > In any case, as soon as CMS uses this method for old gen allocation, it > needs to have the necessary barriers (obviously). I think for CMS, reading and writing are protected by the cms_space->freelistLock(). For example, the CMS sweeper holds the freelistLock. The Java thread trying to allocate requests, then gets the freelistLock(), and the sweeper re-aquires the freelistLock() before resuming the sweep (and reading). So I'd think that there are plenty of fences for CMS? - Derek > > It seems that in CMS, the threshold to use a direct old gen allocation > is pretty high, i.e. object_size > young-gen-capacity, so really really > seldom (in GenCollectorPolicy::should_try_older_generation_allocation) > (or if the gc locker is active). > >>>> This fix works by adding a CollectedHeap::class_allocate() method >>>> and >>>> associated helpers. These are implemented in >>>> CollectedHeap.inline.hpp >>>> only because they share so much structure and code with >>>> CollectedHeap::obj_allocate() that I thought it best to keep >>>> them >>>> together (even though there is no performance reason to have the >>>> new >>>> code inlined). >>>> >>>> Webrev: http://cr.openjdk.java.net/~drwhite/8158946/webrev.02 >>>> jprt in progress... > Thanks, > Thomas > From thomas.schatzl at oracle.com Wed Jun 22 19:01:03 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 22 Jun 2016 21:01:03 +0200 Subject: [RESUMED] RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: <7b0fe659-2a5b-0494-49b5-be13f375f20f@oracle.com> References: <8c360c59-c4c6-715b-fb01-df04c2b45db4@oracle.com> <25b125dd-5512-9337-22b4-29b90b0547e9@oracle.com> <1466548590.2941.3.camel@oracle.com> <62101D79-2A20-457E-A8E0-0CB678AB67D7@oracle.com> <1466611838.2725.30.camel@oracle.com> <7b0fe659-2a5b-0494-49b5-be13f375f20f@oracle.com> Message-ID: <1466622063.2387.4.camel@oracle.com> Hi, On Wed, 2016-06-22 at 14:34 -0400, Derek White wrote: > Hi Thomas, > > Thanks for the comments! Questions below... > > [...] > Maybe this only causes problems when the object is allocated in > > > the > > > old gen (perhaps because it is large).??Is there some other path > > > for > > > large arrays, so we don't have a barrier for every array > > > allocation? > > > I hope I'm missing something... > > I do not know for CMS, but G1's humongous objects do have a > > storestore barrier at the correct place (and it should have the > > corresponding at the reader side). These are the only direct old > > gen allocations G1 ever does. > > Where is this barrier used? I thought the header setting was done up > at CollectedHeap::array_allocate(), outside of G1 code? CollectedHeap::array_allocate() is not used for humongous objects, but G1CollectedHeap::humongous_obj_allocate(). > > In any case, as soon as CMS uses this method for old gen > > allocation, it needs to have the necessary barriers (obviously). > I think for CMS, reading and writing are protected by the? > cms_space->freelistLock(). For example, > the CMS sweeper holds the freelistLock. The Java thread trying to? > allocate requests, then gets the freelistLock(), and the sweeper? > re-aquires the freelistLock() before resuming the sweep (and > reading). > > So I'd think that there are plenty of fences for CMS? I would imagine that the exact ordering of the reads of these variables is important, not necessarily that before or after there are fences. Additional fences may only decrease the occurrences of this issue. Of course, if it is the case that both threads synchronize on the free list lock for allocation and reading respectively in the old gen, the code is fine. Thanks, ? Thomas From derek.white at oracle.com Wed Jun 22 19:33:24 2016 From: derek.white at oracle.com (Derek White) Date: Wed, 22 Jun 2016 15:33:24 -0400 Subject: [RESUMED] RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: <1466622063.2387.4.camel@oracle.com> References: <8c360c59-c4c6-715b-fb01-df04c2b45db4@oracle.com> <25b125dd-5512-9337-22b4-29b90b0547e9@oracle.com> <1466548590.2941.3.camel@oracle.com> <62101D79-2A20-457E-A8E0-0CB678AB67D7@oracle.com> <1466611838.2725.30.camel@oracle.com> <7b0fe659-2a5b-0494-49b5-be13f375f20f@oracle.com> <1466622063.2387.4.camel@oracle.com> Message-ID: Hi Thomas, On 6/22/16 3:01 PM, Thomas Schatzl wrote: > Hi, > > On Wed, 2016-06-22 at 14:34 -0400, Derek White wrote: >> Hi Thomas, >> >> Thanks for the comments! Questions below... >> >> > [...] >> Maybe this only causes problems when the object is allocated in >>>> the >>>> old gen (perhaps because it is large). Is there some other path >>>> for >>>> large arrays, so we don't have a barrier for every array >>>> allocation? >>>> I hope I'm missing something... >>> I do not know for CMS, but G1's humongous objects do have a >>> storestore barrier at the correct place (and it should have the >>> corresponding at the reader side). These are the only direct old >>> gen allocations G1 ever does. >> Where is this barrier used? I thought the header setting was done up >> at CollectedHeap::array_allocate(), outside of G1 code? > CollectedHeap::array_allocate() is not used for humongous objects, but > G1CollectedHeap::humongous_obj_allocate(). That can't be right - G1CollectedHeap::humongous_obj_allocate() doesn't set the object header (it doesn't even know the Klass). It /clears/ the object header, and does the storestore before updating the heap region bookkeeping that makes the new object scannable. At that point the new object is a valid uninitialized object. G1CollectedHeap::humongous_obj_allocate() is called by Universe::heap()->mem_allocate() is called by CollectedHeap::common_mem_allocate_noinit() is called by various CollectedHeap::XXX_allocate() But what Kim is concerned about is the ordering of setting the object header (lock and klass fields) and setting either the array length or the "oop_size" field of a java.lang.Class instance. We (GC) never want to see an object with a non-zero klass in the header and an unset array length or oop_size. These fields are set up in CollectedHeap::post_allocation_install_obj_klass() (and neighbors), but there is no ordering enforced between the stores. I think we're primarily worried by concurrent GC threads (G1 or CMS) seeing these new objects as they are being created. So we aren't concerned about young gen objects. There's some evidence that CMS is synchronizing access between allocators and concurrent scanners (see below), but I don't know if there are similar issues with G1. > >>> In any case, as soon as CMS uses this method for old gen >>> allocation, it needs to have the necessary barriers (obviously). >> I think for CMS, reading and writing are protected by the >> cms_space->freelistLock(). For example, >> the CMS sweeper holds the freelistLock. The Java thread trying to >> allocate requests, then gets the freelistLock(), and the sweeper >> re-aquires the freelistLock() before resuming the sweep (and >> reading). >> >> So I'd think that there are plenty of fences for CMS? > I would imagine that the exact ordering of the reads of these variables > is important, not necessarily that before or after there are fences. > > Additional fences may only decrease the occurrences of this issue. > > Of course, if it is the case that both threads synchronize on the free > list lock for allocation and reading respectively in the old gen, the > code is fine. I think this is the case. Certainly for concurrent sweeping. > > Thanks, > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Wed Jun 22 20:38:12 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 22 Jun 2016 22:38:12 +0200 Subject: [RESUMED] RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: References: <8c360c59-c4c6-715b-fb01-df04c2b45db4@oracle.com> <25b125dd-5512-9337-22b4-29b90b0547e9@oracle.com> <1466548590.2941.3.camel@oracle.com> <62101D79-2A20-457E-A8E0-0CB678AB67D7@oracle.com> <1466611838.2725.30.camel@oracle.com> <7b0fe659-2a5b-0494-49b5-be13f375f20f@oracle.com> <1466622063.2387.4.camel@oracle.com> Message-ID: <1466627892.2778.19.camel@oracle.com> Hi, On Wed, 2016-06-22 at 15:33 -0400, Derek White wrote: > Hi Thomas, > > On 6/22/16 3:01 PM, Thomas Schatzl wrote: > > Hi, > > [...] > > CollectedHeap::array_allocate() is not used for humongous objects, > > but > > G1CollectedHeap::humongous_obj_allocate(). > ? > That can't be right - G1CollectedHeap::humongous_obj_allocate() > doesn't set the object header (it doesn't even know the Klass). It > clears the object header, and does the storestore before updating the > heap region bookkeeping that makes the new object scannable. At that > point the new object is a valid uninitialized object. > > G1CollectedHeap::humongous_obj_allocate()????? is called by > ? Universe::heap()->mem_allocate()???????????? is called by? > ?? CollectedHeap::common_mem_allocate_noinit() is called by various > ???? CollectedHeap::XXX_allocate() > > But what Kim is concerned about is the ordering of setting the object > header (lock and klass fields) and setting either the array length or > the "oop_size" field of a java.lang.Class instance. We (GC) never > want to see an object with a non-zero klass in the header and an > unset array length or oop_size. These fields are set up in > CollectedHeap::post_allocation_install_obj_klass() (and neighbors), > but there is no ordering enforced between the stores. Bug? I mean, if the comment already says it needs this ordering, and there is no explicit barrier, it's a bug in any case. At least on non- TSO platforms the cpu will reorder the stores, and on others there is still the issue with potential compiler reordering.? Guess we were kind of lucky? Or one of these spurious crash reports we have is caused by this? > I think we're primarily worried by concurrent GC threads (G1 or CMS) > seeing these new objects as they are being created. So we aren't > concerned about young gen objects. There's some evidence that CMS is > synchronizing access between allocators and concurrent scanners (see > below), but I don't know if there are similar issues with G1. There unfortunately seem to be quite a few potentially concurrent callers (refinement - scanning the card, marking - advancing the finger) of?oopDesc::size_given_klass() and I can't convince myself we have an address dependency on klass in that method for array size calculation (which would imply a loadload barrier on the platforms needed) - other objects seem fine, as they read a variable based off the klass pointer. (And on TSO systems again it did not matter except for the potential compiler reordering, which seems almost impossible here) But please check that yourselves too. Thanks, ? Thomas From jon.masamitsu at oracle.com Thu Jun 23 20:32:34 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 23 Jun 2016 13:32:34 -0700 Subject: Request for Review (xs) - 8159073: Error handling incomplete when creating GC threads lazily In-Reply-To: References: <1208fcbd-ff75-cbce-1692-225280eeab52@oracle.com> <20160609083312.GI26799@ehelin.jrpg.bea.com> <722fc666-6a9a-a75b-9df6-b8b7c6298728@oracle.com> Message-ID: <7358778e-01ae-4e32-d050-f0d9ceb11c18@oracle.com> The change has grown some (small now, not extra small). Added logging for the case where thread creation fails. http://cr.openjdk.java.net/~jmasa/8159073/webrev_delta_00_01a/ Added fixes for failed thread creation. http://cr.openjdk.java.net/~jmasa/8159073/webrev_delta_00_01b/ Complete fix with test added. http://cr.openjdk.java.net/~jmasa/8159073/webrev.01/ Tested with gc_test_suite with new diagnostic flag on and off. Thanks. Jon On 6/21/2016 1:52 PM, Jon Masamitsu wrote: > > > On 6/21/2016 12:22 PM, Derek White wrote: >> On 6/9/16 4:33 AM, Erik Helin wrote: >>> On 2016-06-08, Jon Masamitsu wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8159073 >>>> >>>> The error handling in add_workers() was not treating the >>>> non-initializing >>>> case correctly. If in the non-initializing case, it is OK to fail the >>>> creation >>>> of additional threads but the number of created threads should not be >>>> incremented nor non-existent thread started. >>>> >>>> http://cr.openjdk.java.net/~jmasa/8159073/webrev.00/ >>> Should we add some logging in case the code fail to create a worker >>> thread (in the non initializing case)? >>> >>> Thanks, >>> Erik >>> >>>> Tested with gc_test_suite with UseDynamicGCThreads turned on. >>>> >>>> Thanks. >>>> >>>> Jon >> >> >> Hi Jon, >> >> Looks good, but I agree with Eric that logging would be nice. > > Derek, > > Thanks for the review. Unfortunately there is more code than I've > fixed that need to tolerate thread creation failure so I'm still working > on a complete fix. > > Jon >> >> - Derek >> > From michail.chernov at oracle.com Fri Jun 24 15:39:04 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Fri, 24 Jun 2016 18:39:04 +0300 Subject: RFR: 8157265: gc/stress/TestStressG1Humongous.java fails with exit code 1 Message-ID: <576D5418.30209@oracle.com> Hi, Could I have a reviews for this small change: https://bugs.openjdk.java.net/browse/JDK-8157265 http://cr.openjdk.java.net/~mchernov/8157265/webrev.00/ This stress test failed once with reason "Could not reserve enough space for 1048576KB object heap ". This change should allow to exclude that test from run on hosts without enough memory. Tested locally and via RBT. Thanks, Michail -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.fazunenko at oracle.com Fri Jun 24 16:13:51 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 24 Jun 2016 19:13:51 +0300 Subject: RFR: 8157265: gc/stress/TestStressG1Humongous.java fails with exit code 1 In-Reply-To: <576D5418.30209@oracle.com> References: <576D5418.30209@oracle.com> Message-ID: <9b628f2b-960d-5451-ad90-aefd995eecc9@oracle.com> Hi Michail, The change you suggested: 31 * @requires os.maxMemory > 1G will unlikely fix the problem. Nowadays, it's very hard to find a machine with memory under 1G. And the problem reported in the CR happened on a machine with 100+G of memory. Thanks, Dima On 24.06.2016 18:39, Michail Chernov wrote: > Hi, > > Could I have a reviews for this small change: > > https://bugs.openjdk.java.net/browse/JDK-8157265 > http://cr.openjdk.java.net/~mchernov/8157265/webrev.00/ > > This stress test failed once with reason "Could not reserve enough > space for 1048576KB object heap ". This change should allow to exclude > that test from run on hosts without enough memory. > > Tested locally and via RBT. > > Thanks, > Michail > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirill.zhaldybin at oracle.com Fri Jun 24 16:24:32 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Fri, 24 Jun 2016 19:24:32 +0300 Subject: =?UTF-8?Q?Re:_RFR=28S=29:_8132715:_Add_tests_which_check_that_no_al?= =?UTF-8?Q?locations_allowed_in_any_of_humongous_regions=e2=80=8b?= In-Reply-To: <1466597770.2725.17.camel@oracle.com> References: <57697D25.6080406@oracle.com> <2b93d8cb-70fb-94b1-58c6-18c2f52bae68@oracle.com> <1466597770.2725.17.camel@oracle.com> Message-ID: <576D5EC0.3080803@oracle.com> Thomas, Thank you for reviewing the fix. Could you please read comments inline? Regards, Kirill On 22.06.2016 15:16, Thomas Schatzl wrote: > Hi Kirill, > > On Tue, 2016-06-21 at 18:14 -0400, Derek White wrote: >> On 6/21/16 1:45 PM, Kirill Zhaldybin wrote: >>> >>> Dear all, >>> >>> Could please review this test for 8132715? >>> >>> The test fills heap with humongous objects with a lot of wasted >>> space, >>> then starts to allocate non-humongous objects and checks that no >>> allocations happened in humongous regions. >>> There are 3 runs of the test: with filled 10%, 50% and 80% of heap. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8132715 >>> WebRev: >>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev.01/ >>> >>> Thank you. >>> >>> Regards, Kirill > > I would kind of prefer if the test took a more systematic approach, > i.e. increase the "opportunity" that allocations at the end of > humongous objects occur, and increase the kind of allocations that may > occur. > > So the test first allocates one of three different kinds of humongous > objects (half a region, "just above a region" and "just above two > regions"). > > Then it allocates random object arrays, trying to make G1 allocate at > the end of an existing humongous object (apparently at least). > > So, while the setup seems fairly okay, I am not sure whether > randomizing the initial humongous object sizes makes a lot of > difference (it does not to the allocator). Maybe, just maybe having all > of these in the test at the same time might make the test more > reproducable. It's not a big deal though. The test uses reproducible random from testlibrary, so initial setup could be reproduced if needed. > > My main concern is with the second part, the allocation of the "poison" > objects by the Allocator thread. > Since they are smaller than a region size, they will always be > allocated in young gen first. Which means, that it is very unlikely > (since they are fairly short living) that they may be allocated in old > gen. > > So the amount of opportunities when such a bad allocation happens seems > too small. I rewrote test so now it keeps some objects alive and calls Full GC often to promote them into old gen. I also set tenure threshold to 0 to speed up promotion. I checked (I had some debug output now deleted) that we actually had non-humongous objects in old gen during the testing. Here are a new WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev.02/ I also addressed some Dmitry's remarks. > > Thanks, > Thomas > From kirill.zhaldybin at oracle.com Fri Jun 24 16:35:59 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Fri, 24 Jun 2016 19:35:59 +0300 Subject: =?UTF-8?Q?Re:_RFR=28S=29:_8132715:_Add_tests_which_check_that_no_al?= =?UTF-8?Q?locations_allowed_in_any_of_humongous_regions=e2=80=8b?= In-Reply-To: <4aec4ce7-9597-84ce-c9ca-0812327482b9@oracle.com> References: <57697D25.6080406@oracle.com> <4aec4ce7-9597-84ce-c9ca-0812327482b9@oracle.com> Message-ID: <576D616F.6090703@oracle.com> Dmitry, Thank you for reviewing the fix. Here are a new WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev.03/ I rewrote the test to address Thomas comments. I also addressed your remarks - see below. On 22.06.2016 15:33, Dmitry Fazunenko wrote: > Hi Kirill, > > Overall the test looks good. > Some minor comments/suggestions > > 1) > @requires vm.gc == null | vm.gc == G1 > --> > @requires vm.gc.G1 fixed > > 2) > Calendar.getInstance().getTimeInMillis() > --> > System.currentTimeMillis fixed > > 3) Would you document parameters args[0] and args[1] > You have > > long duration = Integer.parseInt(args[0]) * 1000L; > > Right after args.length check, it's good. > If you introduce the second parameters in the same way - it would be > enough. > Adding a short comment would also increase readability. fixed > > 4) Will it make sense to vary G1 region size as well? Well, I think that smallest region size could increase chance of wrong allocation. > > 5) Would you consider renaming > > ALLOCATORS_COUNT > --> > ALLOC_THREAD_CONUT > > To include "thread" in the variable name. fixed > > Thanks, > Dima Thank you. Regards, Kirill > > On 21.06.2016 20:45, Kirill Zhaldybin wrote: >> Dear all, >> >> Could please review this test for 8132715? >> >> The test fills heap with humongous objects with a lot of wasted space, >> then starts to allocate non-humongous objects and checks that no >> allocations happened in humongous regions. >> There are 3 runs of the test: with filled 10%, 50% and 80% of heap. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8132715 >> WebRev: >> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev.01/ >> >> Thank you. >> >> Regards, Kirill > From dmitry.fazunenko at oracle.com Fri Jun 24 16:38:08 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 24 Jun 2016 19:38:08 +0300 Subject: =?UTF-8?Q?Re:_RFR=28S=29:_8132715:_Add_tests_which_check_that_no_al?= =?UTF-8?Q?locations_allowed_in_any_of_humongous_regions=e2=80=8b?= In-Reply-To: <576D616F.6090703@oracle.com> References: <57697D25.6080406@oracle.com> <4aec4ce7-9597-84ce-c9ca-0812327482b9@oracle.com> <576D616F.6090703@oracle.com> Message-ID: <384ab088-9dea-1435-3673-be4481370d32@oracle.com> Hi Kirill, new version looks good to me. Thank you for addressing my concerns. -- Dima On 24.06.2016 19:35, Kirill Zhaldybin wrote: > Dmitry, > > Thank you for reviewing the fix. > > Here are a new WebRev: > http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev.03/ > > I rewrote the test to address Thomas comments. > > I also addressed your remarks - see below. > > On 22.06.2016 15:33, Dmitry Fazunenko wrote: >> Hi Kirill, >> >> Overall the test looks good. >> Some minor comments/suggestions >> >> 1) >> @requires vm.gc == null | vm.gc == G1 >> --> >> @requires vm.gc.G1 > fixed >> >> 2) >> Calendar.getInstance().getTimeInMillis() >> --> >> System.currentTimeMillis > fixed >> >> 3) Would you document parameters args[0] and args[1] >> You have >> >> long duration = Integer.parseInt(args[0]) * 1000L; >> >> Right after args.length check, it's good. >> If you introduce the second parameters in the same way - it would be >> enough. >> Adding a short comment would also increase readability. > fixed >> >> 4) Will it make sense to vary G1 region size as well? > Well, I think that smallest region size could increase chance of wrong > allocation. >> >> 5) Would you consider renaming >> >> ALLOCATORS_COUNT >> --> >> ALLOC_THREAD_CONUT >> >> To include "thread" in the variable name. > fixed >> >> Thanks, >> Dima > > Thank you. > > Regards, Kirill >> >> On 21.06.2016 20:45, Kirill Zhaldybin wrote: >>> Dear all, >>> >>> Could please review this test for 8132715? >>> >>> The test fills heap with humongous objects with a lot of wasted space, >>> then starts to allocate non-humongous objects and checks that no >>> allocations happened in humongous regions. >>> There are 3 runs of the test: with filled 10%, 50% and 80% of heap. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8132715 >>> WebRev: >>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev.01/ >>> >>> Thank you. >>> >>> Regards, Kirill >> > From kirill.zhaldybin at oracle.com Fri Jun 24 16:47:18 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Fri, 24 Jun 2016 19:47:18 +0300 Subject: =?UTF-8?Q?Re:_RFR=28S=29:_8132715:_Add_tests_which_check_that_no_al?= =?UTF-8?Q?locations_allowed_in_any_of_humongous_regions=e2=80=8b?= In-Reply-To: <384ab088-9dea-1435-3673-be4481370d32@oracle.com> References: <57697D25.6080406@oracle.com> <4aec4ce7-9597-84ce-c9ca-0812327482b9@oracle.com> <576D616F.6090703@oracle.com> <384ab088-9dea-1435-3673-be4481370d32@oracle.com> Message-ID: <576D6416.1020309@oracle.com> Dmitry, Thank you for review! Regards, Kirill On 24.06.2016 19:38, Dmitry Fazunenko wrote: > Hi Kirill, > > new version looks good to me. > Thank you for addressing my concerns. > > -- Dima > > On 24.06.2016 19:35, Kirill Zhaldybin wrote: >> Dmitry, >> >> Thank you for reviewing the fix. >> >> Here are a new WebRev: >> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev.03/ >> >> I rewrote the test to address Thomas comments. >> >> I also addressed your remarks - see below. >> >> On 22.06.2016 15:33, Dmitry Fazunenko wrote: >>> Hi Kirill, >>> >>> Overall the test looks good. >>> Some minor comments/suggestions >>> >>> 1) >>> @requires vm.gc == null | vm.gc == G1 >>> --> >>> @requires vm.gc.G1 >> fixed >>> >>> 2) >>> Calendar.getInstance().getTimeInMillis() >>> --> >>> System.currentTimeMillis >> fixed >>> >>> 3) Would you document parameters args[0] and args[1] >>> You have >>> >>> long duration = Integer.parseInt(args[0]) * 1000L; >>> >>> Right after args.length check, it's good. >>> If you introduce the second parameters in the same way - it would be >>> enough. >>> Adding a short comment would also increase readability. >> fixed >>> >>> 4) Will it make sense to vary G1 region size as well? >> Well, I think that smallest region size could increase chance of wrong >> allocation. >>> >>> 5) Would you consider renaming >>> >>> ALLOCATORS_COUNT >>> --> >>> ALLOC_THREAD_CONUT >>> >>> To include "thread" in the variable name. >> fixed >>> >>> Thanks, >>> Dima >> >> Thank you. >> >> Regards, Kirill >>> >>> On 21.06.2016 20:45, Kirill Zhaldybin wrote: >>>> Dear all, >>>> >>>> Could please review this test for 8132715? >>>> >>>> The test fills heap with humongous objects with a lot of wasted space, >>>> then starts to allocate non-humongous objects and checks that no >>>> allocations happened in humongous regions. >>>> There are 3 runs of the test: with filled 10%, 50% and 80% of heap. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8132715 >>>> WebRev: >>>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev.01/ >>>> >>>> Thank you. >>>> >>>> Regards, Kirill >>> >> > From michail.chernov at oracle.com Fri Jun 24 16:41:38 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Fri, 24 Jun 2016 19:41:38 +0300 Subject: RFR: 8157265: gc/stress/TestStressG1Humongous.java fails with exit code 1 In-Reply-To: <9b628f2b-960d-5451-ad90-aefd995eecc9@oracle.com> References: <576D5418.30209@oracle.com> <9b628f2b-960d-5451-ad90-aefd995eecc9@oracle.com> Message-ID: <576D62C2.1010905@oracle.com> Hi Dima, Thanks for your response, seems that this is intermittent failure which cannot be reproduced. I will close the bug. Misha On 06/24/2016 07:13 PM, Dmitry Fazunenko wrote: > Hi Michail, > > The change you suggested: > 31 * @requires os.maxMemory > 1G > will unlikely fix the problem. Nowadays, it's very hard to find a > machine with memory under 1G. > And the problem reported in the CR happened on a machine with 100+G of > memory. > > Thanks, > Dima > > > > > On 24.06.2016 18:39, Michail Chernov wrote: >> Hi, >> >> Could I have a reviews for this small change: >> >> https://bugs.openjdk.java.net/browse/JDK-8157265 >> http://cr.openjdk.java.net/~mchernov/8157265/webrev.00/ >> >> This stress test failed once with reason "Could not reserve enough >> space for 1048576KB object heap ". This change should allow to >> exclude that test from run on hosts without enough memory. >> >> Tested locally and via RBT. >> >> Thanks, >> Michail >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Fri Jun 24 17:19:19 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 24 Jun 2016 10:19:19 -0700 Subject: Request for Review (xs) - 8024945: Remove check on minimum size of MetaspaceSiz In-Reply-To: <575F370F.2020500@oracle.com> References: <575F2C00.1020906@oracle.com> <575F370F.2020500@oracle.com> Message-ID: <002e4e70-b4b2-4ff2-fcfb-a705202e57f1@oracle.com> Thanks Kim and Thomas for the previous reviews. Sorry for delay with the latest updates. The only change from the first round is update of the @bug (as Kim indicated) and the copyright update. The updated complete webrev is here http://cr.openjdk.java.net/~jmasa/8024945/webrev.01/ The delta is --- a/test/gc/metaspace/TestMetaspaceInitialization.java +++ b/test/gc/metaspace/TestMetaspaceInitialization.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -24,7 +24,7 @@ import java.util.ArrayList; /* @test TestMetaspaceInitialization - * @bug 8042933 + * @bug 8024945 * @summary Tests to initialize metaspace with a very low MetaspaceSize Thanks. Jon On 6/13/2016 3:43 PM, Jon Masamitsu wrote: > > > On 06/13/2016 03:29 PM, Kim Barrett wrote: >>> On Jun 13, 2016, at 5:56 PM, Jon Masamitsu >>> wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8024945 >>> >>> Previous to this change the smallest MetaspaceSize value allowed >>> was 256k. There is not reason for the restriction so this change >>> removes it. A very small MetaspaceSize (even 0) does not cause >>> a problem because during initialization a GC is not triggered unless >>> the Metaspace needed grows beyond MaxMetaspaceSize. >>> >>> http://cr.openjdk.java.net/~jmasa/8024945/webrev.00/ >>> >>> Tested with -XX:MetaspaceSize=0. General testing with gc_test_suite. >> Looks good. > > Thanks. > >> ------------------------------------------------------------------------------ >> >> test/gc/metaspace/TestMetaspaceInitialization.java >> 27 * @bug 8042933 >> >> Should this be updated to also mention 8024945? > > Ah, yes. > > Fixed. > > Jon >> >> ------------------------------------------------------------------------------ >> >> > From jon.masamitsu at oracle.com Fri Jun 24 17:54:46 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 24 Jun 2016 10:54:46 -0700 Subject: RFR: 8157265: gc/stress/TestStressG1Humongous.java fails with exit code 1 In-Reply-To: <576D5418.30209@oracle.com> References: <576D5418.30209@oracle.com> Message-ID: <60577d41-c58a-a964-e7c8-8207a7f5246c@oracle.com> On 6/24/2016 8:39 AM, Michail Chernov wrote: > Hi, > > Could I have a reviews for this small change: > > https://bugs.openjdk.java.net/browse/JDK-8157265 > http://cr.openjdk.java.net/~mchernov/8157265/webrev.00/ > > This stress test failed once with reason "Could not reserve enough > space for 1048576KB object heap ". This change should allow to exclude > that test from run on hosts without enough memory. Michail, Is requiring the platform to have > 1G of memory enough memory? The JVM with 1G heap will use more than 1G of memory in total. Jon > > Tested locally and via RBT. > > Thanks, > Michail > From jon.masamitsu at oracle.com Fri Jun 24 17:57:05 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 24 Jun 2016 10:57:05 -0700 Subject: RFR: 8157265: gc/stress/TestStressG1Humongous.java fails with exit code 1 In-Reply-To: <60577d41-c58a-a964-e7c8-8207a7f5246c@oracle.com> References: <576D5418.30209@oracle.com> <60577d41-c58a-a964-e7c8-8207a7f5246c@oracle.com> Message-ID: <91dfd300-db65-f781-e42b-f5e55fae74c7@oracle.com> Michail, I saw the previous mail that you are closing this CR. Jon On 6/24/2016 10:54 AM, Jon Masamitsu wrote: > > > On 6/24/2016 8:39 AM, Michail Chernov wrote: >> Hi, >> >> Could I have a reviews for this small change: >> >> https://bugs.openjdk.java.net/browse/JDK-8157265 >> http://cr.openjdk.java.net/~mchernov/8157265/webrev.00/ >> >> This stress test failed once with reason "Could not reserve enough >> space for 1048576KB object heap ". This change should allow to >> exclude that test from run on hosts without enough memory. > > Michail, > > Is requiring the platform to have > 1G of memory enough memory? The JVM > with 1G heap will use more than 1G of memory in total. > > Jon > >> >> Tested locally and via RBT. >> >> Thanks, >> Michail >> > From jon.masamitsu at oracle.com Sat Jun 25 02:33:21 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 24 Jun 2016 19:33:21 -0700 Subject: Request for Review (s) - 8157240: GC task trace logging is incomprehensible Message-ID: <9c5208fd-7128-0349-89d1-5e0200f5491b@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8157240 Fix the logging for GC worker creation so that it is consistent and adds the GC worker name to the logging. http://cr.openjdk.java.net/~jmasa/8157240/webrev.00/index.html Tested by hand to verify output and with TestDynamicNumberOfGCThreads.java. Thanks. Jon From thomas.schatzl at oracle.com Mon Jun 27 12:19:40 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 27 Jun 2016 14:19:40 +0200 Subject: RFR (M): 8159978: Use an array to store the collection set regions instead of linking through regions Message-ID: <1467029980.2352.41.camel@oracle.com> Hi all, ? can I have reviews for the following change that changes the collection set to use an external array of region ids instead of linking them through the HeapRegion class. This - fixes some problems with the sampling thread iterating through the collection set without any memory barriers/synchronization. I.e. the sampling thread is not guaranteed to see all changes previously made to the HeapRegion members by the mutator threads. Note that we have not seen any crashes because of that yet, or at least not able to pinpoint it down to that. - removes some hairy code about the gc time stamp and distributing work across threads when iterating over the collection set much easier to understand. - makes the follow-up change to free the collection set in parallel (JDK-8034842) simpler. CR: https://bugs.openjdk.java.net/browse/JDK-8159978 Webrev: http://cr.openjdk.java.net/~tschatzl/8159978/webrev/ Testing: jprt multiple times, vm.gc testlist with that change. Thanks, ? Thomas From thomas.schatzl at oracle.com Mon Jun 27 13:00:40 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 27 Jun 2016 15:00:40 +0200 Subject: RFR(S): 8132715: Add tests which check that no allocations allowed in any of humongous =?UTF-8?Q?regions=E2=80=8B?= In-Reply-To: <576D5EC0.3080803@oracle.com> References: <57697D25.6080406@oracle.com> <2b93d8cb-70fb-94b1-58c6-18c2f52bae68@oracle.com> <1466597770.2725.17.camel@oracle.com> <576D5EC0.3080803@oracle.com> Message-ID: <1467032440.2352.51.camel@oracle.com> Hi, On Fri, 2016-06-24 at 19:24 +0300, Kirill Zhaldybin wrote: > Thomas, > > Thank you for reviewing the fix. > > Could you please read comments inline? some more comments: - ?38??* @requires vm.gc=="G1" | vm.gc=="null" could be replaced by the new @requires vm.gc.G1. > Regards, Kirill > > On 22.06.2016 15:16, Thomas Schatzl wrote: > > > > Hi Kirill, > > > > On Tue, 2016-06-21 at 18:14 -0400, Derek White wrote: > > > > > > On 6/21/16 1:45 PM, Kirill Zhaldybin wrote: > > > > > > > > > > > > Dear all, > > > > > > > > Could please review this test for 8132715? > > > > > > > > The test fills heap with humongous objects with a lot of wasted > > > > space, > > > > then starts to allocate non-humongous objects and checks that > > > > no > > > > allocations happened in humongous regions. > > > > There are 3 runs of the test: with filled 10%, 50% and 80% of > > > > heap. > > > > > > > > CR: https://bugs.openjdk.java.net/browse/JDK-8132715 > > > > WebRev: > > > > http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev > > > > .01/ > > > > > > > > Thank you. > > > > > > > > Regards, Kirill [...] > > > > My main concern is with the second part, the allocation of the > > "poison" objects by the Allocator thread. > > Since they are smaller than a region size, they will always be > > allocated in young gen first. Which means, that it is very unlikely > > (since they are fairly short living) that they may be allocated in > > old gen. > > > > So the amount of opportunities when such a bad allocation happens > > seems too small. > I rewrote test so now it keeps some objects alive and calls Full GC? > often to promote them into old gen. I also set tenure threshold to 0 > to speed up promotion. > I checked (I had some debug output now deleted) that we actually had? > non-humongous objects in old gen during the testing. :) There seems to be just one problem: the full gc will make everything old gen, and compact the space, so most allocations in old gen may be due to the full gcs, and not due to evacuations. I think the test having full gcs may be useful (checking that compaction does not compact into the humongous regions), but it seems it is invoked too often, as it occurs after every allocation. Did you measure the number of "rounds" the allocators manage with this new version compared to the old one? It should be significantly smaller. Maybe decreasing the frequency of full gcs might help (or have another test run with full gcs enabled). Thanks, ? Thomas From per.liden at oracle.com Mon Jun 27 13:25:25 2016 From: per.liden at oracle.com (Per Liden) Date: Mon, 27 Jun 2016 15:25:25 +0200 Subject: RFR: 8159974: G1 String deduplication logging not aligned with the rest of G1 Message-ID: <57712945.6070904@oracle.com> Hi, Summary: With the introduction of Unified Logging, the style/conventions used for GC logging was changed in various ways. Some of the logging done by StringDedup was however left using the old style. This patch aligns the dedup logging with the rest of G1. Webrev: http://cr.openjdk.java.net/~pliden/8159974/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8159974 Example, before: ---------------- [11.927s][info ][gc,stringdedup] Concurrent String Deduplication 32.3M->32.3M(0.0B), avg 0.0%, 0.7633528 secs [11.927s][debug][gc,stringdedup] [Last Exec: 0.7633528 secs, Idle: 0.5195570 secs, Blocked: 0/0.0000000 secs] [11.927s][debug][gc,stringdedup] [Inspected: 1410367] [11.927s][debug][gc,stringdedup] [Skipped: 0( 0.0%)] [11.927s][debug][gc,stringdedup] [Hashed: 1410367(100.0%)] [11.927s][debug][gc,stringdedup] [Known: 0( 0.0%)] [11.927s][debug][gc,stringdedup] [New: 1410367(100.0%) 32.3M] [11.927s][debug][gc,stringdedup] [Deduplicated: 0( 0.0%) 0.0B( 0.0%)] [11.927s][debug][gc,stringdedup] [Young: 0( 0.0%) 0.0B( 0.0%)] [11.927s][debug][gc,stringdedup] [Old: 0( 0.0%) 0.0B( 0.0%)] [11.927s][debug][gc,stringdedup] [Total Exec: 4/6.7536909 secs, Idle: 4/4.1289840 secs, Blocked: 9/0.8971700 secs] [11.927s][debug][gc,stringdedup] [Inspected: 7163002] [11.927s][debug][gc,stringdedup] [Skipped: 0( 0.0%)] [11.927s][debug][gc,stringdedup] [Hashed: 7159929(100.0%)] [11.927s][debug][gc,stringdedup] [Known: 2916( 0.0%)] [11.927s][debug][gc,stringdedup] [New: 7160086(100.0%) 163.9M] [11.927s][debug][gc,stringdedup] [Deduplicated: 177( 0.0%) 5120.0B( 0.0%)] [11.927s][debug][gc,stringdedup] [Young: 0( 0.0%) 0.0B( 0.0%)] [11.927s][debug][gc,stringdedup] [Old: 177(100.0%) 5120.0B(100.0%)] [11.927s][debug][gc,stringdedup] [Table] [11.927s][debug][gc,stringdedup] [Memory Usage: 250.6M] [11.927s][debug][gc,stringdedup] [Size: 4194304, Min: 1024, Max: 16777216] [11.927s][debug][gc,stringdedup] [Entries: 7162825, Load: 170.8%, Cached: 0, Added: 7162825, Removed: 0] [11.927s][debug][gc,stringdedup] [Resize Count: 12, Shrink Threshold: 2796202(66.7%), Grow Threshold: 8388608(200.0%)] [11.927s][debug][gc,stringdedup] [Rehash Count: 0, Rehash Threshold: 120, Hash Seed: 0x0] [11.927s][debug][gc,stringdedup] [Age Threshold: 3] [11.927s][debug][gc,stringdedup] [Queue] [11.927s][debug][gc,stringdedup] [Dropped: 0] Example, after: --------------- [11.073s][info ][gc,stringdedup] Concurrent String Deduplication (11.073s) [11.975s][info ][gc,stringdedup] Concurrent String Deduplication 33.2M->33.2M(0.0B) avg 0.0% (11.073s, 11.975s) 901.918ms [11.975s][debug][gc,stringdedup] Last Exec: 901.918ms, Idle: 407.930ms, Blocked: 0/0.000ms [11.975s][debug][gc,stringdedup] Inspected: 1450663 [11.975s][debug][gc,stringdedup] Skipped: 0( 0.0%) [11.975s][debug][gc,stringdedup] Hashed: 1450663(100.0%) [11.975s][debug][gc,stringdedup] Known: 0( 0.0%) [11.975s][debug][gc,stringdedup] New: 1450663(100.0%) 33.2M [11.975s][debug][gc,stringdedup] Deduplicated: 0( 0.0%) 0.0B( 0.0%) [11.975s][debug][gc,stringdedup] Young: 0( 0.0%) 0.0B( 0.0%) [11.975s][debug][gc,stringdedup] Old: 0( 0.0%) 0.0B( 0.0%) [11.975s][debug][gc,stringdedup] Total Exec: 4/7275.988ms, Idle: 4/3620.653ms, Blocked: 8/929.258ms [11.975s][debug][gc,stringdedup] Inspected: 7348199 [11.975s][debug][gc,stringdedup] Skipped: 0( 0.0%) [11.975s][debug][gc,stringdedup] Hashed: 7345126(100.0%) [11.975s][debug][gc,stringdedup] Known: 2916( 0.0%) [11.975s][debug][gc,stringdedup] New: 7345283(100.0%) 168.1M [11.975s][debug][gc,stringdedup] Deduplicated: 177( 0.0%) 5120.0B( 0.0%) [11.975s][debug][gc,stringdedup] Young: 0( 0.0%) 0.0B( 0.0%) [11.975s][debug][gc,stringdedup] Old: 177(100.0%) 5120.0B(100.0%) [11.975s][debug][gc,stringdedup] Table [11.975s][debug][gc,stringdedup] Memory Usage: 256.2M [11.975s][debug][gc,stringdedup] Size: 4194304, Min: 1024, Max: 16777216 [11.975s][debug][gc,stringdedup] Entries: 7348022, Load: 175.2%, Cached: 0, Added: 7348022, Removed: 0 [11.975s][debug][gc,stringdedup] Resize Count: 12, Shrink Threshold: 2796202(66.7%), Grow Threshold: 8388608(200.0%) [11.975s][debug][gc,stringdedup] Rehash Count: 0, Rehash Threshold: 120, Hash Seed: 0x0 [11.975s][debug][gc,stringdedup] Age Threshold: 3 [11.975s][debug][gc,stringdedup] Queue [11.975s][debug][gc,stringdedup] Dropped: 0 cheers, Per From kirk.pepperdine at gmail.com Mon Jun 27 13:35:30 2016 From: kirk.pepperdine at gmail.com (kirk.pepperdine at gmail.com) Date: Mon, 27 Jun 2016 15:35:30 +0200 Subject: RFR: 8159974: G1 String deduplication logging not aligned with the rest of G1 In-Reply-To: <57712945.6070904@oracle.com> References: <57712945.6070904@oracle.com> Message-ID: <90DF0E5C-3558-4231-BA64-7F45EA40031C@gmail.com> Hi Per, What is the difference between these two lines? > [11.073s][info ][gc,stringdedup] Concurrent String Deduplication (11.073s) > [11.975s][info ][gc,stringdedup] Concurrent String Deduplication 33.2M->33.2M(0.0B) avg 0.0% (11.073s, 11.975s) 901.918ms Is it possible to stack the following information so that you are doing 1 write instead of many? > [11.975s][debug][gc,stringdedup] Inspected: 1450663 > [11.975s][debug][gc,stringdedup] Skipped: 0( 0.0%) > [11.975s][debug][gc,stringdedup] Hashed: 1450663(100.0%) > [11.975s][debug][gc,stringdedup] Known: 0( 0.0%) > [11.975s][debug][gc,stringdedup] New: 1450663(100.0%) 33.2M > [11.975s][debug][gc,stringdedup] Deduplicated: 0( 0.0%) 0.0B( 0.0%) > [11.975s][debug][gc,stringdedup] Young: 0( 0.0%) 0.0B( 0.0%) > [11.975s][debug][gc,stringdedup] Old: 0( 0.0%) 0.0B( 0.0%) to something like [11.975s][debug][gc,stringdedup] Inspected: 1450663 Skipped: 0( 0.0%) Hashed: 1450663(100.0%) Known: 0( 0.0%) New: 1450663(100.0%) 33.2M Deduplicated: 0( 0.0%) 0.0B( 0.0%) Young: 0( 0.0%) 0.0B( 0.0%) Old: 0( 0.0%) 0.0B( 0.0%) Kind regards, Kirk Pepperdine > On Jun 27, 2016, at 3:25 PM, Per Liden wrote: > > Hi, > > Summary: With the introduction of Unified Logging, the style/conventions used for GC logging was changed in various ways. Some of the logging done by StringDedup was however left using the old style. This patch aligns the dedup logging with the rest of G1. > > Webrev: http://cr.openjdk.java.net/~pliden/8159974/webrev.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8159974 > > Example, before: > ---------------- > [11.927s][info ][gc,stringdedup] Concurrent String Deduplication 32.3M->32.3M(0.0B), avg 0.0%, 0.7633528 secs > [11.927s][debug][gc,stringdedup] [Last Exec: 0.7633528 secs, Idle: 0.5195570 secs, Blocked: 0/0.0000000 secs] > [11.927s][debug][gc,stringdedup] [Inspected: 1410367] > [11.927s][debug][gc,stringdedup] [Skipped: 0( 0.0%)] > [11.927s][debug][gc,stringdedup] [Hashed: 1410367(100.0%)] > [11.927s][debug][gc,stringdedup] [Known: 0( 0.0%)] > [11.927s][debug][gc,stringdedup] [New: 1410367(100.0%) 32.3M] > [11.927s][debug][gc,stringdedup] [Deduplicated: 0( 0.0%) 0.0B( 0.0%)] > [11.927s][debug][gc,stringdedup] [Young: 0( 0.0%) 0.0B( 0.0%)] > [11.927s][debug][gc,stringdedup] [Old: 0( 0.0%) 0.0B( 0.0%)] > [11.927s][debug][gc,stringdedup] [Total Exec: 4/6.7536909 secs, Idle: 4/4.1289840 secs, Blocked: 9/0.8971700 secs] > [11.927s][debug][gc,stringdedup] [Inspected: 7163002] > [11.927s][debug][gc,stringdedup] [Skipped: 0( 0.0%)] > [11.927s][debug][gc,stringdedup] [Hashed: 7159929(100.0%)] > [11.927s][debug][gc,stringdedup] [Known: 2916( 0.0%)] > [11.927s][debug][gc,stringdedup] [New: 7160086(100.0%) 163.9M] > [11.927s][debug][gc,stringdedup] [Deduplicated: 177( 0.0%) 5120.0B( 0.0%)] > [11.927s][debug][gc,stringdedup] [Young: 0( 0.0%) 0.0B( 0.0%)] > [11.927s][debug][gc,stringdedup] [Old: 177(100.0%) 5120.0B(100.0%)] > [11.927s][debug][gc,stringdedup] [Table] > [11.927s][debug][gc,stringdedup] [Memory Usage: 250.6M] > [11.927s][debug][gc,stringdedup] [Size: 4194304, Min: 1024, Max: 16777216] > [11.927s][debug][gc,stringdedup] [Entries: 7162825, Load: 170.8%, Cached: 0, Added: 7162825, Removed: 0] > [11.927s][debug][gc,stringdedup] [Resize Count: 12, Shrink Threshold: 2796202(66.7%), Grow Threshold: 8388608(200.0%)] > [11.927s][debug][gc,stringdedup] [Rehash Count: 0, Rehash Threshold: 120, Hash Seed: 0x0] > [11.927s][debug][gc,stringdedup] [Age Threshold: 3] > [11.927s][debug][gc,stringdedup] [Queue] > [11.927s][debug][gc,stringdedup] [Dropped: 0] > > Example, after: > --------------- > [11.073s][info ][gc,stringdedup] Concurrent String Deduplication (11.073s) > [11.975s][info ][gc,stringdedup] Concurrent String Deduplication 33.2M->33.2M(0.0B) avg 0.0% (11.073s, 11.975s) 901.918ms > [11.975s][debug][gc,stringdedup] Last Exec: 901.918ms, Idle: 407.930ms, Blocked: 0/0.000ms > [11.975s][debug][gc,stringdedup] Inspected: 1450663 > [11.975s][debug][gc,stringdedup] Skipped: 0( 0.0%) > [11.975s][debug][gc,stringdedup] Hashed: 1450663(100.0%) > [11.975s][debug][gc,stringdedup] Known: 0( 0.0%) > [11.975s][debug][gc,stringdedup] New: 1450663(100.0%) 33.2M > [11.975s][debug][gc,stringdedup] Deduplicated: 0( 0.0%) 0.0B( 0.0%) > [11.975s][debug][gc,stringdedup] Young: 0( 0.0%) 0.0B( 0.0%) > [11.975s][debug][gc,stringdedup] Old: 0( 0.0%) 0.0B( 0.0%) > [11.975s][debug][gc,stringdedup] Total Exec: 4/7275.988ms, Idle: 4/3620.653ms, Blocked: 8/929.258ms > [11.975s][debug][gc,stringdedup] Inspected: 7348199 > [11.975s][debug][gc,stringdedup] Skipped: 0( 0.0%) > [11.975s][debug][gc,stringdedup] Hashed: 7345126(100.0%) > [11.975s][debug][gc,stringdedup] Known: 2916( 0.0%) > [11.975s][debug][gc,stringdedup] New: 7345283(100.0%) 168.1M > [11.975s][debug][gc,stringdedup] Deduplicated: 177( 0.0%) 5120.0B( 0.0%) > [11.975s][debug][gc,stringdedup] Young: 0( 0.0%) 0.0B( 0.0%) > [11.975s][debug][gc,stringdedup] Old: 177(100.0%) 5120.0B(100.0%) > [11.975s][debug][gc,stringdedup] Table > [11.975s][debug][gc,stringdedup] Memory Usage: 256.2M > [11.975s][debug][gc,stringdedup] Size: 4194304, Min: 1024, Max: 16777216 > [11.975s][debug][gc,stringdedup] Entries: 7348022, Load: 175.2%, Cached: 0, Added: 7348022, Removed: 0 > [11.975s][debug][gc,stringdedup] Resize Count: 12, Shrink Threshold: 2796202(66.7%), Grow Threshold: 8388608(200.0%) > [11.975s][debug][gc,stringdedup] Rehash Count: 0, Rehash Threshold: 120, Hash Seed: 0x0 > [11.975s][debug][gc,stringdedup] Age Threshold: 3 > [11.975s][debug][gc,stringdedup] Queue > [11.975s][debug][gc,stringdedup] Dropped: 0 > > cheers, > Per > From derek.white at oracle.com Mon Jun 27 14:10:25 2016 From: derek.white at oracle.com (Derek White) Date: Mon, 27 Jun 2016 10:10:25 -0400 Subject: [RESUMED] RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: <1466627892.2778.19.camel@oracle.com> References: <8c360c59-c4c6-715b-fb01-df04c2b45db4@oracle.com> <25b125dd-5512-9337-22b4-29b90b0547e9@oracle.com> <1466548590.2941.3.camel@oracle.com> <62101D79-2A20-457E-A8E0-0CB678AB67D7@oracle.com> <1466611838.2725.30.camel@oracle.com> <7b0fe659-2a5b-0494-49b5-be13f375f20f@oracle.com> <1466622063.2387.4.camel@oracle.com> <1466627892.2778.19.camel@oracle.com> Message-ID: I'd like to split out the memory fence issue from the race fixed by this webrev. I think the fence issue may require more performance testing and several attempts to get something satisfactory. New bug created: JDK-8160369 Memory fences needed around setting and reading object lengths. How do reviewers feel about this patch to fix the initial race condition? - Derek On 6/22/16 4:38 PM, Thomas Schatzl wrote: > Hi, > > On Wed, 2016-06-22 at 15:33 -0400, Derek White wrote: >> Hi Thomas, >> >> On 6/22/16 3:01 PM, Thomas Schatzl wrote: >>> Hi, >>> > [...] >>> CollectedHeap::array_allocate() is not used for humongous objects, >>> but >>> G1CollectedHeap::humongous_obj_allocate(). >> >> That can't be right - G1CollectedHeap::humongous_obj_allocate() >> doesn't set the object header (it doesn't even know the Klass). It >> clears the object header, and does the storestore before updating the >> heap region bookkeeping that makes the new object scannable. At that >> point the new object is a valid uninitialized object. >> >> G1CollectedHeap::humongous_obj_allocate() is called by >> Universe::heap()->mem_allocate() is called by >> CollectedHeap::common_mem_allocate_noinit() is called by various >> CollectedHeap::XXX_allocate() >> >> But what Kim is concerned about is the ordering of setting the object >> header (lock and klass fields) and setting either the array length or >> the "oop_size" field of a java.lang.Class instance. We (GC) never >> want to see an object with a non-zero klass in the header and an >> unset array length or oop_size. These fields are set up in >> CollectedHeap::post_allocation_install_obj_klass() (and neighbors), >> but there is no ordering enforced between the stores. > Bug? I mean, if the comment already says it needs this ordering, and > there is no explicit barrier, it's a bug in any case. At least on non- > TSO platforms the cpu will reorder the stores, and on others there is > still the issue with potential compiler reordering. > > Guess we were kind of lucky? Or one of these spurious crash reports we > have is caused by this? > >> I think we're primarily worried by concurrent GC threads (G1 or CMS) >> seeing these new objects as they are being created. So we aren't >> concerned about young gen objects. There's some evidence that CMS is >> synchronizing access between allocators and concurrent scanners (see >> below), but I don't know if there are similar issues with G1. > There unfortunately seem to be quite a few potentially concurrent > callers (refinement - scanning the card, marking - advancing the > finger) of oopDesc::size_given_klass() and I can't convince myself we > have an address dependency on klass in that method for array size > calculation (which would imply a loadload barrier on the platforms > needed) - other objects seem fine, as they read a variable based off > the klass pointer. > > (And on TSO systems again it did not matter except for the potential > compiler reordering, which seems almost impossible here) > > But please check that yourselves too. > > Thanks, > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirill.zhaldybin at oracle.com Mon Jun 27 15:47:57 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Mon, 27 Jun 2016 18:47:57 +0300 Subject: =?UTF-8?Q?Re:_RFR=28S=29:_8132715:_Add_tests_which_check_that_no_al?= =?UTF-8?Q?locations_allowed_in_any_of_humongous_regions=e2=80=8b?= In-Reply-To: <1467032440.2352.51.camel@oracle.com> References: <57697D25.6080406@oracle.com> <2b93d8cb-70fb-94b1-58c6-18c2f52bae68@oracle.com> <1466597770.2725.17.camel@oracle.com> <576D5EC0.3080803@oracle.com> <1467032440.2352.51.camel@oracle.com> Message-ID: <57714AAD.8070504@oracle.com> Thomas, Thank you for prompt reply! Here are a new WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev.04/ Changes: 1. Changed * @requires vm.gc=="G1" | vm.gc=="null" to @requires vm.gc.G1 2. Deleted FullGC from list of actions. We actually don't need since liveset size is calculated to prevent OOM. Without external Full GCs we get a lot of different GCs: young, mixed and full (caused by allocation failure). 3. I changed 80% heap scenario to 70% since I would like to avoid any OOMs and with 80% heap filled with Humongous objects we were pretty close to oom. I also decreased maximum used memory for allocators for the same reason. 4. Fixed typo "heep" to "heap". Could you please let me know your opinion? Regards, Kirill On 27.06.2016 16:00, Thomas Schatzl wrote: > Hi, > > On Fri, 2016-06-24 at 19:24 +0300, Kirill Zhaldybin wrote: >> Thomas, >> >> Thank you for reviewing the fix. >> >> Could you please read comments inline? > > some more comments: > > - 38 * @requires vm.gc=="G1" | vm.gc=="null" could be replaced by the > new @requires vm.gc.G1. > >> Regards, Kirill >> >> On 22.06.2016 15:16, Thomas Schatzl wrote: >>> >>> Hi Kirill, >>> >>> On Tue, 2016-06-21 at 18:14 -0400, Derek White wrote: >>>> >>>> On 6/21/16 1:45 PM, Kirill Zhaldybin wrote: >>>>> >>>>> >>>>> Dear all, >>>>> >>>>> Could please review this test for 8132715? >>>>> >>>>> The test fills heap with humongous objects with a lot of wasted >>>>> space, >>>>> then starts to allocate non-humongous objects and checks that >>>>> no >>>>> allocations happened in humongous regions. >>>>> There are 3 runs of the test: with filled 10%, 50% and 80% of >>>>> heap. >>>>> >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8132715 >>>>> WebRev: >>>>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev >>>>> .01/ >>>>> >>>>> Thank you. >>>>> >>>>> Regards, Kirill > [...] >>> >>> My main concern is with the second part, the allocation of the >>> "poison" objects by the Allocator thread. >>> Since they are smaller than a region size, they will always be >>> allocated in young gen first. Which means, that it is very unlikely >>> (since they are fairly short living) that they may be allocated in >>> old gen. >>> >>> So the amount of opportunities when such a bad allocation happens >>> seems too small. >> I rewrote test so now it keeps some objects alive and calls Full GC >> often to promote them into old gen. I also set tenure threshold to 0 >> to speed up promotion. >> I checked (I had some debug output now deleted) that we actually had >> non-humongous objects in old gen during the testing. > > :) > > There seems to be just one problem: the full gc will make everything > old gen, and compact the space, so most allocations in old gen may be > due to the full gcs, and not due to evacuations. > > I think the test having full gcs may be useful (checking that > compaction does not compact into the humongous regions), but it seems > it is invoked too often, as it occurs after every allocation. > > Did you measure the number of "rounds" the allocators manage with this > new version compared to the old one? It should be significantly > smaller. > > Maybe decreasing the frequency of full gcs might help (or have another > test run with full gcs enabled). > > Thanks, > Thomas > From sangheon.kim at oracle.com Mon Jun 27 23:54:40 2016 From: sangheon.kim at oracle.com (sangheon) Date: Mon, 27 Jun 2016 16:54:40 -0700 Subject: RFR: 8024137 - Flags should be set using the proper macro In-Reply-To: <9e04cfe3-2c11-2080-9f7b-2f198a8a0d69@oracle.com> References: <9e04cfe3-2c11-2080-9f7b-2f198a8a0d69@oracle.com> Message-ID: <5771BCC0.7020302@oracle.com> Hi Jesper, On 06/21/2016 01:01 PM, Jesper Wilhelmsson wrote: > Hi, > > Please review this change to make the GC ergonomics use > FLAG_SET_ERGO() instead of setting values directly in flags. This > change builds on the fix for JDK-8048093 and assumes that we will > remember that the flags was set on the command line. > > If you know of any other places where we assign a flag directly > without using FLAG_SET_ERGO() please let me know since it would make > sense to change all these places in this change. Looks good. The only place that I found is, g1YoungGenSizer.cpp:48 MaxNewSize = NewSize; And I recommend you to run TestOptionsWithRanges.java for all platforms. Your change seems okay with the test but it would be better to run it if we change flag related codes. Thanks, Sangheon > > Bug: https://bugs.openjdk.java.net/browse/JDK-8024137 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8024137/webrev.00/ > > Thanks, > /Jesper > From per.liden at oracle.com Tue Jun 28 07:46:19 2016 From: per.liden at oracle.com (Per Liden) Date: Tue, 28 Jun 2016 09:46:19 +0200 Subject: RFR: 8159974: G1 String deduplication logging not aligned with the rest of G1 In-Reply-To: <90DF0E5C-3558-4231-BA64-7F45EA40031C@gmail.com> References: <57712945.6070904@oracle.com> <90DF0E5C-3558-4231-BA64-7F45EA40031C@gmail.com> Message-ID: <57722B4B.6020204@oracle.com> Hi Kirk, On 2016-06-27 15:35, kirk.pepperdine at gmail.com wrote: > Hi Per, > > What is the difference between these two lines? > >> [11.073s][info ][gc,stringdedup] Concurrent String Deduplication (11.073s) >> [11.975s][info ][gc,stringdedup] Concurrent String Deduplication 33.2M->33.2M(0.0B) avg 0.0% (11.073s, 11.975s) 901.918ms The first line indicates the start of the concurrent phase, the second the end of the concurrent phase. There could be all kinds of things happening in between, like GCs, etc. This follows the style used by other concurrent phases, such as concurrent mark. > Is it possible to stack the following information so that you are doing 1 write instead of many? > >> [11.975s][debug][gc,stringdedup] Inspected: 1450663 >> [11.975s][debug][gc,stringdedup] Skipped: 0( 0.0%) >> [11.975s][debug][gc,stringdedup] Hashed: 1450663(100.0%) >> [11.975s][debug][gc,stringdedup] Known: 0( 0.0%) >> [11.975s][debug][gc,stringdedup] New: 1450663(100.0%) 33.2M >> [11.975s][debug][gc,stringdedup] Deduplicated: 0( 0.0%) 0.0B( 0.0%) >> [11.975s][debug][gc,stringdedup] Young: 0( 0.0%) 0.0B( 0.0%) >> [11.975s][debug][gc,stringdedup] Old: 0( 0.0%) 0.0B( 0.0%) > > to something like > > [11.975s][debug][gc,stringdedup] Inspected: 1450663 Skipped: 0( 0.0%) Hashed: 1450663(100.0%) Known: 0( 0.0%) New: 1450663(100.0%) 33.2M Deduplicated: 0( 0.0%) 0.0B( 0.0%) Young: 0( 0.0%) 0.0B( 0.0%) Old: 0( 0.0%) 0.0B( 0.0%) I have mixed feelings about this. While something like this would make the output more compact, it this also tends to hurt readability. In any case, given the FC-state of JDK9 I'm not so keen on letting this change grow to fixing things other than the obvious style differences. cheers, Per > > Kind regards, > Kirk Pepperdine > > > >> On Jun 27, 2016, at 3:25 PM, Per Liden wrote: >> >> Hi, >> >> Summary: With the introduction of Unified Logging, the style/conventions used for GC logging was changed in various ways. Some of the logging done by StringDedup was however left using the old style. This patch aligns the dedup logging with the rest of G1. >> >> Webrev: http://cr.openjdk.java.net/~pliden/8159974/webrev.0/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8159974 >> >> Example, before: >> ---------------- >> [11.927s][info ][gc,stringdedup] Concurrent String Deduplication 32.3M->32.3M(0.0B), avg 0.0%, 0.7633528 secs >> [11.927s][debug][gc,stringdedup] [Last Exec: 0.7633528 secs, Idle: 0.5195570 secs, Blocked: 0/0.0000000 secs] >> [11.927s][debug][gc,stringdedup] [Inspected: 1410367] >> [11.927s][debug][gc,stringdedup] [Skipped: 0( 0.0%)] >> [11.927s][debug][gc,stringdedup] [Hashed: 1410367(100.0%)] >> [11.927s][debug][gc,stringdedup] [Known: 0( 0.0%)] >> [11.927s][debug][gc,stringdedup] [New: 1410367(100.0%) 32.3M] >> [11.927s][debug][gc,stringdedup] [Deduplicated: 0( 0.0%) 0.0B( 0.0%)] >> [11.927s][debug][gc,stringdedup] [Young: 0( 0.0%) 0.0B( 0.0%)] >> [11.927s][debug][gc,stringdedup] [Old: 0( 0.0%) 0.0B( 0.0%)] >> [11.927s][debug][gc,stringdedup] [Total Exec: 4/6.7536909 secs, Idle: 4/4.1289840 secs, Blocked: 9/0.8971700 secs] >> [11.927s][debug][gc,stringdedup] [Inspected: 7163002] >> [11.927s][debug][gc,stringdedup] [Skipped: 0( 0.0%)] >> [11.927s][debug][gc,stringdedup] [Hashed: 7159929(100.0%)] >> [11.927s][debug][gc,stringdedup] [Known: 2916( 0.0%)] >> [11.927s][debug][gc,stringdedup] [New: 7160086(100.0%) 163.9M] >> [11.927s][debug][gc,stringdedup] [Deduplicated: 177( 0.0%) 5120.0B( 0.0%)] >> [11.927s][debug][gc,stringdedup] [Young: 0( 0.0%) 0.0B( 0.0%)] >> [11.927s][debug][gc,stringdedup] [Old: 177(100.0%) 5120.0B(100.0%)] >> [11.927s][debug][gc,stringdedup] [Table] >> [11.927s][debug][gc,stringdedup] [Memory Usage: 250.6M] >> [11.927s][debug][gc,stringdedup] [Size: 4194304, Min: 1024, Max: 16777216] >> [11.927s][debug][gc,stringdedup] [Entries: 7162825, Load: 170.8%, Cached: 0, Added: 7162825, Removed: 0] >> [11.927s][debug][gc,stringdedup] [Resize Count: 12, Shrink Threshold: 2796202(66.7%), Grow Threshold: 8388608(200.0%)] >> [11.927s][debug][gc,stringdedup] [Rehash Count: 0, Rehash Threshold: 120, Hash Seed: 0x0] >> [11.927s][debug][gc,stringdedup] [Age Threshold: 3] >> [11.927s][debug][gc,stringdedup] [Queue] >> [11.927s][debug][gc,stringdedup] [Dropped: 0] >> >> Example, after: >> --------------- >> [11.073s][info ][gc,stringdedup] Concurrent String Deduplication (11.073s) >> [11.975s][info ][gc,stringdedup] Concurrent String Deduplication 33.2M->33.2M(0.0B) avg 0.0% (11.073s, 11.975s) 901.918ms >> [11.975s][debug][gc,stringdedup] Last Exec: 901.918ms, Idle: 407.930ms, Blocked: 0/0.000ms >> [11.975s][debug][gc,stringdedup] Inspected: 1450663 >> [11.975s][debug][gc,stringdedup] Skipped: 0( 0.0%) >> [11.975s][debug][gc,stringdedup] Hashed: 1450663(100.0%) >> [11.975s][debug][gc,stringdedup] Known: 0( 0.0%) >> [11.975s][debug][gc,stringdedup] New: 1450663(100.0%) 33.2M >> [11.975s][debug][gc,stringdedup] Deduplicated: 0( 0.0%) 0.0B( 0.0%) >> [11.975s][debug][gc,stringdedup] Young: 0( 0.0%) 0.0B( 0.0%) >> [11.975s][debug][gc,stringdedup] Old: 0( 0.0%) 0.0B( 0.0%) >> [11.975s][debug][gc,stringdedup] Total Exec: 4/7275.988ms, Idle: 4/3620.653ms, Blocked: 8/929.258ms >> [11.975s][debug][gc,stringdedup] Inspected: 7348199 >> [11.975s][debug][gc,stringdedup] Skipped: 0( 0.0%) >> [11.975s][debug][gc,stringdedup] Hashed: 7345126(100.0%) >> [11.975s][debug][gc,stringdedup] Known: 2916( 0.0%) >> [11.975s][debug][gc,stringdedup] New: 7345283(100.0%) 168.1M >> [11.975s][debug][gc,stringdedup] Deduplicated: 177( 0.0%) 5120.0B( 0.0%) >> [11.975s][debug][gc,stringdedup] Young: 0( 0.0%) 0.0B( 0.0%) >> [11.975s][debug][gc,stringdedup] Old: 177(100.0%) 5120.0B(100.0%) >> [11.975s][debug][gc,stringdedup] Table >> [11.975s][debug][gc,stringdedup] Memory Usage: 256.2M >> [11.975s][debug][gc,stringdedup] Size: 4194304, Min: 1024, Max: 16777216 >> [11.975s][debug][gc,stringdedup] Entries: 7348022, Load: 175.2%, Cached: 0, Added: 7348022, Removed: 0 >> [11.975s][debug][gc,stringdedup] Resize Count: 12, Shrink Threshold: 2796202(66.7%), Grow Threshold: 8388608(200.0%) >> [11.975s][debug][gc,stringdedup] Rehash Count: 0, Rehash Threshold: 120, Hash Seed: 0x0 >> [11.975s][debug][gc,stringdedup] Age Threshold: 3 >> [11.975s][debug][gc,stringdedup] Queue >> [11.975s][debug][gc,stringdedup] Dropped: 0 >> >> cheers, >> Per >> > From jesper.wilhelmsson at oracle.com Tue Jun 28 10:49:42 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 28 Jun 2016 12:49:42 +0200 Subject: RFR: 8024137 - Flags should be set using the proper macro In-Reply-To: <5771BCC0.7020302@oracle.com> References: <9e04cfe3-2c11-2080-9f7b-2f198a8a0d69@oracle.com> <5771BCC0.7020302@oracle.com> Message-ID: Hi Sangheon, Thanks for reviewing! I have included a fix for g1YoungGenSizer as well. New webrev: http://cr.openjdk.java.net/~jwilhelm/8024137/webrev.01/ I also ran it through TestOptionsWithRanges. /Jesper Den 28/6/16 kl. 01:54, skrev sangheon: > Hi Jesper, > > On 06/21/2016 01:01 PM, Jesper Wilhelmsson wrote: >> Hi, >> >> Please review this change to make the GC ergonomics use FLAG_SET_ERGO() >> instead of setting values directly in flags. This change builds on the fix for >> JDK-8048093 and assumes that we will remember that the flags was set on the >> command line. >> >> If you know of any other places where we assign a flag directly without using >> FLAG_SET_ERGO() please let me know since it would make sense to change all >> these places in this change. > Looks good. > > The only place that I found is, > g1YoungGenSizer.cpp:48 > MaxNewSize = NewSize; > > And I recommend you to run TestOptionsWithRanges.java for all platforms. > Your change seems okay with the test but it would be better to run it if we > change flag related codes. > > Thanks, > Sangheon > > >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8024137 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8024137/webrev.00/ >> >> Thanks, >> /Jesper >> > From thomas.schatzl at oracle.com Tue Jun 28 11:02:21 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 28 Jun 2016 13:02:21 +0200 Subject: RFR (M): 8034842: Parallelize the Free CSet phase in G1 In-Reply-To: <1463137445.2392.14.camel@oracle.com> References: <1462197842.6903.76.camel@oracle.com> <1462271995.2400.26.camel@oracle.com> <1462892429.3606.21.camel@oracle.com> <82bda377-0724-9203-3819-6e5daad830c2@oracle.com> <1462961085.2448.20.camel@oracle.com> <37462b80-bf67-5e45-d13f-c5d00e247b95@oracle.com> <1463000728.2691.8.camel@oracle.com> <1463043398.2471.3.camel@oracle.com> <1630f34e-129c-ce01-430e-57b71b6d7c62@oracle.com> <1463137445.2392.14.camel@oracle.com> Message-ID: <1467111741.2435.3.camel@oracle.com> Hi everyone, ? there is a new version of this CR available at http://cr.openjdk.java.net/~tschatzl/8034842/webrev.5/?(full) Due to the changes afforded by JDK-8159978 there were a lot of changes that made an incremental webrev useless. However I think this split-out made the change nicer (imo). Testing: jprt, vm.gc testlist Thanks, ? Thomas On Fri, 2016-05-13 at 13:04 +0200, Thomas Schatzl wrote: > Hi Derek and everybody, > > On Thu, 2016-05-12 at 11:08 -0400, Derek White wrote: > > > > Hi Thomas, > > webrev.4/ looks good! > > > ? I had a lengthy discussion with Erik (and Mikael about this > particular topic) about this change yesterday: while he ultimately > approves of it (with some changes), I have been requested to split > out the part where the regions in the collection set are handled in > an array into a separate webrev. > > It would be much better if the collection set for several reasons > were > generally managed using an (explicit) array instead of the current > (HeapRegion-embedded) linked list. > > So stay tuned for updated webrevs :) > > Thanks for your review, > ? Thomas > > > > > ?- Derek > > On 5/12/16 4:56 AM, Thomas Schatzl wrote: > > > > > > Hi again, > > > > > > On Wed, 2016-05-11 at 23:05 +0200, Thomas Schatzl wrote: > > > > > > > > Hi Derek, > > > > > > > > On Wed, 2016-05-11 at 16:19 -0400, Derek White wrote: > > > > > > > > > > Hi Thomas, > > > > > > > > > > The changes in webrev.3 look good. > > > > > > > > > > I have some comments on bigger picture now. I have one > > > > > possible > > > > > bug, > > > > > and several increasingly annoying "you did it this way, why > > > > > didn't > > > > > you do it this way instead" comments :-) > > > > > > > > > > src/share/vm/gc/g1/g1CollectedHeap.cpp: > > > > > > > > > > - Is _regions_freed ever set? Can use > > > > > local_free_list.length() > > > > > instead. > > > > I will look into this. > > > That has actually been a bug. Thanks for catching this. > > > > > > > > > > > > > > > > > - Could add evacuation_info parameter to complete_work(), and > > > > > remove the _evacuation_info field from > > > > > G1FreeCollectionSetTask. > > > > Fine with me. > > > Done. > > > > > > > > > > > > > > > > > - do_serial_work() is done in parallel with > > > > > do_parallel_work(). > > > > > Is > > > > > that safe???hr->rem_set()->clear_locked() or? > > > > > _g1h->_hot_card_cache->reset_card_counts(hr) can be called > > > > > before > > > > > or? > > > > > after _g1h->free_region(hr, &_local_free_list, true, true, > > > > > true). > > > > It is. The rem sets and the card counts are pretty independent > > > > data > > > > structures and can be removed any time. > > > > > > > > > > > > > > Line 4928: > > > > > - Is using the??_serial_work_claim mechanism safer than just > > > > > testing > > > > > for (worker_id == 0)? Because it's not simpler :-) > > > > Because worker 0 might not be actually the first one reaching > > > > the > > > > do_work() method, potentially unnecessarily delaying the entire > > > > process until it finished spinning up. While we always need to > > > > wait > > > > for all threads to spin up to end the task, using worker_id == > > > > 0 > > > > means that we will at least need to wait for spin up of thread > > > > plus > > > > the serial work. > > > > > > > > > > - I was going to question sorting the regions into young and > > > > > old > > > > > lists, and managing two lists instead of having just one. But > > > > > that > > > > > does simplify the G1GCPhaseTimes recording. > > > > This is the main reason. > > > > > > > > I will provide a new webrev tomorrow. > > > http://cr.openjdk.java.net/~tschatzl/8034842/webrev.4/?(full) > > > http://cr.openjdk.java.net/~tschatzl/8034842/webrev.3_to_4/?(diff > > > ) > > > > > > There are a few other changes found when walking through the code > > > with > > > Erik Helin, and then again by myselves. > > > > > > Thanks, > > > ? Thomas > > > From thomas.schatzl at oracle.com Tue Jun 28 12:19:59 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 28 Jun 2016 14:19:59 +0200 Subject: RFR (M): 8159978: Use an array to store the collection set regions instead of linking through regions In-Reply-To: <1467029980.2352.41.camel@oracle.com> References: <1467029980.2352.41.camel@oracle.com> Message-ID: <1467116399.2435.18.camel@oracle.com> Hi all, On Mon, 2016-06-27 at 14:19 +0200, Thomas Schatzl wrote: >?Hi all, >? >?? can I have reviews for the following change that changes the >?collection set to use an external array of region ids instead of >?linking them through the HeapRegion class. >? ? I got some feedback from Erik Helin about this change. These are - we do not really need the multiple-writer/multiple-reader implementation to store the list of collection set regions. We only ever have one concurrent reader and one concurrent writer to it. So I simplified the data structure to use only storestore/loadload barriers for synchronization. The relevant changes got so small that an extra data structure was not warranted, so I removed it. - I strengthened (added) some asserts about some methods that should only be called by the vm thread at a safepoint to support this. Just to indicate that in these methods we do not need the memory barriers. - fixed a bug in the collection set iteration where the HeapRegionClosure::incomplete() method has not been called if the iteration was aborted. - some cleanup Webrev: http://cr.openjdk.java.net/~tschatzl/8159978/webrev.1 (full) http://cr.openjdk.java.net/~tschatzl/8159978/webrev.0_to_1/?(diff Testing: jprt Thanks, ? Thomas From thomas.schatzl at oracle.com Tue Jun 28 12:55:57 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 28 Jun 2016 14:55:57 +0200 Subject: RFR(S): 8132715: Add tests which check that no allocations allowed in any of humongous =?UTF-8?Q?regions=E2=80=8B?= In-Reply-To: <57714AAD.8070504@oracle.com> References: <57697D25.6080406@oracle.com> <2b93d8cb-70fb-94b1-58c6-18c2f52bae68@oracle.com> <1466597770.2725.17.camel@oracle.com> <576D5EC0.3080803@oracle.com> <1467032440.2352.51.camel@oracle.com> <57714AAD.8070504@oracle.com> Message-ID: <1467118557.2326.2.camel@oracle.com> Hi, On Mon, 2016-06-27 at 18:47 +0300, Kirill Zhaldybin wrote: > Thomas, > > Thank you for prompt reply! > > Here are a new WebRev:? > http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev.04/ > > Changes: > 1. Changed??* @requires vm.gc=="G1" | vm.gc=="null" to > @requires vm.gc.G1 > I saw that the change that introduces this has not been pushed yet. You need to either synchronize with Dima or simply revert this. Looks good. Thanks, ? Thomas From thomas.schatzl at oracle.com Tue Jun 28 13:09:30 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 28 Jun 2016 15:09:30 +0200 Subject: [RESUMED] RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: References: <8c360c59-c4c6-715b-fb01-df04c2b45db4@oracle.com> <25b125dd-5512-9337-22b4-29b90b0547e9@oracle.com> <1466548590.2941.3.camel@oracle.com> <62101D79-2A20-457E-A8E0-0CB678AB67D7@oracle.com> <1466611838.2725.30.camel@oracle.com> <7b0fe659-2a5b-0494-49b5-be13f375f20f@oracle.com> <1466622063.2387.4.camel@oracle.com> <1466627892.2778.19.camel@oracle.com> Message-ID: <1467119370.2326.8.camel@oracle.com> Hi, On Mon, 2016-06-27 at 10:10 -0400, Derek White wrote: > I'd like to split out the memory fence issue from the race fixed by > this webrev. I think the fence issue may require more performance > testing and several attempts to get something satisfactory. > > New bug created:? > ??? JDK-8160369 Memory fences needed around setting and reading > object lengths. > > How do reviewers feel about this patch to fix the initial race > condition? ? looking at the 02 webrev: -?http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/gc /shared/collectedHeap.inline.hpp.frames.html 105???// set the j.l.Class instance's oop_size field BEFORE setting the header: I would like to have the "why" answered here in this comment and not a repetition of the code. I think something like: "Concurrent readers expect that the size is set before the klass pointer." Maybe the comment in lines 226/227 are more appropriate here? - the "obj" parameter is cast to an oop four times in CollectedHeap::post_allocation_setup_class. Could you add a local variable? -?http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/oo ps/instanceMirrorKlass.cpp.frames.html Not sure if repeating the exit condition in line 59 makes sense. -?http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/oo ps/oop.inline.hpp.frames.html Maybe fix the comment in 261 to a proper sentence. (And possibly 262, like "Oop size must be larger than zero but is %d") Thanks, ? Thomas From kirill.zhaldybin at oracle.com Tue Jun 28 15:18:24 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldbybin) Date: Tue, 28 Jun 2016 18:18:24 +0300 Subject: =?UTF-8?Q?Re:_RFR=28S=29:_8132715:_Add_tests_which_check_that_no_al?= =?UTF-8?Q?locations_allowed_in_any_of_humongous_regions=e2=80=8b?= In-Reply-To: <1467118557.2326.2.camel@oracle.com> References: <57697D25.6080406@oracle.com> <2b93d8cb-70fb-94b1-58c6-18c2f52bae68@oracle.com> <1466597770.2725.17.camel@oracle.com> <576D5EC0.3080803@oracle.com> <1467032440.2352.51.camel@oracle.com> <57714AAD.8070504@oracle.com> <1467118557.2326.2.camel@oracle.com> Message-ID: <57729540.6020308@oracle.com> Thomas, Thank you for review! Regards, Kirill On 06/28/2016 03:55 PM, Thomas Schatzl wrote: > Hi, > > On Mon, 2016-06-27 at 18:47 +0300, Kirill Zhaldybin wrote: >> Thomas, >> >> Thank you for prompt reply! >> >> Here are a new WebRev: >> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132715/webrev.04/ >> >> Changes: >> 1. Changed * @requires vm.gc=="G1" | vm.gc=="null" to >> @requires vm.gc.G1 >> > I saw that the change that introduces this has not been pushed yet. You > need to either synchronize with Dima or simply revert this. > > Looks good. > > Thanks, > Thomas > From thomas.schatzl at oracle.com Tue Jun 28 15:26:57 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 28 Jun 2016 17:26:57 +0200 Subject: [RESUMED] RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: <1467119370.2326.8.camel@oracle.com> References: <8c360c59-c4c6-715b-fb01-df04c2b45db4@oracle.com> <25b125dd-5512-9337-22b4-29b90b0547e9@oracle.com> <1466548590.2941.3.camel@oracle.com> <62101D79-2A20-457E-A8E0-0CB678AB67D7@oracle.com> <1466611838.2725.30.camel@oracle.com> <7b0fe659-2a5b-0494-49b5-be13f375f20f@oracle.com> <1466622063.2387.4.camel@oracle.com> <1466627892.2778.19.camel@oracle.com> <1467119370.2326.8.camel@oracle.com> Message-ID: <1467127617.2303.1.camel@oracle.com> Hi again, On Tue, 2016-06-28 at 15:09 +0200, Thomas Schatzl wrote: > Hi, > > On Mon, 2016-06-27 at 10:10 -0400, Derek White wrote: > > > > I'd like to split out the memory fence issue from the race fixed by > > this webrev. I think the fence issue may require more performance > > testing and several attempts to get something satisfactory. > > > > New bug created:? > > ??? JDK-8160369 Memory fences needed around setting and reading > > object lengths. > > > > How do reviewers feel about this patch to fix the initial race > > condition? > ? looking at the 02 webrev: > ? another question: -?http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/gc /shared/collectedHeap.inline.hpp.frames.html Why does?CollectedHeap::post_allocation_setup_class() use post_allocation_install_obj_klass() instead of post_allocation_setup_common(), effectively skipping setup of the mark word? Thanks, ? Thomas From derek.white at oracle.com Tue Jun 28 16:37:23 2016 From: derek.white at oracle.com (Derek White) Date: Tue, 28 Jun 2016 12:37:23 -0400 Subject: [RESUMED] RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: <1467119370.2326.8.camel@oracle.com> References: <8c360c59-c4c6-715b-fb01-df04c2b45db4@oracle.com> <25b125dd-5512-9337-22b4-29b90b0547e9@oracle.com> <1466548590.2941.3.camel@oracle.com> <62101D79-2A20-457E-A8E0-0CB678AB67D7@oracle.com> <1466611838.2725.30.camel@oracle.com> <7b0fe659-2a5b-0494-49b5-be13f375f20f@oracle.com> <1466622063.2387.4.camel@oracle.com> <1466627892.2778.19.camel@oracle.com> <1467119370.2326.8.camel@oracle.com> Message-ID: <152e4a29-c21a-a15d-0f30-c88b9db2b566@oracle.com> Hi Thomas, New webrev based on your suggestions: Webrev: http://cr.openjdk.java.net/~drwhite/8158946/webrev.03/ Incremental: http://cr.openjdk.java.net/~drwhite/8158946/webrev.02.vs.03 jprt in progress.... Misc comments below... - Derek On 6/28/16 9:09 AM, Thomas Schatzl wrote: > Hi, > > On Mon, 2016-06-27 at 10:10 -0400, Derek White wrote: >> I'd like to split out the memory fence issue from the race fixed by >> this webrev. I think the fence issue may require more performance >> testing and several attempts to get something satisfactory. >> >> New bug created: >> JDK-8160369 Memory fences needed around setting and reading >> object lengths. >> >> How do reviewers feel about this patch to fix the initial race >> condition? > looking at the 02 webrev: > > - http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/gc > /shared/collectedHeap.inline.hpp.frames.html > 105 // set the j.l.Class instance's oop_size field BEFORE setting the > header: > > I would like to have the "why" answered here in this comment and not a > repetition of the code. I think something like: "Concurrent readers > expect that the size is set before the klass pointer." > > Maybe the comment in lines 226/227 are more appropriate here? > > - the "obj" parameter is cast to an oop four times in > CollectedHeap::post_allocation_setup_class. Could you add a local > variable? OK, I cleaned this up by mirroring post_allocation_setup_array(). > - http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/oo > ps/instanceMirrorKlass.cpp.frames.html > > Not sure if repeating the exit condition in line 59 makes sense. OK. > - http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/oo > ps/oop.inline.hpp.frames.html > > Maybe fix the comment in 261 to a proper sentence. (And possibly 262, > like "Oop size must be larger than zero but is %d") OK Thanks for the suggestions! - Derek From derek.white at oracle.com Tue Jun 28 16:43:07 2016 From: derek.white at oracle.com (Derek White) Date: Tue, 28 Jun 2016 12:43:07 -0400 Subject: [RESUMED] RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: <1467127617.2303.1.camel@oracle.com> References: <8c360c59-c4c6-715b-fb01-df04c2b45db4@oracle.com> <25b125dd-5512-9337-22b4-29b90b0547e9@oracle.com> <1466548590.2941.3.camel@oracle.com> <62101D79-2A20-457E-A8E0-0CB678AB67D7@oracle.com> <1466611838.2725.30.camel@oracle.com> <7b0fe659-2a5b-0494-49b5-be13f375f20f@oracle.com> <1466622063.2387.4.camel@oracle.com> <1466627892.2778.19.camel@oracle.com> <1467119370.2326.8.camel@oracle.com> <1467127617.2303.1.camel@oracle.com> Message-ID: <4bdacdd3-c656-d2d6-5926-1977950fe8ce@oracle.com> On 6/28/16 11:26 AM, Thomas Schatzl wrote: > Hi again, > > On Tue, 2016-06-28 at 15:09 +0200, Thomas Schatzl wrote: >> Hi, >> >> On Mon, 2016-06-27 at 10:10 -0400, Derek White wrote: >>> I'd like to split out the memory fence issue from the race fixed by >>> this webrev. I think the fence issue may require more performance >>> testing and several attempts to get something satisfactory. >>> >>> New bug created: >>> JDK-8160369 Memory fences needed around setting and reading >>> object lengths. >>> >>> How do reviewers feel about this patch to fix the initial race >>> condition? >> looking at the 02 webrev: >> > another question: > > - http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/gc > /shared/collectedHeap.inline.hpp.frames.html > > Why does CollectedHeap::post_allocation_setup_class() use > post_allocation_install_obj_klass() instead of > post_allocation_setup_common(), effectively skipping setup of the mark > word? Hi Thomas, I rewrote this in webrev.03 after your earlier comments, so this is a moot point, but the webrev.02 version it called bothpost_allocation_setup_no_klass_install() /AND/ post_allocation_install_obj_klass(). So it did the mark work also. At one point I was concerned that post_allocation_setup_common() did the object zeroing, so I tried to avoid that call (unnecessarily). - Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From sangheon.kim at oracle.com Tue Jun 28 17:10:32 2016 From: sangheon.kim at oracle.com (sangheon) Date: Tue, 28 Jun 2016 10:10:32 -0700 Subject: RFR: 8024137 - Flags should be set using the proper macro In-Reply-To: References: <9e04cfe3-2c11-2080-9f7b-2f198a8a0d69@oracle.com> <5771BCC0.7020302@oracle.com> Message-ID: <5772AF88.30107@oracle.com> Hi Jesper, Looks good. Thanks, Sangheon On 06/28/2016 03:49 AM, Jesper Wilhelmsson wrote: > Hi Sangheon, > > Thanks for reviewing! > > I have included a fix for g1YoungGenSizer as well. New webrev: > > http://cr.openjdk.java.net/~jwilhelm/8024137/webrev.01/ > > I also ran it through TestOptionsWithRanges. > /Jesper > > Den 28/6/16 kl. 01:54, skrev sangheon: >> Hi Jesper, >> >> On 06/21/2016 01:01 PM, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> Please review this change to make the GC ergonomics use FLAG_SET_ERGO() >>> instead of setting values directly in flags. This change builds on >>> the fix for >>> JDK-8048093 and assumes that we will remember that the flags was set >>> on the >>> command line. >>> >>> If you know of any other places where we assign a flag directly >>> without using >>> FLAG_SET_ERGO() please let me know since it would make sense to >>> change all >>> these places in this change. >> Looks good. >> >> The only place that I found is, >> g1YoungGenSizer.cpp:48 >> MaxNewSize = NewSize; >> >> And I recommend you to run TestOptionsWithRanges.java for all platforms. >> Your change seems okay with the test but it would be better to run it >> if we >> change flag related codes. >> >> Thanks, >> Sangheon >> >> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8024137 >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8024137/webrev.00/ >>> >>> Thanks, >>> /Jesper >>> >> From jon.masamitsu at oracle.com Tue Jun 28 22:41:35 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 28 Jun 2016 15:41:35 -0700 Subject: RFR (M): 8159978: Use an array to store the collection set regions instead of linking through regions In-Reply-To: <1467116399.2435.18.camel@oracle.com> References: <1467029980.2352.41.camel@oracle.com> <1467116399.2435.18.camel@oracle.com> Message-ID: <8b595eeb-b222-2d2f-3ebb-4c93fb06b711@oracle.com> Thomas, http://cr.openjdk.java.net/~tschatzl/8159978/webrev.1/src/share/vm/gc/g1/g1CollectedHeap.cpp.frames.html For an evacuation failure the region is set to old here 4664 // The region is now considered to be old. 4665 r->set_old(); and below the elapsed times are incremented. 4676 if (r->is_young()) { 4677 _young_time += os::elapsedTime() - start_time; 4678 } else { 4679 _non_young_time += os::elapsedTime() - start_time; 4680 } Is it correct that elapsed time for a failed evacuation will be now be added to the _non_young_time? Whereas before it was included in the _young_time because non_young was assigned a value before the evacuation failure was tested? Old code is 4811 if (non_young) { 4812 non_young_time_ms += elapsed_ms; 4813 } else { 4814 young_time_ms += elapsed_ms; 4815 } http://cr.openjdk.java.net/~tschatzl/8159978/webrev.1/src/share/vm/gc/g1/g1CollectionSet.cpp.frames.html 177 void G1CollectionSet::iterate_from(HeapRegionClosure* cl, uint worker_id, uint total_workers, bool may_be_aborted) { I don't understand this iterate method. It seems like because of line 196 195 if (cur_pos == len) { 196 cur_pos = 0; 197 } all the workers will process region 0 in the collection set. Is this method creating slices for each worker? Or trying to stride through the collection set with each worker getting a different starting index? Jon On 6/28/2016 5:19 AM, Thomas Schatzl wrote: > Hi all, > > On Mon, 2016-06-27 at 14:19 +0200, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for the following change that changes the >> collection set to use an external array of region ids instead of >> linking them through the HeapRegion class. >> > I got some feedback from Erik Helin about this change. These are > > - we do not really need the multiple-writer/multiple-reader > implementation to store the list of collection set regions. We only > ever have one concurrent reader and one concurrent writer to it. > > So I simplified the data structure to use only storestore/loadload > barriers for synchronization. The relevant changes got so small that an > extra data structure was not warranted, so I removed it. > > - I strengthened (added) some asserts about some methods that should > only be called by the vm thread at a safepoint to support this. Just to > indicate that in these methods we do not need the memory barriers. > > - fixed a bug in the collection set iteration where the > HeapRegionClosure::incomplete() method has not been called if the > iteration was aborted. > > - some cleanup > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8159978/webrev.1 (full) > http://cr.openjdk.java.net/~tschatzl/8159978/webrev.0_to_1/ (diff > > Testing: > jprt > > Thanks, > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Wed Jun 29 12:32:17 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 29 Jun 2016 14:32:17 +0200 Subject: RFR (M): 8159978: Use an array to store the collection set regions instead of linking through regions In-Reply-To: <8b595eeb-b222-2d2f-3ebb-4c93fb06b711@oracle.com> References: <1467029980.2352.41.camel@oracle.com> <1467116399.2435.18.camel@oracle.com> <8b595eeb-b222-2d2f-3ebb-4c93fb06b711@oracle.com> Message-ID: <1467203537.2413.24.camel@oracle.com> Hi, On Tue, 2016-06-28 at 15:41 -0700, Jon Masamitsu wrote: > Thomas, > > http://cr.openjdk.java.net/~tschatzl/8159978/webrev.1/src/share/vm/gc > /g1/g1CollectedHeap.cpp.frames.html > > For an evacuation failure the region is set to old here > > 4664???????// The region is now considered to be old. > 4665???????r->set_old(); > > and below the elapsed times are incremented. > > 4676?????if (r->is_young()) { > 4677???????_young_time += os::elapsedTime() - start_time; > 4678?????} else { > 4679???????_non_young_time += os::elapsedTime() - start_time; > 4680?????} > > Is it correct that elapsed time for a failed evacuation will be now > be added to the _non_young_time?? Whereas before it was included in > the _young_time because non_young was assigned a value before the > evacuation failure was tested? Unintended change. Fixed. It would have been correct again in the follow-up change that parallelizes collection set freeing, so that's why I probably overlooked this. Sorry. > [..] > http://cr.openjdk.java.net/~tschatzl/8159978/webrev.1/src/share/vm/gc > /g1/g1CollectionSet.cpp.frames.html > > ? 177 void G1CollectionSet::iterate_from(HeapRegionClosure* cl, uint > worker_id, uint total_workers, bool may_be_aborted) { > > I don't understand this iterate method.? It seems like because of > line 196 > > ?195?????if (cur_pos == len) { > ?196???????cur_pos = 0; > ?197?????} > > all the workers will process region 0 in the collection set.? Is this > method creating slices for each worker?? Or trying to stride through > the collection set with each worker getting a different starting > index? The intent is to let different threads iterate over the entire list with each starting at a different index. I updated the change at http://cr.openjdk.java.net/~tschatzl/8159978/webrev.2/?(full) http://cr.openjdk.java.net/~tschatzl/8159978/webrev.1_to_2/?(diff) Changes include (from Erik Helin): - rename G1CollectionSet::set_max_size() to G1CollectionSet::initialize() because generally the post-construction method in our code base typically is called that. - removed the may_be_aborted parameter from?G1CollectionSet::iterate_from(), as it was basically used only for paranoia checking code. - closurified the?G1CollectionSet::verify_young_ages() and?G1CollectionSet::verify_young_cset_indices() methods. - some comments about MT safeness in g1CollectionSet.hpp - constified the G1CollectionSet::iterate* methods - fixed timing attribution Testing: jprt Thanks, ? Thomas From rkennke at redhat.com Wed Jun 29 13:38:28 2016 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 29 Jun 2016 15:38:28 +0200 Subject: RFR: 8154343: Make SATB related code available to other GCs In-Reply-To: References: <1460741484.2795.95.camel@redhat.com> <1460747869.2795.97.camel@redhat.com> <57115D73.7000000@oracle.com> <1460980206.3784.2.camel@redhat.com> <57151E5B.30106@oracle.com> <1461174867.4482.38.camel@redhat.com> <1461612690.4482.103.camel@redhat.com> <20160621151630.GC20451@ehelin.jrpg.bea.com> <1466527757.3203.106.camel@redhat.com> Message-ID: <1467207508.5199.48.camel@redhat.com> Am Dienstag, den 21.06.2016, 14:46 -0400 schrieb Kim Barrett: > > > > On Jun 21, 2016, at 12:49 PM, Roman Kennke > > wrote: > > > > > > how does moving ptrQueue.{hpp,cpp} and g1SATBMarkQueue.{hpp,cpp} > > > makes > > > merging easier for you guys?? > > We made some small changes for Shenandoah in those files. Now > > everytime > > I'm trying to merge a change from you guys, Mercurial flags all of > > it > > as red, and I need to go through it line by line and figure out > > what > > actually changed, and incorporate it into our changed version. I > > know > > it should be easier, I probably did something wrong, but that's how > > it > > is. > To me, this sounds like something may be messed up in your repo. Yep. > Moving files around doesn't seem like something that needs to be done > at this stage in the JDK 9 release cycle.??Some of the other changes > involve substantially more process, e.g. renaming product flags is > not > nearly so simple, requiring retention of the old names as deprecated > synonyms.??And there are other changes in there that want to think > about more, and would prefer were their own change sets, to be > considered separately from the file moves. Ok. > To move forward right now, an FC extension is required, per the > process described by Mark a couple of weeks ago. I don't think it needs to go into JDK9 at this point. Would be glad to discuss it, and when jdk10 starts rolling, go into that. Unless you think that's not a good idea :-) > Also, since this is a hotspot change, the right forest to base > against > and to be pushed to is presently jdk9/hs (was jdk9/hs-rt, but that > switch occurred right around the time of the initial RFR). Ok, good to know. > FYI, I have a stack of half a dozen or so pending cleanups and > refactorings in this area, with intent for at least a couple more. > Unfortunately, they didn't finish coming together until JDK 9 FC was > looming, so I'm going to have to sit on them for a while.??It would > be > a bit of a merging mess to have those files moved out from under my > mq > patches, though I could cope if it were really necessary.??Note that > some of these attempt to reduce the entanglement between these > classes > (esp. PtrQueue) and other parts of G1, which may have benefits for > Shenandoah too. > And no, this does not constitute the rewrite Erik suggested this area > needs. I've made a couple of forays in that direction, but have > always > been tripped up by various issues, some of which are fixed in that > pending stack.??I may try again once those settle. Ok, so I'll probably just wait for those patches for now. Thanks, Roman From vladimir.kempik at oracle.com Wed Jun 29 15:39:11 2016 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Wed, 29 Jun 2016 18:39:11 +0300 Subject: [8u] RFR 8158871: Long response times with G1 and StringDeduplication Message-ID: <6ceba0a2-466b-6098-0c93-342cf4e54f8e@oracle.com> Hello Please review this backport of 8158871 to jdk8u. Few changes for jdk8 were applied: 1) universall logging call changed to gclog_or_tty->print_cr 2) added casting of multiplication result (size_t * double) to size_t because on macosx platform the result was casted to double: _entry_cache = new G1StringDedupEntryCache((size_t)(_min_size * _max_cache_factor)); ... _entry_cache->set_max_size((size_t)(size * _max_cache_factor)); Testing: jprt Bug: https://bugs.openjdk.java.net/browse/JDK-8158871 Webrev: http://cr.openjdk.java.net/~vkempik/8158871/webrev.00/ Thanks -Vladimir From derek.white at oracle.com Wed Jun 29 16:37:11 2016 From: derek.white at oracle.com (Derek White) Date: Wed, 29 Jun 2016 12:37:11 -0400 Subject: Fwd: RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: <152e4a29-c21a-a15d-0f30-c88b9db2b566@oracle.com> References: <152e4a29-c21a-a15d-0f30-c88b9db2b566@oracle.com> Message-ID: Forward to runtime... This bug is a race condition between allocating a java.lang.Class instance and concurrent GC. https://bugs.openjdk.java.net/browse/JDK-8158946 There is an additional issue related to missing memory barriers in storing and loading an array's length or a java.lang.Class' oop_size field relative to the object's klass field, but that is handled by "JDK-8160369 Memory fences needed around setting and reading object lengths." Context: "As Kim mentioned, the new version sets the object size field of a java.lang.Class object before it sets the object's header, so GC can reliably get the size of any object with it's header set. This fix works by adding a CollectedHeap::class_allocate() method and associated helpers. These are implemented in CollectedHeap.inline.hpp only because they share so much structure and code with CollectedHeap::obj_allocate() that I thought it best to keep them together (even though there is no performance reason to have the new code inlined). " - Derek -------- Forwarded Message -------- Subject: Re: [RESUMED] RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated Date: Tue, 28 Jun 2016 12:37:23 -0400 From: Derek White Organization: Oracle To: Thomas Schatzl , Kim Barrett CC: hotspot-gc-dev at openjdk.java.net Hi Thomas, New webrev based on your suggestions: Webrev: http://cr.openjdk.java.net/~drwhite/8158946/webrev.03/ Incremental: http://cr.openjdk.java.net/~drwhite/8158946/webrev.02.vs.03 jprt in progress.... Misc comments below... - Derek On 6/28/16 9:09 AM, Thomas Schatzl wrote: > Hi, > > On Mon, 2016-06-27 at 10:10 -0400, Derek White wrote: >> I'd like to split out the memory fence issue from the race fixed by >> this webrev. I think the fence issue may require more performance >> testing and several attempts to get something satisfactory. >> >> New bug created: >> JDK-8160369 Memory fences needed around setting and reading >> object lengths. >> >> How do reviewers feel about this patch to fix the initial race >> condition? > looking at the 02 webrev: > > - http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/gc > /shared/collectedHeap.inline.hpp.frames.html > 105 // set the j.l.Class instance's oop_size field BEFORE setting the > header: > > I would like to have the "why" answered here in this comment and not a > repetition of the code. I think something like: "Concurrent readers > expect that the size is set before the klass pointer." > > Maybe the comment in lines 226/227 are more appropriate here? > > - the "obj" parameter is cast to an oop four times in > CollectedHeap::post_allocation_setup_class. Could you add a local > variable? OK, I cleaned this up by mirroring post_allocation_setup_array(). > - http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/oo > ps/instanceMirrorKlass.cpp.frames.html > > Not sure if repeating the exit condition in line 59 makes sense. OK. > - http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/oo > ps/oop.inline.hpp.frames.html > > Maybe fix the comment in 261 to a proper sentence. (And possibly 262, > like "Oop size must be larger than zero but is %d") OK Thanks for the suggestions! - Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.wilhelmsson at oracle.com Wed Jun 29 17:06:51 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 29 Jun 2016 19:06:51 +0200 Subject: RFR: 8024137 - Flags should be set using the proper macro In-Reply-To: <5772AF88.30107@oracle.com> References: <9e04cfe3-2c11-2080-9f7b-2f198a8a0d69@oracle.com> <5771BCC0.7020302@oracle.com> <5772AF88.30107@oracle.com> Message-ID: <0018b3d8-d9ba-4ca5-a418-8fcd2118cd60@oracle.com> Thanks Sangheon! /Jesper Den 28/6/16 kl. 19:10, skrev sangheon: > Hi Jesper, > > Looks good. > > Thanks, > Sangheon > > > On 06/28/2016 03:49 AM, Jesper Wilhelmsson wrote: >> Hi Sangheon, >> >> Thanks for reviewing! >> >> I have included a fix for g1YoungGenSizer as well. New webrev: >> >> http://cr.openjdk.java.net/~jwilhelm/8024137/webrev.01/ >> >> I also ran it through TestOptionsWithRanges. >> /Jesper >> >> Den 28/6/16 kl. 01:54, skrev sangheon: >>> Hi Jesper, >>> >>> On 06/21/2016 01:01 PM, Jesper Wilhelmsson wrote: >>>> Hi, >>>> >>>> Please review this change to make the GC ergonomics use FLAG_SET_ERGO() >>>> instead of setting values directly in flags. This change builds on the fix for >>>> JDK-8048093 and assumes that we will remember that the flags was set on the >>>> command line. >>>> >>>> If you know of any other places where we assign a flag directly without using >>>> FLAG_SET_ERGO() please let me know since it would make sense to change all >>>> these places in this change. >>> Looks good. >>> >>> The only place that I found is, >>> g1YoungGenSizer.cpp:48 >>> MaxNewSize = NewSize; >>> >>> And I recommend you to run TestOptionsWithRanges.java for all platforms. >>> Your change seems okay with the test but it would be better to run it if we >>> change flag related codes. >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8024137 >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8024137/webrev.00/ >>>> >>>> Thanks, >>>> /Jesper >>>> >>> > From jon.masamitsu at oracle.com Wed Jun 29 17:06:58 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 29 Jun 2016 10:06:58 -0700 Subject: RFR (M): 8159978: Use an array to store the collection set regions instead of linking through regions In-Reply-To: <1467203537.2413.24.camel@oracle.com> References: <1467029980.2352.41.camel@oracle.com> <1467116399.2435.18.camel@oracle.com> <8b595eeb-b222-2d2f-3ebb-4c93fb06b711@oracle.com> <1467203537.2413.24.camel@oracle.com> Message-ID: <57740032.4050707@oracle.com> On 06/29/2016 05:32 AM, Thomas Schatzl wrote: > Hi, > > On Tue, 2016-06-28 at 15:41 -0700, Jon Masamitsu wrote: >> Thomas, >> >> http://cr.openjdk.java.net/~tschatzl/8159978/webrev.1/src/share/vm/gc >> /g1/g1CollectedHeap.cpp.frames.html >> >> For an evacuation failure the region is set to old here >> >> 4664 // The region is now considered to be old. >> 4665 r->set_old(); >> >> and below the elapsed times are incremented. >> >> 4676 if (r->is_young()) { >> 4677 _young_time += os::elapsedTime() - start_time; >> 4678 } else { >> 4679 _non_young_time += os::elapsedTime() - start_time; >> 4680 } >> >> Is it correct that elapsed time for a failed evacuation will be now >> be added to the _non_young_time? Whereas before it was included in >> the _young_time because non_young was assigned a value before the >> evacuation failure was tested? > Unintended change. Fixed. Thanks. > > It would have been correct again in the follow-up change that > parallelizes collection set freeing, so that's why I probably > overlooked this. Sorry. No problem. > >> [..] >> http://cr.openjdk.java.net/~tschatzl/8159978/webrev.1/src/share/vm/gc >> /g1/g1CollectionSet.cpp.frames.html >> >> 177 void G1CollectionSet::iterate_from(HeapRegionClosure* cl, uint >> worker_id, uint total_workers, bool may_be_aborted) { >> >> I don't understand this iterate method. It seems like because of >> line 196 >> >> 195 if (cur_pos == len) { >> 196 cur_pos = 0; >> 197 } >> >> all the workers will process region 0 in the collection set. Is this >> method creating slices for each worker? Or trying to stride through >> the collection set with each worker getting a different starting >> index? > The intent is to let different threads iterate over the entire list > with each starting at a different index. Ok. > > I updated the change at > http://cr.openjdk.java.net/~tschatzl/8159978/webrev.2/ (full) > http://cr.openjdk.java.net/~tschatzl/8159978/webrev.1_to_2/ (diff) > > Changes include (from Erik Helin): > > - rename G1CollectionSet::set_max_size() to > G1CollectionSet::initialize() because generally the post-construction > method in our code base typically is called that. > > - removed the may_be_aborted parameter > from G1CollectionSet::iterate_from(), as it was basically used only for > paranoia checking code. > > - closurified the G1CollectionSet::verify_young_ages() > and G1CollectionSet::verify_young_cset_indices() methods. > > - some comments about MT safeness in g1CollectionSet.hpp > > - constified the G1CollectionSet::iterate* methods > > - fixed timing attribution Looks good. Jon > > Testing: > jprt > > Thanks, > Thomas > From derek.white at oracle.com Wed Jun 29 19:46:22 2016 From: derek.white at oracle.com (Derek White) Date: Wed, 29 Jun 2016 15:46:22 -0400 Subject: RFC: 8160369 - Memory fences needed around setting and reading object lengths Message-ID: [Request for Comment] This is a follow-on to some discussion that's been taking place on bug https://bugs.openjdk.java.net/browse/JDK-8160369. From Thomas: > Regular objects also need the barriers. I.e. the writing of the layout > helper of the Klass must happen before publishing the Klass pointer to > internal data structures (i.e. it is accessible by the mutator > threads). Regular (huge) objects may be allocated directly into the > old gen too. The issue is a bit simpler here, because we can assume > that there is an implicit loadload barrier when the reader accesses > the layout helper. Also, at least in G1, regular objects are always > allocated through the runtime. Hi Thomas, I think we might be in agreement about what should happen, but are differing in terms. I agree that when creating the C++ Klass object, we should have a storestore barrier between setting the layout helper field and publishing the Klass to the world. It sounds unlikely that a concurrent GC would ever see a store that stayed out-of-order through Klass creation, loading, initialization, and instance allocation, but I'd rather avoid that bug now :-) And I agree that the implicit loadload barrier in code like oop->klass()->layout_helper() is sufficient for the processors we care about. I'm not sure what you mean with the phrase "Regular objects also need the barriers" though. Do you mean in CollectedHeap::obj_allocate(), like we're adding to array_alloc() and class_alloc()? What is being written here that needs ordering? > And java.lang.Class instances also only need the barrier if allocated > into the old gen (afaik they are not). Interesting point. It turns out that huge java.lang.Class instances /can/ get allocated in the old gen. Also, Colleen mentioned that it might be nice if we could allocate all java.lang.Class instances directly in the old gen. It might be a good idea to only do the memory barriers when the object is in the old gen, but I'm not sure how the cost of testing this at runtime compares to the cost of the barriers themselves. I've been assuming that, statistically speaking, CollectedHeap::/foo/_allocate() is only called for old gen allocations, and the rest are handled by the compiled code or interpreter. Modulo a pile of corner cases. Similarly, we use memory barriers only when we're using a concurrent GC, if the cost trade-off made sense. > Also those "other" cases where the layout helper is < 0, and we take > the virtual call must be considered too (whatever these are) to make > sure that a loadload barrier is executed (assuming that instances of > these kind can be somehow allocated in old gen). I think the virtual calls for oop_size() end up using the layout helper (after all), using the array length, or using the oop_size field. So resolving the issue of ordering the length field or oop_size field should be sufficient. Thanks for looking at this issue! - Derek FYI - I have two stabs at fixing this issue: http://cr.openjdk.java.net/~drwhite/8160369/webrev.02 - Minimal barriers, but I'm not sure it's catching everything. http://cr.openjdk.java.net/~drwhite/8160369/webrev.03 - Smaller patch, possibly overly conservative. In both cases, I've used the call to oopDesc::klass_or_null() as a flag that the caller is some part of concurrent GC that is written to safely handle partially initialized objects. If klass_or_null() is called in other circumstances then my patches are doing too many barriers... -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek.white at oracle.com Wed Jun 29 21:27:36 2016 From: derek.white at oracle.com (Derek White) Date: Wed, 29 Jun 2016 17:27:36 -0400 Subject: RFR: 8024137 - Flags should be set using the proper macro In-Reply-To: References: <9e04cfe3-2c11-2080-9f7b-2f198a8a0d69@oracle.com> <5771BCC0.7020302@oracle.com> Message-ID: <4d829943-9837-650c-5e15-f09f37d72886@oracle.com> On 6/28/16 6:49 AM, Jesper Wilhelmsson wrote: > Hi Sangheon, > > Thanks for reviewing! > > I have included a fix for g1YoungGenSizer as well. New webrev: > > http://cr.openjdk.java.net/~jwilhelm/8024137/webrev.01/ > > I also ran it through TestOptionsWithRanges. > /Jesper > Hi Jesper, Looks good to me. - Derek From jon.masamitsu at oracle.com Wed Jun 29 21:38:36 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 29 Jun 2016 14:38:36 -0700 Subject: Request for Review (xs) - 8024945: Remove check on minimum size of MetaspaceSiz In-Reply-To: <002e4e70-b4b2-4ff2-fcfb-a705202e57f1@oracle.com> References: <575F2C00.1020906@oracle.com> <575F370F.2020500@oracle.com> <002e4e70-b4b2-4ff2-fcfb-a705202e57f1@oracle.com> Message-ID: <57743FDC.1060308@oracle.com> I overlooked some of tests in TestMetaspaceSizeFlags.java (but JPRT didn't). I deleted the tests that expected a message about MetaspaceSize being too small. Delta http://cr.openjdk.java.net/~jmasa/8024945/webrev_delta_01_02/ Updated complete http://cr.openjdk.java.net/~jmasa/8024945/webrev.02/ Sorry for dragging this out. Thanks. Jon On 06/24/2016 10:19 AM, Jon Masamitsu wrote: > Thanks Kim and Thomas for the previous reviews. Sorry for delay with the > latest updates. > > The only change from the first round is update of the @bug (as Kim > indicated) and the copyright update. > > The updated complete webrev is here > > http://cr.openjdk.java.net/~jmasa/8024945/webrev.01/ > > The delta is > > --- a/test/gc/metaspace/TestMetaspaceInitialization.java > +++ b/test/gc/metaspace/TestMetaspaceInitialization.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -24,7 +24,7 @@ > import java.util.ArrayList; > > /* @test TestMetaspaceInitialization > - * @bug 8042933 > + * @bug 8024945 > * @summary Tests to initialize metaspace with a very low MetaspaceSize > > Thanks. > > Jon > > On 6/13/2016 3:43 PM, Jon Masamitsu wrote: >> >> >> On 06/13/2016 03:29 PM, Kim Barrett wrote: >>>> On Jun 13, 2016, at 5:56 PM, Jon Masamitsu >>>> wrote: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8024945 >>>> >>>> Previous to this change the smallest MetaspaceSize value allowed >>>> was 256k. There is not reason for the restriction so this change >>>> removes it. A very small MetaspaceSize (even 0) does not cause >>>> a problem because during initialization a GC is not triggered unless >>>> the Metaspace needed grows beyond MaxMetaspaceSize. >>>> >>>> http://cr.openjdk.java.net/~jmasa/8024945/webrev.00/ >>>> >>>> Tested with -XX:MetaspaceSize=0. General testing with gc_test_suite. >>> Looks good. >> >> Thanks. >> >>> ------------------------------------------------------------------------------ >>> >>> test/gc/metaspace/TestMetaspaceInitialization.java >>> 27 * @bug 8042933 >>> >>> Should this be updated to also mention 8024945? >> >> Ah, yes. >> >> Fixed. >> >> Jon >>> >>> ------------------------------------------------------------------------------ >>> >>> >> > From kim.barrett at oracle.com Wed Jun 29 23:04:49 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 29 Jun 2016 19:04:49 -0400 Subject: Request for Review (xs) - 8024945: Remove check on minimum size of MetaspaceSiz In-Reply-To: <57743FDC.1060308@oracle.com> References: <575F2C00.1020906@oracle.com> <575F370F.2020500@oracle.com> <002e4e70-b4b2-4ff2-fcfb-a705202e57f1@oracle.com> <57743FDC.1060308@oracle.com> Message-ID: <926FA84A-7B41-4B0E-8310-1C4ABDFA7161@oracle.com> > On Jun 29, 2016, at 5:38 PM, Jon Masamitsu wrote: > > I overlooked some of tests in TestMetaspaceSizeFlags.java (but JPRT > didn't). I deleted the tests that expected a message about > MetaspaceSize being too small. > > Delta > > http://cr.openjdk.java.net/~jmasa/8024945/webrev_delta_01_02/ > > Updated complete > > http://cr.openjdk.java.net/~jmasa/8024945/webrev.02/ > > Sorry for dragging this out. Looks good. From david.holmes at oracle.com Thu Jun 30 04:28:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jun 2016 14:28:14 +1000 Subject: Fwd: RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: References: <152e4a29-c21a-a15d-0f30-c88b9db2b566@oracle.com> Message-ID: Hi Derek, Understand the fix in principle. But I don't understand why you got rid of java_lang_Class::set_oop_size, and instead exposed java_lang_Class::oop_size_offset(), then had InstanceMirrorKlass::allocate_instance pass the offset to CollectedHeap::class_allocate, which passes it to CollectedHeap::post_allocation_setup_class - that seems rather convoluted. Can CollectedHeap::post_allocation_setup_class not call java_lang_Class::set_oop_size directly? Thanks, David On 30/06/2016 2:37 AM, Derek White wrote: > Forward to runtime... > > This bug is a race condition between allocating a java.lang.Class > instance and concurrent GC. > https://bugs.openjdk.java.net/browse/JDK-8158946 > > There is an additional issue related to missing memory barriers in > storing and loading an array's length or a java.lang.Class' oop_size > field relative to the object's klass field, but that is handled by > "JDK-8160369 Memory > fences needed around setting and reading object lengths." > > Context: > > "As Kim mentioned, the new version sets the object size field of a > java.lang.Class object before it sets the object's header, so GC can > reliably get the size of any object with it's header set. > > This fix works by adding a CollectedHeap::class_allocate() method > and associated helpers. These are implemented in > CollectedHeap.inline.hpp only because they share so much structure > and code with CollectedHeap::obj_allocate() that I thought it best > to keep them together (even though there is no performance reason to > have the new code inlined). " > > - Derek > > -------- Forwarded Message -------- > Subject: Re: [RESUMED] RFR: 8158946 - btree009 fails with assert(s > 0) > failed: Bad size calculated > Date: Tue, 28 Jun 2016 12:37:23 -0400 > From: Derek White > Organization: Oracle > To: Thomas Schatzl , Kim Barrett > > CC: hotspot-gc-dev at openjdk.java.net > > > > Hi Thomas, > > New webrev based on your suggestions: > > Webrev: http://cr.openjdk.java.net/~drwhite/8158946/webrev.03/ > Incremental: http://cr.openjdk.java.net/~drwhite/8158946/webrev.02.vs.03 > > jprt in progress.... > > Misc comments below... > > - Derek > > On 6/28/16 9:09 AM, Thomas Schatzl wrote: >> Hi, >> >> On Mon, 2016-06-27 at 10:10 -0400, Derek White wrote: >>> I'd like to split out the memory fence issue from the race fixed by >>> this webrev. I think the fence issue may require more performance >>> testing and several attempts to get something satisfactory. >>> >>> New bug created: >>> JDK-8160369 Memory fences needed around setting and reading >>> object lengths. >>> >>> How do reviewers feel about this patch to fix the initial race >>> condition? >> looking at the 02 webrev: >> >> - http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/gc >> /shared/collectedHeap.inline.hpp.frames.html >> 105 // set the j.l.Class instance's oop_size field BEFORE setting the >> header: >> >> I would like to have the "why" answered here in this comment and not a >> repetition of the code. I think something like: "Concurrent readers >> expect that the size is set before the klass pointer." >> >> Maybe the comment in lines 226/227 are more appropriate here? >> >> - the "obj" parameter is cast to an oop four times in >> CollectedHeap::post_allocation_setup_class. Could you add a local >> variable? > OK, I cleaned this up by mirroring post_allocation_setup_array(). >> - http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/oo >> ps/instanceMirrorKlass.cpp.frames.html >> >> Not sure if repeating the exit condition in line 59 makes sense. > > OK. >> - http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/oo >> ps/oop.inline.hpp.frames.html >> >> Maybe fix the comment in 261 to a proper sentence. (And possibly 262, >> like "Oop size must be larger than zero but is %d") > OK > > Thanks for the suggestions! > > - Derek > > From per.liden at oracle.com Thu Jun 30 07:14:30 2016 From: per.liden at oracle.com (Per Liden) Date: Thu, 30 Jun 2016 09:14:30 +0200 Subject: [8u] RFR 8158871: Long response times with G1 and StringDeduplication In-Reply-To: <6ceba0a2-466b-6098-0c93-342cf4e54f8e@oracle.com> References: <6ceba0a2-466b-6098-0c93-342cf4e54f8e@oracle.com> Message-ID: <5774C6D6.5010605@oracle.com> Hi, On 2016-06-29 17:39, Vladimir Kempik wrote: > Hello > > Please review this backport of 8158871 to jdk8u. > > Few changes for jdk8 were applied: > > 1) universall logging call changed to gclog_or_tty->print_cr > > 2) added casting of multiplication result (size_t * double) to size_t > because on macosx platform the result was casted to double: > > _entry_cache = new G1StringDedupEntryCache((size_t)(_min_size * > _max_cache_factor)); > ... > _entry_cache->set_max_size((size_t)(size * _max_cache_factor)); > > > > > Testing: jprt > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158871 > Webrev: http://cr.openjdk.java.net/~vkempik/8158871/webrev.00/ src/share/vm/gc_implementation/g1/g1StringDedupTable.cpp -------------------------------------------------------- Since we don't have unified logging in 8 you need to check the PrintStringDeduplicationStatistics flags before printing "Deleted...". Also, since we don't have decorating tags we need more context in the printout. I suggest "[GC concurrent-string-deduplication, deleted X entries, X.XXX secs]". So, the incremental change would be: - gclog_or_tty->print_cr("Deleted " UINTX_FORMAT " entries, " G1_STRDEDUP_TIME_FORMAT, count, end - start); + if (PrintStringDeduplicationStatistics) { + gclog_or_tty->print_cr("[GC concurrent-string-deduplication, deleted " UINTX_FORMAT " entries, " G1_STRDEDUP_TIME_FORMAT "]", count, end - start); + } Other than that, the patch looks good. cheers, /Per > > Thanks > -Vladimir > From stefan.karlsson at oracle.com Thu Jun 30 08:12:02 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 30 Jun 2016 10:12:02 +0200 Subject: RFR: 8159974: G1 String deduplication logging not aligned with the rest of G1 In-Reply-To: <57712945.6070904@oracle.com> References: <57712945.6070904@oracle.com> Message-ID: <5774D452.4060105@oracle.com> Looks good. StefanK On 2016-06-27 15:25, Per Liden wrote: > Hi, > > Summary: With the introduction of Unified Logging, the > style/conventions used for GC logging was changed in various ways. > Some of the logging done by StringDedup was however left using the old > style. This patch aligns the dedup logging with the rest of G1. > > Webrev: http://cr.openjdk.java.net/~pliden/8159974/webrev.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8159974 > > Example, before: > ---------------- > [11.927s][info ][gc,stringdedup] Concurrent String Deduplication > 32.3M->32.3M(0.0B), avg 0.0%, 0.7633528 secs > [11.927s][debug][gc,stringdedup] [Last Exec: 0.7633528 secs, Idle: > 0.5195570 secs, Blocked: 0/0.0000000 secs] > [11.927s][debug][gc,stringdedup] [Inspected: 1410367] > [11.927s][debug][gc,stringdedup] [Skipped: 0( 0.0%)] > [11.927s][debug][gc,stringdedup] [Hashed: 1410367(100.0%)] > [11.927s][debug][gc,stringdedup] [Known: 0( 0.0%)] > [11.927s][debug][gc,stringdedup] [New: 1410367(100.0%) > 32.3M] > [11.927s][debug][gc,stringdedup] [Deduplicated: 0( 0.0%) > 0.0B( 0.0%)] > [11.927s][debug][gc,stringdedup] [Young: 0( 0.0%) 0.0B( > 0.0%)] > [11.927s][debug][gc,stringdedup] [Old: 0( 0.0%) 0.0B( > 0.0%)] > [11.927s][debug][gc,stringdedup] [Total Exec: 4/6.7536909 secs, > Idle: 4/4.1289840 secs, Blocked: 9/0.8971700 secs] > [11.927s][debug][gc,stringdedup] [Inspected: 7163002] > [11.927s][debug][gc,stringdedup] [Skipped: 0( 0.0%)] > [11.927s][debug][gc,stringdedup] [Hashed: 7159929(100.0%)] > [11.927s][debug][gc,stringdedup] [Known: 2916( 0.0%)] > [11.927s][debug][gc,stringdedup] [New: 7160086(100.0%) 163.9M] > [11.927s][debug][gc,stringdedup] [Deduplicated: 177( 0.0%) > 5120.0B( 0.0%)] > [11.927s][debug][gc,stringdedup] [Young: 0( 0.0%) 0.0B( > 0.0%)] > [11.927s][debug][gc,stringdedup] [Old: 177(100.0%) > 5120.0B(100.0%)] > [11.927s][debug][gc,stringdedup] [Table] > [11.927s][debug][gc,stringdedup] [Memory Usage: 250.6M] > [11.927s][debug][gc,stringdedup] [Size: 4194304, Min: 1024, Max: > 16777216] > [11.927s][debug][gc,stringdedup] [Entries: 7162825, Load: > 170.8%, Cached: 0, Added: 7162825, Removed: 0] > [11.927s][debug][gc,stringdedup] [Resize Count: 12, Shrink > Threshold: 2796202(66.7%), Grow Threshold: 8388608(200.0%)] > [11.927s][debug][gc,stringdedup] [Rehash Count: 0, Rehash > Threshold: 120, Hash Seed: 0x0] > [11.927s][debug][gc,stringdedup] [Age Threshold: 3] > [11.927s][debug][gc,stringdedup] [Queue] > [11.927s][debug][gc,stringdedup] [Dropped: 0] > > Example, after: > --------------- > [11.073s][info ][gc,stringdedup] Concurrent String Deduplication > (11.073s) > [11.975s][info ][gc,stringdedup] Concurrent String Deduplication > 33.2M->33.2M(0.0B) avg 0.0% (11.073s, 11.975s) 901.918ms > [11.975s][debug][gc,stringdedup] Last Exec: 901.918ms, Idle: > 407.930ms, Blocked: 0/0.000ms > [11.975s][debug][gc,stringdedup] Inspected: 1450663 > [11.975s][debug][gc,stringdedup] Skipped: 0( 0.0%) > [11.975s][debug][gc,stringdedup] Hashed: 1450663(100.0%) > [11.975s][debug][gc,stringdedup] Known: 0( 0.0%) > [11.975s][debug][gc,stringdedup] New: 1450663(100.0%) 33.2M > [11.975s][debug][gc,stringdedup] Deduplicated: 0( 0.0%) > 0.0B( 0.0%) > [11.975s][debug][gc,stringdedup] Young: 0( 0.0%) > 0.0B( 0.0%) > [11.975s][debug][gc,stringdedup] Old: 0( 0.0%) > 0.0B( 0.0%) > [11.975s][debug][gc,stringdedup] Total Exec: 4/7275.988ms, Idle: > 4/3620.653ms, Blocked: 8/929.258ms > [11.975s][debug][gc,stringdedup] Inspected: 7348199 > [11.975s][debug][gc,stringdedup] Skipped: 0( 0.0%) > [11.975s][debug][gc,stringdedup] Hashed: 7345126(100.0%) > [11.975s][debug][gc,stringdedup] Known: 2916( 0.0%) > [11.975s][debug][gc,stringdedup] New: 7345283(100.0%) 168.1M > [11.975s][debug][gc,stringdedup] Deduplicated: 177( 0.0%) > 5120.0B( 0.0%) > [11.975s][debug][gc,stringdedup] Young: 0( 0.0%) > 0.0B( 0.0%) > [11.975s][debug][gc,stringdedup] Old: 177(100.0%) 5120.0B(100.0%) > [11.975s][debug][gc,stringdedup] Table > [11.975s][debug][gc,stringdedup] Memory Usage: 256.2M > [11.975s][debug][gc,stringdedup] Size: 4194304, Min: 1024, Max: > 16777216 > [11.975s][debug][gc,stringdedup] Entries: 7348022, Load: 175.2%, > Cached: 0, Added: 7348022, Removed: 0 > [11.975s][debug][gc,stringdedup] Resize Count: 12, Shrink > Threshold: 2796202(66.7%), Grow Threshold: 8388608(200.0%) > [11.975s][debug][gc,stringdedup] Rehash Count: 0, Rehash > Threshold: 120, Hash Seed: 0x0 > [11.975s][debug][gc,stringdedup] Age Threshold: 3 > [11.975s][debug][gc,stringdedup] Queue > [11.975s][debug][gc,stringdedup] Dropped: 0 > > cheers, > Per > From thomas.schatzl at oracle.com Thu Jun 30 08:27:28 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 30 Jun 2016 10:27:28 +0200 Subject: RFR (M): 8159978: Use an array to store the collection set regions instead of linking through regions In-Reply-To: <57740032.4050707@oracle.com> References: <1467029980.2352.41.camel@oracle.com> <1467116399.2435.18.camel@oracle.com> <8b595eeb-b222-2d2f-3ebb-4c93fb06b711@oracle.com> <1467203537.2413.24.camel@oracle.com> <57740032.4050707@oracle.com> Message-ID: <1467275248.2417.1.camel@oracle.com> Hi Jon, On Wed, 2016-06-29 at 10:06 -0700, Jon Masamitsu wrote: > > On 06/29/2016 05:32 AM, Thomas Schatzl wrote: > > > > Hi, > > > > On Tue, 2016-06-28 at 15:41 -0700, Jon Masamitsu wrote: > > > > > > Thomas, > > > > > > [...] > > - constified the G1CollectionSet::iterate* methods > > > > - fixed timing attribution > Looks good. > > Jon ? thanks for your review. Thomas From aph at redhat.com Thu Jun 30 08:33:22 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 30 Jun 2016 09:33:22 +0100 Subject: RFC: 8160369 - Memory fences needed around setting and reading object lengths In-Reply-To: References: Message-ID: <5774D952.6090003@redhat.com> On 29/06/16 20:46, Derek White wrote: > And I agree that the implicit loadload barrier in code like > oop->klass()->layout_helper() is sufficient for the processors we care > about. I'm not sure. While we know that the hardware respects address dependency ordering in these cases, a smart optimizing compiler might work out that it doesn't need to read the klass field. It is extremely hard (impossible!) to reason about dependencies at the C++ source level, especially in the presence of data races. C++ now provides order_access_consume for exactly this use, and if we're going to make assumptions about address dependencies we should use consume. This might mean that we'll have to define a "fake" macro for now. Then, wen we start to use a more up-to-date C++ compiler we can re-implement this stuff with real C++ atomics. Andrew. From aph at redhat.com Thu Jun 30 08:34:32 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 30 Jun 2016 09:34:32 +0100 Subject: RFC: 8160369 - Memory fences needed around setting and reading object lengths In-Reply-To: References: Message-ID: <5774D998.1000001@redhat.com> On 29/06/16 20:46, Derek White wrote: > It might be a good idea to only do the memory barriers when the object > is in the old gen, but I'm not sure how the cost of testing this at > runtime compares to the cost of the barriers themselves. Exactly. The cost of a mispredicted branch at runtime isn't necessarily less than that cost of a read fence. Andrew. From thomas.schatzl at oracle.com Thu Jun 30 08:40:05 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 30 Jun 2016 10:40:05 +0200 Subject: Request for Review (s) - 8157240: GC task trace logging is incomprehensible In-Reply-To: <9c5208fd-7128-0349-89d1-5e0200f5491b@oracle.com> References: <9c5208fd-7128-0349-89d1-5e0200f5491b@oracle.com> Message-ID: <1467276005.2417.8.camel@oracle.com> Hi Jon, On Fri, 2016-06-24 at 19:33 -0700, Jon Masamitsu wrote: > https://bugs.openjdk.java.net/browse/JDK-8157240 > > Fix the logging for GC worker creation so that it is consistent and > adds the GC worker name to the logging. > > http://cr.openjdk.java.net/~jmasa/8157240/webrev.00/index.html > > Tested by hand to verify output and with > TestDynamicNumberOfGCThreads.java. ?- How is it possible that the worker_name() methods return NULL? Is this supposed to help for threads not created yet? If that were the case, the logging code would crash too. Wouldn't that be an error in any case, and as such, I would prefer some assert in the worker_name() methods for invalid index (or something like this). - The indentation of the parameters for +??static void log_worker_creation(WorkerType* holder, +???????????????????????????uint previous_created_workers, +???????????????????????????uint active_workers, +???????????????????????????uint created_workers, +???????????????????????????bool initializing) { in workerManager.hpp is wrong - the output seems to really be some kind of developer oriented debug output, mentioning method names and variable names. Maybe something more readable would be nice, but then again it is some trace level message. No particular opinion here, but maybe somebody else has a similar opinion. - would it be possible to write a short regression test checking the output? Thanks, ? Thomas From thomas.schatzl at oracle.com Thu Jun 30 08:48:38 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 30 Jun 2016 10:48:38 +0200 Subject: RFR: 8159893: StringTable cleaning log line lacks the GC ID prefix In-Reply-To: <576A5A36.40503@oracle.com> References: <5767E7B6.8010904@oracle.com> <576814EB.8060401@oracle.com> <57692BCE.70706@oracle.com> <4E3C30A5-DAAA-4AE2-BA57-3A34F06CBEE7@kodewerk.com> <576A5A36.40503@oracle.com> Message-ID: <1467276518.2417.9.camel@oracle.com> Hi Stefan, > > > On Jun 21, 2016, at 1:58 PM, Stefan Karlsson > > cle.com> wrote: > > > > > > Thanks, Jon. > > > > > > StefanK > > > > > > On 2016-06-20 18:08, Jon Masamitsu wrote: > > > > > > > > Change looks good. > > > > > > > > Jon > > > > > > > > On 06/20/2016 05:55 AM, Stefan Karlsson wrote: > > > > > > > > > > Hi all, > > > > > > > > > > Please review this patch to fix the log line of the > > > > > StringTable cleaning: > > > > > > > > > > http://cr.openjdk.java.net/~stefank/8159893/webrev.00/ > > > > > https://bugs.openjdk.java.net/browse/JDK-8159893 > > > > > looks good. Thomas From derek.white at oracle.com Thu Jun 30 11:56:33 2016 From: derek.white at oracle.com (Derek White) Date: Thu, 30 Jun 2016 07:56:33 -0400 Subject: Fwd: RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated In-Reply-To: References: <152e4a29-c21a-a15d-0f30-c88b9db2b566@oracle.com> Message-ID: On 6/30/16 12:28 AM, David Holmes wrote: > Hi Derek, > > Understand the fix in principle. > > But I don't understand why you got rid of > java_lang_Class::set_oop_size, and instead exposed > java_lang_Class::oop_size_offset(), then had > InstanceMirrorKlass::allocate_instance pass the offset to > CollectedHeap::class_allocate, which passes it to > CollectedHeap::post_allocation_setup_class - that seems rather > convoluted. Can CollectedHeap::post_allocation_setup_class not call > java_lang_Class::set_oop_size directly? Short answer is I didn't think so. collectedHeap.inline.hpp has a very small include set, and I was concerned about circular dependencies. Another approach would be to push ::set_oop_size() over to instanceKlassMirror.hpp, and see if the includes seem saner that way. I'll try some alternatives... Thanks! - Derek > > Thanks, > David > > > On 30/06/2016 2:37 AM, Derek White wrote: >> Forward to runtime... >> >> This bug is a race condition between allocating a java.lang.Class >> instance and concurrent GC. >> https://bugs.openjdk.java.net/browse/JDK-8158946 >> >> There is an additional issue related to missing memory barriers in >> storing and loading an array's length or a java.lang.Class' oop_size >> field relative to the object's klass field, but that is handled by >> "JDK-8160369 Memory >> fences needed around setting and reading object lengths." >> >> Context: >> >> "As Kim mentioned, the new version sets the object size field of a >> java.lang.Class object before it sets the object's header, so GC can >> reliably get the size of any object with it's header set. >> >> This fix works by adding a CollectedHeap::class_allocate() method >> and associated helpers. These are implemented in >> CollectedHeap.inline.hpp only because they share so much structure >> and code with CollectedHeap::obj_allocate() that I thought it best >> to keep them together (even though there is no performance reason to >> have the new code inlined). " >> >> - Derek >> >> -------- Forwarded Message -------- >> Subject: Re: [RESUMED] RFR: 8158946 - btree009 fails with >> assert(s > 0) >> failed: Bad size calculated >> Date: Tue, 28 Jun 2016 12:37:23 -0400 >> From: Derek White >> Organization: Oracle >> To: Thomas Schatzl , Kim Barrett >> >> CC: hotspot-gc-dev at openjdk.java.net >> >> >> >> Hi Thomas, >> >> New webrev based on your suggestions: >> >> Webrev: http://cr.openjdk.java.net/~drwhite/8158946/webrev.03/ >> Incremental: http://cr.openjdk.java.net/~drwhite/8158946/webrev.02.vs.03 >> >> jprt in progress.... >> >> Misc comments below... >> >> - Derek >> >> On 6/28/16 9:09 AM, Thomas Schatzl wrote: >>> Hi, >>> >>> On Mon, 2016-06-27 at 10:10 -0400, Derek White wrote: >>>> I'd like to split out the memory fence issue from the race fixed by >>>> this webrev. I think the fence issue may require more performance >>>> testing and several attempts to get something satisfactory. >>>> >>>> New bug created: >>>> JDK-8160369 Memory fences needed around setting and reading >>>> object lengths. >>>> >>>> How do reviewers feel about this patch to fix the initial race >>>> condition? >>> looking at the 02 webrev: >>> >>> - http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/gc >>> /shared/collectedHeap.inline.hpp.frames.html >>> 105 // set the j.l.Class instance's oop_size field BEFORE setting the >>> header: >>> >>> I would like to have the "why" answered here in this comment and not a >>> repetition of the code. I think something like: "Concurrent readers >>> expect that the size is set before the klass pointer." >>> >>> Maybe the comment in lines 226/227 are more appropriate here? >>> >>> - the "obj" parameter is cast to an oop four times in >>> CollectedHeap::post_allocation_setup_class. Could you add a local >>> variable? >> OK, I cleaned this up by mirroring post_allocation_setup_array(). >>> - http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/oo >>> ps/instanceMirrorKlass.cpp.frames.html >>> >>> Not sure if repeating the exit condition in line 59 makes sense. >> >> OK. >>> - http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/oo >>> ps/oop.inline.hpp.frames.html >>> >>> Maybe fix the comment in 261 to a proper sentence. (And possibly 262, >>> like "Oop size must be larger than zero but is %d") >> OK >> >> Thanks for the suggestions! >> >> - Derek >> >> From vladimir.kempik at oracle.com Thu Jun 30 11:57:27 2016 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Thu, 30 Jun 2016 14:57:27 +0300 Subject: [8u] RFR 8158871: Long response times with G1 and StringDeduplication In-Reply-To: <5774C6D6.5010605@oracle.com> References: <6ceba0a2-466b-6098-0c93-342cf4e54f8e@oracle.com> <5774C6D6.5010605@oracle.com> Message-ID: <666fb51d-c94c-d649-faab-38347aaacd62@oracle.com> Hello Thanks for the comment Per. Here is updated webrev - http://cr.openjdk.java.net/~vkempik/8158871/webrev.01/ Can I have some jdk8 reviewer to take quick look at this as well? Thanks. On 30.06.2016 10:14, Per Liden wrote: > Hi, > > On 2016-06-29 17:39, Vladimir Kempik wrote: >> Hello >> >> Please review this backport of 8158871 to jdk8u. >> >> Few changes for jdk8 were applied: >> >> 1) universall logging call changed to gclog_or_tty->print_cr >> >> 2) added casting of multiplication result (size_t * double) to size_t >> because on macosx platform the result was casted to double: >> >> _entry_cache = new G1StringDedupEntryCache((size_t)(_min_size * >> _max_cache_factor)); >> ... >> _entry_cache->set_max_size((size_t)(size * _max_cache_factor)); >> >> >> >> >> Testing: jprt >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158871 >> Webrev: http://cr.openjdk.java.net/~vkempik/8158871/webrev.00/ > > > src/share/vm/gc_implementation/g1/g1StringDedupTable.cpp > -------------------------------------------------------- > Since we don't have unified logging in 8 you need to check the > PrintStringDeduplicationStatistics flags before printing "Deleted...". > Also, since we don't have decorating tags we need more context in the > printout. I suggest "[GC concurrent-string-deduplication, deleted X > entries, X.XXX secs]". > > So, the incremental change would be: > > - gclog_or_tty->print_cr("Deleted " UINTX_FORMAT " entries, " > G1_STRDEDUP_TIME_FORMAT, count, end - start); > + if (PrintStringDeduplicationStatistics) { > + gclog_or_tty->print_cr("[GC concurrent-string-deduplication, > deleted " UINTX_FORMAT " entries, " G1_STRDEDUP_TIME_FORMAT "]", > count, end - start); > + } > > > Other than that, the patch looks good. > > cheers, > /Per > >> >> Thanks >> -Vladimir >> From thomas.schatzl at oracle.com Thu Jun 30 12:09:41 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 30 Jun 2016 14:09:41 +0200 Subject: [8u] RFR 8158871: Long response times with G1 and StringDeduplication In-Reply-To: <666fb51d-c94c-d649-faab-38347aaacd62@oracle.com> References: <6ceba0a2-466b-6098-0c93-342cf4e54f8e@oracle.com> <5774C6D6.5010605@oracle.com> <666fb51d-c94c-d649-faab-38347aaacd62@oracle.com> Message-ID: <1467288581.2417.11.camel@oracle.com> Hi, On Thu, 2016-06-30 at 14:57 +0300, Vladimir Kempik wrote: > Hello > > Thanks for the comment Per. > > Here is updated webrev -? > http://cr.openjdk.java.net/~vkempik/8158871/webrev.01/ > > Can I have some jdk8 reviewer to take quick look at this as well? ? looks good to me. Thanks, ? Thomas (only 8u Reviewer, but you are probably not pushing into 8 anyway ;)) From erik.helin at oracle.com Thu Jun 30 16:02:36 2016 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 30 Jun 2016 18:02:36 +0200 Subject: RFR (M): 8159978: Use an array to store the collection set regions instead of linking through regions In-Reply-To: <1467203537.2413.24.camel@oracle.com> References: <1467029980.2352.41.camel@oracle.com> <1467116399.2435.18.camel@oracle.com> <8b595eeb-b222-2d2f-3ebb-4c93fb06b711@oracle.com> <1467203537.2413.24.camel@oracle.com> Message-ID: <20160630160236.GB13712@ehelin.jrpg.bea.com> On 2016-06-29, Thomas Schatzl wrote: > Hi, > > On Tue, 2016-06-28 at 15:41 -0700, Jon Masamitsu wrote: > > Thomas, > > > > http://cr.openjdk.java.net/~tschatzl/8159978/webrev.1/src/share/vm/gc > > /g1/g1CollectedHeap.cpp.frames.html > > > > For an evacuation failure the region is set to old here > > > > 4664???????// The region is now considered to be old. > > 4665???????r->set_old(); > > > > and below the elapsed times are incremented. > > > > 4676?????if (r->is_young()) { > > 4677???????_young_time += os::elapsedTime() - start_time; > > 4678?????} else { > > 4679???????_non_young_time += os::elapsedTime() - start_time; > > 4680?????} > > > > Is it correct that elapsed time for a failed evacuation will be now > > be added to the _non_young_time?? Whereas before it was included in > > the _young_time because non_young was assigned a value before the > > evacuation failure was tested? > > Unintended change. Fixed. > > It would have been correct again in the follow-up change that > parallelizes collection set freeing, so that's why I probably > overlooked this. Sorry. > > > > [..] > > > http://cr.openjdk.java.net/~tschatzl/8159978/webrev.1/src/share/vm/gc > > /g1/g1CollectionSet.cpp.frames.html > > > > ? 177 void G1CollectionSet::iterate_from(HeapRegionClosure* cl, uint > > worker_id, uint total_workers, bool may_be_aborted) { > > > > I don't understand this iterate method.? It seems like because of > > line 196 > > > > ?195?????if (cur_pos == len) { > > ?196???????cur_pos = 0; > > ?197?????} > > > > all the workers will process region 0 in the collection set.? Is this > > method creating slices for each worker?? Or trying to stride through > > the collection set with each worker getting a different starting > > index? > > The intent is to let different threads iterate over the entire list > with each starting at a different index. > > I updated the change at > http://cr.openjdk.java.net/~tschatzl/8159978/webrev.2/?(full) > http://cr.openjdk.java.net/~tschatzl/8159978/webrev.1_to_2/?(diff) Looks good, Reviewed. Nice work Thomas! Erik > Changes include (from Erik Helin): > > - rename G1CollectionSet::set_max_size() to > G1CollectionSet::initialize() because generally the post-construction > method in our code base typically is called that. > > - removed the may_be_aborted parameter > from?G1CollectionSet::iterate_from(), as it was basically used only for > paranoia checking code. > > - closurified the?G1CollectionSet::verify_young_ages() > and?G1CollectionSet::verify_young_cset_indices() methods. > > - some comments about MT safeness in g1CollectionSet.hpp > > - constified the G1CollectionSet::iterate* methods > > - fixed timing attribution > > Testing: > jprt > > Thanks, > ? Thomas > From jon.masamitsu at oracle.com Thu Jun 30 17:42:58 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 30 Jun 2016 10:42:58 -0700 Subject: Request for Review (s) - 8157240: GC task trace logging is incomprehensible In-Reply-To: <1467276005.2417.8.camel@oracle.com> References: <9c5208fd-7128-0349-89d1-5e0200f5491b@oracle.com> <1467276005.2417.8.camel@oracle.com> Message-ID: <57755A22.6050706@oracle.com> Thomas, Thanks for looking at this. On 06/30/2016 01:40 AM, Thomas Schatzl wrote: > Hi Jon, > > On Fri, 2016-06-24 at 19:33 -0700, Jon Masamitsu wrote: >> https://bugs.openjdk.java.net/browse/JDK-8157240 >> >> Fix the logging for GC worker creation so that it is consistent and >> adds the GC worker name to the logging. >> >> http://cr.openjdk.java.net/~jmasa/8157240/webrev.00/index.html >> >> Tested by hand to verify output and with >> TestDynamicNumberOfGCThreads.java. > - How is it possible that the worker_name() methods return NULL? Is > this supposed to help for threads not created yet? Yes, if the thread has not been created yet, NULL is returned. > > If that were the case, the logging code would crash too. > > Wouldn't that be an error in any case, and as such, I would prefer some > assert in the worker_name() methods for invalid index (or something > like this). I would have preferred to work with just the generic name of the thread such as "G1 Marker" but name() for a NamedThread always appended the thread number (such as #0) to the name of the thread. Using the field from NamedThread avoided the difference between AbstactWorkGang and GCTaskManager but I'll figure out how to dig out the thread name and use that instead. > > - The indentation of the parameters for > > + static void log_worker_creation(WorkerType* holder, > + uint previous_created_workers, > + uint active_workers, > + uint created_workers, > + bool initializing) { > > in workerManager.hpp is wrong Will fix. > > - the output seems to really be some kind of developer oriented debug > output, mentioning method names and variable names. Maybe something > more readable would be nice, but then again it is some trace level > message. I'll work on a better format and get back with it. > > No particular opinion here, but maybe somebody else has a similar > opinion. > > - would it be possible to write a short regression test checking the > output? I'll add some tests. Jon > > Thanks, > Thomas From per.liden at oracle.com Thu Jun 30 19:49:22 2016 From: per.liden at oracle.com (Per Liden) Date: Thu, 30 Jun 2016 21:49:22 +0200 Subject: RFR: 8159974: G1 String deduplication logging not aligned with the rest of G1 In-Reply-To: <5774D452.4060105@oracle.com> References: <57712945.6070904@oracle.com> <5774D452.4060105@oracle.com> Message-ID: <6d625267-21a6-24c1-ea5f-9503a1342de0@oracle.com> Thanks Stefan. Per On 2016-06-30 10:12, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2016-06-27 15:25, Per Liden wrote: >> Hi, >> >> Summary: With the introduction of Unified Logging, the >> style/conventions used for GC logging was changed in various ways. >> Some of the logging done by StringDedup was however left using the old >> style. This patch aligns the dedup logging with the rest of G1. >> >> Webrev: http://cr.openjdk.java.net/~pliden/8159974/webrev.0/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8159974 >> >> Example, before: >> ---------------- >> [11.927s][info ][gc,stringdedup] Concurrent String Deduplication >> 32.3M->32.3M(0.0B), avg 0.0%, 0.7633528 secs >> [11.927s][debug][gc,stringdedup] [Last Exec: 0.7633528 secs, Idle: >> 0.5195570 secs, Blocked: 0/0.0000000 secs] >> [11.927s][debug][gc,stringdedup] [Inspected: 1410367] >> [11.927s][debug][gc,stringdedup] [Skipped: 0( 0.0%)] >> [11.927s][debug][gc,stringdedup] [Hashed: 1410367(100.0%)] >> [11.927s][debug][gc,stringdedup] [Known: 0( 0.0%)] >> [11.927s][debug][gc,stringdedup] [New: 1410367(100.0%) >> 32.3M] >> [11.927s][debug][gc,stringdedup] [Deduplicated: 0( 0.0%) >> 0.0B( 0.0%)] >> [11.927s][debug][gc,stringdedup] [Young: 0( 0.0%) 0.0B( >> 0.0%)] >> [11.927s][debug][gc,stringdedup] [Old: 0( 0.0%) 0.0B( >> 0.0%)] >> [11.927s][debug][gc,stringdedup] [Total Exec: 4/6.7536909 secs, >> Idle: 4/4.1289840 secs, Blocked: 9/0.8971700 secs] >> [11.927s][debug][gc,stringdedup] [Inspected: 7163002] >> [11.927s][debug][gc,stringdedup] [Skipped: 0( 0.0%)] >> [11.927s][debug][gc,stringdedup] [Hashed: 7159929(100.0%)] >> [11.927s][debug][gc,stringdedup] [Known: 2916( 0.0%)] >> [11.927s][debug][gc,stringdedup] [New: 7160086(100.0%) 163.9M] >> [11.927s][debug][gc,stringdedup] [Deduplicated: 177( 0.0%) >> 5120.0B( 0.0%)] >> [11.927s][debug][gc,stringdedup] [Young: 0( 0.0%) 0.0B( >> 0.0%)] >> [11.927s][debug][gc,stringdedup] [Old: 177(100.0%) >> 5120.0B(100.0%)] >> [11.927s][debug][gc,stringdedup] [Table] >> [11.927s][debug][gc,stringdedup] [Memory Usage: 250.6M] >> [11.927s][debug][gc,stringdedup] [Size: 4194304, Min: 1024, Max: >> 16777216] >> [11.927s][debug][gc,stringdedup] [Entries: 7162825, Load: >> 170.8%, Cached: 0, Added: 7162825, Removed: 0] >> [11.927s][debug][gc,stringdedup] [Resize Count: 12, Shrink >> Threshold: 2796202(66.7%), Grow Threshold: 8388608(200.0%)] >> [11.927s][debug][gc,stringdedup] [Rehash Count: 0, Rehash >> Threshold: 120, Hash Seed: 0x0] >> [11.927s][debug][gc,stringdedup] [Age Threshold: 3] >> [11.927s][debug][gc,stringdedup] [Queue] >> [11.927s][debug][gc,stringdedup] [Dropped: 0] >> >> Example, after: >> --------------- >> [11.073s][info ][gc,stringdedup] Concurrent String Deduplication >> (11.073s) >> [11.975s][info ][gc,stringdedup] Concurrent String Deduplication >> 33.2M->33.2M(0.0B) avg 0.0% (11.073s, 11.975s) 901.918ms >> [11.975s][debug][gc,stringdedup] Last Exec: 901.918ms, Idle: >> 407.930ms, Blocked: 0/0.000ms >> [11.975s][debug][gc,stringdedup] Inspected: 1450663 >> [11.975s][debug][gc,stringdedup] Skipped: 0( 0.0%) >> [11.975s][debug][gc,stringdedup] Hashed: 1450663(100.0%) >> [11.975s][debug][gc,stringdedup] Known: 0( 0.0%) >> [11.975s][debug][gc,stringdedup] New: 1450663(100.0%) 33.2M >> [11.975s][debug][gc,stringdedup] Deduplicated: 0( 0.0%) >> 0.0B( 0.0%) >> [11.975s][debug][gc,stringdedup] Young: 0( 0.0%) >> 0.0B( 0.0%) >> [11.975s][debug][gc,stringdedup] Old: 0( 0.0%) >> 0.0B( 0.0%) >> [11.975s][debug][gc,stringdedup] Total Exec: 4/7275.988ms, Idle: >> 4/3620.653ms, Blocked: 8/929.258ms >> [11.975s][debug][gc,stringdedup] Inspected: 7348199 >> [11.975s][debug][gc,stringdedup] Skipped: 0( 0.0%) >> [11.975s][debug][gc,stringdedup] Hashed: 7345126(100.0%) >> [11.975s][debug][gc,stringdedup] Known: 2916( 0.0%) >> [11.975s][debug][gc,stringdedup] New: 7345283(100.0%) 168.1M >> [11.975s][debug][gc,stringdedup] Deduplicated: 177( 0.0%) >> 5120.0B( 0.0%) >> [11.975s][debug][gc,stringdedup] Young: 0( 0.0%) >> 0.0B( 0.0%) >> [11.975s][debug][gc,stringdedup] Old: 177(100.0%) 5120.0B(100.0%) >> [11.975s][debug][gc,stringdedup] Table >> [11.975s][debug][gc,stringdedup] Memory Usage: 256.2M >> [11.975s][debug][gc,stringdedup] Size: 4194304, Min: 1024, Max: >> 16777216 >> [11.975s][debug][gc,stringdedup] Entries: 7348022, Load: 175.2%, >> Cached: 0, Added: 7348022, Removed: 0 >> [11.975s][debug][gc,stringdedup] Resize Count: 12, Shrink >> Threshold: 2796202(66.7%), Grow Threshold: 8388608(200.0%) >> [11.975s][debug][gc,stringdedup] Rehash Count: 0, Rehash >> Threshold: 120, Hash Seed: 0x0 >> [11.975s][debug][gc,stringdedup] Age Threshold: 3 >> [11.975s][debug][gc,stringdedup] Queue >> [11.975s][debug][gc,stringdedup] Dropped: 0 >> >> cheers, >> Per >> > From per.liden at oracle.com Thu Jun 30 19:50:12 2016 From: per.liden at oracle.com (Per Liden) Date: Thu, 30 Jun 2016 21:50:12 +0200 Subject: [8u] RFR 8158871: Long response times with G1 and StringDeduplication In-Reply-To: <666fb51d-c94c-d649-faab-38347aaacd62@oracle.com> References: <6ceba0a2-466b-6098-0c93-342cf4e54f8e@oracle.com> <5774C6D6.5010605@oracle.com> <666fb51d-c94c-d649-faab-38347aaacd62@oracle.com> Message-ID: <83e69d06-3edb-9fa4-d010-a6ac2bf02050@oracle.com> On 2016-06-30 13:57, Vladimir Kempik wrote: > Hello > > Thanks for the comment Per. > > Here is updated webrev - > http://cr.openjdk.java.net/~vkempik/8158871/webrev.01/ Looks good. /Per > > Can I have some jdk8 reviewer to take quick look at this as well? > > Thanks. > > On 30.06.2016 10:14, Per Liden wrote: >> Hi, >> >> On 2016-06-29 17:39, Vladimir Kempik wrote: >>> Hello >>> >>> Please review this backport of 8158871 to jdk8u. >>> >>> Few changes for jdk8 were applied: >>> >>> 1) universall logging call changed to gclog_or_tty->print_cr >>> >>> 2) added casting of multiplication result (size_t * double) to size_t >>> because on macosx platform the result was casted to double: >>> >>> _entry_cache = new G1StringDedupEntryCache((size_t)(_min_size * >>> _max_cache_factor)); >>> ... >>> _entry_cache->set_max_size((size_t)(size * _max_cache_factor)); >>> >>> >>> >>> >>> Testing: jprt >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8158871 >>> Webrev: http://cr.openjdk.java.net/~vkempik/8158871/webrev.00/ >> >> >> src/share/vm/gc_implementation/g1/g1StringDedupTable.cpp >> -------------------------------------------------------- >> Since we don't have unified logging in 8 you need to check the >> PrintStringDeduplicationStatistics flags before printing "Deleted...". >> Also, since we don't have decorating tags we need more context in the >> printout. I suggest "[GC concurrent-string-deduplication, deleted X >> entries, X.XXX secs]". >> >> So, the incremental change would be: >> >> - gclog_or_tty->print_cr("Deleted " UINTX_FORMAT " entries, " >> G1_STRDEDUP_TIME_FORMAT, count, end - start); >> + if (PrintStringDeduplicationStatistics) { >> + gclog_or_tty->print_cr("[GC concurrent-string-deduplication, >> deleted " UINTX_FORMAT " entries, " G1_STRDEDUP_TIME_FORMAT "]", >> count, end - start); >> + } >> >> >> Other than that, the patch looks good. >> >> cheers, >> /Per >> >>> >>> Thanks >>> -Vladimir >>> > From mark.reinhold at oracle.com Thu Jun 30 21:35:10 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 30 Jun 2016 14:35:10 -0700 (PDT) Subject: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector Message-ID: <20160630213510.62860B5E08@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/291 - Mark