May 2013 - hotspot-gc-dev

Request for Review (s) - 8014862:Add fast Metasapce capacity and used per MetadataType
by Jon Masamitsu 20 May '13

20 May '13

This fix calculates the running sums for allocated capacity and allocated used in MetaspaceAux to be per MetaspaceType instead of the sum of both types. http://cr.openjdk.java.net/~jmasa/8014862/webrev.00/

2 5

RFR (XS): 6843375: Debuggee VM crashes performing mark-sweep-compact
by Erik Helin 20 May '13

20 May '13

Hi all, this change fixes a problem when a VM_ChangeBreakpoint operation is enqueued on the VMOperationQueue while at the same time as a GC is running. The GC will process the strong roots and will call both VMOperationQueue::oops_do (via Threads::oops_do) and JvmtiExport::oops_do. VMOperationQueue::oops_do will call VM_ChangeBreakpoint::oops_do which calls JvmtiBreakpoints::oops_do. The problem is that JvmtiExport::oops_do calls JvmtiCurrentBreakpoints::oops_do which points to the same JvmtiBreakpoints as the one VM_ChangeBreakpoint just called oops_do on. This change remove the code VM_ChangeBreakpoint that calls JvmtiBreakpoints::oops_do. All the GCs will visit the breakpoints via JvmtiExport. Webrev: http://cr.openjdk.java.net/~ehelin/6843375/webrev/ Testing: JPRT Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6843375 Thanks, Erik

3 9

RFR: 8013934: Garbage collection event for CMS has wrong cause for System.gc()
by Erik Helin 20 May '13

20 May '13

Hi all, this change fixes an issue with the cause field in the vm/gc/collector/garbage_collection trace event for CMS. When executing a GC via a call to System.gc, then cause was not "System.gc" for CMS in the trace event as expected (it was "CMS concurrent mark"). The problem is that the VM operation VM_GenCollectFullConcurrent gets the cause as parameter but does not pass it on to the CMSCollector. This change adds the parameter "cause" to CMSCollector::request_full_gc and the CMSCollector then saves the parameter as CMSCollector::_full_gc_cause. Webrev: http://cr.openjdk.java.net/~ehelin/8013934/webrev.00/ Thanks, Erik

3 3

RFR (S): 7176220 'Full GC' events miss date stamp information occasionally
by Andreas Eriksson 20 May '13

20 May '13

Hi all, Please take a look at my changes for bug 7176220. The problem is that CMS sometimes misses datestamps for time trace printouts. The proposed fix is to move the datestamp print logic into the class that handles time trace printouts, GCTraceTime. This would make it consistent with timestamps, which are already printed from there. Bugs.sun: http://bugs.sun.com/view_bug.do?bug_id=7176220 JIRA: https://jbs.oracle.com/bugs/browse/JDK-7176220 Webrev: http://cr.openjdk.java.net/~aeriksso/7176220/webrev.00/ Testing: jprt, jtreg Thanks, Andreas

5 14

Re: User Controlled Memory Management (Object Lifetime Management) and Resource Management
by Suminda Dharmasena 20 May '13

20 May '13

Hi, We will need a few supporters and a spec before a prototype. Will you be willing to support drafting a speck and volunteer for developing the prototype? Suminda -- Suminda Sirinath Salpitikorala Dharmasena, B.Sc. Comp. & I.S. (Hon.) Lond., P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM, CEO Sakrīō! ▣ *Address*: 6G • 1st Lane • Pagoda Road • Nugegoda 10250 • Sri Lanka. ▣ *Mobile* : +94-(0)711007945 ▣ *Tele*: +94-(0)11-5 864614 / 5 875614 / 2 825908 ▣ *Web *: http://www.sakrio.com ▣ This email is subjected to the email Terms of Use and Disclaimer: http://www.sakrio.com/email-legal. Please read this first. -- On 20 May 2013 14:30, Clemens Eisserer <linuxhippy(a)gmail.com> wrote: > Time to start writing a prototype - looking forward to your implementation > :) > > Regards, Clemens > > 2013/5/20 Suminda Dharmasena <sirinath(a)sakrio.com>: > > Hi, > > > > I am looking to see if we can introduce user control for memory > management > > and more finer resource management ability through annotations and API. > > > > Part of the discussion on this is in the comment section of the following > > blog which I had with David Homes: > > https://blogs.oracle.com/dholmes/entry/minimize_garbage_generation > > > > Many Java objects can either be allocated on the stack as well as > deleted if > > allocated in the heap without it being passed for GC. Since stack > allocation > > will only work for some objects and will break the current memory model > an > > annotation can be introduced to mark stack allocation. Any contained > objects > > cannot outlive the containing object in this case unless they are > annotated > > to escape. Escaping objects can be heap allocated and collected through > the > > normal GC process. > > > > If an object is heap allocated it can be deleted at define points like > block > > exit, return or end of iteration (in loops) etc. Appropriate annotation > can > > be introduced to mark the deletion. In this case contained objects can > out > > live the containing object. The objects that cannot be deleted will be > > marked for GC during the normal GC cycle. Also an annotation can be > > introduced to help mark fields and methods which might escape and which > does > > not statically. For methods all parameters, local variables and returned > > objects will not escape thus can be deleted after method returns. For > > methods parameters, any objects passed will not escape and can be safely > > deleted after method returns. Not all parameters may be marked. For > fields, > > the objects can be deleted when the containing object is deleted. These > > objects if returned from a method will be clones and any pass to methods > > which are not marked for non escape would be clones else the compiler > should > > complain. For local variables, they can be deleted when method returns > or go > > out of scope. Also for return values an annotation to mark the return > value > > safe to delete after returning and to mark that fields and methods in a > > class do not escape. > > > > There can be finer grain of specification on what the type of > containment is > > and what the escape is. Traditionally this might be thread, stack, etc. > but > > in this case we are more concerned with containment within the containing > > object for field and containment when calling methods with regard to > > parameters, local variables and return types. > > > > In a nutshell we should be able to specify the lifetime of an object at > > point of declaration so it gets deleted when its usefulness is over. Only > > the occasional object that escapes this will need to be GCed. > > > > More fine grain resource management can be done through annotation like > > calling close() before trying to GC with appropriate annotations. > > > > Also appropriate API can be defined also to perform some of the memory > > management operations. > > > > For further examples of possible annotations see the discussion on: > > https://blogs.oracle.com/dholmes/entry/minimize_garbage_generation > > > > Also ability to turn off GC within a code block or function unless an > > outofmemory error happens. > > > > This would leave lesser workload for the GC system. Large part of memory > > management workload will be at know at appropriate point in code (if the > > programmer is disciplined). In GCing we do not know where the execution > is > > when GC happens. If this is in latency sensitive code block you are in > > trouble. This way the developer is in true partnership with the GC and > > memory management system. > > > > Suminda > > -- > > Suminda Sirinath Salpitikorala Dharmasena, B.Sc. Comp. & I.S. (Hon.) > Lond., > > P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM, CEO Sakrīō! ▣ Address: 6G • 1st > > Lane • Pagoda Road • Nugegoda 10250 • Sri Lanka. ▣ Mobile: > +94-(0)711007945 > > ▣ Tele: +94-(0)11-5 864614 / 5 875614 / 2 825908 ▣ Web: > > http://www.sakrio.com ▣ > > > > This email is subjected to the email Terms of Use and Disclaimer: > > http://www.sakrio.com/email-legal. Please read this first. > > -- >

1 0

User Controlled Memory Management (Object Lifetime Management) and Resource Management
by Suminda Dharmasena 20 May '13

20 May '13

Hi, I am looking to see if we can introduce user control for memory management and more finer resource management ability through annotations and API. Part of the discussion on this is in the comment section of the following blog which I had with David Homes: https://blogs.oracle.com/dholmes/entry/minimize_garbage_generation Many Java objects can either be allocated on the stack as well as deleted if allocated in the heap without it being passed for GC. Since stack allocation will only work for some objects and will break the current memory model an annotation can be introduced to mark stack allocation. Any contained objects cannot outlive the containing object in this case unless they are annotated to escape. Escaping objects can be heap allocated and collected through the normal GC process. If an object is heap allocated it can be deleted at define points like block exit, return or end of iteration (in loops) etc. Appropriate annotation can be introduced to mark the deletion. In this case contained objects can out live the containing object. The objects that cannot be deleted will be marked for GC during the normal GC cycle. Also an annotation can be introduced to help mark fields and methods which might escape and which does not statically. For methods all parameters, local variables and returned objects will not escape thus can be deleted after method returns. For methods parameters, any objects passed will not escape and can be safely deleted after method returns. Not all parameters may be marked. For fields, the objects can be deleted when the containing object is deleted. These objects if returned from a method will be clones and any pass to methods which are not marked for non escape would be clones else the compiler should complain. For local variables, they can be deleted when method returns or go out of scope. Also for return values an annotation to mark the return value safe to delete after returning and to mark that fields and methods in a class do not escape. There can be finer grain of specification on what the type of containment is and what the escape is. Traditionally this might be thread, stack, etc. but in this case we are more concerned with containment within the containing object for field and containment when calling methods with regard to parameters, local variables and return types. In a nutshell we should be able to specify the lifetime of an object at point of declaration so it gets deleted when its usefulness is over. Only the occasional object that escapes this will need to be GCed. More fine grain resource management can be done through annotation like calling close() before trying to GC with appropriate annotations. Also appropriate API can be defined also to perform some of the memory management operations. For further examples of possible annotations see the discussion on: https://blogs.oracle.com/dholmes/entry/minimize_garbage_generation Also ability to turn off GC within a code block or function unless an outofmemory error happens. This would leave lesser workload for the GC system. Large part of memory management workload will be at know at appropriate point in code (if the programmer is disciplined). In GCing we do not know where the execution is when GC happens. If this is in latency sensitive code block you are in trouble. This way the developer is in true partnership with the GC and memory management system. Suminda -- Suminda Sirinath Salpitikorala Dharmasena, B.Sc. Comp. & I.S. (Hon.) Lond., P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM, CEO Sakrīō! ▣ *Address*: 6G • 1st Lane • Pagoda Road • Nugegoda 10250 • Sri Lanka. ▣ *Mobile* : +94-(0)711007945 ▣ *Tele*: +94-(0)11-5 864614 / 5 875614 / 2 825908 ▣ *Web *: http://www.sakrio.com ▣ This email is subjected to the email Terms of Use and Disclaimer: http://www.sakrio.com/email-legal. Please read this first. --

1 0

hg: hsx/hotspot-gc/hotspot: 39 new changesets
by jesper.wilhelmsson＠oracle.com 19 May '13

19 May '13

Changeset: 712a1e9c91f3 Author: coleenp Date: 2013-05-07 09:46 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/712a1e9c91f3 8013063: nsk/jvmti/RetransformClasses/retransform001 failed debug version on os::free Summary: Clear out class_file_bytes so they aren't deallocated twice Reviewed-by: dcubed, sspitsyn ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4674e409a9e6 Author: coleenp Date: 2013-05-07 18:51 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4674e409a9e6 8014024: NPG: keep compiled ic methods from being deallocated in redefine classes Summary: Walk the compiledIC relocation records to keep Method* from being deallocated. Reviewed-by: dlong, kvn ! src/share/vm/code/nmethod.cpp Changeset: a1cc1d1e7ce5 Author: coleenp Date: 2013-05-07 16:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a1cc1d1e7ce5 Merge Changeset: 28ae1d38d296 Author: coleenp Date: 2013-05-07 18:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/28ae1d38d296 Merge Changeset: 64340da5b68c Author: hseigel Date: 2013-05-08 08:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/64340da5b68c 8007018: RFE: -XX:+UseLargePages does not work with CDS Summary: Remove command line restriction. It should just work. Reviewed-by: ctornqvi, coleenp, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: cbfe859bd244 Author: sla Date: 2013-05-08 15:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cbfe859bd244 8013591: compiler/ciReplay/TestSA.sh fails in nightly Reviewed-by: coleenp, rbackman, dholmes ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java Changeset: 0dc028fd5101 Author: sla Date: 2013-05-08 10:14 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0dc028fd5101 Merge Changeset: 39ead0411f07 Author: bharadwaj Date: 2013-05-08 14:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/39ead0411f07 8013875: Incorrect vtable index being set during methodHandle creation for static Summary: Set vtable index as appropriate for static interface methods and for interface methods invoked via invokespecial. To be improved in a later enhancement to CallInfo. Reviewed-by: jrose, twisti ! src/share/vm/prims/methodHandles.cpp Changeset: 711016f146fd Author: dholmes Date: 2013-05-08 19:28 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/711016f146fd 8006997: ContendedPaddingWidth should be range-checked Summary: Constrain between zero and 8K Reviewed-by: dholmes, rbackman Contributed-by: Aleksey Shipilev <aleksey.shipilev(a)oracle.com> ! src/share/vm/runtime/arguments.cpp Changeset: 9b77ca4ce35e Author: dholmes Date: 2013-05-08 19:38 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9b77ca4ce35e Merge ! src/share/vm/runtime/arguments.cpp Changeset: c272092594bd Author: dholmes Date: 2013-05-08 21:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c272092594bd Merge Changeset: 0b7f78069732 Author: rbackman Date: 2013-05-08 11:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0b7f78069732 8008255: jvmtiExport.cpp::post_to_env() does not check malloc() return Reviewed-by: coleenp, dholmes, sla ! src/share/vm/prims/jvmtiExport.cpp Changeset: 735c995bf1a1 Author: rbackman Date: 2013-05-13 07:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/735c995bf1a1 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 92ef81e2f571 Author: minqi Date: 2013-05-10 08:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/92ef81e2f571 8003557: NPG: Klass* const k should be const Klass* k. Summary: With NPG, const KlassOop klass which is in fact a definition converted to Klass* const, which is not the original intention. The right usage is converting them to const Klass*. Reviewed-by: coleenp, kvn Contributed-by: yumin.qi(a)oracle.com ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 1fcfc045b229 Author: minqi Date: 2013-05-10 19:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1fcfc045b229 Merge Changeset: 8b40495b9381 Author: minqi Date: 2013-05-13 18:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8b40495b9381 Merge ! src/share/vm/oops/method.hpp Changeset: 43083e670adf Author: coleenp Date: 2013-05-13 15:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/43083e670adf 8005056: NPG: Crash after redefining java.lang.Object Summary: Need to walk array class vtables replacing old methods too if j.l.o redefined Reviewed-by: sspitsyn, dcubed, ctornqvi ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp + test/runtime/RedefineObject/Agent.java + test/runtime/RedefineObject/TestRedefineObject.java ! test/testlibrary/ClassFileInstaller.java Changeset: a9270d9ecb13 Author: shade Date: 2013-05-14 11:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a9270d9ecb13 8014448: Purge PrintCompactFieldsSavings Summary: Remove obsolete debugging code. Reviewed-by: dholmes, kvn Contributed-by: Aleksey Shipilev <aleksey.shipilev(a)oracle.com> ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/globals.hpp Changeset: f944ba972151 Author: hseigel Date: 2013-05-14 09:17 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f944ba972151 8014138: Add VM option to facilitate the writing of CDS tests Summary: Added the -XX:SharedArchiveFile option. Reviewed-by: coleenp, ccheung, acorn, dcubed, zgu ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp + test/runtime/SharedArchiveFile/SharedArchiveFile.java Changeset: f9be75d21404 Author: minqi Date: 2013-05-14 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f9be75d21404 8012902: remove use of global operator new - take 2 Summary: The fix of 8010992, disable use of global operator new and new[] which caused failure on some tests. This takes two of the bugs also add ALLOW_OPERATOR_NEW_USAGE to prevent crash for third party code calling operator new of jvm on certain platforms. Reviewed-by: coleenp, dholmes, zgu Contributed-by: yumin.qi(a)oracle.com ! make/bsd/makefiles/fastdebug.make ! make/bsd/makefiles/vm.make ! src/os/windows/vm/os_windows.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/classfile/altHashing.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/memRegion.cpp ! src/share/vm/memory/memRegion.hpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/unhandledOops.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: 513a5298c1dd Author: minqi Date: 2013-05-14 17:33 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/513a5298c1dd Merge Changeset: 2958af1d8c5a Author: jwilhelm Date: 2013-05-17 06:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2958af1d8c5a Merge ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: d15464bfd4d0 Author: roland Date: 2013-05-03 09:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d15464bfd4d0 8012037: Test8009761.java "Failed: init recursive calls: 7224. After deopt 58824" Summary: test shouldn't be run with a modified CompileThreshold Reviewed-by: kvn ! test/compiler/8009761/Test8009761.java Changeset: e76dd894b984 Author: roland Date: 2013-04-24 14:26 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e76dd894b984 8012292: optimized build with GCC broken Summary: Some #ifndef PRODUCT should be #ifdef ASSERT Reviewed-by: kvn, twisti Contributed-by: gdub <duboscq(a)ssw.jku.at> ! make/jprt.properties ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/utilities/quickSort.cpp Changeset: d73c88e524ff Author: kvn Date: 2013-05-03 15:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d73c88e524ff Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: f0bc60565ba8 Author: twisti Date: 2013-05-06 13:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f0bc60565ba8 7196277: JSR 292: Two jck/runtime tests crash on java.lang.invoke.MethodHandle.invokeExact Reviewed-by: jrose, kvn ! src/share/vm/oops/method.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: aabf54ccedb1 Author: twisti Date: 2013-05-06 19:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/aabf54ccedb1 8008772: remove gamma launcher Reviewed-by: kvn, neliasso, ctornqvi ! make/Makefile ! make/bsd/makefiles/buildtree.make - make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make + make/hotspot.script ! make/linux/makefiles/buildtree.make - make/linux/makefiles/launcher.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make - make/solaris/makefiles/launcher.make ! make/solaris/makefiles/vm.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make - make/windows/makefiles/launcher.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/projectfiles/common/Makefile - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h Changeset: 6f3fd5150b67 Author: kvn Date: 2013-05-08 15:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6f3fd5150b67 6934604: enable parts of EliminateAutoBox by default Summary: Resurrected autobox elimination code and enabled part of it by default. Reviewed-by: roland, twisti ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/6934604/TestByteBoxing.java + test/compiler/6934604/TestDoubleBoxing.java + test/compiler/6934604/TestFloatBoxing.java + test/compiler/6934604/TestIntBoxing.java + test/compiler/6934604/TestLongBoxing.java + test/compiler/6934604/TestShortBoxing.java Changeset: 70120f47d403 Author: kvn Date: 2013-05-09 17:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/70120f47d403 8014189: JVM crash with SEGV in ConnectionGraph::record_for_escape_analysis() Summary: Add NULL checks and asserts for Type::make_ptr() returned value. Reviewed-by: twisti ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/subnode.cpp Changeset: 8bcfd9ce2c6b Author: twisti Date: 2013-05-13 12:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8bcfd9ce2c6b Merge - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 1da5d70655e9 Author: kvn Date: 2013-05-13 14:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1da5d70655e9 8014286: failed java/lang/Math/DivModTests.java after 6934604 changes Summary: Corrected escape state for the result of boxing method. Added force inlining executed boxing methods. Reviewed-by: twisti ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/escape.cpp Changeset: cd6f6fccd287 Author: iignatyev Date: 2013-05-15 22:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cd6f6fccd287 8014068: TEST_BUG: compiler/ciReplay/TestSA.sh fails on Windows: core wasn't generated Reviewed-by: kvn ! test/compiler/ciReplay/TestSA.sh ! test/compiler/ciReplay/common.sh Changeset: e484fe2abebd Author: twisti Date: 2013-05-16 13:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e484fe2abebd Merge - make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/quickSort.cpp Changeset: 2f9ac66165e6 Author: jwilhelm Date: 2013-05-17 08:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2f9ac66165e6 Merge - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 1cdbd42c3e49 Author: katleman Date: 2013-05-16 12:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1cdbd42c3e49 Added tag jdk8-b90 for changeset 1ae0472ff3a0 ! .hgtags Changeset: b19517cecc2e Author: amurillo Date: 2013-05-17 08:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b19517cecc2e Merge - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp Changeset: 7cbdf0e3725c Author: amurillo Date: 2013-05-17 08:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7cbdf0e3725c Added tag hs25-b33 for changeset b19517cecc2e ! .hgtags Changeset: 7ec426e29e4c Author: amurillo Date: 2013-05-17 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7ec426e29e4c 8014760: new hotspot build - hs25-b34 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 2138a2c14831 Author: jwilhelm Date: 2013-05-19 20:31 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2138a2c14831 Merge ! src/share/vm/gc_implementation/shared/markSweep.cpp

1 0

A guarantee failure with CMSClassUnloadingMaxInterval
by Hiroshi Yamauchi 17 May '13

17 May '13

Hi, I'm getting the following JVM crash (a guarantee failure) with flag -XX:CMSClassUnloadingMaxInterval=N (where N > 0) somewhat intermittently. I have a theory of why it's crashing. It'd be great if someone can indicate whether I'm looking at this right. Here goes: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (dictionary.cpp:267), pid=30153, tid=1325398848 # guarantee(!is_alive->do_object_b(k_def_class_loader)) failed: defining loader should not be live if klass is not # # JRE version: 7.0_17-b02 # Java VM: Java HotSpot(TM) Server VM (23.7-b01 mixed mode linux-x86 ) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x4eeb9400): VMThread [stack: 0x4ef7f000,0x4f000000] [id=30176] Stack: [0x4ef7f000,0x4f000000], sp=0x4effe7c0, free space=509k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x720449] VMError::report_and_die()+0x199 V [libjvm.so+0x2e8829] report_vm_error(char const*, int, char const*, char const*)+0x49 V [libjvm.so+0x33b08f] Dictionary::do_unloading(BoolObjectClosure*)+0x8ef V [libjvm.so+0x6aeec5] SystemDictionary::do_unloading(BoolObjectClosure*)+0x25 V [libjvm.so+0x39f741] GenMarkSweep::mark_sweep_phase1(int, bool)+0xd1 V [libjvm.so+0x39fce5] GenMarkSweep::invoke_at_safepoint(int, ReferenceProcessor*, bool)+0x105 V [libjvm.so+0x2d3b62] CMSCollector::do_compaction_work(bool)+0x142 V [libjvm.so+0x2d4d4e] CMSCollector::acquire_control_and_collect(bool, bool)+0x19e V [libjvm.so+0x2d5226] ConcurrentMarkSweepGeneration::collect(bool, bool, unsigned int, bool)+0xe6 V [libjvm.so+0x39e805] GenCollectedHeap::do_collection(bool, bool, unsigned int, bool, int)+0x4a5 V [libjvm.so+0x28f4c7] GenCollectorPolicy::satisfy_failed_allocation(unsigned int, bool)+0xe7 V [libjvm.so+0x7215f4] VM_GenCollectForAllocation::doit()+0x74 V [libjvm.so+0x72ae61] VM_Operation::evaluate()+0x41 V [libjvm.so+0x729748] VMThread::evaluate_operation(VM_Operation*)+0x78 V [libjvm.so+0x729cd8] VMThread::loop()+0x1e8 V [libjvm.so+0x72a375] VMThread::run()+0x85 V [libjvm.so+0x5df1f1] java_start(Thread*)+0x111 C [libpthread.so.0+0x6d4c] start_thread+0xcc VM_Operation (0x4cd8d6b8): GenCollectForAllocation, mode: safepoint, requested by thread 0x4cc38c00 Background: Enabled with CMSClassUnloadingEnabled, this flag should cause the class unloading to invoke less frequently, namely, at every N+1 concurrent collections, as opposed to at every concurrent collection. Here's what I thought: Here's the failing guarantee (in Dictionary::do_unloading() in dictionary.cpp, around line 262 in http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/f8075a623349/src/share/…) // The loader in this entry is alive. If the klass is dead, // the loader must be an initiating loader (rather than the // defining loader). Remove this entry. if (!is_alive->do_object_b(e)) { guarantee(!is_alive->do_object_b(k_def_class_loader), "defining loader should not be live if klass is not"); // If we get here, the class_loader must not be the defining // loader, it must be an initiating one. assert(k_def_class_loader != class_loader, "cannot have live defining loader and unreachable klass"); It seems that at the time of the crash, e is not alive but k_def_class_loader is alive (hence the guarantee failure) and the debugger indicates that k_def_class_loader == class_loader (which would mean that the following assert would also fail.) I'm not sure what this really means (I'm not class (un)loading expert), but it appears that there's a certain class (un)loading invariant that broke due to CMSClassUnloadingMaxInterval. Here's a theory of what I think might be happening: In the CMS initialization sequence, the root scanning option is set statically (once per JVM invocation) to either SO_AllClasses or SO_SystemClasses based on the flag value of CMSClassUnloadingEnabled (at line 810 in http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/f8075a623349/src/share/…) // Choose what strong roots should be scanned depending on verification options // and perm gen collection mode. if (!CMSClassUnloadingEnabled) { // If class unloading is disabled we want to include all classes into the root set. add_root_scanning_option(SharedHeap:: SO_AllClasses); } else { add_root_scanning_option(SharedHeap::SO_SystemClasses); } This code appears to assume that this choice solely depends on the value of flag CMSClassUnloadingEnabled. Then, at the beginning of each concurrent collection invocation, the following code decides whether to perform class unloading with this code (at line 3223 in http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/f8075a623349/src/share/…) bool CMSCollector::update_should_unload_classes() { _should_unload_classes = false; // Condition 1 above if (_full_gc_requested && ExplicitGCInvokesConcurrentAndUnloadsClasses) { _should_unload_classes = true; } else if (CMSClassUnloadingEnabled) { // Condition 2.a above // Disjuncts 2.b.(i,ii,iii) above _should_unload_classes = (concurrent_cycles_since_last_unload() >= CMSClassUnloadingMaxInterval) || _permGen->should_concurrent_collect() || _cmsGen->is_too_full(); } return _should_unload_classes; } If CMSClassUnloadingMaxInterval is 0 (which is the default case), then if CMSClassUnloadingEnabled is true, _should_unload_classes will be always true (that is, class unloading will be performed in every concurrent collection run) as concurrent_cycles_since_last_unload() would always return 0. But, if CMSClassUnloadingMaxInterval > 0, _should_unload_classes won't be always true (and we won't perform class unloading in every concurrent collection run) even if CMSClassUnloadingEnabled is true. Is it possible it should pick SO_AllClasses or SO_SystemClasses based on the result of the update_should_unload_classes() call at every concurrent collection, as opposed to solely based on the value of the CMSClassUnloadingEnabled flag once at initialization? For an experiment, If I insert this code: remove_root_scanning_option(SharedHeap::SO_SystemClasses | SharedHeap::SO_AllClasses); if (should_unload_classes()) { add_root_scanning_option(SharedHeap::SO_SystemClasses); } else { add_root_scanning_option(SharedHeap::SO_AllClasses); } in CMSCollector::setup_cms_unloading_and_verification_state(), around line 3254 in http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/f8075a623349/src/share/…, then the crash appears to fail to recur. I don't know if this does the right thing or just is masking the bug. I could reproduce this crash with JDK 7u17. I could not with a JDK8 probably because the failing guarantee line was removed in JDK8 (around line 168 in http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/1ae0472ff3a0/src/share/vm….) I'm not sure what the removal of the guarantee meant as it was part of what looks like a perm gen removal change. Anyhow, it'd nice to be able to use CMSClassUnloadingMaxInterval. Thanks, Hiroshi

4 9

Request for review: 7186737: Unable to allocate bit map for parallel garbage collection for the requested heap
by Tao Mao 17 May '13

17 May '13

Hi all, Can I have one or two quick reviews? Thank you. Tao 7186737: Unable to allocate bit map for parallel garbage collection for the requested heap http://bugs.sun.com/view_bug.do?bug_id=7186737 webrev: http://cr.openjdk.java.net/~tamao/7186737/webrev.00/ changeset: Print out how many bytes we try to allocate when the allocation fails. This would give us a better idea of memory bottleneck. test: will run JPRT sanity for pushing.

3 6

hg: hsx/hotspot-gc/hotspot: 8014277: Remove ObjectClosure as base class for BoolObjectClosure
by erik.helin＠oracle.com 17 May '13

17 May '13

Changeset: 001ec9515f84 Author: ehelin Date: 2013-05-17 11:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/001ec9515f84 8014277: Remove ObjectClosure as base class for BoolObjectClosure Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/runtime/jniHandles.cpp

1 0